4 Developer Experience pitfalls to avoid
This article is for those on developer experience teams that are seeking to create a reliable strategy for their team. While there is no one perfect way for your strategy to look, there are some common pitfalls in the developer experience space that I hope you can avoid. Below are the pitfalls and tradeoffs I’ve seen in my career–I hope that by identifying them here, you can avoid them to better hit your goals.
1. Losing sight of the vision
Last year I introduced developer experience principles in an organization that had a thriving set of product and platform teams, but that hadn’t yet figured out how to get apps to production quickly.
I joined an existing internal tools team and worked to relaunch with the new developer experience framework. After we relaunched, teams began asking us to build services and infrastructure to support new data capabilities.
While these services would be very valuable for the organization, they did not fall within our scope to improve the developer experience and decrease the time it takes apps to get to production.
While it is tempting to work on high impact products, tread carefully if it is outside your vision. Your organization is investing in your team for a reason. Do the work you set out to do.
Make sure you and your team are crystal clear on the vision and strategy. The clearer your vision, the easier it will be for you and the team to say no.
Now, when people look to you for support, it is an indication of trust in your ability to deliver, and you’ll want to respect and cultivate that. One way to do this is to find a home for these great, but out of scope ideas.
2. Missing the opportunity to find the win-win
So what happens when you say ‘no’ to a feature request? If it is high impact, redirect it to a more appropriate team, and find that win-win.
When I saw a critical mass of data infrastructure requests come to our team, I shared it as research to the organization’s data team. It turned out this was exactly the evidence they needed to secure headcount for their team. Two scoping sessions later, they had a bulletproof proposal that got them the resources they needed.
In these moments look for ways you can actually help. Can you redirect requests to a more appropriate team? Can you host a scoping session to help them define their needs and potential solutions?
What is important here is that you correctly identify high impact work and prioritize finding or creating the right team to do the job.
3. Undefined support expectations
DevEx teams can be internal facing, just like platform and infrastructure teams, but behave differently in that they deliver products that address user needs.
Given internal-facing teams are often service oriented as opposed to product oriented, it’s easy for DevEx teams to slip into a service orientation, which, if not planned, could lead to scope creep.
For example, service teams are often expected to have higher customer support standards than a product team. Metrics for these teams often look like ticket response rate, service level agreements regarding customer support availability, and customer satisfaction.
On the other hand, product teams are expected to deliver valuable features that in turn generate revenue for the business. They are often empowered to prioritize new feature development over direct user support. In some cases, teams like these are often allocated auxiliary customer support in the form of operations teams.
As you build your team strategy it’s important that you decide whether your team is service or product oriented. Not keeping this strategy clear could mean that you slip into expectations that could keep you from realizing your vision.
4. Waffling between business needs and user needs
Similarly, given internal-facing teams are often closer to business needs than end user needs, it’s easy for DevEx teams to slip into a business orientation, which is a break from the DevEx strategy to improve the developer experience.
For example, my team has a vision to help teams get to production faster. So for us, it is clear we must ruthlessly focus on user needs. But it’s not a one time conversation, as a team we realign on our support model every time we get a new customer using our products. And that’s okay.
Discuss with your team where you fall on the spectrum, if left unclear, you run the risk of not hitting your goals.
Have you seen these pitfalls in your work? What others have you seen?
Thank you to Kevin Clark and Ryan Miller for editing support, and to VMware for the time and support to write this article. Credit to Sarah Dresner for creating the DevEx strategy and to Redmonk for insights into the developer experience industry.
