Why moving faster often means slowing down first

If you've ever had to deal with stakeholder management as an engineering leader, there's undoubtedly one question that keeps resurfacing again and again: "How do we make the developers go faster?"

The pressures of a deadline and the risk of being too late to the market - particularly in startups - and a common misconception about software development productivity often drive this feeling of not going fast enough - but what can we do about it?

The Velocity Trap

Early in my career as a technical leader, I fell into a velocity trap – we just needed to write more code in less time. The problem is, people who chase this goal quickly find themselves running faster toward bigger problems.

The reality I've learned is counterintuitive: sustainable speed requires intentional slowdown at critical moments.

The Hidden Costs of Cutting Corners

We've all been there - when the time spent firefighting overtakes the time spent building new value. It can normally be traced back to one of the following - skipping proper requirement gathering; failing to get team agreement; rushing through architecture and design thinking or just coding without thinking.

Each shortcut taken compounds, creating a snowball effect that eventually brings development to a crawl and the result is we spend the next three months firefighting production issues, dealing with unhappy customers, and ultimately rewriting large portions of the codebase.

Don't get me wrong - sometimes it's ok to cut corners. If you have a short lived project or minisite, then you build it in a different way than you would an entire digital platform. As a leader we need to recognise when it's ok to apply speed vs move slower.

So How Can We Go Faster?

As leaders, there's still things we can do we speed up development without taking these shortcuts:

• Should we even do this? - To quote the book Rework, from the team at 37signals, it is "better to build half a product, than a half assed product". Make a small but great thing, rather than a big but bad thing. And sometimes, maybe you don't need to build the feature at all. Your team will thank you for not wasting their time.

• Focus on execution - Execution isn't about doing more things, but about doing the right things well. To do this, you need to:

  • Identify the core value drivers that matter most to users
  • Resist the temptation to spread resources too thin
  • Measure impact, not just output
  • Create space for deep work and meaningful iteration

• Starting in manual mode - Rather than automating everything at the start, look at what you can do manually. I've used this technique a lot to help gauge what we should and shouldn't do; and when you know it works and it's starting to become a scaling problem, then you look to make it automated. If it doesn't work - great don't build it.

• Buy vs build - At my last startup, we needed to deliver a lot of features in a short amount of time - so we looked at what was truely important to the product - the differential - and we found off-the-shelf solutions for the remaining items.

• Be realistic with what you can achieve - Heroics only get you so far. Estimating story points with only the best case scenario never works - there will be issues with the approach and your developer will get distracted by other meetings, tasks or other people. Even if they manage to get a day or two of complete uninterruption, it won't last. There will be unplanned work - like finding a bug in production or a unhappy client. So listen to your team's capacity signals and make sure you account for them before agreeing on a release date with the business.

• Understand how your team works - As a leader, it is your responsibility to learn how your team performs best and give them that environment. I often find a happy team is a more productive team - and you can achieve a happy team by fostering an environment where they can succeed without fear of failure, where no question is a stupid question and without constant distraction.

• Avoid burnout - You need to know how far you can push your team and when you need to stop pushing. If your a good leader, your team will go that extra mile for you from time to time. But if you keep asking to go the extra mile, then they will burnout and start to look elsewhere.

Essentially, what we are looking for is sustainable, consistent progress.

What Else Can We Do?

Of course, there are other things we can do as leaders to help our teams:

• Reduce the distractions - How important is the production bug? Is it affecting a few or a lot of users? Similarly, do they really need to be in every meeting - or could this meeting be shared as a Loom instead? A lot of companies look at meeting-free days as a way to allow for improved productivity. Agreeing with your team if there's a day or time of day (e.g any meetings should happen in the mornings) can help.

• Keep the focus on now - Allow the team to focus on the current priorities rather than what is coming along the pipeline in two or three months time.

• Tell your team it's ok to be in focus time - Set expectations around when you want them to be active on Slack, Teams, email etc. Sometimes we feel constant pressure to reply on Slack to prove we are working. I normally tell my team to answer when they have time, and follow more of a path toward asynchronous team communication.

• Make sure you have some time for being social - Allow time for your team to have fun and let off steam. There are lots of online games you can play with remote teams, or a coffee or bar visit for those who are in office. Sprint demos are also a great way to celebrate the work achieved and spend some time understanding what everyone has sacrificed to reach that point.

--

By Andi Smith