Ask Your Developer

Table of Contents

Summary

Ask Your Developer can help companies translate CEO enthusiasm and raw talent into what they're actually looking for—a superior customer experience achieved through digital transformation.

Ask Your Developer can help companies translate CEO enthusiasm and raw talent into what they're looking for—a superior customer experience achieved through digital transformation.

The book is arranged in three sections:

1. Understanding why developers matters more than ever
2. Motivating developers
3. Helping your developers succeed

Throughout the book, Lawson leverages on this experience at Amazon and Twilio to guide the reader on key areas to focus on while managing a tech company, such as engaging with your developer to determine which part of the software should be built or bought. Lawson also offers advice on engaging and motivating your developers by sharing problems, not solutions.

If you are reading this book from a developer's perspective, I believe the question to ask ourselves is: "What customer problem are you solving?"

Podcast

Listen to the author talk about ideas from the book.

Click here for similar podcasts from other authors from my resonance library.

Key Ideas

Build or Die

• Software used to be something that supported the business, like managing financials and inventory. They were cost centres. It makes sense to outsource these functions and cut costs as much as possible.

• Today, software is the face of the company to its customers. Users don't walk into your physical shop first; they go to your website or app. Your app's user experience becomes a source of competitive advantage ( and key differentiator) of your product. New competitors can enter the market with just an online presence. Airbnb challenged the global hotel industry without owning the real estate.

• The software mindset is evident in companies like Apple, Tesla and Square. Only the required physical interface is required in the hardware. You don't need extra physical buttons. When most of the interactions are software-based, developers can continually update the software over the air. Whatever hardware comes out of the factory is fixed for life.

• There is a rise of software companies like Twilio (author's company) that sell the building blocks that developers can combine to build their applications faster and easier. The author calls this the new software supply chain and the Third Great Era of Software.

If you want to become a software builder, you need to start by changing the mindset of the entire organization. The mindset of "Nobody gets fired for buying IBM" needs to go.

• Build anything that differentiates your product you should build. Build software that faces your customers. The rest that won't give you any differentiation, you should buy.

You can't buy differentiation. You can only build it.

Code is Creative

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

• Most software is CRUD operations. This isn't rocket science. The real difference is how long it takes to solve a problem, and how well it's solved, comes from the developer understanding the problem.

• If you can cultivate user empathy among your developers, they will be motivated to build better products faster. When developers are 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.

• There is a disconnect between managers and developers. It can be difficult for an engineering team when somebody just comes by and says, "Do this, quick, by this deadline," and then runs away.

• Managers can include developers earlier in the discussion instead of presenting engineers with a pre-defined solution and just tasking them to code it out.

• Lawson's biggest piece of advice to those executives who travel the world to visit Silicon Valley is this: Share problems, not solutions with your developers.

• To engage your developers to think about the same business problems as the management, Lawson offers the idea of a "Call for Solutions" within the company. Start by defining big problems your business faces and call for solutions similar to how Y Combinator requests for Startups.

• It is easy to frame the wrong question. For example, 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?”

Experimentation Is The Prerequisite to Innovation

• Tolerance for failure—both personally and organizationally—is the primary key to unlocking innovation.

• Experiments are like planting seeds in the ground. You don't know which one may grow into giant trees. However, if you don't plant any seeds, you definitely won't get any trees. Companies with a low tolerance for failure will fail to innovate.

• Experiments should require low activation energy. We just need to confirm whether the assumption you are making about the problem, market, or customer is correct and whether the opportunity is big enough to pursue if it is successful.

Software can almost always be programmed to do X. The only hypothesis you are trying to prove is whether customers are willing to pay for the software that does X.

• Always write down the original hypothesis. It is very easy for people to forget the initial context and start measuring the wrong metrics or ask the wrong questions.

• Wondering whether you should pull the plug to an experiment? Ask your frontline engineers. It is just human nature that many people do not like to be the bearer of bad news.

• Another way to test ideas online is the "painted door" test. Create a landing page and buy some Google ads to drive some traffic to the website and observe the traffic and response. You don't even need to build the actual product yet.

Recruiting Developers

• It is not impossible to hire the top talents away from the FAANGs. Some advice includes:
  • hiring a great leader and the rest will follow
  • Most employees just need to feel they are paid reasonably. Beyond the threshold, they tend to look out for autonomy, mastery and purpose.
  • Empower developers by trusting them to do their jobs, give them tools, and instill guardrails and rules
  • Developers are always hoping to be pushed, to learn and grow. They look for mentors who will help them develop. They want to create amazing and meaningful things and learn from other smart people.

Engineers sometimes need help to realize that nontechnology companies are filled with important, challenging, and difficult technology problems that would be really cool to work on ... The challenge is how to make engineers aware of these problems and get them excited about solving them. Again this all comes back to explaining the mission—and making it seem compelling.

• To be a good recruiter, you need to present your version of the Hero's Journey where your potential employees receive a "call to action". Present a compelling vision.

When interviewing prospects, ask what they're looking to accomplish and learn in their next role. Ask if they have ambitions to be more of an owner—and commit to helping them achieve that. When developers decide to leave your company, what do the exit interviews say about their motivations to leave?

• When we look at resumes, it's common to measure a candidate's position in their career: did they attend a top-notch school, did they work at prestigious companies prior, and so on. These are measures of position, but they don't measure distance traveled. I think it speaks volumes about grit and capability when a candidate, for example, was the first person in their family to attend college versus people like me, whose parents and grandparents also attended college. This is called “distance traveled,” and when you account for how far a candidate has come in life as a measure of future potential, bootcamp grads rank highly on my list.

Making Your Developers Successful

• You want knowledge and truth to win, not politics.

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

• One of the concept Twillio practices is Open Project Reviews (OPR). Anyone is welcome to observe a project discussion. The goal is to address one of the shortcomings of the “two-pizza team” approach, which is that when you have a large number of small teams they all start to run in a thousand different directions and it can be difficult for any single team to know what all the others are doing. Amazon has a similar practice called the Weekly Business Review. This is the Socratic Method intended to teach students how to think critically and make arguments on their feet.

Small Teams and Single-Threaded Leaders

• How would you compare and contrast those three companies—Amazon at 100 people, 5,000 people, and now 75,000 people? He thought for a few moments, and then said this: “You know, it's the same company. The same sense of urgency. The same bounce in people's step. The same intelligence.

At the heart of Amazon's scale are small teams with empowered, mission-driven leaders. In essence, a collection of startups.

• 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 also started asking all new employees to build an app using Twilio.

• For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose.

• 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. 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.

• If you want a small team whose members are focused on a mission, empowered to make hard decisions, and dedicated to running fast in service of your customers, then a leader is critical. We call such leaders "single-threaded" because they wake up in the morning with only one thing on their mind—how their team can win.The other common approach to running a small team is to have "two in a box" leading the team—typically a product manager and an engineering manager.

• How to groom single-threaded leaders? Most companies only have a few GMs at the very highest levels. Amazon, in contrast, has GMs running things at every level. GMs report to other GMs. Some GMs are Level 7 on the pay scale and others are at Level 3. Somewhere there's probably a young talented person who was given the GM job of running the tire store. It's a tiny fraction of Amazon's total business, so it's a low-risk role for leaders to hand to a young leader. This is how Amazon train future owners of the next wave of Amazon ideas. As new ideas spring up, there's an army of business leaders who can run with them. The problem of the Peter principle can be mitigated.

• It's important to formalize the relationships between teams as “service contracts.” Imagine each team was a literal different startup—and if you did business with them, their product was well defined and their pricing well understood. Without an internal price tag, it has the appearance of being "free" when in actuality, there is of course a cost. 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.

• In this section, Lawson emphasized the importance of Customer Centricity. Having customers, even internal ones, lets small teams have a clear mission that puts customers at the center of their decisions.

• Service is the technical delivery of a product. Hospitality is how the delivery of that product makes its recipient feel. Service is a monologue. Hospitality, on the other hand, is a dialogue.

• Help your developers build empathy for customers. Lawson's suggestion is to have an "idea forum" where users can suggest ideas to the company, and developers get to hear straight from customers what they need and why they need a particular feature. This helps break the barrier and create tight feedback loops between your developers and users. This also reminds me of the forum of Nomad Sculpt where Stéphane Ginier, the solo developer of the popular sculpting app, can interact directly with his users. Many users enjoyed using the app.

• Customers may not know what they want. However, customers are very good at expressing their problems.

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.

Invest in Infrastructure

• Great infrastructure is the foundation of innovation. When your tools direct nearly all of your energy toward the task at hand—serving customers and being creative—it's magical. For further details, read about Twilio's Admiral Platform.

• It's easy to get pulled into the trap of hiring more and more developers who work on customer-facing products, because that return feels more immediate—and their work translates more apparently into revenue. But infrastructure engineers make your entire development team more efficient. “Platforms are a force multiplier,” Jason says. “It's like a fulcrum. For every dollar I put in I can return five dollars.”

Other General Ideas

• It takes from than CEO support and a hungry team to achieve success. It starts with having the right players on the field and then empowering them to make progress.

• Building a structure and methodology for ideas to flow not just down but up the hierarchy, as well as across different areas of the organization, is critical not only to survive but also to thrive.

• I had no experience at a big company. If I wanted to create a meaningful company one day, I needed to learn how big companies operated. What worked well? What should I emulate with my next startup? What stopped working when companies got big? What pitfalls should I avoid? I needed to learn how business worked, how to manage, lead, and scale a fast-growing organization. At startups, you just ran as fast as you could, but how did real companies work? I wanted to find out. (Interestingly, I was doing the reverse at the point of reading. I want to learn how small startup grow and scale fast.)

• Building software is actually pretty easy but building the right thing is hard.

• Amazon's CTO, Werner Vogels, says. “Every day you get to create something new. Engineering is an extremely creative profession. Not all engineers are trained to become creative players. But it can be taught over time.”