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 codebase, the needs of an ever-changing marketplace, and continuously evolving technological demands on the existing 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 diagramming, 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 is a stupid and counterproductive failure of imagination. It shows a fundamental weakness on that team, and I believe 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 who 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. Thinking in those terms will frequently put you at a strategic disadvantage to teams that don’t.
The fundamental problem is this: our beliefs about the world can limit how we see it, and so limit how we frame and understand a problem and its potential solutions.
I think Western society sometimes thinks of intellect-based skills like a small foot race. Solving the problem is the finish line and your engineers and designers are the runners. The smartest engineers or designers are presumably the ones who will get to the finish line first or will be the most adept at solving the problem.
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 that 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 who completes the race in four hours and the one who completes it in three hours and fifty-five minutes is negligible?
In this analogy, trying to get the best of the best runners would be a misplaced focus. For the purposes of your engineering project, any runner skilled enough to complete the marathon in under five hours may be more than good enough.
In the runner analogy, speed equals 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 it.
Likewise, solving problems in the real world is rarely like running down a clearly marked, predetermined path. Our presumption is that the best minds will automatically find the best path. I don’t believe that is what typically occurs.
On the contrary, “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 there is no point in asking for help or having others outside your team look at what you are working on, because what are they going to see that you can’t? And then there is the big sticky problem of what constitutes a “best mind” anyhow.
On software projects there are often many paths to the finish line. You aren’t trying to find the perfect path, but an optimal one—a path that balances the needs of several different stakeholders.
The business wants reusable code that is inexpensive to maintain, permits a pivot when necessary, and offers specific value to customers. How quickly the product can be built always matters, so speed to market may be the first concern after “does what it is supposed to do.”
The consumer wants lots of features, an intuitive interface, regular improvements, quick bug fixes, and for the product to actually do the thing they need.
And there are market needs as well. You can lose good talent if you are building with old technologies. Or it can turn out that a newer framework would cut development time dramatically. That is one way nimble startups maneuver past larger organizations 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 where business meets software. Your “best and brightest” team will frequently optimize primarily for development speed because that is what the business pushes hardest for—and with good reason.
Keeping with the runner analogy, your fast runners will endeavor to find the path that is quickest for them. You will get a project built in the technology stack your engineers have already specialized in, built in the quickest way they know how. If they imagine that very few others can understand the path they are on, they may fail to seek outside insight on whether they should take that path at all.
They may miss innovative solutions. They may even miss obvious solutions. They may miss that a newer framework would leave them with fewer problems to solve or code that is easier to maintain. They may miss that they don’t need that enterprise stack, that huge database, or the frontend framework they used for the last three projects.
More importantly, they may miss untapped expertise and novel perspectives sitting only feet away in the same office.
Optimizing for development speed can be done by sticking with the technologies you know well and are quickest at, or by keeping up with techniques that make much of the work unnecessary. Using the right tool for the job requires diversifying your figurative tool belt over time. If you are always pressed for speedy development, you will frequently fall back to the tools you know best.
You will eventually—immediately, in my experience—build things in a suboptimal way and not have time to go back and fix them. You won’t likely have time to investigate the problem space fully, and thus resort to building a suboptimal thing that works rather than finding an optimal solution.
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 minimum, you need to know what newer tools and technologies might offer your projects, and you should seek different ways of solving familiar problems.
That’s why you should seek 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.
So let me put a bow on this: if you imagine that no one can solve the problem except your team because you are the “best and brightest” at what you do, 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 in 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.