In Conversation - Allan Kelly Top Five Tips For Working With Objectives and Key Results

"OKRs are really a feedback mechanism… it's a two-way street rather than a command-and-control mechanism.”

Allan Kelly Top Five Tips For Working With Objectives and Key Results 

1. Feedback mechanism: OKRs are a feedback mechanism rather than a order giving mechanism

2. Involve as many people as possible in setting OKRs

3. OKRs are not a to-do list, they describe a desired outcome

4. Decide where Business as Usual fits in

5. Ambition or predictable? 

TIME STAMP SUMMARY

01:36 Setting OKRs based on proximity to the customer and understanding of the technology.

10: 50  Success measured in tangible changes 

12: 24  Balancing new products while maintaining existing products

17:00 Clear communication manages expectations

Where to find Allan?

LinkedIn                           https://uk.linkedin.com/in/allankellynet

Website                             https://www.allankelly.net/

Book Link                         https://amzn.to/3EK08kO

Allan Kelly Bio

Welcome to Allan Kelly’s home on the internet. Home to Allan and his company, Software Strategy Ltd. Let him take up the story:

Once upon a time I was a programmer, people I worked with thought I was quite a good one. I was part of a team building a hand-held PC, which was a big deal in 1991. I worked on electricity modelling, I wrote programs for railway timetables, software for banks and real-time data feeds for Reuters. I built secure e-mail systems and mobile phone network diagnostic tools.

The code was not the problem, the problem was the way the team was set up, the problem was the way we were asked to work, or the way work reached us. To fix that problem I needed to become a manager… but I didn’t want to be a foolish manager like all the ones I’d worked for before, so I got myself a management qualification. And while I was getting that qualification, I discovered that modern management thinking was very close to the then newly emerging field of “agile software development.” When I look back at my experiences so much of the good times matched the thing, we call agile.

I still love software, I love coding, but I don’t code any more. (Actually, I do code a little, for love.) I devote my time to helping make software better. In my mind when I’m teaching, advising, coaching, consulting I’m helping the person I used to be. When I see programmers at work I see my younger self. And I want them to do a great job, I want them to be able to do a better job than I ever did.

Today I call myself an Agile Guide – I guide people and organizations to greater agility. I provide coaching and direct advice on agile working to leaders and teams creating digital products (software!). The companies I work with come from many fields as different as healthcare and surveying. However, they all depend on software to deliver for their customers. Without software they are nothing. Yesterday… I started coding in 1982 on a Sinclair ZX81. By 1986 I was earning money as a regular contributor to BBC Telesoftware – PDP, PDR, Eclipse, Fonts, Demon’s Tomb, EMACS (no, not that emacs), Snapshot and Femcoms to name a few, mostly in 6502 assembler. In 1989 I was a system administrator with Nixdorf Computer. In 1991 I was a software tester at DIP in Guildford building the Sharp PC-3000. Even as an undergraduate I was hired by the University to help teach other undergraduates and occasionally post-graduates.