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

“If you knew which ideas would be hits, of course you’d only do those. But of course, nobody knows ahead of time, so you have to be willing to plant a lot of seeds and watch them grow.”

First, vet the idea. This doesn’t need to be exhaustive; there should be low activation energy for starting a new experiment. What you really want to know are just two things: What assumptions about customers, the problem, or the market are you making, and how will your experiment prove or disprove those assumptions? If you are wildly successful, will it be a big outcome? The point is to grow a big tree, so ask whether the seed you’re planting has that chance if it’s successful.

The only reason I would have for declining an experiment is if (a) the opportunity is too small and therefore a successful outcome is meaningless, or (b) the team doesn’t yet know how to measure progress.

Your experiment might aim to (a) figure out if one customer will indeed pay you that much to solve the problem; and (b) validate that the problem is applicable to a sufficient number of customers that you could reasonably find one thousand in the next five years to bite. If you can’t even get one to bite, then that’s a problem. Or if you do, but they’ll only pay $1,000 per year instead of $500,000, that’s a problem. Or if they do pay the right amount, but you realize there are only ten companies in the world that have this need, then that’s a problem.

Those are scientific hypotheses. With software, the answer to the scientific or technical hypothesis—“A computer program can do X”—is almost always yes, we can totally build that. The hypothesis you’re actually trying to prove is the business hypothesis, which is “Customers will pay for a computer program that does X” or, more broadly, “A computer program that does X will make us more money.”

In the Build vs. Die world, you’re not really conducting experiments on software—you’re conducting experiments on the company itself. How can we grow? What products should we make?

One common mistake companies make is not having a hypothesis that predates the experiment—meaning, they invest in testing out a technical hypothesis and even building prototypes without stopping to find out whether there is sufficient demand for the product.

Having a hypothesis, and a set of assumptions to prove or disprove, is great—but you need it in writing so you can track progress.

It’s not uncommon for people to forget the original hypothesis, so keeping it in writing, as well as the results, keeps everybody on track.

Writing it down, reminding people of the experiment’s purpose, and updating them on the progress is a great way to keep the experimental mindset alive and supported.

Mother Nature doesn’t weep or get embarrassed about all the millions of mutations that fail. She just keeps spinning them out.

Instead of forcing people to come in once a year and make a huge budget ask, we’ve set up a forum where anyone can pitch an idea whenever they want. If the idea gets approved, we fund a very small exploratory team, maybe as small as a fraction of a person’s time. The “team” gets just enough money to run a short experiment.

It’s counterintuitive for big company leaders, but sometimes overcommitting is the issue. When you fund an initiative with hundreds of millions of dollars and big fanfare, the pressure for a big outcome in an unrealistically short time hangs over the team. With fewer dollars and a more iterative, experimental approach, I suspect that by spending far less, they could have achieved far more. In retrospect, today Jeff agrees: “I had a team and a process that was set up for scale, not for experimentation. I wish I’d started small, with an entrepreneurial team, and got it started under the radar. And after they found early success, then I could apply the scale that GE was so good at.”

We’ve started an experiment and seen it succeed, only to keep considering it an experiment for too long, and not give it the funding to explode like the market wanted it to. We didn’t properly water the sapling.

What we learned is that when you conduct experiments, you should remember to hold back resources to give needed rocket boosters to the winning experiments.

that the engineering mindset is often predisposed to (a) having strong opinions and (b) not keeping those opinions to themselves. To engineers, facts matter. I just think of it this way: engineers hate bullshit. So if you need someone who will tell you the truth, even if it’s ugly—go find a frontline engineer.

When people talk about accepting failure, they’re talking about accepting the journey of discovery.

The biggest concern people have about experiments is how to avoid harming customers in the process. Because in the process of invention, when you do find a great product, you still need customers to sell it to. If you burned all your relationships along the way of discovery, that doesn’t bode well. Luckily you can experiment while also bringing your customers along on the journey if you structure it well from the get-go.

It doesn’t make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do. —Steve Jobs

A good technical leadership team consists of senior architects, principal engineers, and line managers. The main thing is to make sure your early hires have strong technical chops. The first hires might also be the toughest. But over time it gets easier.

but is often overlooked. The essence of autonomy is feeling trusted to make decisions. If someone else can just veto whatever decisions you make, then you’re not really all that autonomous.

So instead of letting developers just run around and do whatever they want, autonomy actually has its basis in rules. Without guardrails, people won’t know how to make decisions, and leaders will tend to second-guess them constantly. By creating rules, you paradoxically set people free—in the space between guardrails.

I’ve used Mr. Bowers as inspiration to guide my thinking about how to create an environment where the ground rules are known, and then everybody feels empowered to sprint forward.

I want to create amazing things and learn from other smart people.

“There’s a common misconception that you get hired as an engineer just to write code,” she explains. “But communication is a huge aspect of the job. How do you take very technical ideas and make it possible for people who aren’t engineers to understand them? You need to learn about code reviews, how to give a code review and how to receive one, and how to learn from that information. You need writing skills, to create technical documents. You need public speaking, to be able to speak at conferences, or just to get up and disseminate information to other teams.”

Like anybody, developers want their work to matter. They want to develop systems that generate revenue, or save money for the company, or enable the company to deliver new experiences that delight customers. They want to invent new lines of business. Show them that in your organization, developers are considered key to the company’s future, solving problems that have impact on millions of people.

“We’re changing the course of the financial industry. You can be a part of 130 people who are shifting an entire industry on its end,”

As leaders, it’s our job to connect the company’s greater mission to the work our technical teams are doing. Everybody has parts of their job they love, and parts they loathe, and developers are no different. So when a developer is in the drudgery of debugging legacy code or writing tests or waking up when the pager goes off—purpose is what makes these moments tolerable and even sometimes interesting.

To be a good recruiter you need to present your version of the Hero’s Journey. What do we do here? What challenges are we facing? Why is our work important? Why should you care about your job? What’s at stake? Why will you be excited to come to work every day?

For midcareer developers you can offer a chance to grow and develop new skills—just at a time when some might start to feel stagnant or stuck with skills that are becoming less relevant. In other words—mastery. Show them that they can expand their skills and learn new languages, design and write new apps and put them into production.

When you can be yet another cog in the machine, or a key member of a small but important team—many developers find the latter is a pretty compelling opportunity.

Earlier in this chapter I mentioned Daniel Pink and his theory that compensation isn’t really what motivates people, that the point is only to make employees feel that they are paid fairly. Yet many employers focus on bonus structures. They end up conveying a message to employees that management sees them as coin-operated machines, which misses the point on why most employees want to work. Once their basic needs are met, most employees want intrinsic motivation, like autonomy, mastery, and purpose.

You don’t want employees focused on bonuses. You want them focused on customers. You want creative energy.

When things are ambiguous, as they often are when you’re building something, it’s hard to set goals. At the start of every year we had the same big arguments about setting the goals. Are they too hard? Too easy? At the end of each year we argued about whether the goals had been set well at the beginning and whether the bonuses were merited or not.

My belief has always been to pay people well, so they feel it’s fair, but don’t cloud things by believing that compensation is the great motivator, especially for creative roles. (I recognize that for sales, it’s different. In sales, commissions are part of the game.)

When you stop learning, stop listening, stop looking and asking questions, always new questions, then it is time to die. —Lillian Smith

Survival means being lean, nimble, fast, and constantly able to adapt.

As a leader, deep down what do you really want? Do you want people to just blindly accept what you say, or do you want them to think for themselves and come up with the best solution to the problems at hand?

But deep down, you probably know that in order to win, you need the best answer, not the one shouted most loudly or by the highest-ranking person. You want knowledge and truth to win, not politics.

An open, learning environment is one where the organization is receptive to not having all of the answers, is comfortable with uncertainty, and strives to get better every day. It means being flexible instead of rigid, and having a culture where people continually seek the truth.

When someone graduates from college with a technical education, at that time and for the next several years, that young person will be fully up-to-date in the technology of the time. Hence, he possesses a good deal of knowledge-based power in the organization that hired him. If he does well, he will be promoted to higher and higher positions, and as the years pass, his position power will grow but his intimate familiarity with current technology will fade. Put another way, even if today’s veteran manager was once an outstanding engineer, he is not now the technical expert he was when he joined the company. At Intel, anyway, we managers get a little more obsolete every day.

As technical leaders, the more we progress in our careers we tend to exchange up-to-date technical competency for managerial competency. Two valuable but different knowledge sets that we bring to the table. Whose opinion is right—the one with more experience, or the one with more knowledge of the technologies?

An open environment is one where you give people autonomy by sharing problems, but it’s not just a matter of throwing out big problems and letting folks sink or swim. As a leader, you’re still on the hook for results, so sinking doesn’t sound so awesome. Rather, an open environment provides (a) guardrails and (b) support. Instead of “sink or swim,” we give people swim lessons—and even let them wear floaties if they need them.

In business, especially when you’re working on the cutting edge of technology, you’re not looking for an answer that someone else already knows. The business and its employees must find answers to questions that have not been asked before. But an open, learning environment provides the way to find those elusive answers.

These meetings can be tough, but that’s how people learn. Constructive criticism isn’t about tearing people down; it’s about helping them get better. It’s actually a form of respect. And it’s how people learn.

Another benefit is that OPRs hold people accountable. Decisions are made out in the open, in front of everyone—not in secret meetings in closed rooms, where others only learn about things secondhand, through the grapevine, and messages can get muddled. Everyone in the company knows exactly what the people in that meeting are expected to deliver. There’s no going back and changing things later.

Andy looks through the metrics of each team. When he finds something that’s off, for example something that’s trending in the wrong direction, he stops and asks the leader why their metrics are off and what they’re doing to fix it. Here’s the key part—sometimes the leader has a great answer for the issue and what they’re doing, and obviously the leader feels good and looks good in front of many other leaders. But more important is that every other leader in the room just learned what excellence looks like. Metrics will inevitably go off-kilter, but what’s important is the owner is on top of it. Of course there are the opposite scenarios, too—the times when the leader doesn’t know or can’t explain why the metric is off course. That’s bad. You have to know your business. Or maybe the leader knows what’s wrong but has insufficient plans to correct it. That’s bad, too. Andy will spend time leaning into the situation, coaching the leaders (sometimes forcefully, to be honest) in how they could run their business better. These meetings are pretty legendary in Amazon Web Services, because you’d better be prepared, which drives each team to run a tight ship, but also because it’s a master class in being an owner. That’s the kind of open, learning environment that drives innovation and success. The hard part is to balance that open environment for feedback without creating an environment of fear. That’s where the “open” part comes in. Leaders should expect the best from their teams,...

That person isn’t learning. They suck as much as they did yesterday. Repeated failure is certainly a problem and needs to become a personal performance conversation. But that part isn’t open; that’s the private part.

“We use the Socratic method here. I call on you, ask you a question, and you answer it. Why don’t I just give you a lecture? Because through my questions, you learn to teach yourselves.”

The Socratic method is as effective with business problems as it is with complex legal cases.