Think about the last time your team shipped something impressive. It was probably on time, clean code, and had great metrics. And yet somewhere along the way, the business priorities had shifted, and what the team delivered was no longer the top priority. The work was solid, but the direction just wasn't quite right anymore.
This is usually what happens when engineers are disconnected from business context. They're not lacking motivation or talent, but sometimes they just don't have the information they need to build things that people actually want.
Steve Evans, the former SVP of Engineering at Chegg, dug into this during an in-depth conversation with our co-founder Ganesh Datta on the Braintrust podcast. Steve argued that when engineers don't have clear business context, they just default back to measuring their success by how many lines of code they've written, the tickets they've closed, or the features they've shipped. While it would be easy to assume they do this because they don't care, Steve also reminded us that sometimes those are the only outputs they can see or measure.
Engineering is much more than an IT summer camp
There has been a lot of really good writing about how engineers should be given great tools to work with and be allowed to build whatever they want. While there's some validity to this, Steve argues that teams that operate exclusively like this often treat the work as if they're at summer camp, where their goal is to have as much fun with technology as humanly possible.
"We've been measuring for a very long time how fast engineers run on a treadmill, not how far they're going." Steve Evans — Former SVP of Engineering, Chegg
Steve says it's critical to reframe priorities for your developers. When an engineer understands that the real goal is landing a Fortune 10 client and not just shipping a billing service rewrite, their priorities shift on their own. Reliability and scale stop competing with the interesting new framework and the smart developers you hired just find a way to win.
Why all-hands meetings don't actually move context
Most leaders default to the all-hands as their primary mechanism for sharing company direction. The CEO gets on stage, announces the big initiative, and assumes the message has landed. But for many executives, that message rarely lands the way they think it does.
For an engineer locked in on their sprint, a high-level strategic announcement often feels completely disconnected from their daily reality. In large meetings, the people who speak up aren't always the ones you need to hear from. Quiet contributors with valuable signal stay quiet.
"When you hire a junior engineer straight out of college, they think their job is to write code. When the CEO gets up in an all-hands and talks about closing a big deal, it's usually in one ear and out the other. It's not important to them and it doesn't help them deliver their sprint." Steve Evans — Former SVP of Engineering, Chegg
Steve responded to this by scheduling small roundtables of ten to twenty people, all of whom were mixed across functions. Unlike a traditional all-hands meeting, Steve presented nothing. Instead, he asked people to tell him what they were seeing, which gave Steve a much more coherent view of what his teams were up against.
The director's role in the problem
The breakdown in communication usually doesn't happen at the executive level. CEOs and CTOs tend to be aligned, and like it or not, the gap typically forms at the director layer.
Directors often struggle with the transition from managing people to managing business context. That means taking high-level strategy and translating it into something that actually changes how their teams make decisions. If the company is moving upmarket toward enterprise customers, a director needs to make clear that this shifts engineering priorities—probably away from feature velocity and toward compliance and stability.
Steve says that hiring the right people is the first step to mitigating against this. Arming those people with the context they need to make good decisions is the second, equally important step. When a leader skips step two, they leave their teams guessing. Good engineers will fill that vacuum with their best assumptions, which often aren't the right ones.
Providing good, relevant context is a leadership practice
Engineering productivity can't be measured in a vacuum. A startup still hunting for product-market fit needs engineers who move fast and break assumptions. A public company protecting millions of users needs engineers who slow down and think about failure modes. Neither is wrong. But without shared business context, engineers have no way to know which mode they're supposed to be in, and that's a big part of what slows progress toward engineering OKRs in the first place.
The best engineers want to know why they're building something. That's not a soft observation, it's one of the most direct levers a leader has on developer productivity. Tracking the right engineering KPIs and measuring both inputs and outputs are part of it, but the foundation is context. Give people the full picture of what the business actually needs, and most of them will figure out the rest. That's what separates a CTO who drives engineering excellence from one who's just keeping the lights on.
Want to hear more from Steve and Ganesh on engineering leadership? Listen to their full conversation on the Braintrust podcast here.
