At Revelry, we are always sharing with each other what we’ve learned, read, consumed, and been inspired by. During a recent meeting I was inspired by a share from Brian Ng about leadership, called Leadership Lessons from the SEAL Team. The article sums up 10 Seal Team leadership skills as revealed in the book Extreme Ownership: How U.S. Navy SEALs Lead and Win.
Each of us exhibits these leadership skills throughout our process.
As you do when reading a list about what it takes to be the best, I took stock of our own practices. We’re pretty proud of our process here, and I feel just a little prouder now that I notice we seem to have baked these same leadership qualities into the way we work.
This is probably a big part of why we all feel so much ownership and empowerment to keep questioning and iterating on the process.
Depending on the project, we all step into a leadership role at some point. These 10 SEAL Team leadership skills inspire me to notice and appreciate my skills – and those of my coworkers – even more.
Skill 1: Leaders Embrace Extreme Ownership
“You can’t blame your products, your boss, your budget, the economy, competitors or your team for your success or failure. You are accountable for your success in your job, your career and your life.”
Around Revelry, we like to say “Call Your Shots.” We rely on this practice so much that it’s emerging as an additional Core Value.
We trust each other to work to unblock ourselves. And if we’re unsure about which path to take, we know that we don’t have to wait for approval. If I ask for help or direction, but I don’t get an answer? I call my shot. This is where I point to the stands. I don’t need permission to act. I say, “I’ve got it.”
“Call your shots” means visibly, on a ticket or in Slack, stating your next action and then moving purposefully to carry it out.
Don’t let fear of making a mistake stop you from trying to solve your problem. It’s OK if this action turns out to be wrong, or if your solution doesn’t work out. There is no mistake you can’t come back from or, more importantly, learn from.
Unless you’re handcuffed to the nuclear football, don’t be afraid to make a call and move forward.
Skill 2: No Bad Teams, only Bad Leaders
“Mutual accountability means each member demands the highest performance from the others and each individual knows what they need to do to win and they do it.”
Revelry works in one week sprints. On Monday, we have a Kickoff call. During this call, each team member sets an attainable goal. After Kickoff, we all set upon a path with a plan. At first, we pursue this goal individually. And then, we lean on each other to complete that goal if someone is struggling.
We trust each other, and we trust the process. You could say that the PM is the leader, in a sense, but that is only part truth. The PM asks the questions that lead to commitments and plans, but it’s really the process that defines those questions and creates the plan of attack. The process, through Kickoff, leads the team on their way to a successful sprint week.
Skill 3: Mission Clarity
“Everyone on the team must understand not only what do to, but why. Leaders don’t have to explain every decision but they need to communicate the strategic picture and the mission. Let the team ask questions. The leader is responsible to have everyone on the team believing in the mission and clear on the objectives.”
The Revelry process tackles this one in a few ways. In every single project ReadMe, there is a Project Brief. Included in that brief is the idea of what we’re trying to build, who we are building this product for, the main problem or pain point being solved, and the core loop that will define the project in its early stages. Everyone on the team has a reminder at all times what and who we’re building for.
Getting a little more granular, we rely on our User Story format. Each story contains a Background section that captures the objective, in its base form. During Planning Poker, each ticket is discussed and either scored for complexity or sent back for more refinement. Before a ticket is worked, the team gives buy-in and agrees on both the objective and its difficulty of implementation.
Skill 4: Keep your Ego in Check
“Ego clouds and disrupts everything: the planning process, the ability to take good advice, and the ability to accept constructive criticism.”
A major part of the Revelry Process comes in the form of reviews. For example, Pull Request reviews for our projects first run through Lintron, our built-in code style reviewer. It automatically drops comments with code smells as soon as a Pull Request is created. Once we address those comments, the next step is the Peer Review.
Everyone puts a great deal of effort into writing clean, concise, readable code. We don’t look at these review comments as criticisms as much as learning opportunities. Accepting these comments and correcting mistakes is all a part of the built-in process. Sometimes we do merge a Pull Request and, for instance, our VP of Engineering will see a better approach during a weekly sweep of PRs. They’ll take that PR link and drop it into our implementation Slack channel (where all the developers hang out, share, and ask for help).
This isn’t an effort to embarrass anyone or point fingers. It’s a part of the process to create opportunities for the entire team, so we all learn from each others’ mistakes. And, it gives us an opportunity to discuss and debate alternative solutions.
Skill 5: Act Decisively. Cover and Move
“You will never get to 100% certainty. Wait and see means deciding not to decide. The picture will never be complete, there is always a risk, there is no absolute right solution. Therefore, you cover your risks and move forward. Leaders acknowledge uncertainty, mitigate risks and continue advancing towards achieving the mission.”
Leadership still comes down to “Call Your Shots.” This particular article spoke to me so strongly because I think the most important leadership skills are covered by this simple but meaningful phrase.
“Call Your Shots.” Period. Nothing in life is certain, so don’t let doubt cloud your judgment. Call your shot, and move on to take action. Sometimes you’ll be wrong, but more often than not you’ll be right. We’d rather take 100 shots and hit 75% of them than 40 shots and hit 95%. In our view, a shipped mistake is 1000% better than a static idea. Mitigating risk is not the same as staying idle.
Part of the process is trust. Not everyone is available all the time; this happens with remote work. You should ask the question but don’t wait too long for an answer. Make an educated guess on the best solution and move forward. Nobody will judge you for making calls and getting work done.
Skill 6: Simplicity and Clarity
“Complexity is the enemy. Complexity usually means there are many unknowns and that the team has too many variables to work on. A complex problem requires a complex plan which is not easily understood and not easily executed.”
As I mentioned earlier, we play Planning Poker mid-week using our Slack poker-bot. If you’ve never played planning poker, here is the Wikipedia synopsis. It is a system for scoring tickets or issues to be worked, based on complexity, using the Fibonacci series. As a general rule, the issues we work do not go above a complexity score of 8. Scoring a ticket with 13 normally means the team should put some extra thought into breaking a particular problem down into even smaller, more granular, and actionable steps. 13-pointers happen, but they are the exception and not the rule.
Simplicity and Clarity are essential in building good software.
Skill 7: Prioritize and Execute
“When leaders find themselves in a situation where multiple issues require their attention, it is easy to fall in despair. Good leaders identify the highest priorities and tackle problems one at a time.”
In preparation for the upcoming week, we perform Sprint Planning with the Product Manager and the Product Owner. They discuss any issues or stories that need approval, any that need to be written,and where they need to be placed on the kanban planning board. Many of our projects start with an Icebox column that catches all the issues and headlines for future use. Many times, these are draft tickets or lower priority-scored tickets. Once a ticket is scored and confirmed within the scope of a project, it’s moved to the ‘Next Up’ column. This is the column used in Sprint Planning, and issues are organized top-down in priority.
On Monday morning, all project team members, including the product owner hop on a Zoom call for Kickoff. Here we take a look at those priorities and form our sprint commitment for the week. We don’t bite off more than we can chew, we simply take an honest look at the board and say, this week we think we can accomplish this amount of work and we’ll work the issues in order of priority.
There is no true “Leader” in this meeting. We all follow the process, and the process itself embodies the leadership.
Skill 8: Decentralized Command
“In the military, there is a concept called Commander’s Intent. The leader provides a very clear goal, he communicates what needs to be accomplished. The team has freedom to determine the best way how the goal will be accomplished. This gives the team the much needed freedom to innovate and adapt as the situation changes.”
We rely heavily on User Stories and how they’re written. The Product Owner describes the application, or sometimes a specific feature that they want included. The Product Manager listens, asks questions, and eventually digs far enough down to find the root problem the product owner is trying to solve. The PM then has the freedom to come up with a solution for this problem. And that’s how we write a User Story. Once the product owner approves it, the engineering teams implement it.
The Scenario portion of our user stories lay out Acceptance Criteria that a feature needs to pass in order for it to move along in our process. Many times, we keep these AC vague on purpose. The PM writes the story that envisions an end user achieving a valuable result. The story doesn’t include steps for the engineer to follow. The engineer requires a goal and an understanding of the reasons behind that goal.
Much the same way the User Story was fleshed out, the engineer begins to implement it. The process gives everyone the freedom to accomplish the goal(s) set by the Product Owner.
Skill 9: Manage Up and Manage Down
“Good leaders manage up the chain of command. They understand the perspective of their commanders. They ask questions. They provide information and build confidence. Engage with your higher-ups; keep them in the loop–especially when they frustrate you. Leading down the chain of command means being able to convey the overall strategic mission to everyone downstream, while also giving people ownership of certain decisions, which leads to higher buy-in.”
We can manage up and down without putting too much pressure on any one member of the team by following our process. Throughout the approval of the user stories and the implementation, we are all on the same page and we have the same expectations. The PM captures and clarifies goals, and the engineers implement solutions as they see appropriate, in order to reach the desired outcome.
Skill 10: Discipline Equals Freedom
“Discipline does not make a team more rigid, but more flexible. How? By creating processes and systems that allow teams to execute in different conditions without having to re-think the basics. The essential processes are covered by discipline. The mind then is free to focus on what is important in the moment.”
This snippet is basically the driving force behind having a process and caring for it like we do. For the most part, with a good process in place, you can be sure what task to do next, which frees up the mind for more creative thinking and in turn better products and solutions.
Sometimes things are not so cut and dry. We won’t try to fit a square peg in a round hole. We play Jazz a lot. The process is there as a tool to fall back on. But we’re not cultists. When the process doesn’t fit, we allow ourselves and our team to change it up. We make the process work for us when necessary, not the other way around.
Maybe this kanban needs an extra column. Maybe the daily standup in Slack would work better in Zoom for this project. That’s playing Jazz and calling shots.
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.