Systemic alignment: The playbook and North Star

Every flow game still has some expert roles (ie: the goalie). In a modern software project, this may be a cryptography expert, an AI researcher, or any other role that really does require deep specialization (be it through education, experience or both) to perform. While you wouldn’t ask your goalie to line up on the boards for an outlet pass in your breakout, you may rely on them to stop the puck behind the net or make the initial pass, and it’s always helpful for them to communicate where they see opportunities and risks.

In order for all roles to contribute to the team’s success, they need to know the playbook. On projects, like when signing to a team, reading the contract is important. Arguably more important is establishing a team mission statement or North Star around which to rally. Not only does this serve as a target for the team to align their focus on, but it can also anchor difficult conversations (such as conflict or poor performance) around this common goal. This should be done as early into the project as possible, and everyone should have the opportunity to contribute to what this actually is.

Note: in some situations, these may be one in the same; however, there are instances where the mission statement is more “tactically-oriented” and the North Star is an overarching concept or goal for the team. For example, a mission statement may apply to a particular phase of a project and change as new phases begin, while a North Star may apply to the overall project or program.

The key components of a playbook include:

  • Documented development standards

  • Deployment processes

  • Technology frameworks

Without these artifacts in a common format which can be viewed by any team member at any time, there is a risk of divergence among the team’s understanding of and approach to the work. It also means that whoever has the true source of this information poses as a silo to the project and will likely have to repeat themselves several times as they convey this information to the team. Do yourself a favour and write it down.

Drills

While we may strive to make our work feel more like play, in the real world we unfortunately do not have as much time to freely “practice” as a team. Deadlines, budget and scope are all very real.

However, every time we have a chance to run a certain scenario in a flow game, it is a chance for us to improve upon last time. Games can be broken down into plays, such as where everyone should go off of a face-off or the formation upon entering the offensive zone. Projects are broken down into phases or sprints where the goals and expectations are smaller and more prescriptive. In both scenarios, a focus on winning “the small battles” often leads to winning the game.

Sprint ceremonies and retrospectives are essential for building the systemic context required to play the flow game. Just as drills exist for specialized positions, these ceremonies ensure the broader group gains the cross-disciplinary awareness needed to “fill another lane”. Success isn’t just about each individual finishing their own tickets; it’s ensuring the entire solution crosses the goal line.

Creative improvisation under pressure

Flow games are typically “games of mistakes”. They are chaotic, and the ability to read and react to situations in a way which aligns with the team’s goals (ahem, Playbook) are critical to team success. Being overly rigid in one’s expectations or approach often limits the potential of a player (or even a coach). One must, in a word, flow.

For instance, a rigid player sees that the dependency defined in the original design document (the “Playbook”) is unstable and will introduce significant long-term risk. They continue coding against the flawed dependency, waiting for a formal architecture review that may delay the project. The flowing player, however, proactively documents the risk, selects and implements a proven alternative, and immediately communicates the change to stakeholders, ensuring the team stays aligned with the overall North Star of long-term system stability.

It's infeasible to huddle after every play. Most of the time, the game is still live after a certain scenario or situation. When there’s a chance to debrief, the time allocated to do so does not allow for a frame-by-frame breakdown of what occurred. Even in video review, coaches are forced to prioritize key learning moments instead of having the team discuss the entire game in great detail.

Communication is centred around the mission statement, North Star, or other shared goals. The Playbook provides the direction, but the player provides the execution. Information has never been more readily-available, and somehow ambiguity has seemed to proportionately increase. Players (and coaches) who can flow through the chaos in a way that brings the team closer to shared goals are well-positioned for success, no matter their “position”.

AI as the assistant (to the) coach

Agile project methodology has always been closer to a flow game than waterfall-style planning and execution. However, by supercharging the velocity of coding, AI has amplified the flow game nature of modern software engineering to another level; it is faster, more continuous, and more intense than anything developers have experienced before. 

Still, that doesn’t mean that AI will completely replace the roles of humans on a team (any time soon). It does, however, transform those roles.

With the use of AI, software development mirrors the flow of a fast-paced team sport.. AI can perform this at a speed and scale that few (if any) human developers can accomplish. This creates the dynamic of a continuous, high-tempo passing game. For the developer to act as the ultimate playmaker, they must constantly 'read the play', anticipate the next move, and provide the AI with the precise context it needs to execute its next rapid-fire pass.

If humans are writing the code, then AI can be used in even more of an assistant coach’s role. Checking for holes in the defense (security vulnerabilities) or stronger offense (more efficient queries) can be done faster on more lines of code and in a more consistent manner than relying on human reviews alone.

Beyond code, AI can be run against project backlogs. It can help determine where different pods or workstreams are hitting bottlenecks, identify patterns in ways of working, and assist in calibrating sprint goals to that sweet-spot between 'stretching' and 'overly ambitious'.

Despite all the benefits of AI, an over-reliance on it will weaken the posture of a team. While assistant coaches are important pieces of a team’s success, the players must still play the actual game. An over-reliance on vibe coding introduces security, architectural and requirements risks. If developers cannot explain what they need to code, or what their code is doing, that code should not be used.

AI should be used to build stronger comprehension of the overall system, vital for the flow game, for developers. Never before has information been so easily accessible; this is something to capitalize on to enable “filling the lane”. Technical and non-technical roles alike can benefit from asking the AI follow-up questions. Why did it choose a certain pattern? Can it rehearse complex architectural decisions? This capability accelerates learning and ensures system alignment, providing the contextual awareness and confidence necessary to maintain flow.