wioota

Time management might seem like a prosaic topic, but for any CTO who aspires to be more strategic, it starts with being in control of one's time.

How some tool providers describe OKRs it can be over-engineered I agree. You need to adapt tonyour context. E.g. startups can use OKRs but should be very lean about it. OKRs aren't really a framework - there's not lots of things you must do.

The only essential is can a team align on a sentence describing what is true if the goal is achieved and 2-3 measurable items of evidence of the goal being achieved or progress towards achieving the goal.

If things change, scrap the goal and write a new one. Presumably you learnt something that invalidated the previous one. If it's because of someone else's whim you've got a different problem.

The quarterly cadence is not essential but it is often helpful to periodically know when there is a great opportunity for alignment across teams.

When timing of goal setting is inconsistent across teams it's hard to be available to each other when you need support across teams e.g. maybe one team provides a service that another team needs to achieve a goal.

There isn't really one way to do OKRs - you can read a dozen different descriptions and have a dozen variations. It's not a formal methodology but rather an approach that for a long time was passed around organically based on some key adjustments to MBO (Manage By Objectives) which came before it.

E.g. How Measure What Matters and Radical Focus describe OKRs - two of the most popular books on the subject - differ quite a lot.

I think finally there's some consensus that cascading OKRs is a bad practice but unfortunately people keep.doing it because that's how it was described in MWM.

We tended to have goals / OKRs per team and longer term goals they could align to. Flatter the better when possible.

If it's seen as chore it's doomed to fail.

Where I have seen it work well are in competitive markets such as SAAS companies battling for market share.

The maturity for using measurement for decision making is higher because to do otherwise means losing marketshare quickly to a competitor. Network effects often mean regaining a leading market position is tough.

The other element is the leadership treating it very seriously. That means investing in regularly communicating the state of the company's market position and engaging in giving feedback on goals and progress and looking for ways to support the teams.

Unfortunately these are traits missing in many companies.

Might be semantics as the changes I describe are fairly substantial compared to how many companies implement them. I did think of not calling it OKRs anymore at the time but the effort to rebrand it internally didn't seem worth the payoff. I like your suggestions - anything that increases clarity, alignment and debate. If a team wanted to align based on a memo or other doc we could debate I'd go for that as an alternative to OKRs. Documenting what you tried, what worked and why and what you intend to do makes sense to me!

Bad leadership will make a meal of any approach to work, its true. OKRs are not easy - they take good leadership, discipline and a culture which is open to feedback and committed to learning and adapting to what it learns. I wouldn't even say OKRs is the best way to work this way, just the most popular (hence why I wrote about the complimentary things we paired with it).

Achievable and valuable definitely more valuable than hard. I do suggest it's healthy not to 100% know how you might achieve the goal over the period - its good to be open to options and look for evidence you are making progress. I think this is different than trying for a moonshot every quarter :)

100% agree. Lots of other things need to be in a good healthy state for OKRs to be useful.

Some of these are cultural such as it being safe to give feedback and a propensity to act on what is learnt.

The ability to capture and update the persistent model I mentioned in the post requires the leadership to be aligned on the direction.

When your expertise applies to the qualitative aspects of a product or service, it can be a challenge to articulate the importance of issues. Here's an approach that may help you.

Wow, didn't even think to post this here. Pretty cool :) Happy to chat about this post here or in the comments on my publication, Focus on outcomes.

NodeJS, github and the Cloud9ide (powered by ACE editor) is a pretty good ecosystem for this. You can run it on Joyent's no.de hosting or EC2 (or the many other NodeJS hosting services springing up).

This was a great read and the patterns of growth and strategies they used hold true even for much less extreme scaling.