What if there is no “Best and Brightest?”
I’ve seen it a few times in my career, a team that is stuck on a really hard problem — the kind that cuts across multiple layers of software architecture and deals with a fundamental problem between a legacy code base, the needs of an ever-changing marketplace, and continuously evolving technological demands on the existing technology stack. There is an elite set of well-paid engineers or other very talented people working on the problem. They will be considered some of the best at their company or organization, if not the very best at what they do. Somewhere along the line while debating, brainstorming, and diagraming, someone will say “if we can’t do this, no one can.”
They will probably move on to implementing a perfectly fine solution. But that statement, “if we can’t do this, no one can,” is a stupid and counter-productive failure of imagination. It shows a fundamental weakness on that team, and I believe that it comes about when a small group of people start imagining themselves to be the “best and brightest” within some organization or field.
Stay with me here, because I believe we’ve been sold on this myth our whole lives. I’m not interested in disabusing you of the idea that in any set of people there might be a smaller set that are the best at their jobs or the brightest people in the room. I want to disabuse you of the idea that “best and brightest” actually matters in terms of how a team thinks and operates. I also want to make the point that thinking in those terms will frequently put you at a strategic disadvantage to teams that don’t think that way.
The fundamental problem is this, our beliefs about the world can sometimes limit how we see it, and so can limit how we frame and understand a problem and its potential solutions.
I think western society sometimes thinks of intellect-based skills like it is a small foot race. In this analogy, solving the problem is the finish line and your engineers and designers are the runners. The smartest engineers or designers then are the ones who presumably will get to the finish line first and/or will be the most adept at solving the problem. That is what we hope for.
But… what if you are not in a small race at all? Let’s reimagine this analogy as a huge marathon with thousands of adept runners. Does nearly every one of those runners have the ability to cross the finish line? Yes.
Imagine for a moment that all or most of the engineers available can solve the problem in front of you, and you don’t need a perfect solution, you need a good solution that is also timely. What if the difference between the runner that completes the race in 4 hours and the one that completes it in 3 hours and 55 minutes is negligible?
In this simple analogy, trying to get the best of the best runners would be a misplaced focus. In fact, it may turn out that for the purposes of your “race” (i.e. engineering project), any runner skilled enough to complete the marathon in under five hours is more than good enough.
In the above runner analogy, speed = intellect, but there is obviously more to being a great engineer or designer than how quickly you can hypothetically complete a project. In fact, you may have little or no control over how quickly you can complete a project as an engineer.
Likewise, solving problems in the real world is rarely like running down a clearly marked predetermined path. I think our presumption is that the best minds will automatically find the best path. But I don’t believe that is what typically occurs. On the contrary, I think that “best and brightest” syndrome tends to undercut how teams think. It can predispose them to miss valuable insights and alternative perspectives. It can make you imagine that there is no point in asking for help or having others outside your team take a look at what you are working on because: what are they going to see that you can’t? And then there is that big sticky problem of what constitutes a “best mind” anyhow?
On software projects there are often many paths to the finish line and you aren’t trying to find the perfect path, but an optimal one — a path that balances the needs of several different stakeholders. For example, As the business I will want reusable code that is inexpensive to maintain, allows me to pivot to build something different if I need to, and offers a specific value to my customers. Of course, how quickly the product can be built always matters — so speed to market might be the number one thing after “does what it’s supposed to do.”
As the consumer of the software, I will want lots of features, an intuitive interface, i.e. a small learning curve to traverse before I get value from the product, regular new features and improvements, quick bug fixes, and for the product to actually do the thing I need.
And there are market needs as well. You can lose out on good talent if you are building with old technologies. Or it can turn out that you didn’t know that the latest greatest framework would cut your development time down by 75% (that is one of the ways that those nimble startups are maneuvering right past you even though they may not yet afford to pull from the “best and brightest” talent pool).
And that’s the thing, it is often speed that wins out, at least in the world where business meets software. I’m saying that your “best and brightest” team will frequently optimize primarily on development speed because that is what the business is going to push the hardest for and with good reason.
Keeping with the runner analogy, your fast runners will endeavor to find the path that is the quickest for them to take. Hence, you will get a project built in the technology stack that your engineers have already specialized in, built in the quickest way they know how, and if they imagine that very few others can understand the path they are on, they may fail to seek outside insight on whether or not they should take that path at all.
They may miss the innovative solutions. They may even miss obvious solutions. They may miss that if they used a newer framework they would have less problems to solve, and would find the code easier to maintain in the future. They may miss that they don’t need that enterprise stack, that huge database, or the front end framework that they used for the last three projects. More importantly, they may miss that they have untapped expertise and novel perspectives sitting only feet away from them in the same office.
And what that means is that the business is going to get this:
reusable code — probably not, easily changeable code: nope, quick to market: maybe on the first version, tech that attracts new talent: not likely, inexpensive to maintain: absolutely not.
And the consumer will get this: lots of features: yes, quick updates: at first but not as time goes by, does what we need: at first but less so as time goes by, an intuitive interface: not likely, quick response to end user requests and bug fixes: probably not and less so as the product ages.
Why? Because optimizing on development speed can be done by sticking with the technologies you know well and thus are quickest at working with or by keeping up with many new techniques and technologies that can make much of your work unnecessary. Being able to utilize the right technological tool for the job requires diversifying your figurative tool belt over time. If you are always pressed for speedy development then you will frequently fall back to using the tools you know best and thus can develop the quickest on.
You will eventually (immediately — in my experience) build things in a suboptimal way and not have time to go back and fix it. You also won’t likely have time to fully investigate the problem space, and thus resort to necessarily building a suboptimal thing that works as opposed to an optimal solution that takes time to find. Clean coding practices should help to mitigate some of these problems, but I hope the point is clear that being bright or even the brightest is not likely to lead your team to optimal engineering by default.
You should be fighting the impulse to solve problems in exactly the same way and with the same tools. At the bare minimum you need to know what those newer tools and technologies might offer your projects and you should be seeking out different ways of solving familiar problems. And that’s why you should be seeking diverse perspectives and ideas. Not because everything has to be built in a novel way — it doesn’t, but because you can’t see other and potentially better solutions if you are only approaching engineering problems in a narrow/familiar way.
The fundamental problem is that our beliefs about the world can sometimes limit how we see it, and so can limit how we frame and understand a problem, and its potential solutions.
So let me put a bow on this, if you imagine that no one can solve the problem except for your team because you are the “best and brightest” at what you do then you just might have created a mental box around your possible solutions. You could be finding the shortest path on foot while your competitors fly by on a helicopter. In other words, you might fail to notice that there are lots of great people around you who can offer something invaluable: a different way of looking at the problem (or they might just happen to know about that helicopter).
