Month: July 2023

Live as our customer

This principle is something that feels very intuitive at first blush, but in my experience, is rather challenging to adhere to, especially as a team.

I will present this principle as resolving a tension between two forces that are very familiar to me in the realm of developer experience. I am pretty sure that these forces are still present in any other product development, albeit they may have different specific traits.

When building developer products for others, we often have a situation where the development environments that our customers have are different from ours.

They may use different stacks, build systems, or apply different processes from ours. Conversely, we may have our special tools that we’re used to and our particular practices that we employ to be more productive.

This difference forms the basis for the tension. Clearly, to ship a product that my customer loves and is willing to adopt means that I need to understand their environment. I need to know deeply the problems that they are facing every day: what is difficult? What is easy? Where can I help?

At the same time, I have my own environment that I am very comfortable in, honed by years of practice and incremental improvements. This is the environment that works best for me. This is the environment that I understand deeply, with all its quirks and idiosyncrasies.

The platonic ideal here is that I have it both ways: I deeply understand both environments, am able to hold both of them in mind, and develop for one while working in another.
If you can do this, kudos to you. But more than likely, there’s a bit of self-delusion going on. Based on my experience, this is simply not possible.

Instead, we subconsciously lean toward problems that we encounter in our environments, and tend to be blind toward the ones that our potential customers have. When we ship a thing, it looks like an alien artifact. It appears to solve problems that our customers don’t have, or try to solve their problems in weird, unworkable ways.

Imagine you’re an alien who was hired to be a chef. You’re asked to cook for humans. You can’t eat human food, and some of it looks revolting, honestly. Fried eggs. Blegh. How likely are you to cook something that humans will like?

This tension grows stronger if the difference between the environments is large. Putting it very bluntly: if our developer experience is so different that it feels like an island, we can’t build developer experience products that others will love — or even understand.

To resolve this tension, we must live as our customers. We must strive to shift to as close to the same environment as they have. If our customers use Github as their primary tool, we’d better use Github, as well. If the customers we target mostly use Fortran (bless them!), well then we must learn and adopt it as well.

Applying this principle is usually super-uncomfortable at first. Nobody wants to abandon their well-worn saddle. The new saddle will cause cramps and sore muscles for a while.  Expect a lot of pushback and well-reasoned arguments to return to the trusted old saddle. “This bug tracker sucks! I can’t even use keyboard shortcuts to navigate between issues! Our is so much better!” “OMG, this build system is arcane! What is all this XML stuff?! I thought we were in the 21st century?!”

There’s a kind of test that is built into this struggle. We signed up to build for these customers. Do we actually want to do that?

If the answer is still “yes”, we will find that we will be better off in the long term. We will have a much deeper sense of what our customers need, and where the pain points are. We will be able to spot them early and build things that they want to use.

The rise of makers

It seems pretty obvious that there is some sort of cyclical nature to technological progress. There seems to be a rhythm to how things happen, and many words were written to discern the structure of the cycle. My introduction to the cycle came by way of Tim Wu’s The Master Switch. In that book, the author proposed a cyclical rhythm of open and closed ecosystems alternating as new innovations emerge. Echoes of similar dynamics are found in Crossing the Chasm, The Innovator’s Dilemma, and other books. It’s like everyone is pointing at the elephant and trying to glimpse the full shape of it.

A tiny part of this elephant is the rise of makers. The rise of makers is the time in this cycle of progress when those who tinker and prototype emerge as the best candidates for finding the Next Big Thing. 

Every story of a tech giant’s humble beginning in a garage is the story of makers. My assertion is that the reason why we hear fewer of these stories in some periods of time than others is not because we run out of bright, entrepreneurial minds and certainly not because we run out of garages. Rather, the prominence of makers is a function of the cycle of technological progress.

Put differently, makers’ contributions result in significant outcomes in one part of the cycle and shift to the margins otherwise.

📻 Who are makers?

Perhaps I could back up a bit and start by describing what I mean by “makers”.

Makers are tinkerers and prototypers who are engaging with a new technology not because they have to as part of their job, but because they find it irresistibly interesting and fun. I like to say that developers are “9-to-5-ers” and makers are “9pm-to-early-morning-ers”.  This might not be an entirely accurate description, but it captures the spirit. It also hints at the key property of a maker: it’s not a kind of person. It’s a mindset. The same person who puts in their work hours at their day job becomes a maker extraordinaire in the evening or weekends.

Makers make stuff. They aren’t here for entertainment, fame, or other promise of future boon. They get their hands dirty. They build stuff. In the language of Crossing the Chasm, they are the kind of early adopter who doesn’t just adopt the tech. They make new things with it.

Makers play with technology, rather than apply it to achieve business goals. They delight in finding weird quirks and twists, the same way gamers love finding glitches that lead to a speedrun. They find all of your design flaws and unintended side effects – and turn them into a feature. The whole process is messy and often in the “life, uh… finds a way” manner – what makers make may look very different from the technologists’ intended range of use.

Makers write crappy code and wire things on breadboards. They rarely care about the future enterprise strength of their project. They explore ideas non-linearly, random-walking. They scrap half-finished projects and repurposing them into the new ones. All this contributes to the seeming disarray of the maker scene. A good sign of a maker project are fix-forward collaboration practices. 

Makers are here to discover something new, to bravely explore. They crave being first to uncover some way to make technology do a thing that nobody else had seen before. Makers become increasingly more disinterested with a particular technology as it matures and becomes polished. Polish and reliability mean that the tech has become mainstream – and thus, less likely to yield a “holy crap!” moment.

Being a maker means being in constant search of that moment. When the thing finally works and goes viral on Twitter, and investors come knocking – it’s a maker’s dream come true. Often, it’s also the end of a maker’s journey. Once the new big thing is found, makers shift to become businesspeople. The fun hobby project grows into a rapidly growing team around the newfound thing. Not all makers choose that path. After all, the thrill of exploration does get replaced by the mundane concerns of running the business. However, those who do, they wield power to reshape and create industries.

… At least, when the conditions are right.

🧫 Conditions for makers’ rise

When a novel technological capability moves forth to acquire an interface, and a broader audience begins to interact with it, there’s a question that hangs in the air: “What is this thing actually good for?” 

This is the value question. Whoever answers this question first gains a temporary advantage: until everyone else also figured it out, they can seize the opportunity to acquire this value.

Makers arrive at the scene right about then. They start poking at the interface and make things with it. The amount of power makers will have at this point depends on whether or not they can answer the value question sooner than anyone else.

What are the properties of the technological capability (and the environment it is introduced into) that put makers in the driver’s seat?

I’ve been thinking about this a bit, and I keep coming back to these three: 🔒 access to technology, 🏞️ openness of space, and 🚀 iteration velocity.

All these properties interact with each other, so they aren’t exactly orthogonal.

🔓Access to technology is both the property of new technological capability and its environment. It is probably best measured in the number of makers who could practically start using the capability.

It is the property of the capability because technologists who introduce the interface can choose to make it more or less accessible. It is also the property of the environment, because other, adjacent technological advances may make the capability more accessible than before.

A good example of the capability becoming more accessible due to shifts in environment is the introduction of widely available high-speed Internet. Without any discernible change in how the Web worked (no change in capability itself), the increase in bandwidth created new opportunities for makers to spur what is known as “Web 2.0”.

🏞️ The openness of space is reflected by the number of new opportunities created by the introduction of the technology. A good marker of a wide-open space is that a typical market-sizing exercise keeps collapsing into a fractal mess, creating more questions than answers. It’s not just one thing that suddenly becomes possible, but a whole bunch of things – and there’s this feeling that we have only scratched the surface.

Open spaces favor makers, because they require random-walk and large quantities of participants to facilitate the ergodic exploration of the space. Well-established players tend to be subject to their embodied strategies, leaving them unaware of vast portions of the space, and thus highly vulnerable to your usual innovator’s dilemma and counter-positioning.

🚀 Finally, the iteration velocity is what gives makers the edge. Makers rule tight feedback loops. The shorter the lead times, the more likely makers will show up in the leaderboards. If something can be put together quickly, count the makers to stumble into a thing that actually works. Conversely, if the new technology requires lengthy supply chains and manufacturing processes, makers would play at best supporting roles.

Iteration velocity is also influenced by the level of stakes in the game. The higher are the stakes, the less velocity we’ll see. For example, we are unlikely to see makers playing with passenger airplanes or power grids. Those are the areas where the lead times are necessarily long, and no matter how exciting the innovation, makers won’t play a pivotal role in those spaces.

📈 Makers rising

There is no doubt in my mind that we’re experiencing another moment of makers rising to prominence. The galaxy-sized spaces opened by generative AI, its accessibility, and the velocity with which one could put together an impressive prototype – all are pointing at the notion that perhaps the next big thing will come from a tinkerer’s garage. My intuition is that we’re in an historic moment that we haven’t seen since the birth of the Internet – or perhaps even larger than that.

We are living in the age of makers rising. I am not sure how long it will last. After all, the prominence of makers is relatively short-lived, just a moment in the large story of the technological advance. But oh boy, is this moment significant.