The Strawman

Getting engineers to agree can be non-trivial. In fact, I would go as far as saying that it can be a complete yak shave. The issue is not the engineers, rather it is the fact that there are choices. You see, every problem we get a bunch of engineers together to tackle is a problem that has many possible solutions. Each solution comes with a set of trade-offs that the group of engineers will poke at, deliberate, side with or against. My defacto technique for overcoming this is the strawman. At least that's what I call it. Reading the explanation on Wikipedia it feels that I may be using the wrong word here. meh.

The basic premise is that I want to present the group of engineers with a possible solution that is far enough along that it solves the trivial aspects of the problem, but not perfect enough that others can't improve it.

Sounds a bit odd, why bother solving something if you're going to ask others to solve it again? Well, let's walk through what happens if I don't provide the engineers with any structure. The usual sequence will be something like this:

• Individually or in smaller groups they will find a solution
• They will then present this solution to the others
• Each will have some attachment to their own solution
• They will argue their points in circles usually bikeshedding
• Someone will cave and begrudgingly implement the agreed solution

There are a few pieces in this sequence that irritate me. Firstly, they all individually solve the same trivial problems, seems like a waste of effort on the simple stuff. Secondly, the solution that is picked is never the team's solution, it's almost always thought of as belonging to someone. You'll hear phrases like, "It's Sven's solution" or "When Ida designed this bit". Lastly, the bikeshedding, oh-my-god the bikeshedding. I really want the team to discuss the trade-offs of the complicated things, the things that really matter when it comes to building and running this solution. I don't really care whether we use tabs or spaces (I'm being facetious, you should always use spaces).

So how does presenting a strawman change any of this? A few things change. Firstly, instead of starting with a blank page, they start with some of the picture filled out. Hopefully, I've done a decent job of making decisions on trivial items and we reduce the amount of wasted time. The second part is that it's a solution from the manager, which the team should tear apart and rebuild their way. I want them to gang up on my design because I know that their collective brainpower far outstrips mine, and if they do it as a team then they will all own the solution.

Back to the strawman. The strawman that I want to present to the team is a half-baked idea. It's been thought through enough that it just might work. Working through the solution will actually help you form the questions that you need the team to answer. Don't get attached to this half-baked solution, we need the team to poke holes in it and own the solution they come up with that replaces yours.

Now the next part is super important. When you present this to the team you need to make sure that they understand you are thinking out loud. The thing I've learnt through painful mistakes is that a team will always take anything you say as being directive, and not just sparking a conversation. How you do this is different for every team. In some teams I've been upfront and said that I have a strawman to show them, in other teams I have explicitly told them that I'm thinking out loud and sketched on the whiteboard. Whatever you do it needs to be absolutely clear that your idea is half-baked at best, and you need their input to solve it. 

Once you have the conversation started, step back. Let them drive the conversation amongst themselves. When it looks like they're veering towards the bike shed it's time to ask a probing question. When it looks like they're mostly done, it's time to ask them what unknowns they need to learn. Very soon you should have a plan, a list of things to test or research and hopefully a team that collectively owns the solution they are about to build and run.

As mentioned at the start, it's a tool I use often, but not always. Understanding when and who to use this with is something that will come with experience. It's something I've learnt over time, watching others get a group of engineers aligned. It's something you should practice with your team. And, if you tell them exactly what you're doing they will help you get better at it.