LLM Book Knowledgebase

Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century

36 min read

Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century

Metadata

Highlights & Notes

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.

“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 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, and when a GM is unprepared, it should be apparent to that person, but also to the room, that this is not acceptable. That said, the leader should not humiliate that person. It’s easy to do, but it just causes everyone to shut down and is not productive. It’s obviously better to set the expectation of excellence and show the GM and everybody else how to solve a problem in a forceful but supportive way.

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.

When things go wrong, it’s either a time to blame, or a time to learn. I believe each failure is an opportunity to uncover deep learnings about how the organization operates, and what could strengthen it systematically, and then take action.

The purpose of the blameless postmort is to dig below the surface of some kind of bad outcome to the true root cause, and address that as an organization.

Knowing that people inevitably make mistakes, why did “the system” allow that mistake to impact customers? Answering that question will get you to the true root cause, or, more realistically, true root causes.

An open, learning environment is key to both building successful products in the fog of ambiguity and to developing future leadership talent that you will need to succeed. When you hand the reins to employees, you’re teaching them how to take ownership of their work.

It’s my job as a leader to build an environment where our leaders feel constant, gentle pressure to perform, and support for their continued, urgent exploration of their problem domain—but not an inquisition.

For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving.

Once you have a customer defined, then you define a mission. This isn’t a marketing exercise, as company mission statements might become. Rather, this is a core purpose that the team themselves can agree upon and align around.

Last, to measure progress against this mission, and to know if customers are being served by the team’s existence, they need measures of success.

With a strong customer, a clear mission, and metrics of success, the team is well set up to execute, driven by an intrinsic motivation. These three things are not invented by executives in the boardroom—they are created by the team themselves. That helps keep it personal.

Defining customer, mission, and metrics is the foundation of the small team.

A team starts small, say five people. As they grow and near the ten-person mark, we start to plan for how the team might soon be divided into two teams. The big question is typically how to divide the teams. How you do it is situationally dependent. Sometimes it’s by function of the product, sometimes it’s by layers of functionality, sometimes it’s by customer segment—but the most important thing is that you keep the customer, mission, metrics, and codebase together with that team. That last bit—the codebase—is the hard part because you have to plan ahead. Likely the system was built as one large codebase, and in order to split your teams, you must refactor the system into two codebases that two teams can independently own. This takes time; you usually plan these team splits at least six months ahead of time. But one upside is that you’re continually investing in your codebase, refactoring it into microservices, and fixing prior debt in the process. It’s like a regular spring clean, which is good hygiene when a team and product are growing quickly. This keeps your codebase constantly aligned with your teams, who are in turn aligned with your customer needs.

I’m accountable for our results, and the way I’m going to get good results is by hiring and empowering single-threaded leaders, and leading small teams who are close to problems. The best thing you can do is train people to listen to customers and make good decisions. I believe that’s how I’ll achieve my goal, but of course I’m still on the hook.

Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions.

That said, it’s natural for leaders to want to delegate upward. It’s a sanity check on the decisions, but for hard decisions, it’s usually easier to ask your boss to make the call. But doing so is escaping accountability, which isn’t good for building a culture of empowered leaders. As a leader, I tend to ask more questions than answer them. My goal is to make the single-threaded leaders accountable, but help them answer their own questions. I’m not perfect, and too often I fall for the trap of making the call when asked, but my goal is to help them clarify their own decision-making instead.

If you’re the decision maker, you have complete autonomy. If your manager has the decision, you’re likely to understand their process by which the decision is made, you’re in conversations that inform the decision, and you’re likely to go along with the decision. If somebody far away, whom you interact with rarely or don’t even know, makes a decision that impacts you, you take on a victim mindset. These are things being done to you, not with you. You start to believe you’re a passive part of the process, as opposed to an empowered and trusted actor.

When crossing corporate boundaries, these kinds of formalized contracts are a necessity—the product must have definition, the pricing must be agreed upon. But inside a company, it’s all loosey goosey. If each team exposes to other teams a formalized notion of “Here’s what we do, and here’s how to engage with us,” then the cost of coordination is reduced. It’s a way of standardizing those types of interactions, making them into a well-understood and scalable process. You can even put a “price tag” on the services, to aid with internal accounting and resource planning.

In technology teams, these interfaces are usually APIs and good documentation. When the Programmable Voice team needs to place a call to a telephone somewhere in the world, they make an API request to the Voice Connectivity layer to initiate the phone call. This well-defined service contract between teams provides a stable, predictable, and documented way for teams to interact with each other, and even accounts for billing of the underlying services. But this practice isn’t limited to just technology teams.

Taken to its logical conclusion, teams can choose the “product” of an internal team, or even choose to pick a vendor outside the company who provides the same service, perhaps at a better price, or with a better set of features or better service. When everybody has great interfaces, it allows teams to pick the best tool for the job and forces teams to up their game to “win” the business of internal customers.

When you want a small team to act like a startup, having “revenue” as a measure of success is pretty clarifying. Otherwise, more teams depending on you is actually just more work, not winning.

This is really just allowing every team to think about their output as a product, designed to serve customers in the same way we serve people outside of the company.

I believe the goal isn’t better collaboration; it’s actually less collaboration. Great companies don’t say: “I need better customer support.” They say: “We should reduce the need for customers to contact customer support.” In the same way, great companies reduce the need for teams, and individuals, to collaborate by standardizing or productizing the interactions between the groups. This frees up teams to spend more time innovating, and less time in internal coordination meetings. The key is treating other parts of the company as customers rather than collaborators.

Teams do their best work when each member of the team feels accountable to the customer, and a deep sense of purpose to serve the customer. Small teams enable that kind of connection and purpose, with a mission that comes from inside the team, driven by a primary interaction with the customer and their problems, not from executives.

What you want is for members of the team, and the team as a whole, to believe what they’re doing is important. That intrinsic motivation doesn’t come from inspirational speeches or a big paycheck. It arises from the knowledge that your work has real impact on the lives of fellow human beings.

To me, the greatest purpose of small, multidisciplinary teams and single-threaded leaders is to keep teams feeling close to customers, accountable for decisions, and knowing that their work directly translates into progress.

People will forget what you said, forget what you did, but people will never forget how you made them feel. —Maya Angelou

Hospitality is the foundation of my business philosophy. Virtually nothing else is as important as how one is made to feel in any business transaction. Hospitality exists when you believe the other person is on your side. The converse is just as true. Hospitality is present when something happens for you. It is absent when something happens to you. Those two simple prepositions—for and to—express it all.

Service is the technical delivery of a product. Hospitality is how the delivery of that product makes its recipient feel. Service is a monologue—we decide how we want to do things and set our own standards for service. Hospitality, on the other hand, is a dialogue. To be on a guest’s side requires listening to that person with every sense, and following up with a thoughtful, gracious, appropriate response. It takes both great service and great hospitality to rise to the top.

Engineers need big chunks of uninterrupted time to go off and work in solitude. But it’s a mistake to wall them off from customers.

First, you humanize your customers. Instead of being a requirements document, the developers get to hear straight from customers not just what they need, but why they need it. Customers likely express this with a depth or eloquence that would get lost in the translation process to a specification. And when you interface directly with the customer’s words, the need becomes more real—more human—and the work becomes more meaningful.

Developers, like most creative professionals, want to see people use and love the results of their work.

When developers are kept close to customer problems, they can help vet the problems with an instinctual understanding of the problem and its possible solutions.

Great product development press releases start with the understanding that the customer is the reader, and the words have to hook the customer into caring about the product.

during product reviews, start the conversation with the customer problem. Don’t jump right into talk of strategy or features, but start with why the customer will care. Ask your leaders about which customers demonstrated the problem, and how they validated that the customer problem represents a broad market need. The answer doesn’t matter as much as the process does. Does the team have the right mechanisms in place to truly understand customers? By asking these questions, you’ll start to understand how your teams think. Once they know these questions are coming, I bet it’ll set them on the path to wearing your customers’ shoes.

We are uncovering better ways of developing software by doing it and helping others do it. —Agile Manifesto, 2001

While there are many ways to implement Agile development, they all revolve around three main ideas: anticipating change, chunking up work, and maintaining close collaboration between the business and developers.

I won’t go into too much detail on their role, other than to say it’s like any coach—when there’s learning to be done to help the team, a good coach can be invaluable.

Yet that is exactly what some companies do with developers. They hire creative talent, and then stick them into cubicle farms, where they crank out paint-by-numbers software programs, pulling tickets from the Kanban board. People often complain to me that it’s hard to hire great developers, and I tell them it will definitely be difficult to get them if you’re going to treat them like assembly line workers.

Agile itself is not bad for developers—in fact, it’s quite good. But implementers need to take care to ensure that developers stay engaged in the business and treat development as a collaboration, not a task assignment exercise.

Executives say they want innovation, but then unwittingly punish people for its natural consequences. And because human beings are good at pain avoidance, the desire to avoid punishment pretty quickly overrides the innovation directive. The result is an organization that moves slowly, is risk averse, and lacks accountability.

It turns out, great infrastructure is the foundation of innovation.

Software teams are no different. To make your developers successful, you need to invest in infrastructure. You don’t need to do this up front. In fact, these systems tend to evolve organically as your software team gets bigger and more sophisticated, but you do have to actively feed it. There are certain ways of embracing infrastructure that will make your developers feel heard, help them believe that the company is investing in them, and show that the company cares about them as creative professionals.

It’s not uncommon for great software companies to invest upward of 50 percent of all R&D funds into infrastructure. But it will be tempting to question these investments. Every budget cycle, you’ll see a large expense around these infrastructure teams, and people will wonder if it’s really needed. Why are we hiring engineers to manage internal infrastructure instead of assigning more head count to the teams that create products for our customers? It’s because the software infrastructure makes all of your other developers more productive and more successful. Kill it, you’ll quickly realize how much leverage these infrastructure teams give you. Most companies find a productivity lift far greater than the 20–30 percent you’re investing.

That last sentence conveys one of the most important elements of modern software development and something that we at Twilio consider to be almost a sacred value: the person who writes the code also “wears the pager” for that code after it goes into production. It’s your code. If it crashes, you fix it. We like this idea because it pushes developers to deliver higher-quality code. The dread of taking those middle-of-the-night phone calls provides a little extra incentive to take another pass through your work before you ship.

Platform engineers are the people who design and optimize the “assembly line” that speeds innovation.

A good platform will radically slash the time it takes for developers to get new code into production, letting fewer developers produce more code in less time.

Yes, we spent money on those two platform engineers. But their work saved us four thousand person-days per year. That’s the argument for spending money on infrastructure instead of hiring more product developers. Instead of focusing on how much it costs to build a platform team, focus on the return those platform engineers can deliver. But also realize that these investments take time to pay off. Not only do you have to build the team, and have them build the infrastructure; the other teams need to adopt it. This cycle takes time, but it pays back in spades over a multiyear investment. It truly becomes a source of competitive advantage.

“The future of platforms will be allowing software developers to focus only on their features and their customers, and not about all the underlying systems that are required to bring software from somebody’s head to the cloud to a device and to an experience for a customer,”

The bottom line is that a modern development organization needs to use the best tools and methodologies, and a big part of that involves hiring infrastructure engineers to build a developer platform that automates as much of the software creation process as possible.

Backlinks