From Developer Experience to Enablement
How developers use tools is important, but it's not the whole story
Quick favor, a new HERETECHS podcast episode featuring Adam Jacob, co-founder of Chef, is out now, would love your likes and comments on my LinkedIn post, thanks 🙏🙏🙏
It was not the startup turnaround story we expected. Airbnb had become a behemoth in the span of a decade, disrupting the hotel industry along the way to a $31 billion valuation. Then COVID hit, forced layoffs of nearly 2,000 employees, whacked the valuation in half, and begged the question if the company would even survive. Then a week ago, Airbnb announced their intentions to go public.
Airbnb was not the only tech startup to throw their hat into the IPO ring. Earlier this week, a flurry of lesser known tech startups filed their S-1’s for a public offering:
Asana – Team based work management (valued $1.5B)
Sumo Logic – Cloud monitoring and log management (valued $1.0B)
Snowflake – Cloud based data warehousing (valued $12.5B)
Unity – Cross-platform game development engine (valued $6.0B)
JFrog –Binary repository manager for DevOps automation (valued $1.2B)
If we take Asana out of the mix, the other four are strikingly similar in one important way. These are companies whose products help the types of teams that a decade ago were thoroughly ignored; developers and IT operations. Now there are four startups worth $20 billion about to IPO in the next few months.
In the 2000’s, it was hard to get any respect if you were building a product for developers. The thinking went that developers do not spend money, prefer open source, and would not make loyal customers. When entrepreneurs came knocking with innovative approaches to easing the work of operations and development, venture capitalists were asking where’s the money?
Then near the start of the 2010’s, three significant events occurred. First, Salesforce bought Heroku for $212 million, catching the attention of VC’s. Second, software developers were in much higher demand as startups proliferated and enterprises began their digital transformation journeys. Then Atlassian went public in 2015. Selling to developers was suddenly cool and very profitable, with IDC saying the market just for DevOps tools to reach $15 billion by 2023.
Heroku could probably be credited with idea that has driven this growing interest in developer tools. As they were describing their product, they introduced the term “developer experience” or “DX”. This is analogous to user experience in consumer and business applications, but to describe how developers engage with a tool to get work done. Before then, those two words only came up in conversations about hiring developers and years of familiarity in a technology.
There is more to developer experience however than just look and feel. The best definition I could find was from Pamela Fox, a former developer advocate at Google. From her presentation at the 2011 WDCNZ conference, she declares developer experience as the following:
“The sum of all interactions and events, both positive and negative, between a developer and a library, tool, or API.”
In the talk, she outlines a five key aspects of developer experience that any developer tool provider needs to consider:
Do developers want to use it? Does it eliminate some tedious task, have the features to get stuff done now and in the future without repercussions?
How do developers sign up? Can developers use it now, or do they have to first deal with a payment gateway, API keys, or salespeople?
How do developers get started? Where are the binaries to download and are client libraries and examples available to guide developers in getting started?
How do developers use it? Is there ample and easy to search documentation, guides, etc. as well as good API design to be productive fast?
How do developers get help? When developers get stuck, are there places like forums, email, Q&A, etc. to get unstuck or find someone they can talk to?
Many tools vendors and open source communities have made a serious commitment to developer experience over the past decade. The most visible display of commitment is the investment in building developer advocate programs. You see advocates (also known as DevRel) at conferences and meetups, on social media with sizable audiences, and on YouTube shows and Twitch streams. Though I have not personally seen it, I wouldn’t be surprised if there was a DevTok channel, with developers doing live code dance-offs.
Scoff as you might (and there are plenty of overly serious developers that do), all of this activity has been hugely beneficial for developers. Developer advocates help ensure documentation is accurate, create more informative guides and workshops, answer questions faster, and make sure feature requests and product feedback actually gets implemented into the product. This has made developer tools easier to use and more approachable even for junior developers, accelerating the value of these tools and the grown of the tools vendors that invest in developer experience.
Developer tools are only one slice of what matters to developers though. When it comes to their jobs, there many aspect of how work is done and what constitutes work that sits outside of tools and code. This is the broader experience of working as a developer that often gets ignored when discussing how to help developers do their best work. These are the aspects of work that vendors and developer experience cannot address.
In developer surveys that ask about productivity, there are a few commonalities. Working with bad tools is a struggle for developers, but the work environment and how work gets done are bigger challenges. This includes hunting for information or answers, waiting on approvals and reviews, attending unnecessary meetings, and responding to emails, Jira tickets, Slack messages, and the hundreds of other random micro-distractions throughout the day. In fact, the top productivity drains mentioned in the Stack Overflow survey were meetings and distracting work environments.
Not all non-coding work is negative however. There are aspects of work that are important in helping developers and the team such as discussing designs and solutions, reviewing customer feedback, writing tests, creating documentation, and learning new coding practices. This is often dismissively called the “glue work” because it sits outside code, but it is just as important as the code itself. Without this work being done, nothing useful would get done at all.
This is the developer experience that occurs inside a team and organization. These are things that occur outside developer tools and it happens to be a bigger percentage of what developers spend time in throughout the day. Some surveys cite over 66% to 80% of the day is not spent coding, which translates into 5 or 6 hours for an 8-hour day.
To distinguish this internal experience, the term developer enablement is often used. This includes all the aspects that helps developers to do their job better from removing obstacles to optimizing processes to improving the environment.
Some companies have started to create a role and an entire team dedicated to developer enablement. This is not a group that just manages developer tools or implements DevOps tooling. These are teams focused on looking holistically at how developers do their jobs to help them be more productive and satisfied at work. When developer enablement becomes a serious initiative in a company, the change in productivity is profound.
It can be easy to mix up developer experience and developer enablement as one can see from the many articles that confuse the two. It is important however to create a clear distinction so that challenges teams face in productivity can be properly addressed. It can be easy to fall into the trap of thinking a slick tool with a fancy demo can fix a more inherent internal obstruction.
The good thing is that developer experience is something developer teams do not have to struggle with. The tools vendors and DevRel teams have done a phenomenal job in helping developers and their customers. What is needed now is for companies to start building developer enablement as a core function in their engineering teams. That is a topic for the next post.
Are there tools that you have found that had a particularly great developer experience and what aspect of that experience was most helpful?
Episode #12 — The transformative power of an Open Source value chain with Adam Jacob
New episode of the Heretechs podcast is here! Co-hosts Justin Arbuckle and Mark Birch welcome guest Adam Jacob, CEO, System Initiative, and Co-Founder and Board Member of Chef, to discuss the transformative power of an Open Source value chain within your business model.
Check out past Heretechs podcast episodes on Spotify, Apple Podcasts, Google Podcast, or wherever you listen to your favorite podcasts. Please like and subscribe 😁