"A framework for making decisions"

A lot of my time, energy and worry with regards to Free Range over the past year or so has been about trying to establish a direction, a goal, a sense of momentum. A shared and explicit purpose, of what we are trying to achieve and how we think about achieving it.

As we entered the new year, this stuff was very much at the front of my mind, and a serendipity would have it I came across this article by Steven Sinofsky (let’s not hold his Microsoft background against him, at least for now), with some words that felt particularly relevant.

Some quotes:

If you think about a team as a set of folks each coming to work to make difficult choices each and every day (and night!) then the critical element for the team is a shared and detailed sense of the overall plan for a product. Historically software planning has not matured to the degree of planning for most other engineering endeavors (construction, transportation). For the most part this is viewed as a positive—it is the “soft” part of software that makes it fun, agile, and in tune with the moment

But if each perspective on a team is maximizing their creativity and agility, it doesn’t take long for chaos to take over. And worse, if things get chaotic and don’t come together well then fingers start pointing.

It is often amazing how quickly the most well-intentioned folks working together can start to have that so-called natural tension turn into a genuine dysfunction.

For a project of any size that goes beyond a handful of people or involves any complexity, detailing the how and why of a product, not just the what, is a critical first step. The reality is that every member of the team benefits from the context and motivation for the project.

The point of a plan is to build a bridge made up of the how and why, not the what.

A plan for what is being built can sound so heavy or burdensome. It can be. It doesn’t have to be. Another word for a plan is a “framework for making decisions”.

It’s this last sentence that really resonates with me.

I don’t want a plan for Free Range so that we can decide rigidly upfront exactly what we’re going to do, followed by dogmatic excecution.

I want a plan so that we have a framework for making decisions; so that we have a way of evaluating our choices that is based on some commonly agreed goals and principles. Without this, I can only see chaos taking the reigns. And not the good kind either.

interblah.net - "A framework for making decisions"

"A framework for making decisions"

A lot of my time, energy and worry with regards to Free Range over the past year or so has been about trying to establish a direction, a goal, a sense of momentum. A shared and explicit purpose, of what we are trying to achieve and how we think about achieving it.

As we entered the new year, this stuff was very much at the front of my mind, and a serendipity would have it I came across this article by Steven Sinofsky (let’s not hold his Microsoft background against him, at least for now), with some words that felt particularly relevant.

Some quotes:

If you think about a team as a set of folks each coming to work to make difficult choices each and every day (and night!) then the critical element for the team is a shared and detailed sense of the overall plan for a product. Historically software planning has not matured to the degree of planning for most other engineering endeavors (construction, transportation). For the most part this is viewed as a positive—it is the “soft” part of software that makes it fun, agile, and in tune with the moment

But if each perspective on a team is maximizing their creativity and agility, it doesn’t take long for chaos to take over. And worse, if things get chaotic and don’t come together well then fingers start pointing.

It is often amazing how quickly the most well-intentioned folks working together can start to have that so-called natural tension turn into a genuine dysfunction.

For a project of any size that goes beyond a handful of people or involves any complexity, detailing the how and why of a product, not just the what, is a critical first step. The reality is that every member of the team benefits from the context and motivation for the project.

The point of a plan is to build a bridge made up of the how and why, not the what.

A plan for what is being built can sound so heavy or burdensome. It can be. It doesn’t have to be. Another word for a plan is a “framework for making decisions”.

It’s this last sentence that really resonates with me.

I don’t want a plan for Free Range so that we can decide rigidly upfront exactly what we’re going to do, followed by dogmatic excecution.

I want a plan so that we have a framework for making decisions; so that we have a way of evaluating our choices that is based on some commonly agreed goals and principles. Without this, I can only see chaos taking the reigns. And not the good kind either.