Every developer has been confronted with the request, ‘Take your best guess,’ in working their way through a problem. Now, this puts an engineer in a very hard position. Many teams are conflicted when it comes to taking chances: you can take any chance you want, as long as you only pick the right solution. That makes it very hard to put a developer in that position, since it’s not really a guess if the only allowed outcome is 100% success.
As a leader of developers, we have certain responsibilities here. The tendency to be right, which is where a developer tends to answer questions that are new to them correctly, is what I consider a core component of a developer’s Alpha (I’ll address that in detail in a later post). I use Alpha here as an equivalent to Alpha in finance, as sort of a measure of how good a developer is. In this case, guessing right is a component of Alpha – a ‘correctness factor’ that is really hard to find, and even harder to grow. A leader has to learn how to inculcate this in their team members in order to scale their team well.
Our search for high-alpha engineers is a little like the recruiting practices of the Jedi. You try to find developers with a bit of potential, train them over the years, and hope that their innate skill, coupled with the quality of their mentoring, leads to a good Jedi. The alternative, of course, is an engineering equivalent of Darth Vader, what with the slaughter of innocents and all.
So what can we do about this, and why is Patton in the post title?
De l’audace, encore de l’audace, et toujours de l’audace
George Patton had a favorite quote, that he used to motivate himself to relatively positive ends, that was originally said by French Revolutionary George-Jacques Danton, who used it during the french revolution to relatively bad ends (spoiler alert, everyone dies – his other notable sentiment was for terror to be ‘the order of the day’).
This quote was, in English, ‘Audacity, More Audacity, and always Audacity’.
Notwithstanding the fact that quotes from the French Revolution rarely are positive, if you’ve seen the movie Patton, you can see how the urge to move forward dominated his personality. He was a risk taker, and through his skill and training, his risks often were worth it. They had the downside, however, of alienating colleagues and some people he worked with.
Back to Engineering
So, where does that leave our humble software developer, who is neither invading nor governing by guillotine? And where does Audacity fit in? Well, given an unknown problem they are tasked with solving, a developer has 4 choices:
The choices are:
No Guess: A developer can look at their manager and say: tell me what to do. Will this contribute to their personal correctness score? Probably not, though there are definitely cases where it is the right choice.
Safe Guess: An engineer can take what they know and have read in the spec, and build it exactly. It might be right, it might be wrong, it might be close. This is sort of a decision not to decide. There are environments where this is the right choice, with excellent BAs and designers who have covered all the bases. Most of my experience, however, is that there are always loose ends that a developer has to fill in.
Audacious Guess: Here, a developer takes their knowledge and augments the spec in such a way as to increase the likelihood of the work being correct the first time. They are filling in the blanks with their knowledge of the project, their experience, and with good intuition. That is what a good manager ought to foster. Every time a developer adds to a spec in this way, the project improves, costs go down, and customers are happier.
Reckless Guess: A reckless guess is an audacious guess gone wrong. Here, an engineer misses the mark and tries to solve a problem in an inappropriate way. Often, this is actually solving a different problem, and it makes the project worse, or delayed.
Only the latter two contribute to Alpha, I think. A safe guess or following spec is completely acceptable and correct in many cases. We are trying to foster limited risk-taking, not daredevilry. Only the latter is daredevilry – the Audacious Guess is not. It’s when you are using your experience and intuition to attempt to guarantee a better outcome.
Stay away from the guillotine…
So what does a team leader do? In my experience, you need to give engineers a few things:
You need to identify when an engineer is ready for projects that allow them to contribute in this way, and then hopefully tailor this opportunity to the developer. You need to give them the ability to pick their course, and monitor for when a guess is moving into recklessness. Ultimately, we are recognized for having a consistent alpha, and leaders have to do what they can to encourage and build their team members’ skill.
Recall also that we want a version of alpha that is wholly based on teamwork. Patton’s Audacity led to conflict with his peers, which in our world would be reckless. Danton’s wasn’t particularly helpful he really wasn’t particularly consistent in his alpha, at least as far as the means (terror) that he chose.
Consistency is a topic for later…