. What decisions do you make? Take a moment to think that through.
OK. You have built that system And now try to lower WIP. What happens? The well-meaning, passionate, and intelligent people in the system have crafted roles, interactions, structures, egos, and relationships around doing a lot at once, and that’s not something you can simply rationalize away. The system will push back (and often for very real, painful reasons). The same thing happens to individuals who attempt to change a habit.
What are you up against? Below I point out some areas of optimization that will no longer “make sense” (and will fight back) with efforts to reduce WIP. To improve the situation, you’ll need to address the current coping mechanism(s), and that will not be easy. It’s easy to single out individuals for being “change adverse”, but these challenges are mostly systemic, and far from trivial.
Some common adaptations (when optimizing for high WIP):
- Shared Resources
- Saying Yes!
- Bias For Action (Not Reflection)
- Managing Individuals Not Teams
- Kingdoms and Defenses
- Dedicated Teams and the Big Pool
- Big Picture
- Less Cross-Team Collaboration
Handoffs help keep people busy. While Person A is working on something, Person B can start on an upstream task, and Person C can work on a downstream task. Now they could work together, but that would be (seemingly) inefficient, and may require new tools. So a culture of handoffs emerges, and you begin to see folks actually looking for opportunities to “get ahead” of things. Handoffs require coordination and meetings (and people to coordinate and run those meetings). Also, sadly, they impact the culture around celebration and sensing impact. If the final outcome is somewhere “way downstream”, you may never get to sense your part in it (or feel accountable for it).
- How can we make it safer to start together and finish together?
- What are we gaining and losing by “getting ahead” of work?
Are we consistently getting the right voices in the room?
You’d think that pursuing high WIP would necessitate true cross-functional teams (embedded Ops, UX, etc.) but that is not always the case. The opposite seems to be true. We rationalize that we only need “10% of that UX person’s time” for each effort, and that a single person can be matrixed across ten efforts. Pursuing high WIP tends to ingrain the idea of matrixing specialists, and encourages lofty economies of scale assumptions. In tandem with handoffs (above), you also see things like sharing a single downstream QA function across multiple teams because in theory that is “efficient”, and helps clear the decks for teams to grab the next thing. If these shared resources are at all functional — and they try their damndest to be — they’ll continue to be under resourced, drop balls, have people work around them, lose the faith of the org, and…well…stay under-funded.
- What might be possible if this function was 100% available?
- Have our economies of scale assumptions held?
If [some function] is consistently the “bottleneck”, what is stopping us from helping them?
In an environment optimized for starting, and doing more things at once, you frequently find that saying “not now” is viewed as being a crappy team player. No one wants to hear the sobering reality that work is piling up, or that there are one hundred other ideas in the queue with just as much merit. It is relatively easy to say yes and take on new work…especially small bits of work that should be “small” (ignoring that the size of the item is only a small % of overall lead time). Saying “no because ______” equates to bringing forth “problems not solutions”.
- Are we valuing starting more than finishing?
- What might we gain by saying “no” more often?
Is saying “yes” actually helping our customers?
Bias for Action (Not Reflection)
How do you personally adapt to heavy multitasking? At least n=1, I find myself skipping deep work, going with the first solution that pops into my mind, and stumbling through the whole day without really even remembering what happened! I turn UP my bias for action, and turn DOWN my bias for reflection. Now imagine that scaled up to a whole organization juggling high WIP. Consider the traits that are rewarded, and the perspectives, and personality/neuro-types that fall out of favor and have trouble. The pernicious thing here is that juggling, back-channeling, and horse-trading to “make stuff happen” tend to bubble up as valuable survival traits. This suits some…but not everyone.
- How can we better leverage our diverse ways of thinking?
- What might be possible with more time for deep work?
What might we have trouble sensing given how busy we are currently?
Managing Individuals, Not Teams
When individual contributors are “loaded up” (high utilization), you tend to see more focus on individual tasks vs. team goals. Shrink all the points in this post down to the team level, and most apply. This influences performance management, the ability to collaborate in the codebase, the role of the manager in assigning work (to individuals), accountability for actual outcomes, and career paths. It runs super deep. The team becomes less practiced at moving boulders together, which encourages individuals working alone, which elevates the manager to coordinator function, which further prevents practice…and you have a vicious cycle. The manager becomes more “people” manager, and less “team/system” manager. And individuals on the team becomes more focused on “individual progress” and less focused on “team progress”.
- What is stopping us from working more closely together?
- When and how do we celebrate as a team?
As a team, what are we outsourcing to our manager? Is that helping us?
Kingdoms and Defenses
“Shaking the snow globe” to handle new challenges is (admittedly) disruptive, but important for controlling work in progress. With high WIP, instead of figuring out how to work together on a small number of items, you observe a kingdom-multiplying effect…new “products”, new services, new departments, new layers of management, etc. If you can craft what you’re doing as “new” (translation more stuff), you have a shot of getting funding, gaining newfound respect, and a career trajectory boost (in that org, at least). “Doing more at once” increases structures in a non-linear way, and hardens the boundaries between the constituent parts. When you’re super busy, and there are a lot of moving parts, we tend to create a wall around what we can control…even if it does not benefit the global whole. In short, we get more kingdoms, kingdom builders, and silos, and then an influx of connective-tissue roles, silo translators, and kingdom builder-tamers.
- Where does information need to travel? Where can the boundaries in our organization be less rigid?
Are there opportunities to turn an “us vs. them” into an opportunity for collaboration?
Dedicated Teams and the Big Pool
Self-organizing, autonomous, and cross-functional product development teams are beautiful things to behold. What you see in high WIP environments, is that having a “dedicated team” becomes a real asset. It makes playing the Tetris easier. But I often discover that these teams are far from self-organizing, far from cross-functional (to the point about shared resources above), and far from autonomous. They don’t actually “own” a product or service, and lack an end-to-end perspective. We also create them prematurely to fend off the madness, as opposed to a model whereby teams band together for meaningful missions, disband, and perhaps leave “anchors” with key concerns. Having “stable” teams feels good, but there’s a trap whereby you believe you can just keep adding theoretically stable teams to get more started vs. more of the right things done.
The flip side is a completely fungible group of resources that gets treated as N teams of 1…thrown on and off projects, no one caring for the big picture, and getting constantly reshuffled. This is challenging as well! You see both manifest in high WIP environments for different reasons, and each comes along with a ton of baggage: Tetris playing roles, kingdom building (see above), Next Project (see below), etc.
- Are our dedicated teams truly independent? Is that helping?
- Are there opportunities to end certain missions and start others?
How might we retain tribal knowledge about individual services/products during a period of rapid growth?
Big Picture and Red-Orange-Green
With so much going on, it can be impossible to keep everything in your head. So teams abandon “big picture” artifacts because the real-time big picture is too busy and complex. The interesting thing here is that someone still wants to see the big picture, so you also see intricate program/project management functions emerge to try to make sense of the insanity for leadership, and coordinate dependencies. Here’s where you find the much-loved (and always woefully out of date) red-orange-green spreadsheets — the longer the better if everything is green, right? By trying to oversimplify the madness of the big picture, we assume it’s not all that complex, and we jam even more complexity into the system. A vicious cycle, again.
- Can we “keep it all in our head?”
- Do our artifacts represent the true complexity in the system?
Can we explore cheaper/lighter weight ways of keeping people aligned with the big picture?
Less “Cross-Team” Collaboration
This is a scaled up version of what we discussed with individuals above. In high WIP systems, teams have less practice collaborating with other teams directly (vs. through a layer of management/coordination). If you’re so busy getting “your” thing done, it is harder to think about the more global “our”. The message is to keep your head down and finish what your team is “on the hook” for. This type of collaboration takes tooling, visibility, interfaces, headspace, and slack…all in short supply (and ignored) when everyone is super busy with individual projects.
- Assuming we had a compelling large opportunity involving the work of multiple teams… would we be able to tackle the challenge?
How do we collaborate across teams?
Image you have the choice to either 1) let a team keep iterating to explore the upside and outcome, or 2) move a team on to the “next thing”. When a system is optimized for high WIP, planning inventory will pile up. There’s a lot of pressure to move on to the “next thing” (often a silver bullet, because of delays), and you see a lot of rationalizing about how outcomes will be hard to measure, and that it could take “a year to figure out if this will work.” A system optimized for high WIP is optimized for starting, not truly finishing.
- What is the “batting average” for our product decisions?
- How might we accelerate the feedback loop?
- What are we gaining by rapidly shifting off initiatives? What are we losing? Hopefully this gave you a sense of how deep the adaptations can run. Consider starting with a gentle WIP limit. Focus on making safety a prerequisite (see Modern Agile).