Ask Your Developer–Even About Hardware

Inspired by companies like Amazon, Bunq Bank, ING, Netflix, Stripe, and of course Twilio, he writes a compelling primer for leaders looking to build more innovative companies. His message is captured in the simple statement “Ask Your Developer”, which not un-coincidentally makes for a great billboard:

A key message throughout the book is that being a software person is a mindset, not a skill set. I’m always wary of software developer exceptionalism, as there are of course people in every profession doing groundbreaking work. So what is this “software person mindset” and why is it so important today?

Rapid Experimentation

Jeff’s journey as a software person started in a way many of us will find familiar: his family had a PC and he wanted to make it do “cool stuff”. Later he was lucky enough to have 100Mbps (in 1995!) wired connection to his PC at the University of Michigan and started experimenting with early web technologies which meant that for the first time, other people could touch his creations. This, Jeff recalls, gave him a “newfound desire to start something of my own”.

Jeff’s first venture was an online note-taking business for college students called notes4free.com (later Versity.com). Next, he created StubHub where he recalls “The frantic grind to get StubHub launched was a blast. I loved how we could take this idea, build the first version, and get it in customers’ hands so quickly. With that speed, we were able to iterate constantly.”

After the dot com bubble, Jeff landed on what at the time must have looked like a more realistic business model, a brick-and-mortar extreme sports store in Los Angeles, called Nine Star. This was probably the only extreme sports store in the world that had a co-founder in the stockroom coding all the software the store needed!

These early experiences helped cement his concept of the “software person mindset”: “It’s not just software itself—it’s the fundamental agility of software that drives Software People. It starts by listening to customers, rapidly building initial solutions to their problems, getting feedback, and then constantly iterating and improving.”

According to Lawson, this rapid experimentation, driven by curiosity (or “letting developers scratch their itch”) is what fuels innovation or as Lawson puts it: “experimentation is the prerequisite to innovation”.

Build vs Die

In Chapter 1 “Build vs Die” Lawson suggests that innovation is the key to survival for companies in every industry, but is it really true that all companies need to be innovative to survive? I’m reminded of Leonard E. Read’s 1958 essay I, pencil, in which the protagonist of the story is a pencil, which states:

"I, Pencil, am a complex combination of miracles: a tree, zinc, copper, graphite, and so on. But to these miracles which manifest themselves in Nature an even more extraordinary miracle has been added: the configuration of creative human energies—millions of tiny knowhows configurating naturally and spontaneously in response to human necessity and desire and in the absence of any human masterminding!"

I, Pencil demonstrates the complex graph of supply chains and processes involved in the creation of a seemingly simple product, a pencil.

Your business too will be a complex graph of supply chains and processes, and while innovation in all areas may be unnecessary, failing to innovate in the right areas could be risky as Lawson suggests in Chapter 2: The New Software Supply Chain, when he says “My rule of thumb is that for anything that gives you differentiation with customers, you should build. Software that faces your customers, you should build. Anything where your customers will be saying, why doesn’t it do X, and your answer is, well, the thing we bought doesn’t do X”.

Scaling innovation

Move fast and break things. —Mark Zuckerberg, 2009
Move fast with stable infra. —Mark Zuckerberg, 2014

Of course, the idea that companies need to digitally transform is now cliché, but that doesn’t explain why so many that want to do so fail in their attempts. In Lawson’s early career it was easier for him to “scratch his itch” as the feedback from his customers was timely and he had the freedom to respond to that feedback however he saw fit. But can you bottle this magic and unleash it at larger and more complex organizations? Lawson thinks so.

After landing, in 2004, at Amazon Web Services Jeff notes that “Despite the fact that Amazon seemed to me like a huge company, it felt like a startup. The whole company was divided into small, two-pizza teams, each operating as a tiny startup. There was urgency. There was energy. What we were doing mattered. We were inventing the future: that’s the feeling you want your technical talent to feel.”

As companies grow, there is a natural inclination to scale teams around competency, not customers. All the marketing people live here, software developers live here, operations folks live over there, and so on.

Early in my career at a fast-growing company, I experienced first-hand the effects of this mindset. Working on a small team with a specific customer in mind and a tight deadline, we needed virtual machines on which to run our software and we decided to use Amazon Web Services. Not long after we were reprimanded for indulging in “shadow IT” and forced to use the company’s fledging internal cloud — resulting in form filling, manager sign-off, and a 7-day delivery window. Experimentation, and therefore innovation, ground to a halt.

Stories abound of companies who have copied the visible elements of successful companies (often referred to as cargo culting) without achieving the same results because they failed to understand the underlying principles, competencies, and sacrifices involved. If you truly want innovative teams, you will need to unshackle them from some of your slower-moving internal processes and habits.

Yes, Even About Hardware

For our part, everything we do at Equinix Metal — from our developer-centric approach to our hands-on support to Open19 getting hardware to the right places faster to Tinkerbell democratizing hardware operations — is about making sure that the companies who have organized themselves around innovation have access to the fundamental infrastructure they need to succeed.

As edge computing, specialised hardware, hybrid-multi cloud deployments, and countless other advancements slowly shift our shared assumptions about how to do digital infrastructure at scale, I’m consistently amazed by how our partners and customers are adapting to succeed. With each passing quarter, I get to witness firsthand how they are experimenting closer and closer to the hardware and reaping the rewards.

If you’re looking to innovate faster, building an organization that enables and rewards experimentation is the foundation you need. With that organization in place, consider how to expand your experimentation surface area and remove barriers that will slow or stop this culture from taking root, including around non-software stuff.

My advice is to stay flexible about the word “software” and focus on the mindset. We’re entering a golden age of silicon and the ways in which hardware and software can work together to differentiate products is extreme.

In short: ask your developer about software and yes, even about hardware.

If you're interested in the intersection of open-source and fundamental infrastructure you might want to check out Proximity, our first technical user conference on 3/3.