Are You Working on the Right Thing?
There are two kinds of engineers in every company I've worked with.
The first kind wants to do things the right way. Clean architecture. Proper test coverage. Elegant abstractions. Well-documented code that future engineers will thank them for. These are good engineers. You need them. They are the reason your product works at 3am when nobody is watching.
The second kind wants to work on the right thing. They don't care (as much) about whether the architecture is pristine. They care about whether the thing they're building is going to matter. Will a customer pay for this? Will this unblock a deal? Is this the highest-leverage use of the next two weeks? They're the ones in sprint planning asking "why are we building this?" while everyone else is debating how.
Most engineering teams are stacked with the first kind. Very few have enough of the second. And almost no team has a leader who can hold both in productive tension.
Why "the right way" wins by default
It's a hiring artifact. Technical interviews test for "the right way." Can you reverse a binary tree? Can you design a system that scales to a million concurrent users? Can you explain the tradeoffs between SQL and NoSQL? These are "right way" questions. They select for engineers who optimize for technical correctness.
Nobody in the interview asks: "Given these three features on the roadmap, which one would you build first and why?" Nobody asks: "The sales team says this integration is blocking a $50K deal. How would you evaluate whether that's actually true and worth prioritizing?"
So you build a team of people who are excellent at building things correctly and have never been asked to think about whether they're building the correct things. Then you wonder why shipping faster doesn't move the revenue needle.
The tension is the point
I'm not arguing that "the right way" doesn't matter. If you build the right thing badly, it breaks in production and your CS team spends their week apologizing. Quality matters. Architecture matters. Test coverage matters.
But quality in service of the wrong priority is expensive vanity. A perfectly architected feature that nobody uses is not a win. It's a cost center with nice documentation.
The most effective teams I've led or worked with have both kinds of engineers and a leader who can translate between them. The "right thing" people identify the highest-leverage work. The "right way" people make sure it's built to last. The leader's job is to keep the "right thing" from becoming sloppy and the "right way" from becoming precious.
That translation work is harder than it sounds. The "right thing" engineer says "just ship it, we can refactor later." The "right way" engineer says "if we don't do it properly now, we'll pay for it in six months." They're both right. The leader's job is to figure out which one is more right this week, for this problem, at this stage of the company.
The question to ask Monday morning
Open your current sprint or quarterly plan. For each item, ask two questions:
"If we build this perfectly, does it matter?" If the answer is no, you're optimizing the wrong thing. Move it down or kill it.
"If we build this roughly but ship it this week, does it change the business?" If the answer is yes, that's your priority. Get the "right way" people involved to make sure "roughly" doesn't mean "recklessly." But ship it.
Most teams never ask the first question. They assume everything on the roadmap matters and focus exclusively on execution quality. That's how you end up with a beautiful, well-tested product that doesn't move revenue.
The right thing, built well enough, shipped in time. That's the whole game.
Rakesh Kamath is a scaling systems operator who helps SaaS companies install the engineering, operational, and financial infrastructure that makes growth durable.
Rakesh Kamath is a scaling systems operator who helps SaaS companies install the engineering, operational, and financial infrastructure that makes growth durable.
More about working together