When you make speed and “moving fast” the biggest priority on a project or in an organization, the first thing to breakdown is talking to each other. Talking takes time. Consensus is expensive and slow. In a pressurized environment there’s no time to schedule calls, get input from subject matter experts, or resolve key differences of opinion. ASAP makes a big assumption that all relevant parties are already in the room.

Not everything needs to be a conversation. I’m a firm believer in “get the user something to see if there’s interest”. I’d agree that over-thinking a problem and under-thinking a problem both have pitfalls. But dozens of ways exist to get feedback from users on in-progress work without overcommitting to a particular design. By prioritizing speed over talking, cross-org collaboration suffers and a faulty design can steamroll ahead. I am no soothsayer, but I can tell you that you set your organization up for a messy merge conflict in the future between teams who have been traveling in different directions.

I think the second organizational casualty is “the system”. When speed is the priority, there’s no incentive to improve or invest in the shared system (e.g. a design system or codebase) under a tight deadline. If everyone needs to move fast, even something simple like renaming a folder could have dramatic setbacks. Hypermovers will create a new project folder or detach a Figma component. And that new folder of files grows to create it’s own duplicative system of components that are ever-so-slightly different such that they are incompatible with the rest of the system. Resolving system gaps requires conversations, it’s easier to eject from the system at the slightest inconvenience, duplicate, and go your own way. Effectively hiding the time bomb of technical debt for the next unfortunate sucker.

I think AI exacerbates this problem. I think AI can help you build faster (although data suggest otherwise), but I also believe that LLMs are the ultimate tool in the “Don’t talk to my coworkers” toolchain. Why talk to an expert who might tell me no, when the omniscient machine that always tells me yes is right here? Avoiding that friction doesn’t produce better products faster. It makes future conversations more difficult thanks to higher sunk costs and deeper entrenched opinions.

Other pieces of infrastructure begin to chip away when moving fast too: documentation, security, performance, reliability, the fabric of modern American democracy, and developer satisfaction to name a handful. I’m pro-reducing bullshit, I’m pro-reducing toil. But I’m also pro-slowing the fuck down and doing actual human thinking before pulling a trigger… or sending a laser-guided Tomahawk missile… or whatever action-based analogy works best for your organization.

We all love dopamine, we all love seeing new ideas come to life, but more lines of code and duplicate systems –our own little kingdoms in code– doesn’t produce horizontal strength. The job of Engineering Management is no longer pushing tickets across the board to make executives clap, it’s helping organizations row in the same direction together. It’s relentlessly focusing on your users over lines of code and cool project codenames.