Made by
Made by
USS Enterprise
Enterprise or start-up? It’s a question that often comes up in dev rel.
Particularly when thinking about who our developers are, it feels like an easy distinction to make. Once you’ve decided that something is enterprise software or that a group of people are start-up developers, then all sorts of prejudices and assumptions come tumbling after.
And, like all prejudices, they’re more useful in telling us about our own view of the world rather than about the people we hope to work with.
At their best, “enterprise” and “start-up” open the door for deeper thinking about who our target developers are. At their worst, they’re lazy stereotypes that actively get in the way of understanding.
So, how can we usefully distinguish the cultural and business differences between, say, a VC-funded start-up in Mountain View and a three hundred year old bank in Zurich?
Let’s unpack those terms “enterprise” and “start-up”.
High rise buildings
Primarily, it’s a culture thing. We think of enterprise companies as slower moving. They have layers of approvals and management. Dress-down Fridays, Concur, and coffee you have to pay for. In this view, enterprise means relatively stable but ultimately boring.
Taken a step further, the way that we talk about enterprise often unveils a feeling that individuals are expendable. In this view of enterprise, technology is an enabler of some other goal; it’s a cost-centre to be rationalised by non-technical management and, perhaps, outsourced.
Other than culture, enterprise means big and rich. Combined, we see enterprise software as bloated, expensive, hard to use, and sustained by the ability of sales people to buy fancy lunches for procurement managers.
Of course, this is a caricature. Nonetheless, it’s the prism through which many of us in tech view older, larger companies and the software they use.
Table football
So, what about start-ups?
Start-ups are where dev rel flourished. Much of what we think of as developer relations practice is a collection of start-up memes packaged for redistribution. And the rest was borrowed from open source culture.
Tech talks and beer. Standing on the shoulders of giants. Cult of personality, foosball, and changing the world.
Again, a caricature. But, like all caricatures, possibly useful in helping us see something familiar in a new light.
Understanding the developers who use your product, and whom you want to use your product, is crucial to creating a dev rel strategy.
If we think of our product as being better suited to enterprise developers or start-up developers then, perhaps, it tells us something about how to proceed. And it’s at this point that the limitations of these labels become apparent.
Take Google, for example. With more than 100,000 employees, it’s certainly big. But would you ever think of Google as enterprise?
What about Monzo? It’s a bank but has a culture, outlook, and funding model that are recognisably start-up.
Okay, those were easy. Here’s a harder one. What about Bluetooth SIG Inc? It’s a membership organisation that defines and promotes the technologies that fall under the Bluetooth banner. Is it enterprise? Is it start-up? Neither label fits perfectly; maybe neither labels fits at all.
The approach that we take to serving a particular group of developers depends on many more variables than a binary choice between two rather imprecise categories.
Instead, we need to understand as many of the nuances that shape a developer’s profession, life, and worldview as we can.
Let’s find a way to capture some of what we mean by enterprise and start-up, but in a way that allows for more subtlety.
Company size has a meaningful impact on how we approach developer relations. For example, most large companies have more layers of decision making than typical smaller companies. Size might also bring regulation, different resilience needs, and so on.
Size gets used as a proxy for culture, too. But, as we see with Google, Microsoft, and Oracle, large companies of similar size can have very different cultures.
A useful companion to size is the role that tech plays in the company’s strategy. Is tech the differentiator or is it just an enabler?
Think back to Monzo. What makes Monzo different from legacy banks is that, for Monzo, the tech comes first. For many legacy banks, tech is just another cost centre.
So, perhaps a more useful replacement for enterprise versus start-up is to find where the developer segment, company, or product falls on a graph where one axis plots size and the other plots tech-centric versus tech as enabler.
Tech role and company size
When thinking about developer relations strategy, we need to gain a deep understanding of our target developers and how they perceive our offering.
Short-hand, such as enterprise and start-up, are stereotypes rather than useful segmentations. We need to consider many criteria in developing our strategies.
Plotting where something or a group of people fall on the chart of Tech as enabler vs Tech-first and Small company versus Big company is a useful replacement for some aspects of enterprise versus start-up. However, it’s just the start of a deeper segmentation process.