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

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.