Radical Focus - OKRs

Radical Focus explains the OKR process with a business narrative (a startup building the StarBucks of Coffee). The story shows how focusing on OKRs supports the team taking the tough decisions (e.g. stopping promising work if it doesn't support an objective) and spending their limited runway of activity on the right tasks.


It's a short read, with some good points but having read the book and watched "The Executioners Tale" (https://vimeo.com/86392023) I'd pick the video next time!

Key takeaways

• OKRs are great for setting goals, BUT without a system to achieve them you are as likely to fail as with anything else.
• A mission keeps you on the rails - the OKRs provide focus and milestones.
• Set only one OKR for the company - it's about focus
• Timescales should be about 3 months - too long and it's too far away to have impact, and too short and it's not bold enough
• Objectives are inspirational not metrics
• Repeat the message. The goal needs to be in front of everyones mind and tied to all activities. - "When you are tired of saying it, people are starting to hear it" (Jeff Weiner, CEO of LinkedIn")
• Heuristic for KRs - one usage metric, a revenue metric and a satisfaction metric.
• A good key result should be a bit scary - a 50/50 confidence you can make it is about right.
• Use health metrics to identify areas to protect as you meet the goals (what can't you screw up?)
• Use the four-square template (http://www.tightship.io/assets/weekly-meeting.jpg) to keep focus
• Reinforce the message at the beginning and end of the week (Monday discuss/challenge, Friday demonstrate/celebrate)

The 3X Approach

I watched a webinar recently about Kent Beck's characterization of product development as a triathlon and thought I'd summarize the notes here!

Kent presents product development as a three-phased approach (eXplore, eXpand, eXtract). This really closely models the product life cycle (from HBR).

Kent's insight is that you should act differently depending on the phase you are in.

In the Explore phase (stage #1 above) you can't predict the future. You've no idea how long finding market fit is going to take. It's a high risk activity. The main driver of success is the rate at which you can run experiments and learn quickly. At this stage software quality is irrelevant - the half-life of the code is short. You want a cross-functional, loosely co-ordinated team to deliver this phase.

The next stage is Expand - this is rapid growth, equivalent to the B round of venture capital. You have validated the market, you know what to do and how to do it. Time to scale, develop features and get it in the hands of users and build those feedback cycles.

Finally, you are at Extract. This is where economies of scale shine. Work here is predictable - adding a feature will result in a known about of revenue. You can estimate things well because you've done it plenty of times before. Quality is really important - cutting corners now will cost you because you'll be stuck with it for ever.

Organizations can get tuned to a particular way of thinking and that can constrain. For example, it's easiest to get tuned into the last phase Extract (see Innovator's Dilemma)

Beck states that this is one of the things XP got wrong-  there is no one-size fits all methodology. The 3X model says it's all about where you are on the s-curve.

Design Pattern Haikus

Singletons

a singleton is

a global variable

sounds a bit better 

A singleton is just a fancy name for a global variable. I like to think of a singleton as a way of warping to another point in space/time, changing the space time continuum and then heading back. You've seen the sci-fi films where this happens, right? It has similar effects on your code, making it difficult to understand what the hell is happening.

Interpreter

interpreter is

domain specific language

that is all it is

Well, there's not much more to say is there? You want your code to be readable in the language of your domain. One way to do this is to make the code look more like the language of your domain. A domain-specific language is one way to accomplish this.

Visitor

multiple dispatch

that is what you really wanted

visitor will do

You've got a function that wants to do different things depending on the types of the arguments. You've got a language that only allows you to do one different thing via polymorphism. You don't want type-switching cos someone told you that was bad.

Assuming you've got those prerequisites then go for the visitor pattern. Alternatively, look at multiple dispatch and see there's no problem there at all really.

Strategy 

functions compose well

classes do not compose at all

love strategy pattern

You want to break apart a set of work into small discrete components (let's call them "objects"). The strategy pattern allows you to plug these together to solve a problem.

Or... You want to break apart an algorithm into discrete functions (let's call them functions). Functions glue together.