Introduction
Discourse on how to organize work has taken a lot of space: whether discussing methodologies (e.g., OKRs, Agile, Scrum), roles and responsibilities (e.g., Product Management), or organizational models (e.g., "Spotify").
While important, these topics tend to confuse startup founders and engineering leaders in more established companies alike, who struggle to figure out what is "right" for them. Countless time have I heard these questions: should we adopt OKRs? Should we move to a micro-services architecture? How should we set and communicate priorities?
On being deliberate
Discussions on the how can sometimes overshadow the one thing they should be in support of: the purpose of work. Putting aside sprints, objectives, tickets, and roadmaps for a minute:
- We do things for a reason.
- That reason is to have observable impact on some behaviors.
- These behaviors should align with our definition of success.
Methodologies, organizational models, architecture choices are in service of the purpose. OKRs are a popular way to align teams behind a priority with well-defined success criteria at a fixed cadence. The North Star Framework is a popular way to capture the longer term strategy and provide a stable frame for goal settings. Micro-services architecture are a popular way to decouple the deployment of independent parts of the codebase. None of them can help if you are not sure which problem you're solving in the first place.
Back to basics
The most important thing you can do to succeed as an engineering organization is to define what success means for your particular context and frame activities with their purpose. Which goal setting framework, day-to-day execution methodology, and architecture you chose is ever going to be in support of that.
Top comments (0)