This is part nine of a series on Extreme Ownership. View the previous parts if you haven’t already: Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8

One of the leadership tools prescribed in the book Extreme Ownership is a framework for developing and executing a plan. The book outlines the different phases of the planning process, the roles each individual takes and the relationships between them. After reading this section of the book I thought about how it related to one of the best performances my team had at my previous job. Although none of us had read the book at the time, this project was still a demonstration of Extreme Ownership at play.

In 2018 Makr was tasked with creating a logo creation tool to be featured on the Staples website. Unlike our primary offering, where users created designs out of a template, this tool would do all the heavy lifting and procedurally create logos after a few simple inputs. Our resources were limited; we were a team of around ten and we had to get the new product to market in less than half a year. To deliver sucessfully we needed to carefully coordinate our efforts. Extreme Ownership provides guidelines on how leaders should manage teams in a situation like this one.

Leaders should make the mission known to the entire team. Objectives must be clear enough so that team members understand them and know how to move towards them. In our case, we wanted our tool to produce a diverse array of workable logos with mimimum intervention from the user. Those requirements drove our design and implementation decisions.

Leaders should know what resources are available to them. Identify personnel, assets, resources, and time available. Our primary contributors were an art director, a UI/UX designer, a UI engineer, and a full-stack engineer (myself). We also pulled in an external team of engineers later on. All of the art assets were new but we leveraged parts of our existing codebase, reskinned them to fit the new product, and made net new features only when absolutely needed. The project was worked on from late July to early November (a little bit over three months).

Leaders should come up with a specific course of action. Pick your best option and double down on that. Our secret sauce was our process of pulling in assets based on the user’s business information and combining them into logo designs; most of the effort was made perfecting this system. We kept a minimalist approach on the other sections of the application.

Leaders should decentralize the planning process. Leaders must delegate down the chain as much as possible. Makr had a flat hierarchy; some may think that would lead to anarchy but that actually meant everyone had to become a leader. Our product manager carried the overall vision, but she wasn’t well versed in art production, design, or engineering; it was up to the individual contributors to make key decisions in their respective areas of expertise.

Leaders should assume any risks are present, and mitigate those risks as much as possible. I had be willing to take on the project knowing there were going to be uncertainties involved. That being said, there was a key part of our system that wasn’t sure was technically possible, and it would’ve been a showstopper if we couldn’t get this piece implemented. I actually fought hard to get the resources needed to address this risk, and I may go into further detail about this in a later blog post.

Leaders should check in regularly and make adjustments based on the current situation The team did daily check-ins to see if we were blocked by dependencies, and other stakeholders peaked in occasionally to check the quality of our product. From these we found blind spots that needed to be addressed. For example, we had created plenty of assets for restaurants but few for construction businesses, so the team shifted their focus to underrepresented categories so that all users can have a satisfactory experience.

Leaders should conduct retrospectives after execution. No matter how well leaders are at improvising in the middle of a mission, things can still go wrong. At the end of the project, our UI engineer spent late hours finishing the frontend, and our software architect also worked overtime to migrate our platform to a new vendor. By contrast my workload was much lighter, working on new features that wouldn’t have been released until v2. While overspecialization allowed the team as a whole to act quickly, it hindered our ability to delegate and made the experience a lot worse for some of our members.

One aspect we couldn’t achieve was standardizing the planning process. The team was laid off shortly after the project ended so we never had an opportunity to solidify our practices. However, if you’re still running a team you can establish a planning process for them and see the difference for yourself.