Book report: Turn the Ship Around! A VP R&D's Summary

Recently I’ve read Turn the Ship Around! by L. David Marquet following Anton Drukh’s recommendation.

This summary is mostly for me and for people I’ll refer it to - so it’s not the most friendly read. But if you don’t have time to read the book, this post can serve as a useful TL;DR for you. I highly recommend you do read it - it’s a great read and a short one, too!

What’s the book about? It’s about leadership, and specifically the leader-leader leadership model. The core of leader-leader is all about giving away control to the employees instead of hoarding it. To do that you need two supporting pillars: competence and clarity.

This post has two parts: In the main one, I review all the mechanisms that the author describes and try to give one example from an R&D perspective (instead of the nuclear submarine Captain PoV). In the second part I just wrote down a “cheat sheet” for questions to ask in your first 1-on-1’s in a new job.

Mechanisms for Control

Find the genetic code for control and rewrite it

The genetic code for control can be found by finding where control is (policy documents or personal), seeing which specific decisions can be pushed down, and then solving competence and clarity to be able to delegate. This will turn team leads from privileged to accountable.

R&D Example: look who is prioritizing features (deciding on Why and What), and who is deploying (deciding on How, Who, and When). Oftentimes this is happening in the group lead level (and in startups, even in the C-Level). Rewriting this to the team lead (or even senior engineers/PMs) level can move specific decisions downwards.

Act your new way of thinking

When defining a cultural change, make sure to complete the following sentence: “I’d know we achieved this [cultural change] if I saw employees…” with something measurable and code the behavior into the company’s practices.

R&D Example: When setting up an on-call process within my org (happened twice already), I was always first in the rotation and stayed in the rotation.

Short, early conversations make efficient work

Get early feedback between team members. Don’t ask for perfect the first-go-around. Why people don’t like it - “trust” - if your work is checked does that mean I don’t trust you? Trust is a characteristic of human relationship, if the work is actually good is a physics issues.

R&D Example: Performing early CRs for draft PRs, instead of reviewing a PR once it’s done. No need to go through a team lead to get a CR - post in the channel and everybody’s (who’s certified for CR) can review. This works up to the scale of a few teams at least.

Use “I intend to” to turn passive followers into active leaders

Give control instead of taking it. This can also go like this: them: “I intend to…” me: “What do you think I think about this idea?” them: “you’re wondering if it’s safe to do so, since…”.

R&D Example: Instead of developers reporting tickets and waiting for someone to prioritize them - open a ticket and a PR. Instead of waiting for the on-call to start the triage of a production incident - open it yourself, and hand it off to the on-call once they get on the scene. Bias towards action instead of waiting for directions.

Resist the urge to provide solutions

When you follow leader-leader, you must take time to let other react to the situation as well. Many quick decisions means that the org itself is reactive.

R&D Example: This is probably what I’m worst at. I can not think of a single example that I preferred to not provide a solution and/or give others time to react.

Eliminate top-down monitoring systems

Everyone is responsible for their own performance. Sure, stuff might slip, but not the important stuff. Actually give ownership and you’ll get rid of “lack of ownership”.

R&D Example: Instead of the PM/Team Lead setting up the milestone meetings of a feature (PDR, DDR, Deployments, Customer calls) - have the developers set up those meetings themselves (and therefore, own the deadlines - I intend to finish the DDR by X date).

Think out loud

Feel free to use informal language and imperfect ideas, as it is a tool for organizational clarity and control. Lack of certainty is strength and certainty is ignorance.

R&D Example: Bias towards public Slack channels, with “let’s think about X: a thread” threads, and daily summaries of “ugly”, unfinished work. Also, writing and publishing daily blog posts on your work. That can help other people see your thought process, and since it’s relatively unstructured, unpolished, and easy to start (the daily journal is always there; the Slack channels are aptly named) it’s easy to think out loud.

Embrace the inspectors

Concerning areas where you’re an expert, the inspectors are advocates to share with. Concerning areas where you need help, the inspectors are sources of information and solutions.

R&D Example: Instead of doing the absolute minimum when preparing for a SOC2 inspection, try to extract as much value for yourself with every part of the certification. For example: matching every ticket to PR is a doorway towards QA and project management automation workflows which make it simple to promote organizational standards (such as, every ticket has an attached test).

Mechanisms for Competence

Take deliberate action

Mistake don’t just “happen”. They can be lack of knowledge (solved by training), lack of supervision (solved by adding more supervisors), or “working in autopilot”. To have people not working in auto, they should take deliberate action.

Deliberate action is not for the benefit of someone else.

R&D Example: Writing a daily diary. By writing about your work instead of actually doing it, when a developer gets “blocked” (waiting for a build/a context switch) their default window is the diary. So they can return to context quickly, and/or think about their task while they’re waiting for feedback from the machine.

We learn (everywhere, all the time)

Want to have a training program that employees will want to go on? Here’s how it should work:

• The purpose of training is to increase technical competence
• The result of increased technical competence is the ability to delegate increased decision making to the employees.
• Increased decision making among your employees will naturally result in greater engagement, motivation, and initiative.

R&D Example: See what I have to say about learning here. A specific example was setting up an automated board that follows all the TODOs from postmortems and retrospectives (we did it with a Jira task report widget + labelling the relevant pages), to make sure we actually apply the lessons learned, not only say we will.

Don’t brief, certify

Something as simple as read-ahead or think-ahead assignments that people are accountable for accomplishing could turn a brief into a cert.

Certification is a decision point - it’s possible to fail the certification - you are not prepared to take the action yet, lack of knowledge or understanding. Without this being a real decision point, this is just a brief (no one listens to briefs).

Certifying instead of briefing forces intellectual engagement and raises employee engagement.

“How many minutes do you spend on non-mandated learning”.

R&D Example: Game-ify learning experiences (See my CTF) with actual scores is one way to do this in R&D groups.

The deeper concern is: if you allow everyone to do everything from day one, you promote inclusiveness. If you require certification to “touch prod”, you promote stability. How to promote both? My way for implementing this was to forgo a lot of “training” in the onboarding phase and replace it with working with a partner, and being “certified” to perform certain tasks early on. The first day you must merge SOMETHING. The first week - you’re on call! Actually get all the keys to production, etc. That way you certify and you have a safety net.

Continually and consistently repeat the message

What’s the other option? Change the message? Old habits die hard and you must repeat your message often (this means having a message worth repeating).

R&D Example: Create templates for documents that include the reasons for the document’s existence EMBEDDED within the template. For example, I created a PDR/DDR template with the relevant checklists and references to Code Complete.

Specify goals, not methods

Once the team is freed from following a prescribed way of doing things they can come up with many ingenious ways to improve. This means having specific goals in mind when defining a process.

R&D Example: Define how the feature’s success will be measured, instead of how it should look. The measurement should be a lot more rigid and the plan of HOW to do it should be flexible.

Mechanisms for clarity

Achieve excellence, don’t just avoid errors

There’s a lot to say about this topic, but the short of it is: you at most get what you strive for. If you only strive to avoid errors, you might avoid some but you won’t overachieve anything.

R&D Example: Once the MVP of a feature is out, don’t wait until the feedback rounds are ready to start with the next steps - identify the “core” aspects of the feature and start to improve their quality. Something that’s easy to reach for here is performance enhancements or test coverage - usually won’t count as an error to avoid unless it’s catastrophic (timeouts), but excellent software is fast and reliable.

Build trust and take care of your people

If the crew is convinced that you are “on their team” they will be no issues with constructive criticism. But taking care of people does not mean protecting them from the consequences of their own behavior.

R&D Example: It’s easy to think that this means “don’t overwork the team overnight, ALWAYS”. The honest answer here - at least in startup-land - is to never stay overnight if it’s not required. Once in a blue moon, someone will need to work on a critical feature for a client. Stuff happens. The way to build trust after asking for overtime is to make sure the team member feels the impact of their work (for example: by showing up to the customer calls) and by compensating (Paid unofficial PTO, or even bonuses if that’s relevant); need to be careful with this, since generally you don’t want to reward overworking.

Use your legacy for inspiration

This is very org-dependent, so there’s not a lot of value in adding an example here. Just remember that if your org is new, the “legacy” your looking for can be found in similar orgs trying to solve similar issues in the past.

Use guiding principles for decision criteria

R&D Example: One of the guiding principles of Reco was We win together. When deciding to build the teams, we put that principle front and center and come up with guidelines on how to build successful cross-functional teams.

Use immediate recognition to reinforce desired behaviors

Recognition shouldn’t be an internal competition - the org is competing against external forces. Having “excellent” not be a bell curve internally but a real physical indication of excellent means that once enough team members are excellent in X they don’t need to refine it anymore and they can move on to the next one.

R&D Example: In our Slack we set up the #shoutouts channel early on. I recommend you do the same!

Begin with the end in mind

Go through evaluations and look for statements that express achievement. In every case, ask “How would we know?” and ensure that you have measuring systems in place. Have employees write their own evaluations one year, two years, or three years hence - the goals should cascade down from the org goals (not identical but appropriate). How to make achievements indisputable (how would I know) and measurable.

R&D Example: As we plan the upcoming month of work, this could be your conversation the first time: Product: “I want to have less bugs in the system” Eng.: “How much do you have now?” Product: “Don’t know, didn’t check”

And it should change to:

Product: gestures at dashboard “Customers experienced 5 minutes of downtime daily on average. I want them to have a better experience.” Eng.: “I saw that as well and already triaged the root cause before the meeting. We are at the limit of scaling up our DBs, and need to invest in scaling out.”

Encourage a questioning attitude over blind obedience

“Captain, you’re wrong”. Errors should be stopped, not propagated.

R&D Example: Always leave 50% of the meeting’s time for questions, even if it’s an all-hands. It’s more beneficial to answer questions than to uni-directionally deliver messages.

First 1-on-1 questions after taking on a leadership role

This is just a cheat sheet taken directly from the book. Handy for anyone who’s about to go into a role, but be warned - without actually reading the book many of these question will ring hollow and you won’t be able to actually deliver on the answers!

• What are the things you are hoping I don’t change?
• What are the things you secretly hope I do change?
• What are the good things about {{.OrgName}} we should build on?
• If you were me, what would you do first?
• Why isn’t the ORG doing better?
• What are your personal goals for your “tour” (ship tour - translate to job) here in {{.OrgName}}?
• What impediments do you have to doing your job?
• What will be our biggest challenge to getting INSERT NEXT BIG GOAL HERE (in the book it was getting ready for deployment - something SMART not VAPID)
• What are your biggest frustrations about how {{.OrgName}} is currently run?
• What is the best thing I can do for you?