The Importance of Developer Productivity in a Recession

When times get rough, companies and investors get more cautious with how they spend and invest their money. Many companies reduce their spending on employees and salaries by laying off large numbers of people.

More than ever, this increases the need for companies to think about how to involve their remaining workforce in the most effective and cost-efficient way.

Developer productivity is a topic, that becomes more important when companies need to save money. If you cannot hire your way out of a productivity issue, you need to make sure to get it solved with what and who you have. While this is also partially true in a booming economy, it becomes crucial in gloomy times.

When you cannot compensate for inefficient manual processes or flaky pipelines by throwing more people onto the problem, you must make sure to remove those impediments. This guarantees, that the remaining people can dedicate their full potential to evolving and maintaining the product.

Slaughtering the developer productivity team is a bad idea

Companies that are in the lucky position to have a team specialized in developer productivity should try hard to keep it. Usually, those teams have a very broad understanding of the system, other teams, their needs, and issues.

Furthermore, they are trained to see issues and find efficient solutions regarding developer productivity. Especially when everything changes, you want those people in your company to quickly adapt to the new reality.

If that team is destroyed, this is a gamble and a slippery slope. Maybe, in the first weeks, you won’t notice much, as the solutions maintained by that team continue to work for a while. But also, their ongoing effort of helping teams to improve their builds, tooling, and pipelines will stop, and thus the situation will worsen.

After a while, builds are slow, and flaky and nobody knows how to use the monitoring systems or improve the pipelines anymore. The remaining developers are busy figuring out how to get their performance problems under control, and not with shipping features or improvements.

Removing a developer productivity team from a software company is similar to a racing team that fires its box crew. For maybe an additional round it somehow works and subsequently, the racer needs to change tires on their own. — Not a good idea.

“But we cannot afford a whole team for this anymore”

Unfortunately, some companies are in a troublesome situation and cannot afford to keep a team solely focused on developer productivity. I get that.

However, I still think that it is valuable to keep the people on that team in the company. If they are up for the new reality, they could be an excellent addition to feature teams for the following reasons:

1. If the productivity team was built up internally, the engineers on that team know the product and the platform extremely well and have worked on a feature team before. Thus, they already have remarkable knowledge about the system.
2. Furthermore, they possess extraordinary knowledge about all the things around them that many engineers do not have to that extent. Such as build tooling, CI/CD pipelines, cloud infrastructure, monitoring, and more.
3. Moreover, they have a special mindset and perspective on the system, as their concern always will be to keep productivity and experience high.

Therefore, if the developer productivity team is up to split for some time (i.e. three to six months) to join other teams, they will bring invaluable knowledge and mindset into those teams while actively developing features with them.

This approach also has another benefit: The people on the developer productivity team get a very hands-on experience on how it is to work with their solutions, and they will see problems and potential in the way how teams work.

When, eventually, the team comes back together, they have an even more profound understanding of their “customers”. — How cool is that?

Developer Productivity vs. Developer Experience

Beginning of 2022, I wrote an article “Should we focus on developer experience or developer productivity?” where I made the point, that we should focus on developer experience, as it is more human-centric.

In this article, I predominantly use the term developer productivity. Why?

To me, those two term are synonyms, each having a little different taint. However, what I have learned this year is, that while your colleagues like a team that takes care of their experience, some investors might not see the necessity of it.

I get that, too. If you do not have a more in-depth understanding of software development, how should you see that you cannot separate experience from productivity and that engineers usually enjoy being productive? For outsiders, experience sounds more like nerf guns, neck massages, and after-work beers.

While we still call our team at BRYTER “Developer Experience”, I am inclined to use the term “developer productivity” much more often, to help people understand, that those teams focus on making others more productive.

Getting Started with Developer Productivity without Breaking the Bank

From my experience, developer productivity teams can be very beneficial if your engineering team exceeds a size of 20-25 engineers. However, it is not always possible to hire such a team internally or externally. So, what can you do instead?

First and foremost, creating a culture and mindset that is geared towards engineering excellence and developer productivity is a great first step. Engineers should have productivity always on the back of their minds and get alert when processes feel tedious or builds slow down.

Second, you can spend focused efforts on removing the most critical blockers that reduce the productivity of your developers.

I can help you with both.

Are you interested in bringing your companies’ developer productivity to the next level? — I offer you a free 30-minute discovery call. Together, we will identify the next steps that will help your team to become more productive and enjoy work more. — Just find a slot here. I am excited to meet you!

See all my offerings for unblocking your engineering organization here.