What “The 12 Week Year” reinforces
Hi. It’s been a hot minute - even if the weather here in Central Indiana has been quite cool.
The end of the school year and the start of summer has been a busy time - shuttling kids here and there and starting to settle into the summer routines - which has meant I’ve had less hands-on-keyboard time and more head-in-the-clouds time.
In that state, I picked up a handful of recommended business or productivity books, and today I want to talk about one of them a) because it resonated with me in a surprising way and b) it has some lessons that can be applied to how software engineering and product organizations can work a bit better while closely adhering to existing patterns.
The book is “The 12 Week Year” by Brian P. Moran and Michael Lennington, published more than a decade ago.
For a performance-focused business book, it’s also surprisingly touchy-feely and practical. I’ve read more of these sorts of books than I care to admit, but this is one of the few which felt like it understood human frailties and foibles a bit, and suggested routes around it in a surprisingly gentle way for the genre. Don’t get me wrong, there’s still some bullshit and still some lift-yourself-up-by-your-bootstraps mentality, but less of it than most of the genre.
Beneath all of its performance trappings and whatnot is a remarkably straightforward idea: When we plan things on annual basis, we tend to think we have lots of time to catch up and we also tend not to be able to maintain max effort over that period of time, so instead plan for shorter cycles, in this case twelve weeks.
It’s strikingly familiar to the sort of periodization we’re already familiar with in product development cycles, with our sprints, and dev cycles and quarterly planning.
The things I found interesting under the hood are that they advocate for standalone 12-week periods. Essentially, we often think of sprints and development cycles as components of some larger objective. What the book advocates for instead is “What if that 12 weeks is all you have?”
It closely mirrors the sort of approach I took in a past role - just that our “years” were eight weeks rather than 12.
We asked the business what they wanted to release to market in two months, then as a product organization we set out to make that true.
I was talking about this development cycling recently with a local director of engineering, and they asked how that helped things - especially with estimating.
When you estimate most software development projects, you’re working with two variables - scope and time - and you end up having to negotiate on both of them. When you lock in the time - it ships in eight weeks - you only negotiate on scope.
And since you’re always filling the same space of time, you grow better over time with estimating what fits in that hole - without really estimating anything at all.
I last wrote about this back in “Avoiding the estimation death spiral”, and was surprised to find echoes of it here as well.
The book also emphasizes that the goals and actions you take in those 12 weeks need to be tied to your personal vision - where you want to go with your life, inclusive of work.
It spends a fair amount - but not nearly enough - of effort talking about making that vision as explicit as possible.
I’m 45 years old, and it struck me that I’ve never done this, and I’ve never thought about it so clearly.
Whether it’s managing yourself or managing other people, you get better results the closer you can tie the work that needs to be done to what you - or the folks you manage - want for their future selves.
====
Speaking of that vision, I wrote down mine over the weekend in one-, three-, five- and 10-year timeframes.
There’s a lot of travel involved and lots of various financial- and health-related milestones outlined.
But one key point is this:
“I've helped so very many people and impacted so very many lives through writing and teaching and coaching.”
This is what I want my life’s work to be.
It’s why I’m here.
Thanks for tagging along.
====
Related to the above, I’m pondering how I can help accomplish that vision.
The plan right now:
Finish the damn book
Send this weekly
Post an entry to https://chrisvannoy.com weekly
Explore video and/or podcast
Make my coaching offerings simpler
I think a sweet spot for me in helping inexperienced software engineering managers level up quickly is by helping them avoid pitfalls and find better ways of managing people - both the folks they manage and the folks elsewhere in the organization.
I already offer coaching, but I’m going to make it more clear what that includes and what it costs.
I’m also going to offer a package deal to companies that want to automatically include my services for their newly promoted or hired software engineering managers.
I talked this through a potential buyer this week and got back a “That’d be a no-brainer.”
That strikes me as a good sign. :)
Like and appreciate you, and hope you’re in the midst of a fantastic day.