Sven Peters, Atlassian: Wait time is the number one productivity challenge developers have

At this year’s Shift Conference in Zadar, one of the speakers will be Sven Peters, Developer Advocate at Atlassian. He has been studying trends in software development for the last 20 years, uncovering the cultural and technical attributes to help development teams work effectively and drive innovation.

We discussed with him strategies for enhancing and monitoring developer productivity in the face of constant innovation and change within the tech market.

A happy developer is a productive developer

What are the critical challenges that modern software development teams face today, which impact their productivity?

Sven: Different teams face different challenges. Some might have huge issues with the technical debt, while others need help developing the right things. A happy developer is a productive developer. That’s why we call it Developer Joy.

We conduct internal developer joy surveys to find out what critical productivity challenges developers have. Here are the three things that most teams are struggling with:

• Wait time: The amount of time developers spend waiting. Some examples of this are build time, test time, time spent waiting for code review, and time spent in extra meetings.
• Access to tools, processes, and practices: The effort it takes to discover and onboard a new tool, process, or practice that the team needs or would benefit from.
• Execution independence: The team can deliver what you need without depending on other teams, regardless of who owns the code.

Could you share some insights into coordinating work across different teams, especially in larger organizations?

Sven: I’m a huge fan of team autonomy. Autonomous teams that own a task end-to-end. Now, this sounds great in theory, right? You have designers, product managers, developers, IT operations, and testers in one team. The reality looks almost always different. Teams have a lot of interactions with other teams. The larger goal that spans different teams needs to be clear.

If teams don’t have a common goal, it’s hard to encourage collaboration. Being open, listening to each other, and trying to understand problems and challenges are the basis for team collaboration.

Systems need to be open, too. If teams openly share their plans, challenges, and upcoming tasks, other teams can easily align their plans.

We use tools like Confluence and Jira, and we don’t lock anything down. Everyone can see what other teams are doing, comment on it, and ask questions.

Collaboration challenges are a HOW-to-work problem, not a WHERE-to-work problem

With the rise of remote work, what strategies do you recommend for maintaining efficient collaboration among distributed teams?

Sven: Distributed teams are something that has always been there. Even if teams worked in the same building but on different floors, they were distributed and needed tools and meetings to coordinate the work.

Remote work added that the team members needed to adopt a distributed working style. I have worked remotely for 12 years. It offers me a lot of freedom, and we have all the tools that make distributed work easy. It’s more of a human challenge.

It’s hard for many of us to meet our teammates only in Zoom meetings. Things like brainstorming, creativity, and new plans work better for me in person. The social aspect is another challenge that remote workers are facing.

That’s why Atlassian has a distributed work policy called Team Anywhere. Atlassian is the largest organization committed to distributed work, and it works for us. We’re doing things differently. What I mean by that is:

• We have a robust office culture, and all our offices are well-attended, but office attendance is not required.
• Our teams are located across the globe + organized by time zone; teams don’t work shoulder to shoulder, and they are not co-located – they work through our tools
• Teams drive connection through onsite gatherings, not sporadic office attendance

The productive work discussion shouldn’t be about office or remote work. Today’s workers are plagued by back-to-back meetings, overflowing inboxes, vague goals and processes, and minimal clarity on how to drive projects forward. None of these problems can be solved by bringing people back to the office.

These are HOW to work problems – not WHERE to work problems. We urgently need to build new ways of working that help us prioritize the most important work fastest — and drop the time-wasting performance of surface-level pings across a dozen inboxes.

The reality is that every company needs to build new, distributed-first ways of working because every modern organization at scale is already distributed — so these new ways of working need to prioritize a reality where work does not happen shoulder to shoulder.

Isolated dashboards show numbers but don’t tell the story of developer productivity

Striking a balance between development speed and code quality can be challenging. How do you suggest teams approach this delicate balance?

Sven: There is no speed without quality in the long term. If the technical debt increases, the development speed will go down. Sometimes, it might be a trade-off to say we must build this feature and improve the quality later, but this game is dangerous.

I recommend labeling bugs, features, and tasks, whether they help to improve the business or help to run the business.

Teams better understand how much time they spend on scaling infrastructure, fixing bugs, and improving code quality vs. working on shipping value to customers. The number might change over time, and the team should openly discuss why this is happening.

I’m not a big fan of just looking at quantitative numbers, but there’s a reason why the 4 DORA metrics consist of two quality and two-speed indicators. It’s always a balance.

Measuring developer productivity can be subjective. What metrics or strategies do you advise teams to use to gauge their productivity effectively?

Sven: I recommend using a mix of quantitative metrics (that systems deliver to you) and qualitative metrics from surveys. Teams that constantly measure their cycle time, deployment frequency, change failure rate, or whatever is essential for the team have a good feeling about the software development. If a number changes significantly, the team needs to talk about it.

At Atlassian, our engineering teams are running a ritual that we call CheckOps, where we come together as a team to look at the metrics and context around the metrics. Even if the team notices that the cycle time went down, it doesn’t mean they need to change anything. If the team had to work on an incident in production or work on a complicated part of the code, it’s natural that the cycle time will suffer from this. There’s no problem.

We found this ritual of regularly checking the metrics with a human approach so helpful that we built it into our tool, Compass. In Compass, you can see the metrics and events during a period and run a CheckOps to document what actions the team wants to take. It helps us tremendously in improving our developer experience.

That’s why an isolated dashboard doesn’t make much sense to me. They show the numbers but don’t tell the story. Humans do.

How can these metrics be translated into actionable insights to drive continuous improvement?

Sven: Great question. That’s where the surveys come in. I told you that we identified wait time as the number one issue for developer joy. Wait time for builds can be easily measured, but the developers decide if it’s something that needs to be fixed.

Teams should be empowered to make the changes they want to see, but leaders need to provide the space for it.

At Atlassian, we declared that teams are to set aside 10% of their time to fix developer productivity issues AND plan for it by putting it on their team roadmaps. This ensures that the project doesn’t fall on one person. It puts the responsibility back on the developer teams.

We’re measuring if the time is being used, and we hit the goal already for two quarters in a row. Engineers tell us how much they appreciate having the time to work on the things that make their lives easier and more productive.

The developer joy survey runs regularly, so we’re figuring out if the initiatives developers have been working on positively affect the experience and productivity.

Sitting and hoping things will get better won’t help

Can you share instances where companies used data-backed insights to enhance their development processes and outcomes?

Sven: One of the teams was measuring how long a pull request was open. It was three days on average. The authors of the pull requests were suffering for a long time. They had to return to the code after three days, read through the comments, and maybe fix an issue. The customers had to wait three days for their feature to be shipped.

The team wrote an automatic reminder for reviewers of open pull requests that notified them in the morning. That way, the developers could start reviewing pull requests daily and get into the programming flow afterward.

The pull request time went down to 1.2 days. The authors of the PRs were happy, and the customers were delighted.

Could you share a story or two about how companies tackled development challenges and reinvented their ways of working?

Sven: A few teams were frustrated with the speed of the QA team. It was always the bottleneck to release new features. It wasn’t the goal of the QA team to slow everyone down, so they were not happy about the situation, too.

The QA team became an enablement team. The quality engineers taught the developers how to test the software. Before the programmer started to work on a new feature, QA sat down with them and developed a test plan. After that, the developer implemented the functionality and tested the feature themselves with the test plan. Without a quality engineer involved. There was no drop in the quality, and features were released faster.

The job of a software developer is different from 10 years ago

What key takeaways would you like our audience to remember from this interview?

Sven: Measuring the developer experience is a combination of metrics your systems can provide you and surveys.

No one metric shows how productive developers are. Software development is a creative process; we often solve problems that have yet to be solved. We can’t treat development like a production line.

Improving the developer joy should be the responsibility of the software developers themselves. They know best what needs to be improved. Good engineering leaders empower their developers with the right tools and a culture where engineers can tackle productivity challenges themselves.

A central platform or developer experience team might help with problems most teams face or with running surveys and sharing the results.

Just sitting and hoping it’s getting better won’t help. Let’s identify the pain points, try new things, and bring back the fun into our craft.

Can you also explain your role as a developer advocate? What motivated you to become a developer advocate in the first place?

Sven: Software development is a fascinating field. It’s still a young discipline, and we’re constantly figuring out how to build better software faster without burning out. It’s continuous learning and adoption. The job of a modern software developer is different from 10 years ago. It’s hard for software developers to follow the latest trends, adopt new working methods, and deliver new features simultaneously. As a developer advocate, I can help those software teams to show what’s currently industry standard, how leading organizations are developing software, and what trends are coming. I like to help developers do a better job with more joy. That’s my motivation. That gets me out of the bed every day.