Modern engineering is a flow game

The game is changing. If you’re still waiting for a hand-off from a PM to tell you exactly how to write every line of code, you aren’t an engineer; you’re a linebacker waiting for a whistle that isn’t coming.

Traditional engineering follows a “waterfall” approach, most likened to American football, which sports psychologist Dr. Saul Miller calls “the game of the plan” in his book, Why Teams Win. A small group of individuals create a plan, raise capital and then install the assembly line. There is a quarterback, and there are linebackers, and there is a kicker (among other positions). The downside for the engineer is the monotony of only ever solving one type of problem, the constant waiting for the next handoff and the lack of systemic understanding that leads to slow feedback loops and burnout.

Why teams win: the Agile 'flow game'

Modern software engineering, in contrast, demands an Agile “flow game”, akin to soccer or hockey. Plans, and the development of these plans, is seldom linear. The team knows the ultimate goal of the project, but success is brought from “filling lanes” more than “staying in one’s lane”. The players on the field should know the playbook, but it’s not unheard of for a forward to hop into a defender’s spot mid-play. Specialization still has a place here; having one’s top goal scorer play goalie would likely lower the team’s chances of winning. However, success comes from maintaining a clear, fixed direction while embracing adaptable, flexible roles (“filling lanes”) to reach that goal efficiently in a non-linear environment.

Here's how embracing the flow game mindset, from knowing your role to leveraging AI, will redefine your career and your team’s success.

The expert generalist

A focus on generalists should not be mistaken for a lack of depth. The “expert generalist” is a unique professional who delivers deep domain knowledge but also possesses the flexibility and systemic view to contribute across the non-linear development process; this is an especially key skillset in modern engineering. 

Even in flow games, players have positions. The “defense” still exists, but they are no longer isolated; they are simply the first line of counter-attack. Even points leaders need to backcheck. These roles include:

• Infrastructure engineers

• DevOps engineers

• Security engineers

If the user is the goal, front-end and product engineers are the forwards. That doesn’t mean they can’t help out the defense in the event of a poor-performing database or a failed deployment.

True expert generalists are able to succeed in their day-to-day domain while supporting other positions when needed.

This brings us to the concept of 'filling lanes'.

Filling the lane

In a hockey game, if a defenseman carries the puck deep into the offensive zone, a forward should read and react to cover that defensive position. This is “filling the lane”, and it enables high-performing teams to truly flow.

During the lifespan of a software engineering project, it’s not uncommon for the lead architect to get bogged down in a security audit. When this happens, a senior or lead engineer may need to step in and support the role of the lead architect by driving detailed design discussions, supporting key decision-making to unblock the team and ensuring the overall solution continues to be met.

Imagine a front-end engineer notices performance issues in the data layer during a security audit. Instead of waiting for the data team to finish their sprint, the front-end engineer dedicates an afternoon to tuning a couple of key queries. They temporarily “filled the data lane” to keep the product moving.

It is critical to distinguish this practice from the capacity-driven development anti-pattern. Filling the lane is a deliberate, targeted act focused solely on solving emergent bottlenecks within the team’s current product or stream to unblock the core mission. Unlike capacity-driven development, which increases cognitive load by taking on external work simply to maximize resource utilization, filling the lane is driven by systemic need and maintains focus on the team’s existing goal.

The main message here is that team members don’t need formal training (or even a certification) in every discipline, but they do need the contextual awareness to identify an open gap, and the courage to step in.

As the name suggests, the majority of roles in a flow game are fluid. Out with 'I’m a React Developer', and in with 'I'm an engineer currently playing in the ‘front-end’ lane to drive this feature home'.

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.

The game plan

A coachable player with a great coach will almost always be more effective than a great player without one. However, a coach without a player is just a person with a clipboard. AI can suggest a play, but someone actually needs to execute on it.

The best players in the world of modern software engineering are those who know their roles, but can also step in to support other roles as-needed. Filling the lane is a must-have awareness and skill.

Systemically, the team needs a playbook in order to align on shared goals in a clear, unified manner. This is key for highly-specialized roles and expert generalists alike. A playbook can anchor multidisciplinary discussion and avoid, or at least cut through, confusion and uncommon language. Get team buy-in on the North Star, mission statement, and sprint goals.

Learn together; move as a unit. Defense-only and offense-only drills have their place, but it is most important that all the players can flow together.

Creative solutions to complex problems are necessary. This is even more true in the face of tight budgets, short timelines and ambitious scope. To be successful, individuals and teams must learn to flow together; this means improvising while staying aligned with the playbook. Rigidity and a lack of adaptability will break down in the face of chaos.

Leverage AI to strengthen the team. Effective use of AI can remove the “grunt work” from players’ responsibilities and elevate them to be more strategic. But the player must still play. The first step toward mastering the flow game is to schedule a team meeting to draft your project’s North Star or mission statement, and ask your engineers to identify one “lane” they will practice filling this sprint.

The game has changed. Our ability to flow is how we win.