Thom Clanzy’s Software Engineering Conductor

The Need for a Conductor in Large Projects

I've long had this unrefined idea that large projects need a "conductor" role – someone to connect the dots. Picture this: someone announces in one Slack channel that their shiny new feature is now live. A week later, another person mentions in a meeting that they are working on creating that very same feature, unaware it already exists. Who bridges the gap between the two?

Or in another example: In a team lead meeting, a decision is made. Perhaps it's documented somewhere, and all leads are expected to disseminate this information to their teams, ensuring that the decision is implemented. Yet, weeks later, it becomes evident that several teams never received the memo. Who identifies this oversight and ensures that everyone is on the same page?

Dissecting Communication Challenges

These two scenarios are mere illustrations of a broader problem. In reality, such communication hiccups occur multiple times daily in varying forms, especially on sizable projects involving dozens of individuals. One might argue against these examples, questioning where the fault lies: with the original team, the second team, the leads, or even the structure of the meetings themselves. While my examples might seem imperfect, they serve their purpose. They highlight that a single communication error can stem from various sources or be addressed in numerous ways. Furthermore, these are just instances – the types of communication challenges that arise in a large project are vast and varied.

The Concept of the Conductor Role

So let's talk about this idea of a conductor role and why I believe it could have real value. In my mind, I've been playing the role of an unofficial conductor on my projects. I'm one of those people who reads every Slack message, takes notes in meetings, and connects the dots whenever I see an opportunity. This might be as simple as cross-posting one Slack message into another channel or thread. It might be calling out a disconnect in stand-up or some other meeting and suggesting that someone reach out to a certain team to resolve it. The role is not clearly defined in my mind yet. However, if you've worked with me on a project, you've likely observed me doing these things. I'm writing this not because I've sat down and fully fleshed out a formal definition of this role—indeed, it remains as nebulous as ever. Perhaps someday I'll do that. But today, I want to connect two dots.

Drawing Parallels with the Gaming Industry

The first dot is this concept of the conductor role, and the second is, of all things, an article in Issue 359 of the Game Informer magazine. Yep, that's right, the magazine you get at Game Stop. The article is titled as follows (if you read it vertically lol):

RETROSPECTIVE

STEALTH

THE HISTORY OF

ACTION

SPLINTER CELL

REDEFINED

How an unlikely crew of inexperienced game developers created one of gaming’s stealth icons BY NOLAN GOOD

It’s a great read for the story of how various elements converged to create a perfect storm for creativity and success. Specifically though, the dot I'm trying to connect is from a part of the article where it discusses how a game designer named Nathan Wolff organized the work of many as it related to game mechanics. Essentially, Wolff created what is known as a Design Bible. He wrote docs on every one of those gadgets, items, and interactions detailing their significance within the game and potential use cases. Then each element in these docs was made available to all teams in a central place, physical boards in a “War Room”. Teams then mapped out these elements as they applied to the game, ensuring a balanced distribution of these ideas throughout the game's narrative.

Connecting the Dots

Maybe the connection between what Nathan Wolf did on the first Splinter Cell game project and what I believe a conductor would do on a modern software project is not completely clear. Yet, think about how Nathan must have gone about collecting the data, probing teams for details, and discovering connections between one team's choices and another team’s choices. By being the go-between, with a specific purpose of connecting dots, Nathan Wolff was playing the conductor role. I'd contend that without such a role, Tom Clancy’s Splinter Cell may never have shipped or at least not in the award-winning state that it did.

Let me know what you think about the concept of a Conductor and how you might refine this idea further.