5 min read ·
Corporate ADHD
There's a particular kind of dysfunction that only shows up in tech companies that move fast enough to confuse motion with progress. I think of it as corporate ADHD: the inability to stay with a problem long enough to solve it before chasing the next shiny abstraction.
You'll see it the moment a team of engineers finally gets traction. They've spent weeks understanding the contours of a real problem. They've wrestled with edge cases, discarded naïve approaches, and started to build something grounded in reality. It's messy, but it's honest work.
Then management walks in.
Not with questions, but with answers. Not with context, but with vocabulary.
"Why aren't we using AI for this?"
"Shouldn't this be event-driven?"
"What if we made this a platform instead?"
You can almost trace the origin of each sentence to a tweet, a conference talk, or a half-digested blog post. It sounds informed if you don't look too closely. But if you do, you'll notice something missing: experience with the actual problem at hand.
And that's where the derailment begins.
The project stops being about solving this problem for these users and starts becoming a vehicle for demonstrating that the company is "thinking ahead." Suddenly the scope balloons. The constraints dissolve. The original goal gets buried under layers of ambition that have nothing to do with the task.
What was once a clear line becomes a foggy cloud of "possibilities."
This is how you turn a working solution into a never-ending initiative.
There's a quiet arrogance in believing that you can shortcut understanding with abstraction. That you can sprinkle the right buzzwords on a problem and elevate it into something more important than it really is.
AI is the latest accelerant.
Now every system must be "AI-powered," every workflow must be "AI-first," and every engineer is expected to become a kind of operator — someone who prompts tools instead of thinking through systems.
It's not just wrong. It's wasteful.
AI is a tool. A powerful one, yes. But still a tool. It doesn't replace the need to understand your domain, your constraints, or your users. It doesn't absolve you from making trade-offs. And it certainly doesn't turn vague thinking into good architecture.
I use coding agents every day, and I like them. They type faster than any of us. They will not tell you who a feature is for, because that answer lives in a customer's head and a support queue, and neither of those is in the repository.
Yet you'll hear the same refrain: "Can't we just have AI handle it?"
Handle what, exactly?
The undefined edge cases? The conflicting requirements? The trade-offs you haven't even acknowledged yet?
AI can amplify clarity. It cannot create it out of confusion.
What's really happening here is a breakdown of respect for the craft.
Engineering isn't just typing code. It's the process of turning ambiguity into something concrete. It requires patience, continuity, and a willingness to sit with the problem long enough to understand it.
When management barges in with half-baked directives, they're not accelerating that process. They're resetting it.
Every pivot carries a cost. Not just in time, but in understanding. You lose the mental model the team was building. You discard the lessons learned. You trade depth for novelty.
And you do it over and over again until nothing meaningful ships.
A reset is cheap for whoever calls it. The person who asks "Shouldn't this be event-driven?" spends one sentence on it. The team spends weeks answering it, and by the time the answer arrives, the next question is already on the calendar. Corporate ADHD survives because the people who pay for each pivot never get a vote on it.
Startups are especially vulnerable to this.
There's always pressure to look like you're on the cutting edge. To signal that you're not just building something useful, but something important. Something investors can map to the latest trend.
So instead of finishing the product, you reinvent it.
Instead of simplifying, you expand.
Instead of trusting your engineers, you override them, and then you ask them why it's late.
And the irony is that the companies that actually win rarely behave this way. They're the ones that stay focused. That resist the urge to chase every new idea. That understand productivity isn't about doing more things — it's about finishing the right things.
If you want to increase productivity, start by removing the noise.
Let engineers finish what they start.
Force ideas to prove their relevance before they hijack a roadmap.
Use AI where it helps, not where it headlines.
And most importantly: respect the difference between talking about a problem and actually solving it.
Because the real bottleneck in most tech companies isn't a lack of tools.
It's a lack of discipline to stick with the work long enough to matter.