“The truth is that most software is pretty simple. It’s what developers call CRUD applications: Create, Read, Update, Delete. Most apps online are forms that let the user input data, modify data, report out data, or delete data. Nearly every website or mobile app you’ve ever used is 95 percent CRUD operations. This isn’t rocket science.”
The above quote comes from Jeff Lawson — CEO and Co Founder of Twilio — and is from his book, “Ask Your Developer: How To Harness The Power of Software Developers and Win In the 21st Century”. Lawson (pictured below) isn’t trying to diminish the role and vale that software developers bring. In contrast, Lawson argues that software developers can bring a lot of different things to the table, beyond writing software code. “Ask Your Developer” encourages readers to move away from a process in which managers merely tell developers what solutions to build.
The central point of the Ask Your Developer approach is that developers should be engaged much earlier in the process, when we’re defining the problems that need to be solved. Lawson mentions Apple as a good example of this approach: developers are given problems and can solve however they think is best. Ultimately, the Ask Your Developer approach is about trusted collaboration.
Image Credit: https://www.askyourdeveloper.com/
“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.”
I love how Chad Etzel — iOS Engineer at Apple — points out in the book how managers have the power to connect developers with customer needs, and help them facilitate a solution. “Great product managers are not a layer between customer needs and developers” argues Etzel. “In fact, they actually remove layers, eliminate preconceived solutions and erroneous presumptions, and streamline communications.” I totally agree that great product managers facilitate the understanding of customer problems, not only for developers, but for all people involved in building the product or feature.
Another reason for involving developers early and often is that (good) ideas don’t tend to come at set times. Lawson writes about how the former CPO at Twilio — Chee Chew — changed the more traditional approach whereby engineers could only pitch products and ideas during the fourth quarter, when Twilio was making budgeting decisions for the following year. “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 explains in the book. At Twilio, Chee introduced the idea of a rolling pitch season, with a forum to continuously assess any ideas and assigning small exploratory teams to run a short experiment and see whether there’s value in the idea.
“If you think about it, most hierarchical companies (which means most companies) are structured such that the person or people at the top supposedly know all the answers (even through we all know they don’t) and therefore make the decisions.”
The role of experimentation comes back in the book’s chapter about “Creating an open, learning development”, where Lawson writes about moving away from traditional command and control environments. He explains that an open environment is one where you give people autonomy by sharing problems and letting them discover ways to solve these problems.
Image Credit: https://www.businessinsider.com/twilio-ceo-jeff-lawsons-book-engineers-know-when-project-wont-work-2021-2
However, such an open environment doesn’t equate with anarchy or no room for leaders to lead. In an open environment, a leader has two main responsibilities. Firstly, leaders provide guardrails to people and teams, which act as decision-making principles. Secondly, leaders offer support for teams to do their best work and achieve results. In fact, Lawson highlights that leadership is critical 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.
At Twilio, such leaders are called “single-threaded” because they’re hyper focused on creating the conditions for their team(s) to win. Threads are units of execution in a computer program — a multi-threaded program is doing a lot at once, but a single-threaded program is focused on doing just one thing. Lawson argues that accountability ultimately sits with a single person that leads the team. He seems less in favour of an approach whereby a high up executive makes the key decisions and cascades down to the front line teams who will have to translate these decisions into plans. Similarly, a “two in a box” setup — with an engineering manager and a product manager both leading the team — isn’t favoured by Lawson, as he feels it creates confusion about accountability or how to break ties to unblock progress.
Finally, Lawson offers two reasons as to why it’s important to put engineers directly in the flow of customer feedback. Firstly, customers are thus being ‘humanised’. Lawson explains: “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.” Secondly, developers can thus make instinctive decisions about work-versus-reward trade-offs. Developers are in a great position to make quick estimations about effort required relative to expected value, so their instincts serve them well in picking ideas that give the most bang for the buck.
Main learning point: “Ask Your Developer” should be read by anyone who doesn’t yet engage closely when developing products. Too often, implementation and therefore engineers are treated as an afterthought in the product development process. This book offers a number of strong argument for engaging with engineers early and often, and putting them directly in the flow of customer feedback. The days of just tossing a detailed product requirements document over the wall to engineers should be a thing of the past!
