Deliberate software development

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.