Book Notes: Ask Your Developer

I just finished reading (or rather listening to) "Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century" by Jeff Lawson. I saw this book lying on a colleague's desk, it piqued my interest and after reading the reviews I decided to purchase the audiobook.
The author is the CEO and founder of Twilio, a cloud messaging company based in Silicon Valley that became famous for its billboard "Ask your developer" (pictured above). The point of the billboard was that if companies would ask their developers which service they should use, they would certainly recommend Twilio. This approach of "developers know best" is what made Twilio hugely successful and a great place to work, at least according to the book. Funnily enough, the day I started to read this book, this article appeared on HN, lamenting the fact that Twilio had lost its way.
Key Takeaways
Here are my main takeaways and how I will try to apply them to my daily work:
- Responsibility, freedom, purpose and autonomy are what makes developers tick. As a manager, one should strive to bring problems, not solutions to the team and trust them to find the right solutions. Managers should leave decisions to the teams and only intervene if they will damage the business or the customers. Don't second guess the team on every decision, don't bikeshed (usually the only area where managers can contribute anyway).
- Also, developers should be involved early in the discussion when planning new work. In a misguided good intention to shield developers from too many meetings, I have failed to do this all too often and always paid the cost.
- Developers need to walk in the customer's shoes, and be as close to the customer as possible. This gave me the idea that every team member should spend a couple of weeks doing customer support.
- Always start with the customer's problem, e.g. in product review. Always ask that question first "what's in it for the customer".
- Great product managers don't create a layer between customers and developers, they remove it.
- Before adding more people, rethink the division of the work in team and code. After such a change, it can take as long as 6 months before you are effective again.
- Having autonomous teams that do duplicate work is better than having no duplication and no autonomy.
Other notes
- "Build vs die": every company needs to become a software company and build the software they need to create added values for customers. Buying software means no differentiation, slow changes, no feedback loop with customers. The author, who worked at Amazon, recalls that Jeff Bezos always considered Amazon a software company, not a retail company.
- To succeed in the modern age, a company needs people who can turn any problem into a software problem. This doesn't necessarily mean software developers, but what the author calls "Software people".
- At Varsity (a startup to give free lecture notes to students) they managed people by producing automated reports of who was making the best notes, and automating the actions they needed to take. They managed hundreds of people in 5 minutes this way. They called it "Robomanager".
- Software Development is a creative endaveour (thank you!). Like musicians and filmakers use Youtube and Spotify to channel their creativity, developers use Saas and APIs. Many developers find other outlets for their creativity, like woodwork, painting, personal projects.
- Perks don't matter, that's not what makes people stay. People go to Silicon Valley and come back with the idea that free food, massage etc. is what's needed to replicate the culture of innovation, but it's not.
- Bonus systems don't work. If they are tied to company results, they are not motivating (you can barely affect them). If they are individual, they are usually obsolete and prevent you from doing what's right. MBOs also don't work, because things are too ambiguous and lot of time is spent to create them only to be forgotten soon after. The only sane way to manage compensation is to pay a competitive base salary and maybe award stocks. This is exactly the conclusion I came to after recent experiences.
Conclusions
In summary, the book is a collection of principles from the usual classics: Working backwards, The Mythical Man Month, High-Output Management, Only the Paranoid Survive, the Agile literature. It talks about how they were applied at Twilio and what the author learned while doing that. While nothing groundbreaking, it gives yet another practical example and confirmation of these principles. I'm glad I read it, if only to be reminded of things I already knew but forgot to pay attention to.
Buying the audiobook allowed me to listen to the book while commuting and running, but it made it very difficult to go back to the book and review the key points, for example to write this post. I wish there was a way to buy audiobook and e-book together and switch seamlessly between the two (there is, it's called WhisperSync but it requries that you use the same markertplace for both Audible and Kindle, which I don't).