Part 2 of our Developer Experience Series.
A friend (thanks, Dees!) flagged a McKinsey article that makes the case for the importance of a good Developer Experience (DX). This is an interesting development.
Developer Relations topics appearing in mainstream business literature is an important and encouraging step towards wider recognition of the importance of Developers and the practice of Developer Relations, so is naturally something we are keen to highlight and support.
It’s a detailed article at some 1,600+ words, and the authors define the benefits of delivering a good Developer Experience as:
Talent attraction and retention
Productivity and cost savings
Consistency and quality
Security and compliance
Speed
As external benefits like increasing product adoption, brand awareness, and revenue are not listed, this suggests the focus of the article is solely on the internal Developer Experience inside a company.
Interestingly, the authors include the distractions software engineers have to endure inside organizations within their definition of Developer Experience - doing email, attending emails, fighting internal process, etc. - implying that companies who minimize the distractions and bureaucracy will be more attractive to prospective hires in a competitive labor market.
RELATED ARTICLES
We’d suggest this is perhaps a slightly simplistic take on the realities of working in any modern organization. It also - no doubt unintentionally - implies that Developers are just there to sling code all day long without interruption, with little to contribute to the wider organization. We are pretty sure 99% of employees in most companies would bemoan they have too much email and attend too many meetings. It’s not a problem unique to Developers.
Developers do need to be participating in the wider company discourse to ensure they understand ‘the why?’ of their role and to see the impact their work has. Clarity on this context is a compelling reason to work for a company and goes a long way in ensuring a developer is proud to say, “I made that!”.
Distinctive DX is defined in the article as a singular platform that brings previously disparate elements together, including:
Infrastructure and development tooling, including documentation, demo environments, and fast self-service onboarding with one-click deployment
Presented in an app-store-like environment based on a structured service catalog
Reduced complexity, via a standardized technology stack with built-in security and reusable components to speed up delivery and maintain consistency
Asset transparency through centralized status tracking and version control
Key performance indicators (KPIs) and dashboards to measure and compare performance for KPIs like velocity, tech debt, error rate, mean time to recovery, and infrastructure cost.
Would an organization be prepared to rip and replace everything to consolidate into a single platform from a single vendor, even if they technically could?
We would also suggest that a platform alone is not the silver bullet. You need to consider the Developer touchpoints, which likely span multiple departments, strategies, objectives, and personalities.
The Developer Journey Map is our attempt to visualize the Developers end to end interaction with your company or product. It plots the Developer’s direction of travel, the goal of the developer at each stage, and the individual touchpoints that contribute towards the successful completion of the Developer’s journey.
It should be noted that our Developer Journey Map is oriented through the lens of an external Developer program, but much is reusable for an internal setting. It is offered under a CC:BY:CA license so we would welcome adaptation for an internal context.
Successful DX is as much about interdepartmental collaboration and alignment around common objectives as it is about technology solutions.
We developed the visualization below to illustrate how the metrics and objectives of different departments can be aligned around the needs of the Developer. Again, this was originally created with an external Developer program in mind, but the same approach could be adopted to identify and align departments around the needs of an internal Developer.
We hope this reaction is additive to the original article and is not intended as a criticism of the work. The opposite is true, we are delighted to be in the position of writing our first ‘reaction’ post, and congratulate McKinskey for highlighting the need to consider Developer Experience. We look forward to seeing more Developer Relations related articles appearing, and if you found this useful, we may do more reactions in the future.
Don't miss new posts. Get email notifications by subscribing to our blog.