Engine Building for Engineering Teams

I’m a big fan of board games. My collection no longer fits in the two bookshelves I have, it sprawls into the closet next to our game room. One of my favorite genres is engine building. This is the idea that you start with basic means of doing something—exploring ruins for instance—and build up your capabilities and efficiencies over time. Therefore an action at the beginning of the game doesn’t produce the same output as an action at the end, but without those initial actions, those latter actions wouldn’t have the same weight.

These games are incredibly satisfying as I see things get more efficient and effective, gaining more points or a better position as my engine starts to hum along. Problematically for board games, I love the feeling of efficiency to a fault: the first time I play a game I’ll be focused on building out the engine and miss the point when I need to start thinking more about winning. That might be points or getting far along a path, but I’ll miss it because instead of seeing the forest, I’m staring at these fantastic trees.

Building Your Team’s Engine

How does this relate to software engineering and teams? Building out that team is much like building that engine in a board game. Your goal is to produce value via software and your initial hand of cards or actions will not produce much. You have to figure out what actions you can take that will improve your efficiency both on an individual action level and a holistic level.

If you’re working with an existing team, adding process and structure will create tension. Team members with experience will have worked on teams before that added needless structure, hoops to jump through to, and other processes that add no value. When introducing these new processes you’ll show how it produces value, potentially as experiments. However, if you run them as experiments you must treat them as experiments and be willing to see them fail and hear feedback from your team.

Teams are unlike board games in one important—and obvious—way: in a team, you’re working with other people and their opinions matter. You shouldn’t approach the building of a team with the mindset of a game player optimizing their own strategy, but that of a coach introducing an improvement and hearing out concerns and feedback. You might be the manager, but you’re working with people. Hear them out, change the process to fit your team, and evolve what you know to work best them.

Over time your team’s engine will start to get more efficient. What was once a deliberate process of following a list becomes normal and easy. The best part is that the inflection point is obvious: once you have enough process that things are getting moving along and getting merged, that’s when your engine is working. It’s worth watching the processes and checking in from time to time, but let them grow and shift due to how your team works with them. Let them evolve on their own and invite feedback on a regular basis.

What steps can you take to build that engine? Stay tuned to subsequent posts. I’m planning on covering written documentation and RFCs next.