One of the problems I am always thinking about as an engineering manager is setting my team up for success when kicking off a new project.
Providing too little detail can lead to excessive brainstorming without clear direction, while overloading the team with specifics can stifle creativity and ownership.
One approach I’ve found effective is “commander’s intent”. This framework focuses on communicating the why: the underlying problem we’re tackling and a criteria: the north star to indicate when the team has achieved success.
I typically translate this intent into a concise wiki entry outlining the problem in a few sentences and defining success through bullet points or a single sentence.
Following the wiki creation, we hold a kickoff call to review the document and address any questions.
After the initial call, we will do regular check-in calls. My responsibility as the manager is to own eliminating the problem itself, while the engineers own crafting solutions. These regular calls ensure alignment and confirm we’re moving in the right direction.
They also serve as an opportunity to identify opportunities for collaboration within the team, across teams, or with external stakeholders, as well as any potential roadblocks that require my intervention.
As a manager, I assume that I’m the least smartest person on the team. The engineers on my team has more domain knowledge and for this reason has the answers to solve a problem.
Commander’s intent is one of the frameworks I’ve used that has led to success in solving problems as a team.
