During a recent conversation about the developer experience of his employer’s cloud offerings – or more accurately, the lack of one – a senior executive chuckled ruefully and said, “well, like everyone else, we ship our org chart.”
On the one hand, this was an unsurprising response, because it’s something of a truism at this point. Whether or not it’s explicitly acknowledged in this fashion, vendors long ago internalized this idea. Which makes sense, given that the history of this industry is littered with examples of organizations whose products – for better and for worse – reflected the teams and structures that produced them.
On the other hand, however, the sense of fatalism and inevitability to this and other similar statements betrays a kind of organizational learned helplessness. It’s true, of course, that anyone not at the very top of a given organizational structure is unlikely to be in a position to directly alter it – and almost certainly not in any fundamental way. But organizational structures are not unalterable; they are not handed down on stone tablets from a higher power. They’re mutable, and can and have been changed to match the changing demands of a given market in the face of sufficient need.
Microsoft’s org chart in the Azure era, as but one example, is quite distinct from that which guided the company during Windows’ heyday; it was deliberately and consciously adapted because the landscape around the company had shifted dramatically with the introduction and explosive growth of the cloud. Nor was that the only time the software giant had been compelled to rethink its organizational structure by changing market dynamics.
Any company that has been around long enough to see and experience tectonic shifts in the market, in fact, has likely been through these or similar transitions. The organizational structure that’s optimized for one world is likely to not be the best fit for the next. With market change of course comes opportunity, assuming that an organization and the structure which defines it is able to make the necessary changes. The question is not whether it can, it’s whether it will.
Change, after all, is a function of incentive and will, a combination of challenge and response. As then Vice President Biden was fond of saying on his campaign, “Don’t tell me what you value, show me your budget, and I’ll tell you what you value.”
What this all means in practice, then, is that is that there exists a simple heuristic for determining whether and how organizations are responding to a growing demand for an improved developer experience. If rhetoric is set aside, all that’s required are the answers to a few basic questions:
- Do you have a role explicitly and solely responsible for the overall developer experience?
- And if the answer to that is yes, what is their budget, headcount and functional mandate/scope of authority?
The questions are simple by design and have two very basic goals: first, to establish whether or not a given organization has acknowledged the problem with developer experiences today – are they taking the problem, at least, seriously? And if the answer to that question is yes, how seriously – what are they doing about it beyond paying it lip service? How is their budget allocated?
The answers, of course, vary widely, but unavoidably provide an insight into the level of commitment. The reality is that org structures that have been designed to iterate and produce services at scale are not likely to satisfactorily address gaps between the services that negatively impact developer experiences without at least some change. If there’s no appetite for that, progress is likely to be limited.
Which is why an answer that arrives in the form of a rueful chuckle suggests that there’s yet hard work ahead.
