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

The success of the Contact Center 2.0 project is a testament to the skills of the engineers at ING and proof that “regular IT people” can transform into ace developers who build world-class software. These world-class software builders are everywhere. Companies need to find them and turn them loose. Make them feel like owners.

Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date. So at Amazon, an internal culture of API documentation arose. One team could find another team’s API documentation and start using their services, often without even needing to talk. This enabled the teams to effectively work together, solving the coordination problem.

The loose coupling of autonomous teams only works if the other teams have what it takes to self-serve. Docs & onboarding for internal services.

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.

Apple’s secret sauce involves knowing which parts to buy and which to build; knowing how to integrate those parts in unique ways; and, most important, hiring some of the best developers on the planet to write great software. They’ve also always been good at telling their story and selling their brand—that’s another area where they’ve decided to differentiate, and it’s paid off.

Lots of opportunity here for Docker, considering our brand. How could we sell that in a conscious & explicit way?

Exactly when competition is growing more fierce is when companies must focus all of their internal development effort on the differentiating parts of the business. Buying the table-stakes capabilities offered in this Great Third Era of Software, even from your fiercest competitor, is what enables you to have a shot at winning. That’s why you see Netflix, which competes with Amazon Prime Video, as a large and public customer of AWS. That’s why at Twilio, we see large carriers leverage our services for contact centers, customer notifications, and more. Oftentimes, these decisions to not leverage cloud services are made at the top because . . . strategery. I think this is foolish.

When you pitch a new product idea to potential customers, one of two things happens, especially when they’re an acquaintance. If they genuinely like the idea and it seems to solve a pain point in their life, they ask you questions. Does it do this? Does it do that? They’re trying to match your solution to their problem. That’s a good sign. If they don’t see your idea as solving some pain point they have, the conversation goes differently. They try to be polite, and say: “Oh, that sounds nice . . .” as their voice trails off. After a few moments of awkward silence, they’ll change the subject. “So, how ’bout them Tigers?” Not a good sign.

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.

But as we dug in and realized how hard it truly was, that encouraged us even more. The worse the legacy world was to deal with, the bigger our opportunity was to simplify it and improve the customer experience.

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

Fried says their method is to share problems. “We just say to a team, ‘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. They decide how they want to attack the problem. We might go back and forth, but the project is theirs. We could detail something out and figure out there need to be forty-two steps and then . . . giv[e] someone forty-two tasks . . . but then you’re telling them, ‘Don’t use your brain, just do what we tell you.’” They provide a backstory to explain where the idea came from and why it’s important. They might give the team a rough sketch with markers on a whiteboard illustrating their preliminary thoughts, but that’s about it.

When a developer is merely reading a specification document, they become isolated from the people who will use the software. The code becomes clunky and error prone because the developer didn’t know how people were going to use it. Not only that, but the act of writing the code takes forever because the developer feels no passion and has no intuition for how to get it done.

Don’t set them necessarily on a “great idea,” but do set them on a customer segment and a problem that needs solving. Don’t necessarily tell them what to build, but do tell them which customer to focus on and which (hopefully) valuable problem you can solve for that customer. Those are the customer and mission parts of the team definition. Next, agree upon metrics of success. Eric Ries is great at this, so read his books The Lean Startup and The Startup Way to learn his in-depth methods for what he calls “Innovation Accounting.” But in short, the small team needs a set of metrics to define what a successful experimental outcome looks like. Note, these aren’t long-term business metrics; these are short-term experimental outcomes. Eric calls it validating your blind-faith assumptions.

The problem is that “good ideas don’t come along only during the planning cycle. They hit you at any time of the year,” Chee says. He introduced the idea of a rolling pitch season. 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.

As a result, we’re able to run a lot more experiments at the same time, and though many won’t succeed, we can at least figure that out faster and move on to the next experiment.

Jeff also notes that the talent he hired was probably inappropriate for the transformation. “I hired big tech pedigree leaders—from Cisco, SAP, IBM, and Oracle—but not true entrepreneurs. They thought about scale, not experimentation. I would have done that differently.”

From this experience I learned two things. One, this wasn’t an experiment. Due to the contract, we were all in, building blindly without any customer validation. The developers building it knew this. Second, I should have listened to the frontline engineers, who thought the apps were worthless and the business judgment unsound. We wasted over a million dollars of our precious startup cash on this misadventure. We could have avoided that if I’d paid attention to my frontline developers.

On partner contracts without customer validation

Since it’s just a fraction of people, it’s a great way to learn without making a big commitment to your customer base. Shutting down a 1 percent experiment is easy, and also cheap. It’s much more difficult and costly (in dollars and reputational damage) to shut down an experiment that has been rolled out to a large number of subscribers. Of course, this works well when you have hundreds of millions or billions of users, so it doesn’t work for every type of company. Luckily, many ways of testing ideas are decidedly less sophisticated and work just as well.

The easiest way is just to talk to customers. “Would you buy a thing that . . .” is a very easy way to test the waters.

When Kevin joined in 2012, his mission was to build a completely new technology organization. At the time, Domino’s had 150 workers in IT globally. Eight years later that number has grown to 650, of whom only 50 were part of the group Kevin inherited. He began by turning to his professional network and hiring a strong core team. This wasn’t just executives. 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. Kevin’s advice to others—don’t rush and don’t settle.

They also advocated strongly for being included in big decisions. The White House technologists came up with a concept called technical quotient (TQ), akin to the notion of IQ or EQ, to explain to executive leadership across departments and agencies—whether at the Pentagon, the White House, the Small Business Administration, the Department of Education, the Department of Health and Human Services, the General Services Administration, or the Department of Homeland Security—the importance of having “TQ at the table.” “We are at a point in history that technologists need to be part of the decision-making process for nearly every important decision,” Evan says.

Most companies, even in our backyard, pay a bonus tied to weird corporate objectives. One kind is tied to company-wide objectives like revenue or profitability, the idea being that the whole company bands together to achieve these goals. The problem is that in reality no individual employee has the kind of impact to make or break these goals. So their compensation, which they will focus on a lot, is not tied to their job. It’s essentially random. Another problem is that you might have done a great job, but those idiots over in that other department didn’t do theirs and now nobody gets their bonus. What a rip-off!

Sometimes exit interviews are simple multiple choice surveys, so don’t accept vague, inactionable answers like “better opportunity.” Of course, if it was a worse opportunity, they wouldn’t have taken it! Find out why they believe some other company is offering a better opportunity. Is it something simple like pay? An ineffective manager? Or something more cultural: Are developers given opportunities to shine and grow?

School isn’t so much about learning content; it’s about learning how to learn. That process of learning to learn is one that every child goes through, starting in kindergarten. Yet once we graduate and enter the workforce, we seem to forget about all that. The process of “learning to learn” gets lost. We create rigid, unforgiving cultures that punish people who make mistakes.

A big difference between an open, learning environment at work and the one we experienced in elementary school is that in school, the teacher knows the answers but shows students how to do the work to arrive at the answer on their own. 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.

So why bother anointing a twenty-seven-year-old general manager and giving me the reins? Well, it was a training ground. I learned how to be a GM, and be an owner, when the stakes were low. If I succeeded and learned, I would get to move on and own something bigger.

Lots of companies help employees learn by holding events like brown-bag lunch sessions, off-site leadership courses, or online training videos. But I believe that the most valuable form of learning is by doing, and that’s up to leaders to let their people run things. Look for projects where the stakes are low, where a leader-in-training can screw up a few noncritical things without doing much harm and become a better leader in the process.

Target has made a big commitment to training and education. Every member of the IT staff spends fifty days a year on learning—which is a lot! Some of the learning comes through reading books or taking classes and seminars, but most of it is learning by doing.

First, we instituted an idea that all employees would do some amount of customer support—not as their full-time job, but enough to maintain a customer connection. We asked all new employees to handle fifty support tickets in their first couple of weeks to get to know our customers, our product, and our customer service approach. We also started asking all new employees to build an app using Twilio—not just the developers, everybody. Obviously the sales reps and customer service agents would be well served by using our product. But we also asked the lawyers, the accountants, the analysts—everybody—to build something using Twilio so they knew what we enable customers to do. The point was to build more connections between our employees and our customers. To this day every new Twilion, no matter their role, learns the basics of coding and builds an app on our platform. When they complete their app they earn a red Twilio track jacket—a true badge of honor!

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.

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.

Product managers often see themselves as “gatekeepers,” describing their role as “protecting” engineers from customers. To some extent this makes sense. You don’t want your engineers getting bogged down handling every customer and every complaint. 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.

Engineers on his team are required to speak to at least one customer a quarter. Getting that done isn’t as easy as you’d think. One way is to attend a hackathon or meet-up that Twilio hosts for customers. Another is for an engineer to listen in on a call where an account manager is checking in with a customer. The best might be when a sales rep brings a developer along on a sales call, in addition to the sales engineer. “They can bring along the person who actually builds the product,” Ben says. “Sure, the developer won’t be as polished as the sales rep, but a smart rep will play that to their strength.”

You can tell I’m a bit wary of the word strategy because it can be mistaken for marching orders from executives, versus listening to customers. At Twilio, I often say “our strategy is simple: build things our customers want for which they’ll pay us.” Obviously we have long-term plans for the business, but I don’t want teams to confuse our company’s goals for serving our customers. The only way we can bring our corporate plans to life is by serving customers.

My favorite way of understanding if teams are wearing the customers’ shoes is to walk around and ask developers what customer problem they’re working on. If they tell me a feature, then I ask what customer problem it’s solving. If they can’t answer it, then that’s a sign that the team might not be building enough connection with customers. You can do this, too—it’s easy. Another thing to ask your developers: 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.

While the engineers implement the current sprint’s backlog of tasks, the product manager’s job is to get the next sprint’s backlog ready by resolving ambiguities and removing uncertainties as best as possible. Beyond the next sprint, there’s probably a sea of tasks in various stages of definition, but only as the sprints progress do they get to a finer and finer resolution. But that’s not a failing of Agile, that’s the point. Push out decisions until just before they’re implemented, so that the most information can be known. This limits wasted work.

Think of the User Stories as an artifact that describes the work to be done, all from the customer’s point of view. This differs from the Product Requirements Docs (PRDs) of yesteryear, which focused more on what the software needed to do than on what the customer needed. The difference may seem subtle, but it’s important. In a well-functioning Agile team, the creation of the artifact and the discussion that produces it are focused more on the customer than they are on the software itself.

Like many companies, we have a big annual user conference called SIGNAL, which is our platform to announce products, get press, and wow our customers. So the deadline is usually set when our marketing team books the venue and starts selling tickets. That leaves features and certainty. Generally speaking, uncertainty doesn’t help, so features are the variable that we give teams control over to meet the deadline. We are measuring certainty in the months leading up to SIGNAL, but by a month before, certainty should firm up to a yes or no, at which point features are the only variable to meet the deadline. That’s a good trade-off.

Jason defines his job, and that of the platform team—a group of about one hundred engineers across thirteen small teams—as “to provide software that will enable a traditional software developer to be successful in a DevOps culture without having a deep background in all of these specialized disciplines.” They don’t develop software that ships to customers. They make software that developers use to write, test, deploy, and monitor software. If anything about our process resembles an assembly line, this is probably the closest thing. Platform engineers are the people who design and optimize the “assembly line” that speeds innovation.

Every team has the ability to customize its pipeline based on the unique aspects of its product, but also for its working style—thus enabling autonomy. But there are several default, preconfigured pipelines that teams can start from. These represent the most “paved paths” for standard workflows, such as for websites, microservices, or database clusters.

That’s where one of Jason’s other principles—opt in to complexity—comes into play. While teams can take the default settings, they can also dive into the bowels of Admiral, and rewire it for the particulars of their project. Don’t like the default unit testing framework? Developers can plug in their own, while still keeping all the benefits of Admiral and the rest of the pipeline. The same goes for all components. This gives teams autonomy to pick their tools, while making the defaults easy and attractive, helping to encourage adoption of Admiral.