Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century – A Management Playbook for Tech Industry Leadership and Digital Transformation

by Jeff Lawson

There are few people in the world who are experienced both as software developers and as business executives.

Ask Your Developer is an essential resource for understanding the connection between software, the people who build it, and the value they offer in building and transforming the organizations we need in the age of digital disruption.

The message worked because we didn’t try to explain what we do. Instead, we provoked a conversation. We caught people’s attention. We piqued their curiosity. Later, when they looked us up, they got the message.

But at some high-performing technology companies, developers often play an outsized role not just in the code they’re writing but also in the product and business strategy. They treat their products more as a craft than a job and, in doing so, delight customers with digital experiences—think Apple, Google, Spotify, and Uber.

Building software is incredibly hard, and building a culture of digital innovation is even harder.

However, businesspeople and developers often speak different languages and have different working styles—and these differences can inhibit the business and the developers from effectively collaborating to achieve their goals.

Company leaders who build industry-changing software products seem to do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers’ success.

“Our business is not what’s in the brown boxes,” he said. “It’s the software that sends the brown boxes on their way.” We monetized our software not by selling it directly, but by selling everything else—books, DVDs, and CDs. What’s more, the quality of our software would determine whether we succeeded: “Our ability to win,” Jeff said, “is based on our ability to arrange magnetic particles on hard drives better than our competition.”

Another way to think of this: Software has moved from being a cost center to the profit center.

Suddenly, software isn’t a liability to be outsourced. It is the source of competitive advantage.

To truly thrive in the digital era—either as a disruptor or those fending off the disruptors—you need to think like a Software Person. Now, a Software Person is not necessarily a developer—it’s anybody who, when faced with a problem, asks the question: “How can software solve this problem?” That’s because being a Software Person is a mindset, not a skill set.

Every kind of company can become a software company—all you have to do is internalize the value of rapid iteration. You don’t need to be Elon Musk or Jack Dorsey; you just need to believe in the power of iteration, and Darwin will be on your side. But of course, to iterate, you first need to build. You can’t iterate on something you’ve bought off the shelf. That’s why it’s Build vs. Die.

The problem is that, by definition, a one-size-fits-all piece of software doesn’t suit anyone very well. And if every company buys the same software, no company can differentiate itself. They are all just the same as their competitors, at least as seen through the digital lens—which is increasingly the only lens that matters.

with off-the-shelf software apps, you have to change your business to match the software—which is crazy! Really, you should change the software to build the business your customers need.

If you want to become a software builder, you need to start by changing the mindset of the entire organization.

These world-class software builders are everywhere. Companies need to find them and turn them loose. Make them feel like owners.

What matters isn’t how you use servers, but rather how you serve users. —Me, 2010

The answer turned out to be keeping the code and the teams together. As Amazon split the organization up into small teams, they also kept carving up the code into small pieces so the teams could “take it with them” and operate it independently. These teams and their respective code needed a way to talk to each other, and “web services” turned out to be the answer. Instead of each team shipping code into some giant repository that somebody else would deploy and run on servers, each team would run their own code as a service that other teams could interoperate with. Because each team was small, the surface area of their service was typically somewhat limited as well. Over time, these became known as “microservices” because each individual service typically did one thing, and did it well.

Why write your own microservice for calculating currency translation on international sales when you can just buy that microservice from a vendor that specializes in currency translation software? So your developers start plugging in pieces from specialist providers, and boom—you have a software supply chain. Does it really matter what company’s logo these microservice providers have on their business cards?

Cloud platforms are the new building blocks for modern developers. They’ve made it much faster and cheaper to develop applications. They can scale up to support billions of users. All of this would have been unimaginable ten years ago.

The only things companies should build themselves are the things that are core to their business.

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. That’s a problem. When your customers care, you need to build.

But for most back-end operations, and for things that won’t give you any differentiation with customers, you should buy.

But let me repeat the rule of thumb again: anything that is customer-facing, you should build.

Because you can’t buy differentiation. You can only build it.

You tie together these building blocks into the end-to-end experience, which you imagine, build, and own—because that’s your competitive advantage. But the pieces that make it up are taken off the shelf and rapidly integrated and integrated upon. You’ll add into the mix many of your own microservices, but instead of re-creating the wheel, the services you build are those that represent your “secret sauce” areas of competitive advantage.

But by taking off-the-shelf building blocks wherever possible, you can put all of your energy toward your unique areas of differentiation.

The “value add” of your company might be the way you integrate the pieces, and how well you develop the customer-facing software that sits on top of microservices.

Executives should understand the ecosystem of available services at a high level, and strongly encourage teams to adopt a “building block” approach that will accelerate building value for customers.

I’ve always thought that the best way to learn something new was to commit yourself to “customers” and force yourself to learn.

The whole company was divided into small, two-pizza teams, each operating like 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.

This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works. So I kept looking for ideas.

I’ve learned that building software is actually pretty easy but building the right thing is hard.

the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions.

If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea. —Antoine de Saint-Exupéry

Share problems, not solutions with your developers. Then watch with amazement what happens. The quality of the software improves, cycle times shorten drastically, users are happier, and your developers stay at the company longer. I’ve never met a business executive who didn’t want all of those things.

‘Scientists find problems, and engineers fix problems.’ That’s always been my outlook on software engineers. They’re problem solvers. They sit down and look at a problem and then find the most efficient way to solve it.”

For developers, code is more than a job—it’s a creative outlet. When developers can’t express that creativity at work, they find other areas to do it. Many have outside projects and even startups on the side.

‘Here’s the idea, here’s roughly where we want to go or want to build. It’s your responsibility to take that and figure that out.’ There’s a lot of agency here, a lot of autonomy.

When developers actually care about their work, intrinsic motivation kicks in and unlocks new and even more creative ideas.

Great product managers don’t abstract the developer from the customer needs; instead, they facilitate understanding of customer problems.

For better or worse, we all fall in love with our own ideas. What better way to instill that sense of ownership than to enable people to come up with their own solutions? When we do that, people will run through walls.

There’s an old story about NASA trying to develop a pen that astronauts could use in space. It was tricky to get ink to flow upside down, and pens kept failing. We spent millions of dollars trying to come up with a space pen, until someone realized how the Russians solved the problem—they used pencils. Unfortunately this story is an urban legend, but it still gets told a lot in the software world. Like all good fables, this one illustrates a common mistake—the one where people set out to solve the wrong problem. The problem NASA needed to solve was not “How can we make a pen that writes upside down in zero gravity?” The real problem was “How can we write in space?”

People in any field rise to the expectations set for them. Ask Your Developer is about setting high expectations for developers—not how much code can they grind out, but how well can they use their ingenuity and creativity to solve the world’s biggest problems.

The most important thing is to give developers problems, not solutions.

If you’re actually inventing something, you shouldn’t know what you’re doing. —Caterina Fake, cofounder of Flickr

It’s natural, and very human, to want to succeed and to avoid the negative stigma associated with failure. However, tolerance for failure—both personally and organizationally—is the primary key to unlocking innovation.

If you can try things in a low-risk way and quickly learn about your customers’ needs, why wouldn’t you?

There’s an old joke that goes like this: A woman goes to church every week and prays to God to win the lottery. Week after week, year after year, she prays. Finally after decades of this, God finally answers: “Meet me halfway, and buy a lottery ticket!”

Innovation is kind of like that—experiments are buying lottery tickets for the chance of a breakthrough innovation. The more lottery tickets you buy, the better your chances.