Fluent in both the codebase and the org chart
Why the most useful people sit on the seam between building and leading.
Most careers push you to pick a lane: go deep technical, or move into management. The two get treated as a fork in the road. I've spent mine refusing to choose, and it's been the most useful decision I made.
The reason is that real problems don't respect the org chart. A slow support queue isn't a “support problem” or an “engineering problem” — it's a routing rule, a missing tool, a workflow nobody owns, and a team measured on the wrong thing, all at once. Fix one layer and the bottleneck just slides to the next.
Someone who can read the codebase and the org chart at the same time sees the whole shape. They can tell when the fix is a script and when it's a conversation — and they don't reach for a reorg when the answer is a database, or for a database when the answer is that two people need to agree on who owns intake.
It costs something. You're never the deepest engineer in the room or the most polished manager. But you're often the only person who can translate between them, and that translation is where a lot of value quietly leaks out of organizations.
My rule of thumb: stay technical enough to build the thing yourself, and stay close enough to the team to know whether building it is even the right move. The seam between those two is where I do my best work.