Impact

A professional koan: of the projects I can work on, which has the most impact for the business?

Thinking about this highlights the importance of a prioritized backlog. If impact is a component of the prioritization, then the project with the highest impact is clear.

A senior manager recently commented on some faulty advice they’d heard about service development being more important than client development. They clarified that impact determines importance. We should be working on projects with impact.

“The Secret to Growing Your Engineering Career If You Don’t Want to Manage” makes several good points.

Many engineers become managers because management provides an obvious and well-defined leverage point to scale your impact.

It’s relatively easy to produce more if I can delegate work out to a team.

The less conventional paths outside of management require more creativity, and there are fewer available narratives of successful engineers outside of management for us to model ourselves after.

I can attest to this, and explore it further in “Technical-organizational balance”, but I find it surprising given the idea of parallel tech and management tracks is ostensibly common practice.

Your ability to decide where to spend your efforts to maximize your impact — what code to write, what software to build, and which business problems to tackle … You identify and solve problems that are core to the business, or you enable those around you to more effectively solve those core business problems.

Hopefully our ability to identify projects with high impact improves over time.

“How to Grow as an Engineer (Working Remotely)” also touches on impact.

It’s also not enough to just solve any problems. You need to be solving the right ones. You should constantly make sure there’s alignment between what you want and what the business needs…