Delivery Pressure: Stop Burning Through It, Start Thinking Through It
The new normal
Delivery pressure is not new to our industry. We have always had it. A missed deadline here, a crunch time there. What is new is that delivery pressure has become sustained. In the past, crunch time was followed by recovery time. Now, the crunch is the norm. I know of many teams where this pressure has been sustained for more than 2 years!
The expectations from investors, markets, and businesses have reached levels that many teams simply cannot keep up with. Deliver faster. Innovate more. Deliver yesterday. More features, more output, more, more, more.
A small thought exercise to warm up
Your neighbour runs a moderately successful delivery business delivering letters. They have worked hard, built a reputation, earned a loyal customer base. For a long while, business was stable & growing. Then things started to fall apart. Deliveries are getting missed. Customer complaints are rising. Trustpilot ratings are dropping. Their employees are overworked and unhappy.
Your neighbour thinks this is a temporary shock & things will return to normal, they have to just stick it out a bit more.
Some questions for you
- Do you think that is the right thing to do? If the answer is it depends, what factors would make your answer more concrete one way or the other?
- What other questions would you ask your neighbour?
- What would you recommend they do next?
Why we keep getting it wrong
When the pressure mounts, our gut tells us to just burn through it. Work harder, work longer, throw more people at it. We were able to deliver successfully for so long, if we can just survive this sprint, things will go back to normal. But they don’t. That is barely a strategy, let alone a good one. It is hope and a prayer dressed up as a plan.
The problem is that people fundamentally misunderstand what delivery pressure is. They are quick to attribute it to something observable, usually a motivation issue, a process hiccup, something else that they can quickly fix or push through. These fixes almost always have the opposite effect.
When pressure is high, people are tense. If it has been sustained, any trust that you had previously earned has been eroded. In that situation if you are trying to motivate people you have to get your message perfect. That is next to impossible. These are the same things that stand in the way of improving processes and many other things. Broken systems create broken people and broken people will produce broken things.
So what is the fix? What is the way out? Well, it depends. If it was easy, this post wouldn’t be this long. However, there is a clear starting point.
Don’t trust your intuition. The fix is certainly counterintuitive
One of the best descriptions of agile I have heard is that it is counterintuitive. What your gut tells you to do is most likely the opposite of what you should do. That is the beauty and the curse of agile.
Understanding delivery pressure
In a software ecosystem, delivery pressure when simplified, usually means the throughput of your work is not keeping up with expectations. This does not necessarily mean you have slowed down. It might mean that the scale of improvement has not kept pace with the demands placed on you. It might also be a case of wrong expectations being set. Most likely, it is a combination of both.
You have to find out where the friction is.
One of the best pieces of advice I received was from Erik Dörnenburg:
When your plate is overflowing, you will want to focus more on the tactical stuff, but the overflowing plate is a clear signal to stop doing tactical things and start thinking strategically. Strategy is your way out.
This opened my eyes. Before I talked to Erik, I would look at the mountain of things to do and think about the best way to get through them. I looked at prioritization methods, trying endlessly to sort them into rocks, pebbles & sand. I tried time management tools, pomodoro timers buzzing endlessly. I tried focus time blockers, working odd hours so that I could focus. All this helped, but too little. For every 5 things I would finish, 10 new things would enter my funnel. I was being too tactical.
I was focussing too much on what needs to be done. After talking to Erik and other brilliant people, I changed my approach. I started asking “Why this needs to be done?” With iterations, I ended up with this filter:
- Does it need to be done?
- Does it need to be done now?
- Does it need to be done by me?
This let me look at things I was blind to, letting me design and create my delegation network, my meaningful and achievable action plans, creating autonomy, alignment and accountability in my teams. The mountain of tasks wasn’t scary any more!
What I described is a journey. One that takes a bit of time and a lot of vulnerability. In the next sections I will try to give you some things to stop doing. I hope they will help in slowing down the bleeding and buy you some breathing room.
Some common mistakes to avoid
I believe that the prime directive applies by default, unless we have clear evidence against it. So please do not infer the intent to be malicious for the points mentioned below. In fact, most of these cases I came across, the intention was always good.
Do not cut access to information
Many a time I have seen leaders at all level try to protect people by shielding them from context, decisions not yet made final, problems that might or might not land. Or they just want the team to focus, so they don’t invite the team members to the meetings. The thinking is kind: do not burden them. But the people in your team are knowledge workers. They need information. By shielding them, you are depriving them of a vital tool. You cannot overcome this alone. You will need your team, but you will have to lead them.
Do not make decisions without involving the people impacted
This is an extension of the point above. I have seen huge architectural and process changes being made without even consulting the team. The decision is made 3 to 4 layers above and then communicated as directives in a cascading manner. There are a lot of downsides of doing it. No buy-in from the people you need to make it happen. Finger pointing / lack of accountability, people adjusting their performance to meet expectations. If you treat your developers as mere code-outputting humans, they will stop being developers and focus on just outputting code.
Do not hyperfocus on a metric
Metrics are great, and if done right, they will help you get out of delivery pressure. Their curse is that they are very easy to collect but very hard to operationalize. If you choose a metric without a clear understanding of how it drives desired outcomes, you might end up optimizing for the wrong thing.
Often I have seen people hyperfocus on the most visible and the easiest to measure metrics, such as, Velocity or Capacity or , in the recent days, Tokenmaxxing. Because they are easy to measure, they are also easy to game. If you are constantly pushing your team to increase velocity without doing a real inspect and adapt cycle, the result is what used to be marked as 3 story points become a 5, the 5s become 8s and so on and so forth.
Metrics are never truly isolated from each other. Changing one isn’t without side effects on something else. It is a game of tradeoffs. Always keep a holistic view and set realistic targets for improvement on the metrics you are focussing on.
Metrics that aren’t connected to a desired outcome and an accompanying change strategy will do more harm than good. If the metric you chose is not getting the desired outcome, do not hesitate to throw it away. Remember, the desired outcome is the goal here, not the metric reaching a certain value.
Do not pollute the vocabulary by having your own twist on things
This is from my perspective of being a consultant brought in to help the team. I want to get in quick, help you get back on track, ideally with small changes that stick and then get out.
This gets incredibly hard when people use popular words, but reality doesn’t match. Do not call your services as “micro” when they do 40 different things. Do not say they are domain-aligned when business folks and the dev team haven’t talked directly in the history of their existence. Do not say you do continuous integration if you have a sprintly merge-fest. Do not claim you are doing DevOps when the Ops team can only communicate with devs over an Incident ticket that was promoted to a Jira bug after a 7-step escalation process.
Step 1 of fixing 💩 is acknowledging that there is 💩 to be cleaned up. There should be no shame in this.
I am going to stop here. There are many more things to avoid, but these are the most impactful ones I can think of. In the next section, let’s explore some good starting points for your strategy to address.
Some places to look deeper into
Where are the gaps in your quality strategy?
The biggest resistance to fixing delivery pressure comes from rework. The things you delivered in the past come back as bugs or change requests. This rework breaks flow, trust and, in extreme cases, morale. If you find yourself fire fighting and/or task forcing more and more with each passing week, your quality strategy is probably the best place to start inspecting.
Side Note: Quality strategy isn’t just about tests and automated suites. Quality needs to be ensured across all phases of SDLC (Software Development Life Cycle), from feature discovery to things running in production. Do not underestimate the damage caused by bad requirements and struggling support teams. Your improvements also need to work for these functions!
Has your architecture evolved?
Many teams I talked to have made, or operate under, architecture decisions. Some even have Architecture Decision Records (ADR)! They are able to explain those decisions very well. However, when I ask them “When was the last time you revisited a decision?”, I am greeted with silence. In larger enterprises, these decisions tend to fossilize. They are treated as set in stone rather than a line in sand.
The problem with this approach is that though they are decisions, they are based on assumptions and predictions. I would recommend adding a section that captures how you will measure the success or failure of your decision, including the date by which the changes should start showing their effect. Then make it a practice to review and revise ADRs periodically.
Are the people set up to succeed?
When things are going well, stable team setups, where people or roles don’t change too much, are great to have! But when things are hard, stable team setups should not be the priority. Each individual is different, and they also change over time and with circumstances. Yes, team should operate as a unit, but you cannot ignore the individuals.
If someone is in or close to a burnout. Give them the breathing space to recover and come back strong. This benefits both the individual and the team. Speaking from personal experience, burnt-out people don’t make the best decisions.
Every individual has their strengths and their blind spots. People perform best when their strengths are allowed to shine. This is the entire premise of Clifton StrengthsFinder. Are your people, especially those with leadership responsibilities, still playing to their strengths?
How autonomous are the teams? What can you do to improve their autonomy?
Have you set the expectations properly?
Sometimes the pressure is simply a gap between what was promised and what can realistically be delivered. Expectation setting requires vulnerability. It is a negotiation, and one party cannot dictate terms. These are difficult conversations, and they can get heated. But you cannot avoid them forever. The uncomfortable truth about difficult discussions is that they only get harder with each passing minute.
To conclude
Delivery pressure is here to stay. But that does not mean we have to simply accept it and burn through it. We have to analyze where the friction actually is, resist the gut reaction to just work harder, and think strategically about what needs to change.
And do not forget yourself in all of this! Maybe you yourself are not positioned in the right place. Maybe these are the wrong conditions for your strengths to shine. Lastly, ask yourself periodically, are you the right person to lead through this change? That question deserves honest consideration too.
Acknowledgements
Many thanks to my wonderful colleague Kamila Sultanova for helping me sort my messy thoughts into a coherent document.