Back Original

Lippitt-Knoster in Practice (Field Notes for Managing Complex Projects)

"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, 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 own humble contribution. The order I'm presenting it in is also my contribution – the order in Mary Lippit's original 1987 model is quite different, for reasons I couldn't discern.

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.