"Lippitt-Knoster" is one of those things where if you've worked with me during the last 10 years, you've likely heard me mention it. You might even be reading this because I needed somewhere to point you. In which case, Hi! đ
The Lippitt-Knoster Model for Managing Complex Change was originally written to describe a way of navigating large organizational shifts, but Iâve found that itâs also useful as a diagnosis tool for any kind of large and long-running project. After all, every project is a "change" in a microcosm. You might not have a complex organizational change to manage every day, but everyone is involved in long-running projects of some size and shape in a company. So thatâs what I use it for, and it is useful indeed.
The beauty of the model is that you donât need an MBA or a special issue of the Harvard Business Review to explain it. It says that any complex project requires six components to succeed, and if one or another is missing, youâll have some specific and corresponding failure.
It can be summed up in a simple chart but also rewards you with some deeper insights as you apply it:
- Vision is the purpose and endpoint of a project. Vision tells you where youâre going and why. If the vision is missing, there will be confusion about what is being done and why work is happening.
- Consensus is a team's agreement and alignment around the vision. If a team lacks consensus, people will not want to do the thing and they will sabotage you.
- Incentives are the motivation or reasons for why people support the work and prioritize it appropriately. If not everyone is incentivized properly, there will be resistance. Resistance is the passive sibling of sabotage.
- The Action Plan is the practical set of steps to get from vision to finish. If you lack an action plan, your team will experience a routine set of false starts and treadmills, which is another way of saying that it will look like work is happening but nothing actually moves forward. You wonât make progress.
- Resources are the organizational capacity (people, budget, time) needed to accomplish the work. Lacking resources is a close cousin to lacking skills; it leads to frustration in trying to do something you know you're capable of, but with an unrealistic set of operating constraints.
- Skills are the ability to do the work necessary to complete the project. If a team lacks the necessary skills, you'll have a lot of questions around if this work is possible, leading to anxiety.
Vision, consensus, and incentives are all Strategic Concerns. They involve abstract political work: ideas, relationships, people, and an understanding of the business. The action plan, skills, and resources are all Tactical Concerns. They are focused on the practical details of âhowâ something gets done.1
One mistake I often see people make is to focus primarily on one concern or the other. For example, a product manager or corporate strategist might spend too much time focused on the strategic side of things without understanding if the team or company is able to execute. Consequently, their ability to build consensus will be negatively impacted by not knowing what is possible or probable. Line managers and software engineers typically make the opposite mistake. They focus too much on the âhowâ instead of the âwhyâ. Theyâll prove that something is possible and how it can be done, without realizing that sometimes the team or business doesn't want to do the thing theyâre proposing. Neither myopia ends in a successful project.
The order of the model components matters â they flow into each other â but can be managed in either direction. For example: you might start with a vision, build consensus, arrange the right incentives for everyone to act, create a plan, provide adequate resources and timeline to accomplish that plan, and make sure it is staffed with people who have the skills to execute on it. Easy peasy!
You could also navigate the components the other way, working through a series of questions: is something possible? Do skills exist to accomplish the thing? Do those skills (people) have excess capacity that can be allocated to this idea? Can it be done without budget? Can that group of people be small enough that they organically develop their own plans? And if so, are they incentivized to take on this kind of work outside their daily responsibilities? Does it need sign-off from anyone? If youâve found confirmatory answers along the way, congratulations: you can carve out a secret R&D initiative within your team or your company. (This is also 'effectuation' in practice.)
You can also read the model from the perspectives of both cause and effect. Reading it one way creates a checklist before kicking off any major work: âHere are the six prerequisites for success, are we all set?â (A causal, prescriptive reading â given starting parameters, what will be the end result?) Reading it backwards turns it into a troubleshooting tool. For example, if someone comes to you mid-project complaining that "We keep going in circles and the team is anxious! What can I do?" you might look at the model and respond, "Well of course! You don't have an action plan. Or maybe, it hasn't been adequately distributed and communicated and people feel that they lack the skills to accomplish something so big. Let's break it down into manageable pieces that we do have the skills for." Itâs pretty quick to go between looking at the failure states and looking at the necessary components to diagnose whatâs going on with a project. (A diagnostic reading, reasoning backwards.)
The model is a fantastic tool for making sense of things. But that leaves the hard work to start after you've made sense of things. How do you drive consensus? How do you align folks around a vision? How do you build up skills, or break down big projects into smaller pieces for which skills exist? How do you win resources, or align incentives?
Some of those answers are obvious, but most are not. Many of the answers are best understood as the manifestation of tacit expertise â a âfeelingâ for the right move in any particular context, a form of expertise that comes from having been around the block a few times.
And like with most tacit expertise, youâll find that there are no one-size-fits-all answers to any scenario, but there are plenty of good practices and useful observations.
So here are some of mine:
Strategic Concerns
The most common and important questions that come up after someone lays out a vision are âWhy should we do this?â and permutations around the follow-up details. If you see those questions, thatâs âconfusionâ, which is another way of saying youâve presented a fantasy instead of a vision (or perhaps, the vision is missing entirely). Thatâs because many people confuse vision for having a colorful and inspiring imagination, making their picture too colorful, unrealistically grand, or too far off.2
My experience is that you make more progress by simply providing adequate context and letting people derive their own vision. The art of context is giving people breadcrumbs to get from where you are today to where you want to be in the future, and giving them some good reasons to follow those breadcrumbs with you. Thereâs nothing more effective than a self-motivated team that thinks theyâre the ones who came up with the idea, that they saw what things could be like. Thatâs vision.
Similarly, consensus is a straightforward concept, but strangely elusive in most organizations. Any organization beyond a certain age and size will typically have a 'minimally viable consensus' while practically being at odds with itself. Departments often turn into silos with their own internal logic for what should happen. Job security encourages teams to think about whatâs best for them instead of for the company. And companies donât do a great job tying âwhatâs best for the companyâ with âwhatâs best for the individuals within, or the communities aroundâ,3 which makes most employment mercenary: people naturally find a balance between what theyâre paid and how much to care about the thing in question. (In that sense, incorporated businesses are kind of like democracy: a bad choice, but among the best of the options available for coordinating large groups of people to accomplish things.)
Recognizing that, one amateur mistake people make is trying to build consensus in a group setting. It just doesn't happen that way. Youâre either going to have everyone nodding along and afraid to say their piece in front of everyone else, or youâre going to have one guy (and itâs usually a guy â sorry, my dudes) start pulling some âwhat aboutâ-ism and dragging the conversation into a black hole of details that you never intended to argue about but find yourself frustratingly debating anyway.
In either scenario, the meeting will end without consensus.
In Japanese business culture there is a concept called ânemawashiâ, which translates roughly to âtending to the rootsâ or âlaying the groundworkâ. Itâs a good analogy because the practice of creating consensus requires a lot of political skill, footwork, trust-building, and private conversation. It means giving people space to tell you everything thatâs wrong with your idea, finding ways to address those concerns, and making sure everyone is aligned before the alignment actually happens. The group meeting when everyone signs off in agreement should be the result of careful stage management â you should know and have already addressed everyoneâs concerns, including second-order effects of how addressing one personâs issues will impact others.
There should be no surprises; it is theater, not improv.
That said, you might not be able to get to consensus. Perhaps your boss wants the âthingâ to happen but thereâs another department thatâs actively against it. Maybe you're encroaching on their turf, or it will reduce their capacity in some zero-sum resource bucket. Maybe they just have a different perspective on the world and the approaches the business should take. Maybe you've wandered into a long-running feud and this project is just one of many different battles being waged. Who knows, people can be both petty and complicated!
If you can't get their buy-in, they will sabotage it in all sorts of creative ways. Because sabotage and resistance are close cousins and are political (in the sense of not being open conflict), monographs on activism and subterfuge can be read as useful primers. Consider James C. Scott's Weapons of the Weak and the OSS's Simple Sabotage Field Manual for what kinds of foot dragging, malicious compliance, noncompliance, evasion, sowing confusion, slander, useless meetings, arbitrary hurdles, revisiting decisions, and moving goalposts to expect.
My advice for these scenarios is to try one of two things. Your first option is to get to the bottom of why there is no consensus and figure out if youâre in a position to address that root cause. Often, youâre not in a position to address those things; if you pursue resolution, youâre going to use up a lot of your political capital or burn out trying to get the project moving forward. And success can be fleeting â projects can continue to be sabotaged even after launch. I once had a project launch only to have all of its resources immediately pulled, forcing its premature death.
Not even chief executives are immune to this; sometimes the solution to a lack of consensus and active sabotage is to simply fire the people in disagreement. (Obviously, use this technique sparingly â youâre scorching the earth.)
So I recommend most people take the second approach, which is to just drop it. Move on. Itâs a lost cause. Donât be the sailor with a bucket trying to dump water off this Titanic. Quitting things and dropping things is a totally acceptable thing to do; life isnât a video game where youâre striving for 100% completeness on every side quest. Move on to things where youâre actually making a difference.
But letâs say everyone agrees. Now you need to make sure that things are prioritized appropriately. Youâre not going to make any progress if this is low on everyoneâs priority list. So you incentivize teams and people.
Positive incentives typically work better than negative incentives, but most people are not in a position to offer meaningful (financial) incentives to push a project forward. Instead, you can rely on horse-trading (âif you help me move this project forward, Iâll help with your thingâ), you can help people resolve their problems, and you can paint a compelling-enough end-state that people also want to reach that goal with you.
Otherwise, people are going to be resistant, which is a passive form of sabotage: sabotage without commitment, or general apathy. It might not even be malicious. Itâs just⌠well, youâre just one more project for people to care about and work on. Why should they do it above all else?
And more importantly, resistance can turn into sabotage when incentives are not just missing, but misaligned. Misaligned incentives can break consensus when you're sweating the details.
Tactical Concerns
Now, letâs say you figured out the strategic bits and youâre working through the implementation portion. Some projects are simple enough that you can just describe what needs to be done, and you can count those requirements on a single maimed hand. Weâre not talking about those projects.
Any complex-enough project requires coordination of requirements, dependencies, timelines, people, and other details. Iâve written a bit about those issues in âWhen Everything is Important But Nothing Is Getting Doneâ, so I donât want to retread too much ground.
But one thing worth highlighting is how skills and anxiety are coupled, and how to navigate a lack of skills. Any ambitious project is at some point going to run into a lack of skills or prior experience because the work wouldn't be ambitious if you'd done it before. So in many regards, it is an existential question for any project: are you and your team able to do what needs to be done? If not, youâll get a very stressed team, or youâll get a simulacrum of what you expected.
There are ways to compensate for a lack of skills. I rely on three techniques:
First is up-skilling people. Education, mentorship, and training are effective ways to turn juniors into seniors, low-skilled employees into high-skilled employees. While there are a variety of documented techniques for this (see: accelerated expertise, tactical decision games), the caveats are that (a) this typically takes longer than the time-span of a single project and (b) you need to find people who are interested in learning.
So the second technique is atomization: break the requirements into smaller pieces that meet the level of skill available rather than trying to get people to rise to the required level. Instead of making everyone work harder, just make the requirements easier. Instead of asking people to âcut database reads by 50%â or âcreate a capacity forecasting model for the next 12 monthsâ (where they may not even know where to start), give them smaller tasks and directions for what to do to accomplish that. Point folks in the right direction, explain the what and the why, turn big asks into a series of steps, a recipe to accomplish something. This is in itself a form of teaching, and it is more project-sized (see what I did there?).
The third technique is to roll up your sleeves and contribute. Iâve learned from many effective leaders that there is no work below your pay grade. What makes many great leaders "great" is their willingness to spend extra time doing âglueâ work, filling in the holes between roles, and making sure all assumptions are bridged back to real expectations. They are never too good to personally write up a project document, to manage a tracker, to make sure that people are talking to each other. They often know as much or more about the details than subject matter experts, but they don't needlessly meddle â they support where needed and use gaps as up-skilling opportunities.
Much of the work of compensating for skills gaps is directly translatable into managing budget, time, and effort tradeoffs to navigate the âresourcesâ component of Lippitt-Knoster. And your ability to solve for skills and resources directly translates back into the specific action plan you need to put together. For example: you may decide not to spend $100,000 on a vendor because you can reverse engineer a single feature you need for a project, but you need to add time to the plan for that.
These considerations become a calculus of risks, rewards, and effort, which in turn underpins the strategic portions that we talked about earlier: sure, you might think you can lead a team to rebuild the hot new vendor in house in two months, but have you earned organizational political capital to place those chips on the table?
So there you have it, Lippitt-Knoster in practice. Lead on!
1 - This grouping is not present in most Lippitt-Knoster model descriptions Iâve come across; it is my one humble contribution.
2 - A realistic vision that is too far into the future is its own type of risk â every day presents new opportunities for conditions to change, starting conditions to be led astray. The likelihood of any far-off future has too many compounding variables... too many things have to go right and be true for it to be reliable enough to pin your hopes to.
3 - These things are usually at odds with each other. There's a big literature about how "equity" is a tool to get employees to care about corporate success, but most startup equity goes to zero; for the average employee, a bonus or a pay raise is more useful. Public company equity presents a different issue: it is dependent on public market behavior, and less on your individual ability to impact it â being in a public company, you're likely one of thousands-plus of employees.
Thanks for reading
Useful? Interesting? Have something to add? Shoot me a note at roman@sharedphysics.com. I love getting email and chatting with readers.
You can also sign up for irregular emails and RSS updates when I post something new.
Who am I?
I'm Roman Kudryashov -- I help healthcare companies solve challenging problems through software development and process design. My longer background is here and I keep track of some of my side projects here.
Stay true,
Roman
Instagram Engineering
Shopify Engineering