The question in title was something I was recently asked by someone who used to work with me and with whom I continue chatting with some frequency. It came with the addition that teams are currently overloaded, working overtime and quite stressed. Still leadership keeps trying to schedule more work and only ask them to work faster.
The last part is something I take quite seriously. To me, not overloading and imposing stress to teams is reason enough to limit how much work is happening and thus create more focus. It turns out that there’s much more to that, which is good news, but also quite frankly something that annoys me with how little regards sometimes it gets.
The causal chain is simple (which is different from easy):
Work in less things in parallel → Creates Focus → Increases Flow → Enables more effective products / services
It’s all pretty logical in mine and perhaps many other minds (what about yours?), but we humans seem to be “wired” differently (for the good and for the bad), and typically behave driven out of our perception (what we expect to see) of things. Once I remind myself that, then it hits me, and that was precisely the first level guidance I could provide to the person who engaged with me:
“Have you tried to prompt where does leadership comes from to keep pushing more work? What kind of overarching (misleading) premise / assumption might be driving that behavior? Is it clear what they are trying to optimize for: (a) keep people busy or (b) getting things done?”
I believe prompting that alone can go along way – at least in terms of opening up for further meaningful conversations. Because I’d assume they haven’t really thought through that well-enough. And I’d assume they prefer optimizing for getting things done. That’s when we can get opening to take some moves which would stand a chance to succeed:
We got to make them understand the implications of the trade-offs that seem to be currently taken, and how that’s fundamentally misaligned with what in principle we are trying to achieve: get things done.
In my book (and granted that going through that might feel much less linear because you want to meet people where they are and adapt to the given context of how conversations are going…), the next sensible moves are, in a nutshell, a combination of the following:
First things first: make things explicit (visible). I’d bet (in the particular case and typically everywhere) leadership hasn’t really ever spent sufficient time just visualizing how much work has been pilled up in the (delivery) system. Start there. But also try to make explicit what are the underlying reasons why they feel compelled to keep pushing for more (e.g., is it based on need to change direction? Did something turn to a higher sense off urgency all of sudden? If so, why aren’t we at least making trade-offs and deliberately stopping something else?!).
Work with them to understand the implications* of the kind of “peanut butter” execution approach that seems to be going on:
Things will tend to take longer, there will be more of a batch-like pattern of delivery (which means more risk and less opportunity for learning).
Set priority might not be what determines what comes out first (this alone should make product management absolutely mad, in my personal opinion).
Whenever you have a reasonable reason to try to change gears and prioritize something new, the decision of what can drop becomes more conflicting.
Get buy-in (even if not explicit, directionally is OK for now) on what to try out (experiment) next so to attempt doing something about improving the current situation. That may involve actions like:
Agree to not start anything new until the number of ongoing things comes down to an lower agreed upon level (don’t overdo it: there’s no magic formula to determine what that should be, you will have to find out the right balance in your context. Some practical tips here). Then, after that, maybe agree to the simplest of the rules: you can only start something new if something else got done.
Triage ongoing work (WIP) and take some deliberate actions to stop doing some of the work that maybe you shouldn’t have started in the first place, or that lost traction and sense of urgency for some reason). A.k.a., “clean up the pipe”.
Agree on how we can keep an eye on things moving forward, so to not allow things to derail once again, and more importantly: to keep improving the situation. I personally am a big fan of using early signals like aging WIP (as a leading indicator of cycle/lead time).
The handful of practical advice above is quite a lot! Chances are that it will take you quite some time to see the impact of that, especially if it’s somewhat done is a “stealth mode” (not as deliberate managed change guided by leadership, but just a sort of informal agreement to try out something a bit different and see how it goes). Particularly if we are talking about influencing and seeing the impact at scale (across multiple teams). For instance, in my own experience, the difference in the graph below, as an aggregate across more than 10 teams, took nearly 2 years to be accomplished. It’s a journey, more of a marathon than a sprint.
To wrap up with a simplified sort of playbook, this is how I’d summarize it:
Clarify the goal of the delivery system (what you’re optimizing for).
Work out to make leadership realize the misalignment of the current trade-offs being taken and their implications.
Get to work. Do something about it (even if all you have is a kind of directional buy-in).
Don’t be afraid of having to go “stealth mode”. It will probably mean it will take longer, but still pretty much worth the trouble.
As one of my favorite contemporary thinkers has famously said:
There are no solutions. There are only trade-offs.” – Thomas Sowell
* In my two-part series (part 1, part 2) of how product development benefits from flow, I’ve used a simple simulation game that hopefully helps landing some of the key implications related to this.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.
There are some great insights and advice here.
- Probing as to why more work is being asked to understand where leaders are coming from
- Making work visible. This alone is a great insight, after all "You can't manage what you can't see"
- Setting priorities together with leaders
- Triaging ongoing WIP work-in-process
- Clarify what the teams are optimizing for (you call it delivery system)
However there's a blind spot in the article. Nowhere do you mention the concept of a project, and the process of getting projects approved and their usual delays (average of 60% in my data at two large SW companies).
This project-driven management alone can cause huge amounts of parallel work.
At a company I worked we had 150 projects ongoing for about 120 engineers. Why? Simple! When a project is started it is assumed it will finish on time. But they don't (see above). However there are other important and urgent projects in the portfolio that need to get started. And they do because they have committed and motivated project managers and stakeholders who want them started.
This leads to more and more work being started.
In the article you don't address this entirely predictable dynamic in project organizations, and that dynamic alone will significantly reduce the impact of the great ideas you have shared.
Will you address this dynamic at some point