Why Developer Productivity?

Throughout my career, whether I was an individual contributor, manager, or technical lead, I’ve always worked to improve my (and the team’s) developer workflow. Yet some organizations have Developer Productivity Teams. What can they do to help?

There are many ways to think about what a good, productive developer experience is. DORA Metrics capture the end result of how well a team delivers. The SPACE framework captures key factors that enable efficient, productive delivery. One brief definition of the developer productivity function is to help developers deliver high-quality code with as little friction as possible.

Some aspects of developer productivity are basic things developers can just do (if they are willing and able to do them):

• Good, fast, isolated unit tests that enable teams to make changes with confidence that they aren’t breaking anything.

• Continuously refactoring to make the code more modular and maintainable.

• Committing changes in small, frequent increments, in the context of a modular architecture, so you are not spending time resolving code conflicts.

• Maintaining an automated release process, which includes the ability to roll back a release if there are significant errors.

There are more things one could mention, such as using a simple Main Line-based code line model. With these in place, the technical aspects of Developer Productivity are often well on the way to being handled. So why don’t teams do this?

Some of the key barriers to teams improving developer productivity are:

• Lack of knowledge or skill. Writing good tests, or automated deployment processes, requires skill.

• Lack of ownership. In the context of a monolithic codebase, one team may not feel empowered to make certain changes, even if they know how. And if they do, they might not have the knowledge they need. Or another team owns the release process, so a team can’t automate or improve it.

Related to all of these is organizational culture. If you have ever had a manager suggest skipping tests in the name of speed, you may be familiar with how culture affects productivity. (This is distinct from a conversation about the right tests and how to write them effectively.) While this is a larger issue often outside the scope of the team or a Developer Productivity team, there are ways to surface the impact of these decisions through metrics.

While some issues affecting developer productivity are best addressed by the feature teams, a developer productivity team can help an organization bridge some of these gaps through:

• Finding areas with unclear ownership and enabling feature teams to take a more active role in their support and improvement.

• Working with feature teams to bridge knowledge gaps and help teams to be more self-reliant.

• Serving as a conduit to share good practices across an organization. This includes both areas where the productivity team is a subject-matter expert and improvements teams have developed.

There are a few approaches to doing this. Based on my experience managing a Software Test Engineering Team at Fitbit, two important ones are:

• Embedding: Working closely with teams to solve problems

• Building frameworks and tools based on work done for the feature teams we embedded with, or problems discovered.

There may also be support work, and fixing the larger problems that no one is getting to because of lack of ownership, but even with those, having a development team who may benefit from the Dev Pro Team’s work engaged at some level during the process is a key success factor.

While some might consider the embedding to be a poor way to scale work, the experience at Fitbit was that:

• Tools built for a specific problem were often immediately applicable at a larger scale

• Domain knowledge partner teams acquired helped them to be able to support their colleagues.

Much like DevOps, it works best when you think of it as a mindset, supported by a team that fills gaps on feature teams. In the end, it’s about what the team does, but the team may need support.

Developer Productivity is most sustainable when feature teams take ownership of their code, continuously seek ways to improve their flows, and, in turn, share their lessons with others. In the meantime, a Developer Productivity team can be a valuable mechanism for getting teams to that state through support, training, standards, tools, and supporting infrastructure.