Beware of becoming a bottleneck: Tips for developer experience teams

In?another article, I wrote about how we shaped our developer experience team and why we decided on this team constellation.

This article delves into the interaction modes of the Developer Experience Team at BRYTER, which provided tools, services, platform components, and documentation that other software development teams relied upon. It describes the team's oscillation between platform team and enabling team mode. The article explains the three pillars that form a solid offering for developers: usability, findability, and credibility.

Additionally, I share how developer experience teams can prevent becoming a bottleneck and avoid restricting the freedom of other teams.

Two main interaction modes?

In the developer experience team at BRYTER, we mostly worked as a platform team. As a platform team, we provided tools, services, platform components, and documentation that other teams could rely upon.

But: Sometimes, more than just working in a platform mode and providing components for other teams is needed. Frequently, we found that our work also influences how other teams can work. For example, when we introduced?release toggles?in 2021, part of our work was to document the feature and implement the abstractions. However, providing the components and hoping for other teams to start using them, which might also entail a change in how they work as it enables better development practices, is too optimistic.

Thus, we realized that it is beneficial for us to work closely with other teams and therefore switch more into an enabling mode. In such a working mode, we would make an effort to join teams for team programmings around specific topics where we can help them to adopt the technologies we provide.

Working as a platform team?

As a platform team, we needed to work on three pillars that form a solid offering for developers. These pillars are very similar to what you would aim for in?normal?product development:

1. Usability
2. Findability
3. Credibility

Usability?

Our goal was to make the lives of developers easier. Therefore, our offerings needed to be easy to use, and developers needed to know how to use our services and components.

Aiming for high usability increased the likelihood that people used our?products?and led to higher adoption rates.

Findability?

The best usability is worth nothing if people do not know about your products. This is true for companies as it is for developer experience teams.

As a platform team, you also are your marketing and sales team to a certain degree. It would be best if you made sure that developers understand what you offer and which problems of theirs you are solving with those products.

There are many approaches to increase the findability of your offerings. First, ensure that you have the appropriate amount of documentation in a place where developers would usually look for. Second, you can also give training and presentations and announce updates and new?products?via internal communication channels like Slack.

At BRYTER, we posted a weekly update with exciting changes to other teams. Furthermore, we announced more extensive news individually in Slack or as a tech fair presentation. In addition, we sometimes facilitated cross-team programmings to share knowledge about platform capabilities and get direct feedback from developers.

Credibility?

It is crucial that developers can trust your offerings. This means they should work as expected and not be surprising in their use.

Therefore, they should behave as documented, have good quality, and be stable. Especially if you change the APIs of your offerings or frequently deprecate some of them, people will lose trust as you give them a lot of work, which might eat up the benefits.

Furthermore, it is beneficial to aim for consistency in your different offerings to reduce space for surprises.

Working as an enabling team?

When working in an enabling mode, the work is less about providing a?product?and more about helping teams understand and adopt those products or practices that might benefit their work.

As a developer experience team, constantly shifting between those two modes has many benefits:

Foremost, you increase the adoption rates and ensure people understand your offerings. Second of all, you get immediate feedback from your?customers. And third, you stay in close contact with the other teams and get a feeling for their biggest pains and struggles.

Working in an enabling mode can mean many things. Parts of your team might temporarily join another team to work with them together on a particular topic. This can be days, weeks, or even months. The goal here is to build up knowledge in the other team so that it can work entirely independently in the end.

It can also mean facilitating team programmings around specific topics where your team discovers a slow adoption or a lack of knowledge.

In general, you have to make yourself approachable to other developers and teams and have a?customer-oriented?mindset.

Disclaimers?

Do not become a bottleneck.?

As a platform team, you are at risk of becoming a bottleneck. Especially if you do it wrong, you mustn't do the work for other teams, like implementing parts of certain features or setting up and maintaining their deployment pipelines for them. Instead, it would help if you made their work easier, i.e., by developing abstractions that make working with the CI/CD pipelines less cumbersome.

Therefore, if other teams ask questions about those areas, do not just do the work for them but pair up with them and ensure that after you are gone, they can maintain the solution on their own.

It is essential to communicate this frequently, as other teams might have a different understanding of a developer experience team. It might wait on that team to deliver specific solutions or make certain decisions.

You are not the police.?

As a developer experience team, you will get a broad overview of the various working styles of different teams. Frequently, you might see something that does not fit your understanding of good software development practices, or you think you know better how others should do their job.

Whatever it is, you must not restrict the freedom of other teams. Sure, you can consult them and give them some impulses, but you can never force them to work in the way you would prefer.

Force will create resistance and will also lead to frustrated developers. This can sometimes be difficult as it feels easier to just decide which test framework all teams should use, which testing style, and how they should document their work. However, this will never work eventually, as people might stop thinking and blindly do what you say without understanding. Or they may quit and find another place where they are freer to do their work as they like.

Thus, if you want to influence how people work, you need to enable them and help them attain an intrinsic motivation to follow your path. In other words: Help them to understand why your way is better, but do not take away the different methods from them.

Summary?

As a developer experience team, we moved continuously on the spectrum from platform to enabling mode. Depending on the topic we were working on, we found ourselves more on the one or the other side.

It was highly beneficial for our team and other teams to be mindful and flexible about the working modes, as sometimes better results can be achieved by not sticking to one of the extremes.

Are you working in a developer experience team? What is your primary operation mode? Share your insights here in the comments!