How to Make your Developers Work Faster

I used to work for a consultancy where we often reminded each other to "slow down so you can speed up". But there is a much deeper veiled statement. We weren't telling each other to be meticulous or careful. We were telling each other to do the due diligence necessary to be most effective.

Slowing Down

So what does slowing down really mean? It means putting your software delivery on the back burner so that you can put tools, processes, and team structures in place that will drive a truly high-performing software organization. What are those things? Well, the list goes on and on. But here are a few to get you started.

• CI/CD Pipelines. This is so commonplace these days that it's almost not worth mentioning. But I have found that a lot of folks still wait to implement this very late in a project. If you're in that position, you should definitely stop and automate anything and everything you can. Don't let anything reach any environment manually.
• Consider what you're measuring. The bottom line for software organizations boils down to two items: software quality and delivery speed. Ultimately, everything you measure should have a direct correlation to at least one of the two. For instance, there is no direct correlation between the number of git commits made by each team member and the quality of the software nor the speed at which the next feature reached production. But there is a very strong correlation between your delivery cadence and how long it takes a feature to reach production after the feature was merged to the main branch in git.
• Ensure that you have the proper training and skillsets in place. I once consulted for a team whose manager refused to put training time in the schedule for her staff. They were very well versed in writing software for on-premises systems, but that did nothing to speed up their migration to Azure and Kubernetes. They were fumbling constantly and trying to learn as they went, but it is just such a large chasm to cross that they were bogged down in the technical weeks without having a chance to learn the fundamentals. With just a little time to learn the core concepts of Cloud-Native development, this team would have been up and running at full speed in no time. Instead, they were a year into the project with almost nothing to show for it.
• Define your work and your processes very clearly. If your team doesn't know what to work on or what the flow of work should look like, then you have a major issue.
• Consider the structure of your teams. So many are afraid to touch this one, but it is critical that you get it right if you want to create a high-performing software organization. Structure your teams to optimize communication channels and cross-skillset collaboration. If you're not familiar with how high-performing organizations structure their teams, please read this book.

Speeding Up

This part comes naturally after you slow down. The part where you slow down simply lets you get organized and plan your approach, build highly relevant skills, and reattack with a very concentrated effort. It's counter intuitive, but when you need to speed up, the best answer is always to slow down. And it almost never involves throwing more people at the problem.

I hope you find the courage to consider how your team can slow down and find the necessary missing links to becoming a high-performing software team. I have experienced the effectiveness of this approach time and time again. In fact, I experience it nearly every day when I spend the first 30 minutes planning my day, considering what's important and how it lines up with the needs of the business, and ultimately putting that plan in my calendar. On days when I do that, I end up accomplishing so much. But when I don't do it, I am all over the place with distractions and a lack of overall direction.