allan kelly

Core message – succeeding with OKRs

Agile / / / ,

“What is your core message?”

Perhaps surprisingly “this”what is your core message?” is one of the tougher question I’ve been asked lately. My problem is, while know the value of focus and regularly preach it focus I can be weak myself. So, this question has me thinking of several possible answers.

Those answers are connected but I’d have to spend time enumerating my philosophy. And actually, the best explanation of that philosophy is the books I’ve written over the years starting with Changing Software Development.

Fortunately, my inquisitor was asking specifically about Succeeding with OKRs in Agile so the full question was really “What is your core message of your OKR book?” which makes it a bit easier.

(By the way, the Italian translation of Succeeding with OKRs in Agile has just been released.)

Succeeding started life as a brain dump to myself of what worked, and what didn’t work, when using OKRs in agile teams. It wasn’t intended to have a core message, it was more “here is bunch of things to help with OKRs.”

Still, there is reoccurring, core, message: OKRs are mechanism for agreeing shared goals, communicating goals and driving action, to work everyone on the team should be included and everyone is responsible.

Let me expand on that…

When something (opportunity, challenge, problem, whatever) is big enough to need more than one person then it is a very good idea indeed if those people can agree on a shared goal (objective, target, aim, desired outcome). Unfortunately, giving people goals is a really poor way of goal setting for a variety of reasons.

The days when one person could give orders down the hierarchy are gone. That may have worked in 1914 but society is less accepting of that approach today. Not only that but modern companies and systems are too complex for a big brain approach to work.

Perhaps the biggest reason is that a big brain approach fails is because simply giving people work to do fails to harness their motivation, talents and abilities of the people doing the work.

Commitment – and therefore motivation – will be highest when those doing the work have had a voice in forming the goal. Co-creating goals shares and enrols people. This brings all to the table and harnesses their brainpower. In doing so there is a place for diversity and dissenting opinion. Different views and different approaches creates more opportunities.

Driving working from goals is superior to working from plans because goals are more stable, plans are frequently derailed. You can, and should, keep coming back to goals. Plans are just a means an end, plans are created as needed to advance on the goal.

In this context OKRs are a mechanism for agreeing share goals, communicating goals and driving action to deliver goals.

Now that is the core message, but alongside it is some caution. Unlike some OKR proponents I recognise problems. Not fatal problems, but things to be careful with.

Goals can mislead. By their very nature they simplify and abstract so you need compensating mechanisms. So revisit goals regularly – the OKR framework defaults to every 3 months. This provides opportunities to refine goals and renew enrolment.

Simpler short term goals are great for motivation and focusing work but they miss the broader view. Broad long-term goals can be too abstract for people to associate with or to drive work. So these need to be used in tandem.

Smaller and short term goals need to be nested inside broader, longer term, goals and ultimately our personal and organisational purpose. However, goals is not a sure fire win.

Problems arise when goals conflict: The sooner this is identified the more options there will be for reconciling those conflicts.

While single minded goals are great at focusing teams for action they risk destabilising the wider system, e.g. near term cost reduction can undermine resilience, succession planning and innovation. So you need to regularly take a step back and think more broadly.

Back to core message: In the days of the big brain mastermind they (CxO, consultant, central planner) was expected to do the broad thinking while lesser minds would consider action. Rather than separate by role I suggest they are separated in time: everybody shares responsibility, while they spend most of their time delivering they surface every few months and think broadly. Its more egalitarian.

This doesn’t take any longer because the big brain doesn’t need to spend time explaining their great ideas to everyone else and then policing compliance. And since everyone is involved with setting understanding and motivation are higher so the chances of meeting the goal are higher.

Core message – succeeding with OKRs Read More »

Writing OKRs masterclass online in January

Agile / / / , ,

My online Writing OKRs Masterclass is back in January. Held in partnership with Avanscoperta this hands-on class has you writing OKRs, understanding what makes good OKRs and what to avoid!

If you are struggling to write OKRs, or if your job requires you to write OKRs regular then this is the class for you: Product owners and Product Managers, Scrum Masters and Agile Coaches, Managers of all descriptions and aspiring leaders who expect to be using OKRs in the future.

Starting with the nature of objectives and key results we will look at what makes a good objective, what they are not, and why objectives are subjective, and objectives in the organizational context and goals-within-goals.

We will then look at how to measure key results, how to put numbers against intangible results and quantify changes. We will discuss the importance of refining OKRs with feedback and present rules of thumb for writing OKRs. Finally we will discuss the difference between leading and lagging indicators, the advantages and disadvantages of each.

Sign-up now, use the code Allan_Blog_10 for a 10% discount – places limited.

Writing OKRs masterclass online in January Read More »

How do I combine OKRs with KPIs?

Agile / / / , , ,

“How do I combine OKRs with KPIs?”

I’m going to let you in on a secret: this is both the question I get most often about OKRs and a question I dread.

I groan internally when someone asks. Unfortunately, its one of the most common questions I get. So while it has been on my list of “Things to blog about” for a year I’ve been putting it off.

Dragon Jojic ask me this last year and I spent weeks digging up articles and reading. I kind of got an answer, but its not a great answer, it was about 10 pages long.

So why do I hate this question?

The thing is, KPIs – key performance indicators for those who have been lucky enough to avoid them – are something of a moveable feast. That is to say, they mean different things to different people in different places. To make this worse, it turns out that KPIs lack a foundational text.

When I began my research last year I assumed that I could find the original book or journal article were KPI were described. But, it doesn’t exist.

The expression seems to have just arisen in management talk and stuck. So there is no commonly agreed definition. So let me give you three ways the I see it being used, and thus, three answer to the original question.

First “Informal KPIs”. Teams and companies talk about KPIs and many numbers are called Key Performance Indicators but there is no agreement on what the important, key, KPIs are. Nor is there any definition what a so-called KPI actually measures or how it is measured.

Worse the increasing use of dashboards is making means KPIs are proliferating. Increasingly the term is just applied to any old metric that somebody wants to aggrandise.

If you are using informal KPIs like this then go right ahead and use OKRs. Hopefully OKRs will, in time, help bring order to your KPIs.

The second type of KPI are Formal and Targeted. There are a recognised limited number of well defined KPIs. Not only does the company set targets for KPI measurement but they may well draw up action plans to achieve those targets. I found David Parmenter’s “Key Performance Indicators” book a pretty wise here.

Used like this KPIs aren’t actually massively different from OKRs. If this style of KPI is working well for you then why add OKRs? You need to understand why you would use both because they overlap. Adding OKRs may simply increase costs and bureaucracy, at worst OKRs might set up conflicting goals.

However, while many companies are undoubtedly using many informal KPIs there are very few who are using this style of formal KPIs.

Finally, the third type of KPIs are my preferred sort. This style of KPIs is closer to Balanced Scorecard approach style. Here KPIs are well defined but they are not targeted directly. Rather, KPIs are used to monitor the organisation and check it is moving in the right direction and not getting out of balance.

This model is akin to hospital monitoring instruments. The instruments tell you patient heart rate and blood pressure but have no control over those measurements.

OKRs are the mechanism to change those measurements. OKRs on change and action, they also help individuals and teams plan and align. You don’t say “Lets target lower blood pressure” you say “Lets target a healthier diet” or “Reduced stress.” That in turn reduced the KPI.

So there you have it, in order to answer the question “How do OKRs fit with our KPIs?” I need to ask you first “How are you using KPIs?”

Want to discuss your situation more specifically? Get in touch, e-mail me or book a call.

How do I combine OKRs with KPIs? Read More »

The first agile transformation failure

Agile / /

Shall I tell you a story of a failed corporate transformation project?

A story of executives who enthusiastically embarked on a journey to greater employee involvement utilising new technology – embracing self-organisation in teams, or to use an older term sociotechnical systems.

A story of well intentioned, experienced, consultants who bit of more than they could chew. Consultants who would have followed organic, piecemeal growth, elsewhere but driven by executive desire to get the project done fast misled themselves. Consultants who adopted a cookie-cutter approach, expanded their team with less experienced consultants, while neglecting the very client employees they sought to enlighten.

Perhaps you are already bored, you’ve heard this story before. But what if I tell you it was PacBell in 1986? – 15 years before the agile manifesto.

This story, together with many others is in a book called Age of Heretics. By the end of the book I felt I had seen a glimpse of the future, and it wasn’t a happy future.

While I knew bits of the story – or stories – the booked filled in some pretty big gaps. It turns the “agile revolution” is a remake on a bigger scale, there is no happy ending but maybe there is reason to hope.

For most of the last 20 years me an others have been talking about a collection of ideas known as agile. It is well known that most of these ideas go back far further…

Eric Trist described “sociotechnical systems” which were the fore runner of self-organizing teams.

Edwards W. Deming and Philip Crosby began a quality movement which was the pre-cursor of technical excellence and things like pair programming, refactoring, automated testing, etc.

Toyota’s Lean system teaches the importance not just of quality but managing workflow, involving the workers, stockless production and just-in-time working.

But it turns out there are many more stories which are less well known. I knew a little of the Topeka Work System but was oblivious to similar experiments at Procter and Gamble.

Nor did I appreciate just how many of these ideas were interconnected already. That in the post war period the academics and practitioners who invented and experimented intermingled, shared ideas and built on one another.

It turns out that what were a few experiments in the 1950s grew in the 1960s. By the 1970s General Foods and P&G were building new factories on these principles and Shell was abandoning its Unified Planning Machinery.

While growth continued into the 1980s there were failures like PacBell. Despite great success General Foods was never able to capitalise on the Topeka success. In fact, in an eery future echo others in the company found it difficult to work with the self-organizing teams at the factory.

And thats why Age of Heretics also reads like back-to-the-future for agile practitioners. While many of the experiments were a great success many of them eventually succumbed to normality.

In some cases the guardian angel boss moved on and their successors failure to appreciate or protect the experiment.

Ideas failed to travel and experimental plants were seen as odd or difficult. When ideas did travel the transplanted seeds failed to grow. It turns out copying processes is only part of the change needed.

Just about all the case studies given in this book will resonate with those in the agile community. The PacBell case in particular could have been written about many large companies, particularly banks, on an agile transformation in the 2010s.

(There are some other pre-cursors of our current world in here too. Like the 1972 Limits to Growth report which pre-shadowed many of today’s environmental discussions.)

Its very easy to be depressed about agile transformation after reading these stories but I shouldn’t be. After all, now I understand things better maybe I can avoid them?

Perhaps more positively, despite all these failures these ideas keep coming back. Haighmoor coal mine may have been the first self-organizing team in 1950 but by 1960 there were more. Not all survived but more followed them.

Topeka may have been the largest example when it opened in the early 1970s. Despite facing challenges – the loss of key staff, neglect by the parent company, changes of ownership, expansion and down-sizing – it was still self-organizing until 2002.

Repackaged as agile these ideas have reached more teams than ever before. While there have been lots of failures and sacrifices in this time the ideas live on. Slowly, the superior performance of this way of working, the applicability to work in the digital age and the expectations of younger generations probably guarantees that this is the future.

However, that doesn’t guarantee success for any one company or team. There will continue to be failures. So, as we pause for breath I suggest you read the fascinating Age of Heretics – it may not contain the word agile but it is a both an agile history and prophecy.

The first agile transformation failure Read More »

Little book of workflow management

Agile / / / ,

I have a confession to make. I recently published a series of articles not on this blog, and not even in my newsletter. I wanted to try something a bit different. I wanted to try writing short descriptions of the working techniques agile teams use but without using the word agile, referring to software development, or even IT. It is increasingly clear that the agile way of working benefits many beyond technology so I wanted to see if I could help.

All the articles are free on LinkedIn and now I’ve combined them together is a short book – or is it booklet? – which I’m calling Little Book of Workflow Management. I’m writing this on LeanPub and you can get the book now – the code Blog2024 should get you the book half price.

There are a few more short pieces I plan on adding, most of them will find their way to LinkedIn too but some will not. After that, I’m not sure what happens, I’ve got a few ideas of where this project might go.

As always I’d love to hear your feedback on this embryonic book so please let me know what you think. And if you’d like to talk about how to apply these lessons in your team book some time with me.

Little book of workflow management Read More »

How can you scale without authority?

Agile, Scaling / / / , ,

A few weeks ago I was at the Royal Albert Hall for one of the BBC proms concerts. I’m there to listen to an orchestra perform a concert but what always amazes me is how the players work together. How do they do that? How do they all know exactly, to the split second, to push their bows up? And exactly when to pull them down?

Sure there is a score, and a conductor giving them clues but there is more to it than that. How can they all play the same tune at exactly the same time? Soloist I understand, easy, one person, but in an orchestra? Synchronised every second? Now that is what I call a scaling problem.

Do you scale?

Let me ask: Do you scale? and how do you do it?

Do you lie awake at night trying to work out how your team can work together with three other teams all building parts of one solution? – like the violins working with the wind section, and occasionally a big drum coming in.

Scaling seems to be a perennial conversation, and inevitably it actually means scaling up: how should we scale our company? how should we scale our team? should we use SAFe? or LeSS or some other scaling framework?

Organising in the large frequently boils down to giving some people authority to tell others what to do. Sometimes that is by issuing direct instructions today “Today you do this, you do the other and you do that thing.”

Less often it is by setting rules, rules are standing orders: “all expenses must be approves by a senior member of staff”. And sometimes by mandating what is to be the output “Don’t stop until all products are 10cm in length and weigh 100g.”

In the modern work environment where individuals and teams expect autonomy – perhaps they are Gen-Z or perhaps because they take an agile approach – this creates a lot of tension. While a framework might reconcile some tensions it still boils down to giving someone authority at some time. It becomes an exercise in passing the authority baton: the Product Owner mandates what is to be done and passes the baton to the Scrum Master. When the work is done the baton is passed to the Release Engine, next is the Business Owner who decides success or failure.

Leadership doesn’t so much emerge as gets programmed. There are fewer opportunities for shared leadership and what there is happens as a time share. Many teams are still following somebody elses plan rather than co-creating.

Less common scaling methods

Yet there are other co-ordination mechanisms out there which are all too frequently overlooked. In fact, in his latest book my favourite management thinker Henry Mintzberg sets out six:

1. Mutual Adjustment: Communicating directly

2. Direct Supervision: Issuing Instructions

3. Standardizing the work: Establishing rules

4. Standardizing the outputs: Controlling performance

5. Standardizing the Skills and Knowledge: Prior Training

6. Standardizing the Norms: Sharing Beliefs

Numbers 2, 3 and 4 utilise authority, someone issues the instructions, someone sets the rules and someone controls performance. These are the ones which formal scaling approaches rely on. The brand name frameworks say little about 1, 5 and 6 – missed opportunities.

Number 1 and 6 tend to be what happens informally in small companies and families. Those scaling teams and projects may treat them with suspicion.

Number 5 is key to orchestras, other arts and the military. Actors and musicians often spend more time rehearsing than performing. Armies will train soldiers again and again. Military training is expensive too: they will be sent to foreign climes for exercises and train with allied nations to make sure their troops can work together. (Such exercises can also send a message to potential opponents too.)

How does the BBC orchestra do it? Don’t ask me! I see the conductor doing 2, the music score controls the output 4, and I know they have trained as individuals for years then rehearsed together, 5. I’d hazard a guess that 1, 3 and 6 also play a part.

Technology companies try to recruit skilled “plug compatible” staff. New employees arrive ready trained and are expected to substitute for one another. One Java programmer leaves so they hire a ready trained one to replace them. They might get a half-day induction but they then they are thrown into the team without any training.

The emphasis on existing skills almost precludes shared training or finding common beliefs. Companies rely on #2, #3 and #4 to instruct them what to do. Some companies embrace #1 while other insist on several thousand kilometres separation. (In the online world casual, ad hoc, conversations are rare, you need to schedule video calls 2 weeks in advance.)

A better way to scale

So, instead of scaling with authority – instructions, rules and controls – what if scaling was done through training and rehearsal? Instead of standardising by mandate what if scaling was done through collaboration and exploration? And what if shared leadership was acknowledges and embraced?

Instead of scaling with the written word, what if people are brought together to find common beliefs, common values and to create a shared understanding of what work goals were? And then practice working together?

I think this is one of the challenges for the next decade. Most of our companies, their structure, organization and management thinking is predicated on the assumption of authority and that people can be told what to do. It is an assumption which increasingly doesn’t hold and even if it does there are commercial, competitive, advantages, for those who can find different, superior, ways of working. That is the new challenge.

Like to conitinue the conversation? E-mail me or book a call.

Opening image of a proms concert from courtest EddieColdrick CCL licesne via Wikicommons

How can you scale without authority? Read More »

Embracing shared leadership

Agile / / / , , , , ,
Shared pizza

I’ve recently made a point of reading up on shared leadership and I’m converted, I think its the way to go. Two reasons really, first it describes better what I see happening in the work environment and second, it offers an alternative to the confusion around “self-organising teams” (or is it “self-managing” ?)

I regularly hear comments like “everyone in your company is a leader” or “leadership is all around you”. I struggle with these sometimes because I wonder “if everyone is a leader… who is doing the following?” or to put it another way: if everyone is leading who does the non-leadership work? In the discussions of shared leadership I find the answer.

Let me dig into both a little further.

Most of the papers I’ve been looking at come from the academic world. That makes for some very dry reading and many of those papers aren’t easy to access – luckily I have access to a University library at the moment. The upside is that it means the field has been researched properly.

Lets start by defining what I mean by shared-leadership:

“shared leadership is a dynamic, interactive influence process among individuals in groups for which the objective is to lead one another to the achievement of group or organizational goals or both” Pearce and Conger, 2003 (this book is referenced in several of the papers I looked at so seems a good starting point)

Lets add:

  • Shared leadership covers influencing peers as well as those who appear higher and lower an org chart.
  • While some authors use the term “shared leadership” to describe determined job-shares (e.g. joint CEOs) most use see it as an emergent state.
  • Leadership is exercised through Influence more often then direct authority, and influence derives from knowledge, ability, technical skills and soft skills.

This describes the way I see good teams work. The Scrum Master leads daily stand-up meetings with their facilitation skills, they may set up the planning meeting and lead the team through the steps. But the Product Owner/Manager steps forward when it comes to nominating and prioritising the work to do. When the conversation turns to technical issues team members my more naturally follow the suggestions of an experienced coder or designated architect.

Outside of set piece events, during the day-to-day work, the person who picks up a piece of work will lead on that work. If get stuck they may call in others while retaining leadership of the problem. Or, they may defer to a more experienced colleague who comes to help.

The idea that leadership moves matches what I see happening. That doesn’t preclude there being a designated leader or, manager. In appointing managers companies expect them to take on a leadership role and in designating them a manager confer some authority on them.

A good manager will respect the abilities of others and allow leadership to flow. So they will let the Scrum Master run meetings, let the Product Owner/Manager prioritise work and let experienced coders lead on the design. They will use their authority to resolve disputes, interface to the company, and use that authority for the good of the team.

Of course, not all managers are good, weak managers are all too common. I recall one in particular, Jerry, who on appointment immediate moved to put the team in their place. He didn’t want team members deciding on priorities, design, team working or even speaking to other managers. Until he arrived the small team were sharing leadership and working effectively.

Shared leadership matches the “distributed and devolved authority” that I’ve been advocating for years. What is needed is for decisions to be made by those closest to the need to the decision and those with the most knowledge.

Distributed and devolved authority has been my formulation for side-stepping the questions of “self-organising” or “self-managing” teams. While I’m all in favour of involving more front line staff in decision making those terms create problems.

For a start, there is little agreement on whether it is “self-organising” or “self-managing” – or what the difference is. Neither term is particularly well defined. Sometimes “self-directed” gets thrown into the mix to complicate things.

Because the terms are poorly defined they bring unwarranted assumption. Even some well known advocates take the terms to mean “No managers” – and in particular no project managers. Now while there might be reasons to reduce the number of managers in such an environment once people think managers might be gone it creates problems.

Then there is the question of who is in the self-organising team and who is outside the team? I remember one developer who took exception to the Product Owner nominating the work to do. He pointed out that the team was supposed to be self-organising – at least according to Scrum – and he saw the Product Owner as behaving like a manager. To his mind that was wrong.

His interpretation gave me a lot to think about, there was a logic in his interpretation. At the time I didn’t know the term “shared leadership” but I was applying the ideas. In my interoperation the Product Owner and Product Manager lead on what commercial, customer facing, work needed to be done. Plus, they were members of the wider team, they were specialists, leaders, in one aspect of the product but not all aspects. When it came to the solution design, and how the work was split up then other team members would step forward.

The problem is that hierarchies tend to develop whether you want them or not. In the absence of a formal hierarchy an informal one often emerges. The one that emerges might be more problematic than a formal one. Consider a team which swaps its designated manager for self-organisation only to see an prejudiced Alpha Male emerge as leader. (See In defence of hierarchy.)

Now don’t get me wrong, I agree there are lots of problems with “Management” but, unlike some, I don’t see Management as fundamentally flawed. Rather what I see is a lot of bad management. In truth much of this is because few stop to take the time to learn about management and how to perform it. Management is a skill like any other – or perhaps, given the breadth of management it is multiple skills.

Herein lies another problem, if a company adopts “self-managing” teams and removes many dedicated managers it does not mean all the management work is magically removed. Sure some will be, but managers don’t spend the whole day talking to other managers. The management work which remains will now need to be done by the team members. In other words, fewer managers means more people managing.

Given that these people have decided not to become managers there is every chance they aren’t interested in management work – much of which can be boring. Neither will these people have spent time, or be interested in, improving management skills which they now need.

The best teams I see practice a form of shared leadership while still having a manager. Sometimes that manager is close, even in the team, other times they are removed. But a good manager appreciates the abilities of the team and lets leadership flow between team members.

I expect to hear more of shared leadership, it is a model I intend to learn more about and help my clients embrace. If you would like to continue this conversation please get in touch, e-mail me or book a call.

Embracing shared leadership Read More »

Why I’m talking about Modern Management

Agile / / / , , , , ,

Management has changed. Or at least, it has for the most successful. Unfortunately some people have yet to get the message and too many are stuck – managing or on the receiving end – in the old world.

While some reject the idea of managers and management entirely I don’t. I think the anti-management ethos is a reaction to bad management and outdated management thinking. “Management” is a messy, varied field, it is a practice, part administration, part leadership and several other parts too. Unfortunately, few managers ever study or reflect on management practice. There is a lot of poor, outdated management out there.

New technologies, new thinking and a new generation mean the idea of management, and what it does, needs updating. If management had a standard model it is the model of General Motors and General Electric in the post-war years. The model continued into the 70s and 80s as the baby-boomers replaced the managers who learned their craft in the war years. Today the management baton has passed to Gen-X and Millennials with a Gen-Z workforce.

These generations have attitudes and expectations of work which means management needs to change in order to do their job. Managers who follow Alfred Sloan’s model are going to have problems. While I love the visionary writing of Peter Drucker it too is a historical document.

Obviously technology has changed but technology has always changed, that is the nature of technology. Remember: technology change demands process change. That is why management can’t stand still.

Sloan’s writing about GM was replaced by Grove’s writing about Intel. Google replaced GE as a role model to work for, and Spotify replaced P&G as something a bit different. The “agile transformations” of the last 10-20 years have been about that process change as digital tools permeated every workplace.

Unfortunately some fields move more slowly so there is an impedance mismatch: think about accounting standards, or the way banks fail to consider knowledge as loan collateral. (Capitalism without capital contains a great discussion around topics like these and again demonstrates the change.)

In the last few years many of the new ideas and management trends have found a home under the Agile umbrella. Even I am guilty here with Succeeding with OKRs.

It is hard to work out which begat which: did the agile movement give us #NoProjects and lead to Product over Project, or was it the ascendancy of Product model in digital which drive agile adoption?

Eric Trist might have documented self-organising teams in the 1950s and General Mills might have experimented in the 1970s but it was the agile movement which brought them into the mainstream (even if they are still the exception).

But as “agile” absorbed more and more it has itself become harder to define because of that breadth.

Does agile include diversity? – I’ve asked before is agile dyslexic. Both the standard management model and the agile manifesto were created by men. Women, not to mention other groups, have since contributed and emphasised different ideas.

Organizational learning and Psychological safety are key to making agile work but should they be considered part of agile? The former pre-dates agile while the latter seems to be a movement on its own. Similarly Beyond Budgeting fits very very nicely with agile and shared-leadership but it isn’t a standard part.

I wrote last time about the Good Jobs Strategy, and in my work on OKRs I emphasis purpose in work. Should good jobs and OKRs be added to agile? Certainly they are part of modern management.

Agile isn’t big enough to add all these. To do so makes it unwieldy even if they are all fellow travellers on the road to realising Theory-Y.

Agile has always had the potential to be about more than IT. Indeed, as more industries adopt digital tools they need both agile and other ideas to get the most from those tools – including AI. The evidence that agile like processes work in healthcare, hotels, law firms and elsewhere is growing. (I’ve got some experience here and I’m actively seeking “outside IT” opportunities now, so I want to learn more.)

Recently I’ve taken to calling agile and all these other ideas: Modern Management.

Taken together all these ideas are consistent and compatible. They represent a break from General Motors and GE so they break from the standard management model. Management as commonly conceived in 2000 doesn’t cut-it.

If you consider yourself an agile coach or consultant today you need to have these ideas in your tool box. The toolbox used to be labeled “Agile” and those who knew the word thought of it as very IT. Now needs to be called “Modern Management” – there is are more tools and the ideas are more widely applicable.

Why I’m talking about Modern Management Read More »

Massing saving on Succeeding with OKRs in Agile this week

Agile / / / , , ,

Succeeding with OKRs in Agile is on sale this week only – September 9, 2024 at Amazon.

For this week only the e-book version of Succeeding with OKRs in Agile is $2.99 / €2.99 / £2.99 instead of $9.99 / €9.95 / £9.95 – that is 70% off.

The print version is reduced by 50% or more depending on market, from $19.95 to $9.95 – although some of these cuts price have yet to come through on the print version.

Other markets have similar massive price reducting this week only – there are a few exceptions because Amazon set a minimum price in some markets. And price-cuts are limited to Amazon, princes on Kobo and elsewhere remain the same because of the mechanics of the price cut.

Check your local Amazon or go direct…

Buy @Amazon UK
Buy @Amazon USA
Buy at Amazon DE
Buy at Amazon NL

Massing saving on Succeeding with OKRs in Agile this week Read More »

Employees: growth driver or cost to trim?

Agile / / / , ,

Walmart doesn’t operate here in the UK, I was never impressed by the store when I lived in the US and rarely shopped there. My mental image is “pile it high, sell it cheap” – which was actually Tesco. Evil empire exploiting workers and customers alike. But, it seems I’m wrong. My image might have been correct once upon a time but Walmart now follows something called the Good Jobs Strategy: they invest in their workers, train them, pay good wages, give them more meaningful work and reap benefits which more than pay for the extra costs. Rather than being a cost employees drive growth.

The dominant operating model of many companies may well be pay-as-little-as-possible, avoid training and any other non-essential costs, accept high staff turn over and have supervisors police and micro-manage employees. Yet there is another model which seems workers as a growth driver and it delivers higher returns.

While there are examples from health care, manufacturing and elsewhere it probably easiest to see the Good Jobs Strategy in retail companies: Trader Joe’s and Costco in the US, Zara and Mercadona in Spain, and here in the UK Richer Sounds.

I’ve been hearing about Good Jobs Strategy for a few years now and finally read Zeynap Ton’s The Case for Good Jobs a few months ago. Yet I’ve hesitated to write about it because Ton’s case is rooted in the “low-paid” occupations like retail. I generally work with high-paid knowledge workers – engineers, sometimes accountants or marketeers, and so on.

Yet the logic applies whatever the wage level. When salary costs are higher the cost of recruiting and onboarding is going to be higher too. The same arguments I’ve been making under the banner of “agile” apply to good jobs strategy: listen to employees, expect them to do quality work, trust then and enrol them in process improvement.

Today’s standard business strategy is often to keep staff costs low: pay as little as possible, avoid costs like training and if possible keep staff on “zero hours” contracts so there is no need to pay them if they are not needed. But, if you apply a little systems thinking here and look at what happens you realise this model is failing employees and employers alike.

Because wages are low employees are always on the look out for (slightly) higher paying jobs. So staff are prone to move often. Which means that employers are constantly spending to recruit and onboard new staff. That also means that staff don’t know much about the product offering, say, where to find things in the shop; which in turn means customers service is poor and customer loyalty is low, opportunities to up-sell and cross-sell are lost. Staff are costs to be limited.

Working for such an employer is not a lot of fun. Staff might need to hold two jobs to pay the bills. So why should the staff commit? Why should do anything more than they need to? – especially when the employer doesn’t go anything more then the essentials. Why should they smile? And why would they stay when someone else offers 10¢ and hour more?

McGregor’s Theory-X “Works are lazy” becomes a self-fulfilling prophecy.

Now flip it around: Good Jobs Strategy is Theory-Y thinking, staff are growth drivers.

Such companies invest in their staff, pay decent wages, train them, trust them and allow discretion in work. Now staff stay, so hiring and onboarding costs are reduced. They understand how the business operates and what the product line up is so customer service improves, customer loyalty increases, up-selling and cross-selling increase and the world is a happier place.

Many will say I’m dreaming, that is not how the world operates. Maybe, but Zeynep Ton has collected the evidence and shows that it does payback. Walmart is the evidence, it used to follow the standard strategy but for over 10 years has followed good-jobs and the results show.

I suspect at some level everyone, CEOs included, innately understands this. Thus the question is: why do companies undermine themselves by not treating workers well?

Unfortunately, the answer is that bad jobs are so normal that anyone (CEO included) who suggests something different undermine their own positions. CEO feels compelled to keep costs low because it is the standard model and everyone – shareholders included – expect it. And if the CEO feels the pressure all the other managers will too.

Now, why am I writing about retail jobs in a blog more concerned with high paying occupations? It is because I see the same thing. Recently I came across a company that moved technology engineering to high-cost Finland because it saw the engineering standards would pay back. Paying high wages for quality work was cheaper than paying low wages for rubbish.

Forget low wages. The people I work with – the likes of product managers, software engineers, even managers – all get paid far more than minimum wage but they still suffer from a lack of training, lack of trust, lack of discretion and excessive tasking (micromanagement). High staff turn over and lack of business knowledge are the result.

Secondly, the more I work with OKRs the more I see that company purpose is really important. Anyone who has joined my OKR training workshops, or seen recent presentations, will have seen my “Eggs”. Near term goals (the objectives for this quarter) need to support longer term goals (the product goal or annual OKR). That goal needs to support the greater mission goal, and the mission goal needs to support the company purpose.

Goals nest inside goals. Several levels, but ultimately you need an outermost goal. That needs to be purpose. Without purpose there is nothing to align goals, and weak purpose (“make more money”, “do more stories”) isn’t very useful, meaningful or motivating.

Good jobs strategy ties together other ideas. In a bad jobs environment there can be no psychological safety, which in turn means no organisational learning, so process improvement (agile) is shot though, there is no improvement process, effectiveness and productivity are hobbled. You need a good jobs strategy to make it all work.

OKR adoption is one place to start breaking this cycle but there are others. Start by surfacing issues and improving jobs. If this makes sense and you’d like to move in this direction please get in touch or book a call to chat and lets see what can be done.

Employees: growth driver or cost to trim? Read More »