The Sacred Cow
Pressure is one of the most important tools in the leader’s toolbox. If you are a leader, it’s your job to control the pressure that’s on your team. Too little pressure and direction kills companies. Nobody can afford a large team that’s not pulling their weight. It’s also very wrong to think that your people will be happy. People want to work, they want to be productive and they’ll quickly get frustrated and leave if they don’t see things moving forward.
Too much pressure, at least in a team of software engineers, is also very destructive. Software engineers are not easy to replace when they burn out. They’re relatively easy to hire but they leave with a lot of knowledge about your domain and your code base. This takes years to develop. Literally. Software engineers are also constantly making trade offs between delivering features in the short term and investing their time to save time in the long run. Too much pressure and productivity quickly deteriorates. If your team is in such a rush that they can’t spend time on quality engineering, they’ll be moving slower within three to six months.
It’s an advanced skill but as a leader, you can choose how much pressure to put on your team. A good leader will do this in the context of the situation. At times, a good leader will have to act as a pressure shield, and protect their team from unhelpful pressures coming from the wider company. At times, they will have to make sure the team continues to be happy and productive by clarifying fuzzy goals and expectations.
So, pressure is important and there are healthy and unhealthy levels of pressure. But how exactly should you go about applying it? It turns out there are healthy and unhealthy ways to do that too!
Time-boxed delivery
Time-boxed delivery (achieve project x by time y) can be a big mistake in software engineering. This is counterintuitive to many because it is the most common way to regulate pressure and it’s at the core of many goal setting frameworks (like SMART, for instance).
The main problem is, it’s an extremely blunt tool. Writing software is a process of discovery. No engineer knows exactly what needs to be written before they sit down to work, they discover that when they write code. The discovery is the work, which is an unfortunate fact that can’t be made to disappear by “detailed planning”. Software teams normally underestimate (because there are a lot of unknown unknowns). This, in turn, means that if you select what looks like a reasonable deadline, you normally end up applying much more pressure than you intend.
Working this way also means the team gets fixated on what they’re building, not what they’re trying to achieve, and managers often become obsessed with increasingly detailed and expensive estimates that magically always seem to end on the last acceptable date. When teams are working with a strict timeline, there is no room left to think about the customer and there’s no room to think about the future beyond the deadline. The rate at which technical debt accumulates is often terrifying.
A good software team, given context, is capable of making decisions that are correct for the company. Together with a product manager, they can learn what the customer needs, balance this with avoiding technical dead ends and maximise the delivery of value in small iterations. They just can’t do this with the sword of Damocles hanging over them.
OKRs
People adopt OKRs to solve many of these problems. But OKRs have problems too. There are two structural problems with OKRs, that have nothing to do with your culture or the skill of your team.
First, it’s simply not possible to consistently choose builds that will move metrics over the short time periods needed to meaningfully hold people to account. There are exceptions to this but typically the quarterly cycle is too short to see any impact on any meaningful metrics. Trying to work like this holds you back and either you revert to time-boxed projects and “get creative” with the numbers, or you only ever take on the small stuff.
Get Tim Leslie’s stories in your inbox
Join Medium for free to get updates from this writer.
Second, metrics have associated noise. Things other than your work will move them. I was the CTO of a small startup going through the pandemic. We were being held accountable to a series of business performance metrics by the board. It just so happened that the nature of our business meant that our customers (small business owners) found our product extremely useful for their planning when the first lockdown hit. After a few weeks, however, the planning was done, the businesses were closed and they needed to reduce costs. This led to a spike followed by a collapse in our sales. I remember being completely bemused in this period because the board’s reaction was to clap up on the back and congratulate us when sales spiked and then to berate us a couple of months later when the new trend became obvious. At no point had we really made any significant changes to the way we operated but the metrics acted like a thick fog that these really clever people seemed unable to see through.
There are then, of course, several cultural problems layered on top of these fundamentals. Targets have a tendency to replace strategy, for example, which is as true on a software team as a board of directors. OKRs are also entirely useless in low trust environments, like the boss holding out a gold coin called “autonomy” only to snatch it away again when someone tries to reach for it. However, I want to get away from the idea that if OKRs aren’t working for you it means there’s something wrong with your culture. The problem runs deeper. We need to drop the concept of achieving x by time y. It is a sacred cow that has been holding us back for a long time.
Metrics are important. I’m not suggesting that you should stop looking at them. It’s important to have a clear understanding of how and why they move. However, I’m not convinced that the timeboxed movement of a metric makes a good goal for a product team.
The alternative
Transparency over timelines can be important. It can be important to size a project as part of the prioritisation process. It can also be important to know when work is going to be finished in order to coordinate a project. These factors need to be considered but before we start, I’d like to make a really clear distinction between using estimates for transparency like this, and using deadlines as a tool to regulate pressure on the team. Big problems emerge when the two are mixed. The most obvious example is when a leader increases pressure by setting a tight deadline (intentionally or otherwise) and then relies on this to make critical decisions about the surrounding project. If the deadline is unachievable, as is often the case, this can lead to significant wastage as timelines go awry, tech debt builds and the team burns out.
Transparency
The critical question to ask is what knowledge about the timeline is actually needed when. You have to answer this yourself for your own circumstances but, in the knowledge that estimates are time consuming, wasteful and generally inaccurate, it is wise to ask for as little as possible up front. In general, this might mean rough and ready t-shirt sizing of projects for prioritisation and then, once a project is taken on, if and only if there are significant other dependencies, increasing the precision of the estimate as the project progresses. For example, if we think we’re more than a month out, we tend to give our estimates to the nearest month, if we’re between one and four weeks away, we tend to give our estimates to the nearest week and if we’re expecting to deliver within the week, we’ll estimate to the day. We also normally put a confidence on our estimates, so for example, in May we might say, we’re extremely confident a project will be delivered before the end of July and there’s a small chance we might be able to do it before the end of June. We find this normally gives other teams plenty of warning so they can coordinate with us.
Pressure
How do you regulate pressure without deadlines? How do you prevent teams from gold plating? How do you keep them moving?
Think about how your engineers respond when there’s a major incident. Do they hang around and drag their feet until you tell them it needs to be fixed by the end of the day? If they do, then I respectfully suggest you have other problems.
I find this a very powerful example actually. It shows that a shared understanding of urgency and a shared goal is enough to motivate a well managed team. The key is clear and consistent communication about urgency. We’re all adults.
One of the best ways to do this, I find, is to talk about horizons. Do you want the team to maximise value over the next 3 months or 3 years? This leads to very different discussions when you ask questions like, is it okay if we have to revisit this codebase in 18 months time? Should we release something that works in one month or something that impresses in six? Even, should we spend our time hiring and onboarding or building and delivering value?
Conclusion
In summary, as a leader it’s important to apply healthy pressure to your team in order to keep them productive and engaged. However, blunt tools like time-boxed delivery and strict OKR goal setting often backfire, resulting in rushed work, technical debt, and burnout. Instead, focus on open and clear communication about priorities and urgency. Give team members context to make good decisions that balance short-term delivery with long-term success. Estimate timelines transparently when coordination is needed, but don’t let arbitrary deadlines drive development. Motivate through shared understanding, not threats. If you build a culture of trust and psychological safety, your team will respond with their best work when it matters most, just like in an incident response scenario. With the right culture and communication in place, you can keep your team moving fast without compromising engineering excellence.
