Hi all,
I'm starting to write a book about making things (a dramatically different concept than having finished writing a book) and in particular, what I know about leading engineering and product development teams. I'll tell you why in a second and then I'll share an outline.
In drafting the outline, I realized many of the chapters were already written as blog posts, which seemed like a good head start. And, I thought the unwritten chapters would make good posts in the weeks and months to come.
My hope and my request to you as readers is that you'll ask questions, debate, and help me sharpen my ideas. At this stage, my chief questions are: Does the outline form a coherent framework? How can it be improved? What should be added or dropped? And which chapters would you want me to write first?
Why?
I have a deep-seated belief that good technique leads to better outcomes with less stress. Further, much of "good technique" when it comes to leading and managing teams isn't necessarily hard, but it's often unintuitive. Also, and this is important, it can definitely be taught.
It takes a bit of chutzpah to claim I'm good at this, but in some cases, I've got real data to point to. For example, my product team at Amazon had unheard-of job satisfaction scores above the 90th percentile in all six measured categories. I shipped a Kickstarter solo. I've led successful product launches on teams with great morale.
I also think there's a gap in the literature. There are books about managing projects (I actually think the majority of them are bad) and books about leadership (some of which are quite good!), but nothing about the combined leadership skills, project planning, and execution skills needed to lead a team to effectively ship high-quality product.
From one point of view, much of the content in the outline is repackaging, or in a better light, curating things I've learned elsewhere. But for maybe 30-40% of it, I think I have something original to say and something new to bring to the table.
At the very least, putting a few more blog posts together can't be a bad thing.
Without further ado, the outline:
Leading, Managing, and Motivating
Start with Why - communicating and motivating
Natural Born Problem Solvers - leveraging customer empathy and engineer's intrinsic motivation.
Teaching is the Most Scalable Way to Improve the Team
Feedback (Read the One Minute Manager or Read This. Also, I Tell My Spouse "I Love You" Every Day) - giving feedback is part of leading.
Setting Up and Cheering Continuous Progress - How small wins mitigate risk and keep a team excited and focused.
Setting Goals - The "results chain" and techniques for managing and hitting goals
Mindset
There's No Integration Risk if You're Always Integrated - Agile, but you know where you're going.
There Is No Proof Like Actual Proof - A paranoid mindset to drive out the unknown unknowns.
In the Face of the Unknown, Invest in the Tools to Explore the Unknown - Build to learn, but with more purpose.
The Four Product Risks - The various reasons that products fail.
(Risk Adjusted) Weighted Shortest Job First - The fastest, cheapest way to avoid failures.
Specs vs. Requirements - In life, there are no requirements. The spec is just what you are agreeing to build. There are no warrantees it will be successful.
Planning
Journey Mapping - The most powerful technique I know for thinking about systems, from product experiences to back end APIs.
Breaking Down User Stories - Journey Mapping at a detailed level.
Techniques for Negotiating and Brainstorming Solutions
Estimating Things - Even more detail.
Building a Schedule (High Level) - The approach to setting high level deadlines and milestones.
Building a Schedule (Detailed) - Detailed schedule planning.
Executing
Mechanisms over Wishful Thinking/Good Intentions - Taking systematic approaches to making sure things get done
The Importance of Cadence - Ad hoc meetings are the death of maker time.
Status Updates and the Right Questions - Collecting information efficiently.
Retros
Pre-Mortems
Tidbits
Design for BOM Transfer - Designing for movies is a thing. But we're designing something that will ultimately be manufactured.
Put a Sticker On It (There is Only One Part #1) - My pet peeve: re-labeling parts as #1, #2 and #3 and what to do about it.
Achieving Failure - A warning on executing on the wrong thing.
Enough UX Research Skills to be Really Dangerous
Usability Testing for Dummies
The Switch Interview and Jobs to be Done for Dummies
Bonus: More Elucidation Techniques