Developer experience is one of most important things for a Head of Engineering to care about. Is development safe and fast? Are developers proud of their work? Are our processes enabling great collaboration and getting the best out of the team? 

But sometimes, developer experience doesn’t get the attention it deserves. It is never the most urgent problem to solve, there are lots of different opinions about how to make improvements, and it seems very hard to measure. 

At Tessian the team grows and evolves very quickly; we’ve gone from 20 developers to over 60 in just 3 years. 

When the team was smaller, it was straightforward to keep a finger on the pulse of developer experience. With such a large and rapidly growing team, it’s all too easy for developer experience to be overshadowed by other priorities. At the end of 2020, it became clear that we needed a way to get a department-wide view of the perception of our developer experience that we could use to inform decisions and see whether those decisions had an impact.

We decided one thing that would really help is a regular survey. 

This would help us spot patterns quickly and it would give us a way to know if we were improving or getting worse. Most importantly it gives everyone in the team a chance to have their say and to understand what others are thinking. 

Borrowing some ideas from Spotify, we sent the survey out in January to the whole Engineering team to get their honest, anonymized feedback. We’ll be repeating this quarterly. 

Here are some of the high-level topics we covered in the survey.

Speed and ease

To better understand if our developers feel they can work quickly and securely, we asked the following questions:

• How simple, safe and painless is it to release your work?
• Do you feel that the speed of development is high?

[infogram id=”speed-and-ease-1hdw2jplgzlkj2l?live”]

You can see we got a big spread of answers, with quite a few detractors.

We looked into this more deeply and identified that the primary driver for this is that some changes cannot be released independently by developers; some changes have a dependency on other teams and this can slow down development. 

We’d heard similar feedback before running the survey which had led us to start migrating from Amazon ECS to Kubernetes. This would allow our Engineering teams to make more changes themselves. It was great to validate this strategy with results from the survey.

More feedback called out a lack of test automation in an important component of our system. 

We weren’t taking risks here, but we were using up Engineering time unnecessarily. This led to us deciding to commit to a project that would bring automation here. This has already led to us finding issues 15x quicker than before:

Autonomy and satisfaction

We identified two areas of strength revealed by asking the following questions:

• How proud are you of the work you produce and the impact it has for customers?
• How much do you feel your team has a say in what they build and how they build it?

[infogram id=”autonomy-and-satisfaction-1h7k230qx8deg2x?live”]

These are two areas that we’ve always worked very hard on because they are so important to us at Tessian. In fact, customer impact and having a say in what is built are the top two reasons that engineers decide to join Tessian. 

We’ve recently introduced a Slack channel called #securingthehumanlayer, where our Sales and Customer Success teams share quotes and stories from customers and prospects who have been wowed by their Tessian experience or who have avoided major data breaches (or embarrassing ‘Oh sh*t’ moments!). 

We’ve also introduced changes to how OKRs are set, which gives the team much more autonomy over their OKRs and more time to collaborate with other teams when defining OKRs.

Recently we launched a new product feature, Misattached File Prevention. Within one hour of enabling this product for our customers, we were able to share an anonymised story of an awesome flag that we’d caught.

What’s next?

We’re running the next survey again soon and are excited to see what we learn and how we can make the developer experience at Tessian as great as possible.