David's work changed or rather legitimized my already formed point of view of work and contexts, and of thought. If you ever wondered if some project or plan just didn't make any sense? Or you were left with a "just get it done" command, or no one in a leadership role could provide the real "why"?
You are not alone.
As it turns out, there are different ways to solve problems or create value and they are closely coupled to the situation at hand. Learn more about David's great framework here in these links.
I always start any engagement with a level set on situational "problem solving".
Otherwise, we might end up "doing the wrong things righter".
How to organize a children's party
HBR article, Snowden and Boone - "A Leader's Framework for Decision Making"
Every organization, apparatus, or collective is a "system" & it is bounded by constraints.
Constraints can be enabling or disabling.
Technology has been creating enabling constraints for decades, BUT, it's absorption by legacy enterprises has always lead to the insertion of many common disabling constraints.
The result is a common plight for both the IT practitioner and their business counterparts.
We feel like things "used" to work. We where lead to believe IT is a commodity with little to no distinction.
A disabling constraint is anything that limits or halts the generation of value from the use or change of a technology. Lack of adequate resourcing or funding, or ceremonial portfolio rationalization of individual projects are such constraints - as they "delay" and "confound" value generation.
Worse yet - the system's use of IT to deliver value is inherently invisible. Its not a software factory at all. So, we use the closest forms of thinking we could and we default to the classic MBA/Cost Accounting model of IT where any and all technology is commodity.
This is a lot to take in, but please understand that true visibility and true prioritization of change that eliminates impediments to economic flow and value derived from IT usage is only real way to thrive or survive. Broad "hot-topic" transformations that are in vogue or bench-marked as a must-do are very dangerous if not anchored to a real business outcome like sales or profit.
The body of work known as the "Theory of Constraints" by Dr Goldratt illuminates the data-centric and scientific method he built making clarity out of chaos.
To learn more about a TOC centric improvement take a look at Goldratt Consulting.
Dr . Ajai Kapoor is a great resource.
TOC was referenced heavily in the "Phoenix Project" and underpins works in Agile.
We spoke so far of situational thought (Cynefin), Theory of Constraints in systems, and now, systems themselves. What is a system ? What is systems thinking ?
Systems can be, anything then ? Yes.
They are, but we only get to see and change them through our mental models, which are informed by our senses.
These mental models describe real systems, but the structures and apparatus of "tech-based" economic systems are invisible, compared to a car factory.
Who literally "see's" the generation of money out of a computer ?
No one. (If you do - please call me ! )
I am not talking about crypto-currency. That's a semantic mashup of economic value and IT.
Rather, I'm talking about the economic value generated by and for all parties when you use a web site instead of mailing in a letter, as an example.
But, what is Systems Thinking ? Here is a great explanation, non-technical, by our own CDC in the US. -
For more reading.
Author Peter Senge - How the learning organization operates in selective systems.
Now that we know systems have characteristics and we comprehend them as mental models, let's see a great example of counter intuitive improvements and how we must examine each one after the other, not all at once (too much change).
I like to consider the notion of Flow as the literal creation of and flowing of economic value to its recipients.
Some speak of the Flow of "work". But, how do we know we are "working" on the right things to optimize the economic value of technology (IT) for our company or purpose?
Theory of Constraints tells us that to change a system for the better, we must know what to change, why, and only change that one thing, and then observe.
Consider then the visual of flowing water being economic value. Or maybe its quality of life measured in a periodic survey, or as seen by an NGO's observations.
Managing a bottleneck.
Yes, it's a literal Bottleneck. What was striking about this visual representation?
- Turbulence and noise seem to be associated with lower flow
- Calmness and speed seem to be associated with higher flow
- What we didn't see, adding another bottleneck in parallel (doesn't solve the problem)
- Application of real-world cause and effect through direct observation. No benchmarking or best practice here.
Ever heard of Conway's law?
Why do sub-optimal systems exist or why do we create or leave them that way?
In 1968 a wide area network engineer named Melvin Conway observed that organizations tended to build systems (applications) whose interactions were modeled after the interactions (communications) inside the system (organization) who built the system (application).
Although it's more of an observation, it turns out to be pretty darn inescapable too, like gravity.
He first published this observation in Datamation, http://bit.ly/2BwskDQ, in 1968 under the title "How Do Committees Invent".
Conway's law is homomorphic http://bit.ly/2URB0f9 and commutative http://bit.ly/2tf7pAA. (thanks Jabe!) Just as their algebraic origins indicate Conway's law tells us that the central organizing theme of a system e.g. a company will find its way into the system e.g. application/product that is created.
Think of the amount of duplication and overlap we see in a typical enterprise. It's not, as we were told to think, that we had sloppy project planning, portfolio management, or leadership. It's that we had a cost center (IT) taking in many siloed requests from business P&L owners. So we end up with mini-versions of what could have been enterprise solutions.
Commutative also means this works in reverse. An existing application will cause a supporting organization to emerge to service the application.
In other words - no round pegs in square holes, please.
Now what? Well, the first stage of moving ahead is accepting the truth in some things. Conway's law tells us we must use the structure and models we have as constraints and we must do things to change that do not depend on those constraints changing. Cynefin tells us that this initiative is highly "Complex", not "Obvious". This means if you plan to change the business - IT model, don't start with best practices and process checklists.
You better start with:
- Reconnecting with how IT drives economic value
- Small batch changes
- Visible outcomes to a customer or stock market
- Small teams who self organize around an ideal "architecture" and prove through repeated "demos" that they are operating in accordance with the desired architecture.
Think about it, if we didn't have disruption-renewal market systems that allow providers like AWS to emerge, would we ever have had ubiquitous cloud services which now represent near 60% of IT spend and growing. No, we would not have. It's only because of two forces, Moore's law which pushes technology disruption into new markets and uses, and our public markets which hold the threat of renewal through adoption or destruction to get to a new homeostasis.
This is heavy stuff. So what new hidden structures in the world of Agile and DevOps might be limiting us?
This is why techniques like Agile were so effective. They "hacked" the invisible map between organization and technology and created a new law (or force) which was greater than Conway's. I call this the "Shiny Object Law of Attraction".
There is a "hack" to get out of Melvin's observation - don't use the current IT-Business conjoined system to arrive at a goal that is incompatible with the current IT-Business conjoined system. ( Channeling Einstien)
As it turns out Conway's law, as inescapable as it may be, doesn't extend beyond the system in which it has influence and residence. So, by making new organizations that aren't modeled on current ones (Agile Teams instead of departments and hand-offs) we create new systems, bounded by a negotiated context.
And by using a component of a more attractive system e.g. AWS instead of local hardware, we can cause the business-IT marriage to change.
After decades of observation and organizational consulting, here are Larman's Laws of Organizational Behavior. These are observations rather than laws to follow ;)
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level managers and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as the status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. As a corollary to (1), if after changing the change some managers and single-specialists are still displaced, they become “coaches/trainers” for the change, frequently reinforcing (2) and (3).
5. Culture follows structure.
Elaboration on law 5: A longer form is, In big established groups, culture/behavior/mindset follows changes in the organizational system and design. That is, if you want to really change a culture, you have to start with changing the organizational system (groups, teams, roles and responsibilities, hierarchies, career paths, policies, measurement and reward mechanisms, etc), because culture does not really change otherwise. Said another way, the organizational system is strongly influential on mindset and behavior.
The systems-thinking advocate John Seddon also observed this: "Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes."
This is an observation in big established organizations; in contrast, in small startups, it's the reverse: structure follows culture. That is, the (probably simple and informal) organizational design reflects the mindset and culture of the small number of members in the startup. As the organization grows, at some point it usually reverses to culture follows structure.
And "culture follows structure" (in large groups) is why purely “mindset” approaches such as organizational learning are not very sticky or impactful by themselves in large groups, and why frameworks such as Scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture — if the structural change implications of Scrum are actually realized.
So what your saying is....
How many times have you brought in a change initiative for consideration and been told "we don't want to be religious about it".
Well, that is one of the problems.
You can't get to an improved state by "sort of" doing it. Mitigate risk and rejection by testing it among the willing first, then scale it. Don't "download" the change right into your organization. Get them onboard.
The state of Utah has had some real promising success over the past 8 years or so using Theory of Constraints and problem solving through Systems Thinking to re-imagine state health services for its citizens in need, reducing time and enlarging access for mental health and other services.
PDCA - Plan, Do, Change, Act
OODA - Observe, Orient, Decide, Act
Ever since being introduced to Wardley Maps in 2012, I have not produced another IT Strategy Deck or Roadmap, yet I have changed the tech/business strategy of one of the world's largest, oldest, and most regulated companies. How? Because Wardley mapping, although a substitute for conventional IT roadmaps, is more of a damnation of previous conventions, than a new convention.
So, be careful here. You have to understand you may just be the next Galileo https://en.wikipedia.org/wiki/Galileo_Galilei but if you recall when he first promoted and evolved Heliocentric thinking https://en.wikipedia.org/wiki/Heliocentrism (the Sun was the center of our system, not the Earth) he was in big trouble.
Have you felt you wrote documents, attended meetings, made presentations which all had the appearance of urgency and importance, and long term strategy, only to realize your well researched, cogent, and an articulate case made NO (ok a little) impact. In fact, if you as an IT Architect MADE an impact on the business, you likely had a great sponsor.
Well, you are not alone here as well.
As architects, we are used to drawing what we call "design" documents or specs. We are also used to creating roadmap or planning documents.
These each convey a sense of place and time and for the audience of architects and engineers, they made sense. One could present and argue the importance and urgency of a business-IT effort, and one could exchange and swap out items to get a portfolio result which was greater than the sum of the parts. A good outcome!
Although we make/change these documents transactionally or periodically - the roadmaps or stage gates really don't change what's being done, and we, as architects, feel we are wasting our time. Well - we may be.
Maybe we need to be renamed Sherpa. And, maybe we need to be valued for what we do and can do.
Please read the section on Cynefin soon, before you get too anxious.
A "recovering management consultant" as he calls himself, Simon Wardley came up with a mapping technique, a visual method for getting through the layer of permafrost between IT and business. His method bridges the gap of IT-Business alignment, and also implicates tech and consulting vendors as complicit agents in the "Matrix".
Maybe I will refer to myself as a recovering CTO or EA?
Simon was part of the LEF (leading-edge forum) https://www.wardleymaps.com/
He's great in person and I highly recommend finding him at a conference.
This video he often does best conveys the "why" of Wardley maps.
Video: Start here https://www.youtube.com/watch?v=Ty6pOVEc3bA&t=316s If you can spare 5 minutes start at 4:05. But really - just start at 0:00.
AND if you dare...
Then, "Crossing the river by feeling the stones" https://www.youtube.com/watch?v=oZZKjxeg5W0
Steve Bungay - "The Art of Action"
General McChrystal - "Team of Teams"
The A3 report was a problem-solving method developed at Toyota and helped them enable "50%+" problem solving for all employees. When we look at an example it seems like a simple template for proposing a problem, its current condition, supporting data, and proposed experiments, all to be presented to a team and a leader. But what made it valuable, is in its simplicity. The A3 report had to (think enabling constraint here) fit literally in a piece of A3 paper. A3 is sized 11.7" by 16.5". The words and data required had to fit into this form.
One of the WORST things I've seen done is converting it into a word or PowerPoint template, which 1) removed the kinesthetic effect of writing a sentence etc and 2) allowed teams and writers to "expand" the field length of the template(d) sections of the A3. It would be like adding infinite message length to Twitter. Then you would not have Twitter, you would have a blog.
Some of his recurring thoughts and themes. Please visit his Wikipedia section for more. Please note the commonality with systems thinking, TOC, and Complexity Science, particularly in knowledge work.
Decentralization and simplification. Drucker discounted the command and control model and asserted that companies work best when they are decentralized. According to Drucker, corporations tend to produce too many products, hire employees they don't need (when a better solution would be outsourcing), and expand into economic sectors that they should avoid.
MJL: Note the connection to Simon Wardley's views on mapping to drive shifts to commodity.
The concept of "knowledge worker" in his 1959 book The Landmarks of Tomorrow. Since then, knowledge-based work has become increasingly important in businesses worldwide. In 1999, Drucker wrote "we know how to increase the productivity of the knowledge work, and we know these methods are totally different from manual workers."
MJL: Think for a moment. If even as far back as the 80's and 90's academics and great minds knew that knowledge work and technical work, particularly if combined, could be made more productive, but not through the means applied to simple labor such as utilization rates etc.
A lament that the sole focus of microeconomics is price , citing its lack of showing what products actually do for us,thereby stimulating commercial interest in discovering how to calculate what products actually do for us, from their price.
A belief in what he called "the sickness of government." Drucker made nonpartisan claims that government is often unable or unwilling to provide new services that people need and/or want, though he believed that this condition is not intrinsic to the form of government. The chapter "The Sickness of Government" in his book The Age of Discontinuity formed the basis of New Public Management, a theory of public administration that dominated the discipline in the 1980s and 1990s.
The need for "planned abandonment." Businesses and governments have a natural human tendency to cling to "yesterday's successes" rather than seeing when they are no longer useful.
The need for community. Early in his career, Drucker predicted the "end of economic man" and advocated the creation of a "plant community" where an individual's social needs could be met. He later acknowledged that the plant community never materialized, and by the 1980s, suggested that volunteering in the nonprofit sector was the key to fostering a healthy society where people found a sense of belonging and civic pride.
MJL: Ive often noted that even in large enterprises which may have the dissonance of managing the knowledge worker as if they where a laborer, the community effect which arose in shared buildings and plants often acted as a superior counter-action to misaligned objectives. Take-away - being close physically improves the actual alignment to the purpose of a company more so than prescriptive directions and yearly G&Os. Agile and Devops thrive because of this.
The need to manage business by balancing a variety of needs and goals, rather than subordinating an institution to a single value. This concept of management by objectives and self-control forms the keynote of his 1954 landmark The Practice of Management.
A company's primary responsibility is to serve its customers. Profit is not the primary goal, but rather an essential condition for the company's continued existence and sustainability.
"Do what you do best and outsource the rest" is a business tagline first "coined and developed" in the 1990s by Drucker. The slogan was primarily used to advocate outsourcing as a viable business strategy.
A great HBR article written in 1963 on his early sensing of the knowledge work and their different means of value creation compared with the laborer of the Taylor model..
How to apply these VALUABLE bits of advice while imagining and building/installing a new way.
Here are some ways to decode the rubric of the Doctrine Table
How we communicate:
How we communicate:
Operating a function – consider how we operate Architecture:
Moore's Law. Description Courtesy
Diagram courtesy Creative Commons Share Alike 4.0.
The observation is named after Gordon Moore, the co-founder of Fairchild Semiconductor and CEO of Intel, whose 1965 paper described a doubling every year in the number of components per integrated circuit, and projected this rate of growth would continue for at least another decade.
In 1975, looking forward to the next decade, he revised the forecast to doubling every two years. The period is often quoted as 18 months because of a prediction by Intel executive David House (being a combination of the effect of more transistors and the transistors being faster).
Scanning probe microscopy image of graphene in its hexagonal lattice structure.
In 2016 the International Technology Roadmap for Semiconductors, after using Moore's Law to drive the industry since 1998, produced its final roadmap. It no longer centered its research and development plan on Moore's law. Instead, it outlined what might be called the More than Moore strategy in which the needs of applications drive chip development, rather than a focus on semiconductor scaling. Application drivers range from smartphones to AI to data centers.
Diagram: Mark Landy
If compute power has been increasing by double every 2 to 3 years, and advances in chip fabrication have shifted to new materials and methods, the increases keep coming.
So what ?
The effect is profound and, a theme you will see here again and again, the effect is invisible.
Wikipedia contributors. (2019, March 7). Moore's law. In Wikipedia, The Free Encyclopedia. Retrieved 12:48, March 8, 2019, from https://en.wikipedia.org/w/index.php?title=Moore%27s_law&oldid=886664781
A method of creating ratios which measures the actual output created in consideration for a ratio of allocation as opposed to pure cost. Cost accounting uses the cost allocated to determine OE (operating efficiency). The assumption being that the more utilized an asset (man or machine) is the more efficient the system is. This makes sense until you realize two things, well really three, no four.
1 Men & machines which are not used are still costing you money. This is not directly billable to product creation taken from the Taylor-ist definition of work breakdown, so its considered overhead or waste. This thinking promotes the notion that waste is bad, therefore you must occupy it.
2 Men (e.g. human being), I used Men because that's the wording in Taylor's work "The Scientific Theory of Management", 1911, men are not machines. We, us humans, are assets and we contribute to "production" in terms of value generated from the use of emergent or stable technology while we are sleeping, driving, eating etc. We have "ideas" which when we join the team during the work day - we share and exploit. You don't really work for an hourly rate as a knowledge worker.
3 It's all invisible. For technology which generates value through its use, improving the effect of the knowledge worker, or the customer who needs a service, we can't see the means of production in front of us. So we go to what we next see as a boundary or need to satisfy which is very often the allocation of scarce resources e.g. money. So the thing that drives the utilization scrutiny is literally the assumed notion of Cost Accounting and efficiency, purely and only, in the absence of any notion of throughput or value. I'm sure if I looked hard enough I might find a term called "Value Accounting". Maybe its called earnings per share ? Maybe that should be the measure.
4 Its "Complex" which means its emergent and co-adaptive. You cannot go to a small room for 6 months and emerge with the answer. You must iterate in small, tight loops executing on the current near term backlog or experiment, while targeting the systems oriented final state. You are said to be directionally correct at this point.
Great talk at the Theory of Constraints Practitioner's Conference in 2017.
And an excellent text on the topic by David Anderson going back to 2003.
And to see that asymmetric bets on disruptive tech are becoming more the main-stay of value creation, as opposed to highly instrumented and controlled project plans, refer to this article written by Tom Demarco. Please ensure you can view articles from computer.org via the IEEE.
Conventional financial models imply every "resource" should be near full utilization because cost is the only measure that locally bubbles to the top. In the absence of other frameworks, get every unit of use from every unit of cost.
Work being done through the system. We need to look at value delivered, not just work completed. Throughput Accounting moves us in the value view.
Its a slow walk. Pick one team, one type of work to be done.
The important thing is that this little exercise and knowledge will show up and unveil how good or bad the humans can regulate and deliver the flow of value from technology.
Total time for a service or request is the sum of the service times of each worker, plus their wait times.
Practical advise here would be to get data about the work and service times of interest. In the absence of service or delivery data, mood substitutes. A good mood or how a team feels is a leading indicator of ability to serve well. Likewise poor mood portrays high queue depths and variability.
As utilization of a "server" or "human" approaches 90% to 100%, wait time becomes an order of magnitude of service time.
This ratio is sort of straight line simplification for those of you who do know Markov chains. But it does show up in the numbers for knowledge works particularly those responding to tickets, but does show up in project based work as well.
At 90% utilization, a common goal for worker active modes excluding breaks, training, days out, the knowledge worker (think IT worker) will have 10X more total time for each step in delivery done sequentially.
Considering technology and its associated knowledge workers as productive units is a natural outcome of cost based accounting and Tayloristic work decomposition of manual labor.
But, value is created by flow and collaboration "through" a technology enabling system of people.
These value chains require slack (50% at least) and time to recover and allow for emergence and thought.
This sets up a "Moral Hazard" for the technology folks who should enable the most value for the company over time, yet may be forced into cost reduction efforts targeting utilization.
Just think - sometimes we pay for "availability" and that's good too
A great animated clip which explains virtualization, in the greater context of ephemeralization, connected to the development of society.
Doing more with less, in a continuously increasing ratio, almost infinite.
https://www.youtube.com/watch?v=X8lqnO7aYe0 At 6:11 his notion of an unlimited ratio of doing infinitely more with infinitely less is well said. How does this make sense to you when considering technology and its value.
Consider that, again, the value is often unseen as is the mechanism of its generation.
About Buckminster - https://www.bfi.org/about-fuller
Societal (system) change in understanding, even though rooted in correspondence truth, will not happen over night.
So, you have discovered a new truth and finding it difficult to get your colleagues or customers or leaders to accept it, debate it, or just listen to you.
When introducing a change to a human-system or a culture, of which your change may threaten the status-quo, being oblique, and being a mentor, coach, leader or enabler of the "why", is preferred than arguing the hard facts.
Be empathetic. What if roles where reversed.
Visualize your work.
Understand the relationship between WIP and throughput.
A novel about flow in IT for a business, synthesized from nearly 1,500 company profiles. Eerily familiar scenarios to the IT practitioner.
On the Learning Organization - Its what we now call LEAN.
Want to see if we have been there before.
Want to see how structure can change for the better.
Want to see how people are usually considered the "issue", but its really the invisible "structure" that guides their behavior.
John Shook describes a wonderful real experience he was engaged in.
Credit to Lean WX 2015 - Will Evans for hosting this.
https://vimeo.com/128205865 View all of it but at least 27 minutes forward. At 40 minutes the "light bulb" moment for me was the notion of the moral dilemma. IT workers, particularly the Architect - almost always have the "moral dilemma".
See also Failure Demand v.s. Value Demand. https://www.callcentrehelper.com/failure-demand-a-technique-to-reduce-cost-and-improve-the-customer-experience-91527.htm
First manufacturer who used interchangeable standardized parts.
Solving a problem first when seen, and then moving on.
Knowing what the job to do is.
How do we do and improve the work.
How does the management system define behaviors which optimize the goal.
Donald G. Reinertsen - http://blackswanfarming.com/product-development-payoff-asymmetry/ and " The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. "
Tom Demarco - Famously stated if you can't measure a project you can't control it. Well, he took that back in regards to today's IT.
Why do we call it Project Portfolio Management ? Ever try to remove a project ? Its more like a shipping manifest of preset answers. Why don't we use a list of problems to solve ?
In the meantime - how about a simple but powerful consideration for prioritizing scarce resources and scarcer change capacity ? Its called the Cost of Delay "COD".
Empathy Mapping under construction
Paying it forward... I have learned a lot from Jeff over the many years and projects we worked on together.
Agile thought leader. Chapter 6 Jeff Sutherland's "The Art of Doing Twice the Work in Half the Time" highlights of a business transformation at Medco Health. Read more...
His company https://www.scruminc.com/
A paper to consider the possible long-term impact of rapid technological progress – and in particular of work automation and artificial intelligence. http://bit.ly/2WZvKYC
Otherwise known as the "Solow" paradox. Attributed to Prof Robert Solow, in 1987 who said "You can see the computer age everywhere, but in the productivity statistics" A recent position at Stanford.
Don't think this is just about Millennials.
Simon once again zooms right into structural and system characteristics that conspire to weaken our humanity and rob us of our life's pursuit of joy.
Coaching a team ? Figuring out the issues are really structural and not in their ability to control ? Maybe no sponsor ?
Placeholder for Obliquity
More to come