*Based on the interview with Kristjan Ulst & Tiit Hansen
Developers’ time is one of the biggest expenses of a software company. Although we love the myth of 10x developers, developer productivity depends less on personal superpowers than on systemic issues. Are the company’s processes and systems an invisible tailwind for developers or a never-ending obstacle course of coordination, waiting times, and reinventing the wheel?
Concise’s developer productivity team works in the background to make developers’ daily work smoother. For example, all those small and annoying, but ultimately time-consuming activities that fragment a developer’s day are standardized and automated to the maximum. All so that developers can create maximum value with their precious time.
Read more about what the developer productivity team does, how it relates to developer experience, and which companies should consider creating such a team.
What is a developer productivity team?
Kristjan Ulst, engineering manager of the developer productivity team, immediately refutes the idea that their team would somehow make developers faster: “We don’t make developers write code faster, but our goal is to remove obstacles and make their workflow smoother.”
Most companies don’t have such a team – but maybe they should. Concise’s developer productivity team was initially the team that was given tasks that didn’t directly fit under any business team, such as migrations and other activities. That can sound like they were a dumping ground for ownerless tasks, but the focus is a lot clearer now.
Unlike, for example, a DevOps team that deals with specific problems that have already arisen, a developer productivity team looks at the big picture to prevent problems, reduce bottlenecks, empower developers, and streamline processes.
The developer productivity team mainly deals with four types of tasks:
- Identifying and removing bottlenecks so the developers can solve specific business problems without interruption and don’t get “stuck” anywhere.
- Various broad-based updates and migrations that are more efficient to do centrally so that the developers don’t have to do updates manually.
- Providing ready-made “software pieces” or “building blocks” to developers, with which developers can solve their problems faster.
- Learning & development, or identifying and sharing best practices, so that each team or developer does not have to learn on their own and reinvent the wheel.
Example: Automated migration that saved €100,000 in work time
Concise had to help a client migrate their systems to a new container registry. The change affected dozens of services, but it had to be carried out in a way that would not affect any of them. It is very easy to build something new, but it’s much more difficult to migrate old solutions on a large scale.
If each developer had had to fix their code manually, both communicating and implementing the changes would have taken an enormous amount of time, caused a lot of confusion, and the developers’ main work would have been at a standstill. The developer productivity team automated the entire process. A total of 88 automatic pull requests were created, which saved an estimated 100,000 euros worth of working time.
The solution is comparable to having 88 trucks all needing their tires replaced. If each driver had stopped working and started organizing the tire change themselves, it would have caused a lot of time and hassle. Automation is comparable to having a special team that changes tires almost unnoticed alongside their daily work – so that the main work continues uninterrupted.
Read more: How Concise Helped Arrive Automate a Fleet-Wide ECR Migration and Save 1,000+ Developer Hours
Why it’s worth doing small things on a large scale?
Many things steal a developer’s time on a daily basis – from meetings to how easy it is to test a new environment, etc. When hundreds of developers wait 5 minutes every day for some obstacle, the time spent is insane. That’s why the developer productivity team looks for small problems that affect as many people in the organization as possible.
For example, if you take a small individual change that people need to make in many places, it’s very time-consuming. In the end, it’s easier and cheaper to make a small script that makes this change everywhere at once. Similarly, when one team invents a solution, the developer experience team takes it to all other teams so that other teams don’t have to waste time investigating and solving the problem repeatedly.
Finally, this approach also helps to standardize small tedious activities and processes, which reduces complexity and errors.
Combating accidental complexity requires conscious action
No one deliberately builds complex systems, but as systems grow and develop, random complexity inevitably constantly grows. In physics, there is a concept called entropy, which characterizes the degree of order in a system. It always goes from higher to lower – a fully inflated car tire will deflate over time and will not fill up on its own.
Complexity adds up faster if no one is doing anything to combat it. This is where the big picture view of developer productivity comes into play, which looks at processes as a whole. For example, migrations are key to combating random complexity.
Something that worked or justified itself in the beginning becomes obsolete as the business changes or grows. At some point, you have to realize that instead of improving or repairing the old solution, it’s time to throw it away and start using the right tool. Figuratively speaking, a screwdriver is a very good tool, but a rather bad solution for driving a nail into a wall.
Developer productivity and developer experience go hand in hand
When it comes to developer productivity, many developers fear that their code will be scrutinized and measured with a ruler. This is the exact opposite of the Concise culture, where psychological safety and developer autonomy are important – developer productivity actually supports both.
The developer productivity team can also be considered the spokesperson for developer experience, because one does not work without the other.
- Productivity = are the right things done correctly and efficiently
- Experience = what is the developer journey and environment like
Kristjan explains that their team quietly creates an environment where developers can thrive and focus on what they do best: “The best experience is when the developer doesn’t even realize that someone is taking care of it.”
A good developer experience can exist without productivity, but productivity without good experience not so much. For example, a developer who plays ping pong all day can have the best experience in the world but zero productivity. If something on the productivity side makes a developer more efficient, the developer will also have a better experience. “If you have to do the same thing day after day, both your experience and productivity will be poor,” Kristjan explains.
Removing small obstacles helps developers do their best work
Flow state and deep work play a big role in developer productivity. The company’s work culture and environment should encourage developers to have as little context switching as possible and as much flow state as possible.
There are two prerequisites for flow state and deep work:
- You have to be good at what you do and
- What you do must be interesting to you
For example, if you make a good developer simply rewrite some software, he may be very good at it, but it is not interesting to him at all – flow state does not occur and the experience is, to put it mildly, bad.
This means that all these little things that are not worth mentioning, but prevent the flow state from occurring for a developer, are ultimately “death by a thousand paper cuts” – a major stumbling block to developer productivity and satisfaction.
3 best productivity practices every development team should implement
Regardless of whether a company has 15 or 500 developers, it’s worth keeping in mind 3 principles to promote developer productivity.
- Helicopter view and preventing problems – one of the most important roles of the developer productivity team is to systematically monitor how the organization is doing, how the developers are doing, and how the team can make developers’ lives easier. Surveys and interviews are conducted to identify large and small pain points, and an active Slack channel is in place to address concerns.
- Documentation and central solutions – it’s important to avoid a situation where each team solves the same problem separately. Therefore, the developer productivity team does a lot of documenting best practices, so they can proactively offer best practices and solutions to the developers. Central documentation also helps keep solutions consistent and avoid repeating errors in different teams. Overall, the goal is to identify and consolidate as many activities, pieces of work, changes, etc., as possible that affect as many people as possible – no matter how small the concern is – and make them as automatic as possible.
- Removing bottlenecks – the most time-consuming activity is human interaction. When there are multiple links in information exchange, the feedback cycle becomes long and problem-solving slow. Therefore, the developer productivity team tries to proactively provide developers with all the right tools and instructions so that they can do their work as autonomously as possible and with minimal coordination. Along with freedom, responsibility also moves to the product team level, which in turn motivates developers to do the best work possible, because they have to solve any problems that arise themselves.
5 things this helps achieve:
- The processes are as standardized and simple as possible.
- Teams and developers don’t have to reinvent the wheel.
- Updates and migrations are faster, more efficient, and more secure.
- This saves the time and energy of the developers, which can be used to solve more important problems.
- The developers have an overall better work experience – and this increases both satisfaction and results
Does every company need a developer productivity team?
Concise’s developer productivity team currently has 6 people, but there are 600 developers in total in the client’s project. Kristjan admits that the workload has actually reached its ceiling and they need to carefully consider which problems affect as many people as possible.
But where is the line at which a separate developer productivity team makes sense? It is estimated that a separate team starts to have a clear impact with 200–300 developers. There is a big difference whether you save 5 minutes for 10 people or 500 people. With more people, complexity also increases and the benefits from optimizing processes are greater.
But even if there is no point in creating a separate team in the company, management could be aware of the principles of developer productivity.
The most important thing for efficiency is to look at:
- Are the developers doing the right thing?
- Are they doing the right thing right?
- How does the team work together overall?
How to measure the performance of a developer productivity team?
According to Kristjan, prioritizing problems is actually extremely difficult, because when looking at each problem, you have to think about how many people it could actually burn, i.e. how much benefit there is from solving it.
The success of a developer productivity team can be measured mainly through two indicators:
- How much developers’ time has been saved.
- How much the quality has been increased – for example, security has been increased through the automation of certain processes.
A third result can also be a good developer experience, but this is difficult to measure because people usually don’t know how to appreciate a good thing when it exists, because it seems so natural.
According to Kristjan, developers often discover only when going to work at a new place that some things were much easier in the previous place. Therefore, the ultimate indicator of developer experience is, when a developer leaves you but comes back.
Finally: create a culture where developers can do their best work
People often talk about “10x developers,” but if a great engineer gets tangled in processes, coordination, and endless meetings every day, it’s impossible for them to be effective. A 10x organization, on the other hand, is very possible – if the culture and tools support autonomy and allow developers to create maximum business value.
Ultimately, the question isn’t whether you have a separate developer productivity team for it. The question is whether your organizational culture allows each developer to do their best work?
Stepping your first steps in developer productivity & experience world? – Use our experience and competence and take us on board. Get in touch with us bellow ⬇️
