Nothing torpedoes a startup faster than a room full of geniuses sprinting in random directions. It really could be problematic for startups to have too many 10x (or highly skilled) engineers. That’s because having a power tool can really speed up your work, but can also be extremely dangerous in the hands of someone who doesn’t know how to wield it. I know this is a first-world problem, but I’m lucky to have worked with a lot of very good teams where the eng talent wasn’t the issue, per se. Are your coding ninjas helping you get nowhere fast?

Special Offer: Unplugged with Aviv, where you get at least a monthly live session with me and others where I perform a deep dive on a topic and answer your questions, is still at ridiculously low introductory pricing. Check it out.

“I can do that in a day”

Let’s go back to ancient history, where people had to actually draw things if they wanted an illustration. That required people’s time, making illustrations something that companies paid for only when it made enough sense. Contrast that with AI forcing us to scroll vertical miles of Ghibli-themed drawings. When the cost of doing something is lowered, it can allow us to move much faster, but it can also just be used to produce a pile of waste at a breakneck pace.

A common case with teams comprising very senior engineers is that their estimates for different ideas reduce due diligence and planning too much. When I am approached by startups that barely make progress in development, it’s clear to everyone that there’s an issue. However, when the team can deliver things relatively fast, everyone might feel like progress is being made, while the company is actually treading water.

If you say something would require two or three months, you can be pretty sure the Product team will assess it very carefully in any startup before committing to it. When the team is capable of doing the same thing in a matter of a couple of weeks or even days, it removes a lot of natural hesitance. That might be great—if the work is the right work.

Faster… Straight Into a Wall

You might be wondering what the big deal is. So the team will perform a detour that takes a few days, and realize it was the wrong move. Doesn’t that happen in essentially every startup at one point or another? Certainly. However, when each such detour comes at a relatively low cost, we often don’t realize the compounding effect of these road miscalculations.

I’ve seen teams that had virtually no real roadmap because they kept rushing from one idea to the next. And don’t get me started on the much deteriorated signal-to-noise ratio many sprints have with the advent of AI. Yes, it might allow you to speed through ideas faster, but even more at the cost of thinking about what you’re doing. Research is already showing vastly inferior cognitive skills for people who write mainly with AI, and the same can happen when we couple speedy engineers with AI.

Add Friction Where Needed

Teams that provide lower estimates and that move fast have a lower static friction coefficient (never thought those high school physics lessons would come in handy). It’s easier to start pushing something, yet you end up pushing a lot of things, thus spending more effort in total.

Instead, you, the leaders in your org, and the senior engineers should all make it a habit to help assess a project’s value. Rather than immediately spit out an estimate and rush to the keyboard, do your due diligence. Think of the scoping and descoping that can be done. Talk about the opportunity costs wasted by going in this specific route. Ask for context and understand it, to see if there are better ways to verify a hypothesis than implementing the whole thing.

Just because you can code it fast doesn’t mean you always should.