Agile

The Product Manager’s great feedback loop in the sky

Agile / / / , ,

Reading a product management blog recently I came across this: “Corporate Product Manager have it easy because they don’t need to achieve Product Market fit.”

I interpret what the author was trying to say was: “corporate product managers don’t have to sell their products so they don’t have to work at making their product meet market needs and produce something customers to pay.” While there is a point there I think the author vastly under appreciates the difficulties faced by corporate product managers specifically because they don’t have the giant feedback loop in the sky provided by sales.

Other way round

The logic is the other way around: “corporate product managers have to work harder because they can’t judge success by market fit.”

When your goal is to create a product that earns revenue you have a massive advantage: you know what success looks likes, people buy. There is an default answer to the question “What is this product for?” – “To make money.” That might not always be the true but it is a good starting point.

As a Silicon Valley Product Manager you have one overriding goal loop: to make customer give you their money.

Money is the best form of feedback

When someone pays they giving you feedback. They are saying “The most valuable use of this money for is your product.”

They are choosing not to spend money on something else – perhaps a competitor or maybe something you don’t see as a competitor. They are giving up the interest benefits of money in the bank. Rather than buy your software a customer might decide to go to the cinema and see a film with the same money. Money is meaningful feedback, money costs.

Silicon Valley Product Manager can test almost any product hypothesis with the question: does it generate more revenue? Money is the great feedback loop in the sky.

Vanity products

In the corporate environment things are a lot harder. Unfortunately, corporates have a habit of starting vanity products, or continuing endeavours past the point where they should be killed.

I once managed a corporate extranet. The company had persuaded itself that customers really wanted to self-serve in all sorts of ways and had build a website to do just that. Umm.

When I took over the product I started meeting customers – actual customers who paid for the firms telecoms products. They were being given the extranet free to make the products more sticky.

It only took a few interviews to discover that customers did not want the knowledge sharing platform the website was intended to be. Quite the opposite. The last thing customers wanted was their engineers sharing information with engineers from competitors.

Bang went the big motivator for the website.

The remaining capabilities could be provided by the SalesForce system the company was in the process adopting. And it would be a lot cheaper to just give customers a styled SalesForce portal.

Kill your darlings

Inside the company the extranet was always fighting for resources because it didn’t deliver revenue. It repeatedly lost out to other projects that could claim increased product sales.

As Product Manager the way to deliver the most value was to kill the product. I did.

Corporations have a habit of treating every ideas a potential feature, without the discipline of market feedback choosing decisions come down to opinions.

Recently I inherited a backlog along with the product. It contained a multitude of stories that some stakeholder or other thought the system should do. Many more stories originated with team members who thought “It would be good if they system does this.”

If this were commercial product I could reason, and even test, whether those stories held value: would anyone be willing to buy them? What new market could they open up? Can they give us an advantage over a competitor?

But no. There is no feedback loop. No market discipline. Everyone of those stories is there because some stakeholder thought it was a good idea. Stakeholders don’t agree – one say it is pointless, another that it is essential. Some stakeholder have command more authority than others – little Hippos.

Data over opinions

As Jim Barksdale at Netscape said: “Data beats opinions – If you don’t have any facts, we’ll just use my opinion.” Everyone of those stakeholders has an opinion and without the money feedback loop getting data can be impossible.

Part of my role as Product Manager is to determine the value and make judgements on those opinions. As a result I spend a lot of time talking, or rather listening, to stakeholders. I have to be fair (or at least seen to be.)

I work hard at trying to determine the value of my product and understand how enhancements can add value. But that also means I need to decide what constitutes value because it is not money. No wonder many product people get exhausted and give up trying.

Less is more but doing less means saying no. That can be career threatening. It also means deciding what to do soon and what to delay, again without the giant feedback loop in the sky that can be hard.

Corporate life isn’t easy

So when I read a comment like “Corporate Product Manager have it easy because they don’t need to achieve Product Market fit” I get annoyed. This is another example of the Silicon Valley view of Product Management dominating the discussion.

Corporate product management might look easy from the outside but from the inside I long for a giant feedback loop in the sky to give me the data.

The Product Manager’s great feedback loop in the sky Read More »

Heterogeneous Product Management is the future

Agile, Management, Product Management / /

My early career repeatedly moved between corporate software (products used in the business) and commercial product companies (products which earned revenue). Here in the UK I never met a product manager. Few, if any, UK companies understood product management.

Back then Silicon Valley seem to have all the answers so I went to see. Actually, it was a bit of an anti-climax, it wasn’t that different to the City of London. People worked long hours, people put work first, appearance was more important than performance, and house prices ever rising. Technically, they had the same technology and same problems, the same bugs, and made the same architectural mistakes.

But Product Management was different. It existed!

I hadn’t met a Product Manager before. In California it seemed like every other person was a Product Manager. In time I came to consider Product Management the “secret source” of Silicon Valley.

It made complete sense. Silicon Valley made world beating products because someone was charged with making a product that people wanted to buy. It wasn’t left to luck or an insightful coder.

All about the sale

Most Product Management commentators assume this commercial product point of view – the “Silicon Valley” or “Traditional” view. Whether software as a service (HotMail), a service only available via – and because of – software (Uber), or a good-old-fashioned installed product (Windows). There is an assumption that Product Management as about creating products which sell and bring in revenue.

Consequently most writing focuses on market testing, product-market fit, market disruption, etc. The thrust is the same: products that will sell, product which will sell more, product which are differentiated from the competition.

Look at the table of content from the Product Manager training I did with Pragmatic Marketing: Distinctive Competence, Market Research, Market Problems Competitive Analysis, Market Sizing, Win/Lose Analysis, Pricing, Positioning, Sales Plan – I could go on but you get the picture. There are other topics but the thrust is product which sell.

There is nothing wrong with that view. I get it. I drank the kool-aid. And once I thought that view was it, that was what Product Management was all about.

Now I see this as one description of product management. It is one view, one definition, it sometimes fits. But, it is not the only view, not the only definition and doesn’t always fit.

Product Growth

Post .com boom I watched as the UK and Europe caught onto product management and shared the secret source. As product management expanded geographically it also expanded intellectually. The Silicon Valley view leads to a one sided view of the role.

That model didn’t match the first product I ever officially managed – I felt guilty, I felt like an imposter. Nor does it match the products I find myself managing now: corporate systems.

The traditional model is part of the reason I find myself constantly asking: what does a Product Manager actually do?

As Product Management spread beyond Palo Alto it has changed. Modern product management isn’t always about a product which is sold and it isn’t always focused on product-market fit.

Modern Product Management is often concerned with products which serve corporate aims. Digital business depends on multiple software products but no one product is dominate. The business is about much more than a software product.

The traditional framing makes it common to talk about he Product Manager as the “CEO of the Product” and in a small, possibly start-up, company the product and the company were one so often the CEO was the first Product Manager. In the, larger, modern framing there are multiple software products which contribute to the overall corporate offering. The Product Manager is concerned with how their product adds value to the corporation.

The big question in traditional product management was: what does the market want? and what will people pay for?

Consequently the vast majority of product management writing focuses on customers, product fit, product launch, market testing and other early stage activities.

Inside the corporation product management is more concerned with later stage activities. What does the corporation need in future? How can it generate value over time? There are no customers, only captive users, and their needs are second to corporate needs, strategy and goals.

Today’s corporate technology products are key to the way the corporation operates. These systems, products, need managing to ensure they keep delivering value and change in ways that support the business. The days when software was expected to stop changing are gone. That is where the Product Manager sits.

Now do you see why I spend so much time agonising about the Product Manager role?

The ironic thing here is that I shouldn’t agonising about this. I described the way software products requires continuous attention, continuous improvement and continuous management 10 years ago in Continuous Digital.

Continuous

Continuous Digital set out to describe how to manage software technology in a project less world. Remember that “CD” was the companion to Project Myopia.

I’ve known the answer all along but the Silicon Valley view blinded me.

I do remember at the time thinking: if we don’t have projects who replaces the Project Manager? Someone has to think about the future, product strategy and the day-to-day questions. Project managers might not have been the best people for this but in the project model they were it.

I rejected making a case that Product Managers replace Project Manager because then the only model of Product Management was that traditional version – customer need! markets! products for sale! – I thought it would confuse matters.

It’s the product, stupid

Products rather than Projects are increasingly the organisational currency. The transition is incomplete, vestiges of project continue for the accounts but product thinking is in the ascendency.

Product Management has evolved too. Silicon Valley style commercial product type Product Managers still exist but that is just one model. Silicon Valley may still be the centre of innovation but software technology is far more widespread. Silicon Valley can no longer claim a monopoly on “the right way”.

Product Management may have started in Silicon Valley but today the profession has learned from elsewhere and it has expanded. The product, the thing, is still central but Product Managers need to think life-time over early stage.

Ironically, once you accept the Silicon Valley model of Product Management is just one model it becomes harder to define just what Product Management is!

To be continued…

Speaking in November

I’m return to Ordev in Malmo next month, 4-6 November where I am presenting Ideas to shape our AI future and The Good, the Bad and the Ugly of the The engineering mindset.

The following week I’m speaking at the OKR Summit online on 12 November – “5 Lessons from working with OKRs“. Use the link Allan20 to get 20% off tickets.

Heterogeneous Product Management is the future Read More »

New book: Managing with OKRs and KPIs

Agile / /

Big announcement: my first book in over 3 years – Little Book of OKRs and KPIs: Managing with gaols, numbers and purpose is now on sale.

This quiet blog

This blog has been quieter than usual for the last few months. There are multiple reasons why, and as it was summer I’m not too worried.

My current client takes a lot of time, I had to finish my EuroPLoP paper and, I’ve been working on this new Little Book.

This book started as a short guide to OKRs, KPIs and how to use them together – expanding on my paper last year. It has expanded because I wanted to include warnings about over reliance on metrics and discuss the importance of having meaning beyond numbers.

Conflict in management

The way I see it there is a central conflict in management between the rational way of management and the more emotional, heartfelt, way of. Although I discusses the rational way of managing with OKRs and KPIs I highlight problems with numbers and the need for greater meaning.

The power and the flaw of both OKRs and KPIs is the same: the numbers. Managing with numbers can be very powerful but managing only with numbers is dangerous. So this book also looks the pitfalls from the numerical, rational, approach and gives some advice on how to avoid them.

This book is more developed and closer to finished than usual when I release a LeanPub book. That is because over the last few years I’ve started and abandoned a several books. So I have hesitated to announce this one until it was more fully formed than usual.

It also means this book borrowed some content from one of my abandoned books on company form and the need to nested goals. However, this goes further, perhaps controversially I argue that while OKR style targets are good for near term goal setting the biggest, most purposeful goals, should not be quantified.

Anyway, read the book and let me know what you think. As before this is a LeanPub endeavour which means you can buy and read the book now, before it is finished. It is still a work in progress so you can influence the upcoming content.

Problem Solution

My other recent project was finishing my annual EuroPLoP paper. This year’s paper is Reframing the Problem-Solution pairing – one pattern & a discussion. For the third year in a row what started as a small little pattern expanded once I got to thinking hard about the subject.

One version of Problem-Solution will be appearing in the Springer Nature proceedings in a few months. I normally make a similar version more publicly available. I expect to do the same again but am thinking of how to best present this work.

As they say, watch this space.

New book: Managing with OKRs and KPIs Read More »

My regrets and why I’m rethinking Product Managers

Agile, Management, Product / /
Young business owner woman prepare parcel box and standing check online orders for deliver to customer on tablet, laptop Shopping Online concept.

Regrets? I’ve had a few, particularly when it comes to books. Take Business Patterns for Software Developers, perhaps the book I’m proudest off, certainly the book which was hardest and longest to write.

While I’m very proud of the book I regret the name. I remember several conversations with my editor about what to call the book. Even back then I knew it wasn’t the right title. Now it is easy to see: it should have been titled: Strategy Patterns for Software Products.

Or consider Continuous Digital, this masterpiece sets out my philosophy more than any other book – which might be why it didn’t sell! This book was ahead of its time; not infrequently I’m gripped by an idea and think “I must write about this…” Sometimes it is only as I start to write the words I think “Haven’t I written this before…” and there it is in Continuous Digital.

Continuous Digital is packed full of ideas, whether it is Time-Value Profiles, the value of nothing, deadlines over dates, diseconomies of scale, software as an asset, and purpose – all ideas which could be books themselves (and I really want to write a book all about purpose.)

Or consider the my advice on teams: Amoeba teams, minimally viable teams, Conway’s law, value seeking teams, team life cycle and more. If you know what you are looking at you can see what went on to become Team Topologies. About the time I was writing “CD” I worked on a project with Matt Skelton and we had long conversations about teams.

But the thing I regret most: Product model.

CD is cut through with discussion of products, I never say “the product model” but that is essential what I’m talking about. Today, when talk of “the product model” is common it is easy to I’m arguing for a product model way of working. I even though that at the time but I never call it “the product model.”

While CD and Project Myopia tried explain why projects were not a good idea and what to do instead they both avoided the topic of Project Managers, and if you focus on products not projects what do you do about Project Managers, who replaces them?

I’ve long considered many project manager role to be junior managers, the first step on the management ladder. Many project managers would be better thought of as work managers. Many project manager roles are now replaced by Delivery Managers. This does come closer to Work Manager role so it is a way of keeping some of the role without the project bit.

It is too simplistic to say Product Managers are the replacement because Product Manage is too different role. Now, 10 years later I’m starting to think that obvious answer might be the right one. But the Product Managers I’m seeing are not the Silicon Valley style “market fit” one. When I was first a Product Manager I probably saw that model as the right model but now I don’t. It is one version of Product Manager. I regret not seeing this sooner.

The Product Manager I’ve been in the last few years carries a lot more strategy than most Silicon Valley PMs. I spend a lot of time thinking about how to product will improve and where I want to take it. (This also differentiate the role from the misnamed Product Owner role which is usually (and wrongly) a lesser Product Manager.)

I promise to write more about the way I’m seeing the Product Manager role these days and why as it becomes more widely used it looses its original, and ultimate, feedback loop: money.

My regrets and why I’m rethinking Product Managers Read More »

AI is creating problems of surplus

Agile / /

At EuroPLoP last week I learned of a popular Open Source gaming framework (I forget which one) had instigated a blanket ban on AI contributions. It appears that AI meant there were more submissions coming in and the maintainers were struggling to understand and review them.

I hadn’t had time to think through the implication of this before the Financial Times carried a big piece on the same issue across the Open Source world (paywalled: Who cleans up after the vibe coding party?). It actually turns out this problem could undermine many of the OS libraries we’ve come to depend on.

Next a friend was telling me about his dozen AI coded mini-products, one of them has eight or so prototype. None are finished, none in the market, all sound like good ideas and potential products.

All these examples are perfect illustrations of Jevons paradox in AI: when things get more efficient (cheaper or easier) then more is consumed. AI coding agents make coding cheaper so we do more of it.

But, as we have known for years: build it and they will come rarely, if ever, works.

Since LLM coding agents appeared the number of submissions to app stores has rocketed and the number of available apps increased faster than before. Yet, the number of app downloads has not gone up. Say’s Law does not hold, supply does not create demand, just because there are more apps written doesn’t create more downloads.

One can reason that the same pot of customer money is now being spread across more apps so the average contributor makes less money – maybe that’s OK because the apps are so cheap to produce. Or maybe with so many more apps to choose from people stick with the popular ones and there is an even greater gap between the few “winners” and the “also rans.”

These kind of problems have always existed but by lowering the cost of change AI has made them more common. Previously, the slower pace of creation mean that more questions were asked and there was more time to catch such issues. Now things happen so fast there is no time to ask and new problems are appearing.

Understanding what customers will pay for is more important than ever. Can AI help there? Perhaps with market research but someone still needs to make a decision.

So much of our world is concerned with managing, controlling and rationing limited resources – indeed the “allocation of scarce resources” is sometimes considered the underlying problem in economics. But increasingly we see problems of too much and we lack solutions for too much.

That is not to say we don’t have solutions. In the 1970s and 80s we had over production of some foods, there were wine and milk “lakes”, and butter and gain “mountains.” The EU had to start paying farmers not to produce.

Software product companies traditionally have an spend split of 33%/33%/33% (approximately): one third on technology engineering, one third on sales and marketing and one third on everything else, like finance, HR, property, etc. Many of those cost remain even if the cost of coding goes down. If there are more competitors then maybe more needs spending on marketing.

More companies that aren’t software companies will find they have software which needs to be supported in some fashion. More software demands more cyber security and until machines replace all the humans those that remain will need more training, and even AI written systems will require maintenance and updates. Then there is the cost of complexity from all those systems which nobody quite understand.

As to Open Source projects, I don’t know. Maybe it will be a shift back to proprietary products, or maybe the submitters need to be charged.

Jevons paradox is working exactly as expected. Resolving the problem in one place is creating problems elsewhere. Problems are truly generative.

AI is creating problems of surplus Read More »

My #1 lesson from Bavaria

Agile / /

I’m just back from my annual pilgrimage to EuroPLoP in Bavaria – I say pilgrimage because every year, after nearly eight hours travel (3 trains, 1 plane and 1 taxi). When I open the door to my room I feel like a monk entering my cell – probably because the conference is at a former monastery and the hotel rooms were once monk cells.

There is one lesson I re-learn there every year, and this year it seems particularly relevant – because of AI, because people are lazy, because of my current client, because I see the same mistake being made again and again.

Almost everyone at EuroPLoP brings a paper, I certainly did. And we read each others paper – by the time I get there I have typically read over 100 pages in detail.

The conference exists to review these papers. As a writer I sit and listen for over an hour listening – only listening, no talking, no saying “you don’t understand” – as other people discuss my paper. It can be joyous, it is also hard and can be hurtful. The lesson I learn again and again is simply: the person who decides the message the writer is sending is not the writer, it is the reader. The same applies for speakers and listeners: it is the receiver not the transmitter who decides the message.

As a writer you may think you are clear, unambiguous and to the point. You may think there is no room for misinterpretation or ambiguity but you are wrong.

Every reader brings their own context, their own concerns, problems and priorities. Readers read into your paper what they want.

This lesson goes beyond my writing, it goes into my speaking and my presenting, from there into my leading, my enthusing, my nudging.

Ultimately, it is very hard for me – or anyone else – to tell anyone else what to do because it is the receiver who decides what they have been asked to do. (More next time.)

I’d love to see you at EuroPLoP and see you learn this lesson but few can afford the time – and energy – so take this short cut: always assume people will interpret your words differently. Strive to keep you messages simple. Explain yourself, ask other what they have heard and always, always, give other people the chance to say something so you can receive feedback. Without feedback you can’t correct and you can’t improve.

When the audience is important to you, when you actually care about them don’t just say “Any comments?” or “Does anyone have questions?” Instead, pause. Ask the person on your right what they think, then the person to their right, and go all around the circle. Don’t reply, let everyone have their voice and respect that voice.

You might not have time to do this too often but make some time to do it. When I do multi-day training sessions I usually do it each morning, or important meetings after a break or before we move to conclusion. Many people shy away from speaking so give everyone a moment to be special. Save your replies to the end.

My #1 lesson from Bavaria Read More »

Trapped in the system

Agile / /

Woody Zuill has a great catch phrase: “It is in doing the work that we understand the work.”

If you are like me your first response is to think about the problem domain: “The problem the customer wants solving is understood when we try to solve it.”. This certainly fits many of my client projects. When I was building electricity forecasting system it was by building the system that I came to understand how the electricity markets worked, how electricity was priced and how we could use contracts for difference to optimise spend.

Or when I was building telecoms software I came to understand how mobile phone network work and how protocols are wrapped in protocols, all the way down.

Complexity in the enterprise

Increasingly I see Woody’s maximum applying to the processes, authorisations, gateways, approvals that make up the way an organization works, or rather the way it think it works.

This was brought home to me recently when I went to visit a client’s offices – yes a physical visit! I was there with a dozen or so other consultants. This client took security seriously so as well as being on the guest list in advance we needed photo id and to pass airport style security.

Time consuming but it worked, in the morning that is. The problem came at lunch time. It was good whether so everyone left their bags, coats and gubbins behind – lunch would only be 30 minutes. As we were about to leave someone said “Do we need ID to get back in?”

Arh.

One of the hosts said “If you have it on your phone you are OK”

Someone check with the security guard: “If you came in this morning you are OK, you are on the system.”

Another said “Make sure you use the other entrance ‘cos you are registered.”

Needless to say, on our return, the other entrance wouldn’t accept us.

ID was demanded.

Digital ID was not acceptable.

Everyone needed to register all over again.

For a few crazy minutes it seemed I couldn’t enter the building to retrieve my ID to prove who I was to enter the building!

As it turned out: nobody really knew how the system worked. Not even the security people who were supposed to know. Everyone had an understanding but nobody really understood it until we lived it.

Rules, processes, procedures, …

It was Woody’s maxim: despite our efforts to understand the building access rules it wasn’t until we had to live them did we understand them.

The larger the organization the more rules, standard processes, formal procedures, authorisation and systems there are. To make it worse, almost every company is in a state of continual changes: new processes and rules are being introduced and others retired. Some people think one set apply while others see others say other rules do.

Last year I found myself observing a project spend authorisation committee. As the committee ran over its regular questions the project was asked about stage gates:

Committee: “I don’t see any stage gate clearances”

Product Manager: “We have not completed any stage gates because this project is governed under the new life cycle model.”

Committee: “We’ve never had one of them before”

Committee other: “I’m not sure we are allowed …”

It was only by living the processes that the process could be understood. (My recent queuing post touch on the same idea.)

You don’t need many different processes, and updates to processes, in play before it becomes impossible to understand the interplay of these systems.

At the start of my career it was the technology – the solution domain – which was the difficult bit. Understanding it, making it perform, the limits of what it could do. Today technology power is almost unlimited and you can, supposedly, just ask it for what you want in plain English.

Next in my career it was the ask – the problem space – which was the difficult bit: understanding what the customer wants, defining the problem to be solves, sizing the opportunity and achieving market fit.

That is still the problem in smaller enterprises – start-ups and innovative companies.

Now, I find myself working with bigger organizations and this problem is rampant. Such places have processes, ways-of-working, procedures, rules, the systems of doing work – plus tools like Jira and DevOps which impose more – and nobody knows how they all hang together. The only way to know is to live the process.

Such places are caught by their own demands for processes and procedure. Many of these reflect a unwillingness to trust staff, or a decision to decompose work between different roles: project managers, analysis, coders, testers, devop, security, architects, …

Complexity

Consequently complexity and costs increase. Faced with these problems it is almost pointless to estimate effort or budget, the system is the governing factor.

Nor is it any use looking for a boss to solve the problem. Managers too are prisoners of the system, worse, they are expected to uphold the system and encourage people to follow it.

Complexity breads complexity. For my money less is more, they need simpler approaches that can be understood and reasoned about.

Trapped in the system Read More »

Link feast: learning to learn, AI future and conferences.

Agile / /

I’ve been really bad at sharing things recently so have a glut of things to share. Take your pick.

Agile Ideas for our AI future: my presentation to Agile Northants in April, the video is now online and the presentation can be downloaded from my website.

As usual I’ll be at EuroPLoP in Bavaria this year, so if you want a very different type of conference please join us.

No presentations. No keynotes. In fact, no speakers.

Lots of discussion. Really learn about feedback, learn about writing and cutting edge ideas.

Plus enjoy games, sauna and outdoor swimming. Honestly, its a serious conference!

Perhaps more importantly, my paper from EuroPLoP 2025 Learning to Learn: Patterns for Building the Learning Organization is now available either from my website, or, if you like a more formal version from Springer Nature.

Still on conferences, I’m delighted to announce I’ll be at the Oredev Developers Conference in Malmo again this November.

It is four years since I delivered the keynote there and this year I’m giving two talks in the main programme: Ideals shaping our AI future and The Good, the Bad and the Ugly of the The engineering mindset.

Finally, as some of you already know, I quietly released my first online self-paced course with LeanPub recently: Long term Product Goals for creating superior products. Subscribers who use this link, or simply use the code SubscriberJ26, can get 30% off.

Link feast: learning to learn, AI future and conferences. Read More »

Leading like you row a boat

Agile / / / ,
Person rowing a boar

I have this mental assumption that I can’t tell anyone to do anything. Some of that is rooted in me – I don’t like being told to do things! Some because I’ve rarely held a position where I have direct authority over anyone. And mostly – I like to think – because I respect others and I think everyone does their best work when they choose to do something.

Two oars

Hence my mental model of leadership is a rowing boat. There are two oars and you need both. One oar is marked authority and the other leadership – although I think of it more as inspiring and motivating people. I’m not big on authority, I don’t like people having authority over me so I don’t like using that oar, I work mostly with the other one.

Perhaps this is because of my early leadership experience… back in my 20s I was active in my local politic party, but it could have been almost any local voluntary group. Nobody was paid, everyone gave time freely because they believed in something and wanted (political) change. Mostly this seemed to involve sitting in an old hall and listening to someone talk about the way things should be.

Young and enthusiastic I was quickly made branch secretary. I got to sit at the front, with the local chair. I had power, I controlled the agenda. I was responsible for getting leaflets delivered, writing and distributing minutes (I tried e-mail but few people had it then), completing forms for party HQ and so on. Leg work. I was a leader I was very much the servant of the party members.

No authority

I needed help in my work but I didn’t have the power or authority to tell anyone to do anything. It was all optional for everyone. All I could do was ask for help. If I made my case well, or got people into habits, I would get more help. If I’d been interested I could have started to crawl my way up the political ladder but I decided not to.

In my mind, getting people to do something means asking them for help. It means setting out what needs doing and asking for volunteers. It is about appealing to what they want and showing them how it could make the world, and their life, better. It can mean inspiring people to do more – in my 20s I wasn’t very good at that but I observed how others could inspire me.

In my career I have seldom held positions which give me really access to the authority oar. Most of my career – as a coach, trainer, speaker, advisor/consultant – I set out what might be done, what needs doing, and then people have the choice to help, or not.

Enrollment

My thinking and logic is massively influenced by a 1992 paper I first read in 2003: Enrollment Management, Managing the Alpha AXP Program (IEEE subscription required, free in Digital Technical Journal, 1992.) It might be old but Peter Conklin’s paper deserves to be better know.

I take this thinking into the way I work and the way I try to bring change. Anyone who has done training with me will know, my sessions usually finish with a dialogue sheet exercise were people and teams decide what they want to do.

In my mind when I do training sessions I’m doing two things: 1. I am letting people practice new ideas. 2. I am laying out a stall of things that might make their work – and their lives – better. Of course, all the way through I’m trying to motivate and inspire them to try the new ideas. Then at the end I say “Of all the things I’ve talked about: which do you want to do?” I step back and let the sheets collect the actions. My sessions have a pretty good record of creating change and I’m convinced giving people choice is a big part of that.

One session in the Netherland stands out in my memory more than any other. The team on one table listed what they wanted to do and finished by saying “If our managers will let us”. I turned around to face a table were the managers were also doing the exercise and said “Andre, can they?”

Authority shy

So when I’m put in a position where I do have authority it is not automatic for me. I shy away from telling people what to do and hate assigning work. Its nice to know I can fall back on that, and my requests for volunteers are probably received differently when people know I can use authority, but I really don’t want people to do what they don’t want to do.

Hence the rowing boat metaphor with an oar each for authority and leading. I’m rowing with the inspiration oar. (Of course, the metaphor breaks down because you can’t row a boat using just one of two oars but hay ho, the model works for me.)

Let me know what you think. I’d love to know if I’ve struck a chord with others.

Leading like you row a boat Read More »

Lessons from war: change, command and product development

Agile / /

For the last four years I’ve been saying: “There will be some interesting papers written in future about Ukrainian strategy and command.” While I had hoped for peace and serious studies by now neither has occurred so let me start.

The change paradox

First, remember that the protagonists started in the same place in 1991. While they both changed a lot over the following 20 years they retained much in common. As I understand, it was less than 10 years ago that Ukraine set about modernising their army and moving away from Soviet style command-and-control.

Yet in that time Ukraine moved from a very hierarchal structure to mission command (next up). Importantly, they have done this under intense pressure: they were at war.

I have seen this change paradox many times. Everybody knows “the time to fix the roof is when the sun is shining”. The problem is, when you have time and resources to change and fix things the motivation is low. When times are tough the resources are limited but the motivation is high.

My heart sinks when companies tell me: “We want to make this change but right now we have an urgent project to finish.” They should be thinking “This urgent project is the reason to change how we work.”

Mission command: Leadership for agility in battle

“Frequent and rapid decisions can be shaped only on the spot according to estimates of local conditions.” Moltke quoted by Tetlock

One side: big, powerful, well equipped with a strict command and control approach.

The other: small, under equipped, few plans, responding to what happens.

Everyone expected the bigger to win in days but the smaller one repulsed the attack. A small team out performs a larger team.

The difference was mission command: a philosophy that gives commanders a mission, an objective, an outcome and lets them decide how to achieve it. This has been American doctrine since the 1980s and asks the local leaders to : “think. If necessary, discuss your orders. Even criticize them. And if you absolutely must … disobey them. … Clarification of the enemy situation is an obvious necessity, but waiting for information in a tense situation is seldom the sign of strong leadership—more often of weakness.”

American doctrine became NATO doctrine became Ukrainian doctrine. Perhaps troublingly, America didn’t invent the idea, they took it from the Wehrmacht. Auftragstaktik as it was known lead to victories in the early years of WWII but was later undermined by leadership who involved themselves too much.

(The quotes are from the best introduction I’ve read to mission command, Philip Tetlock’s book Superforecasting.)

Product Development: Drones

Like computers, airplanes and radar before them the pace of drone innovation and manufacturing on both sides is a sharp reminder of how war can drive rapid innovation. Ukraine in particular stands out as a world leader, perhaps the world leader, both in drone innovation and battlefield tactics with drones.

Ukraine stands in sharp contrast with western efforts which, while not insignificant, are very much in a peace time mode. An increasing number of start-ups are bringing modern digital product development skills to bear but since the major customers are still in peace mode even these are frustrated.

A few years ago I met a team building a weapons system. The first systems test was two or three years off. When I asked why they couldn’t do it sooner they looked at me as if I was mad “too expensive, we can’t just blow up an expensive prototype.” So every decision was considered, reviewed, re-examined, and took time.

They would say they were saving tax payer money but I saw a waste of money because they were trying to learn (slowly) on paper. (I asked about digital tools: another, disconnected, group.)

As I keep saying: engineers engineer within constraints. For the legacy armaments suppliers the main constraint is Government funding, not just the amount of funding but the strings that come with it. Before any money is spent all sides need to show that the money is being spent wisely, fairly, and that no unnecessary money is spent. This results in procurement and approval systems which are themselves long winded and expensive to operate – queuing again.

War changes the constraints, now time to market – time to kill – is more important than saving money. Test and learn opportunities are plentiful. Fear of a failed test, or wasted money is less than the fear of defeat. Money hasn’t gong away, but it is not saving money in development, it is reducing cost of manufacturing.

As always: there is more than one way to solve a problem and the constraints determine how you go about solving the problem.

Put it all together

Ultimately all these three examples are about learning and acting on that learning. Most learning occurs early on. Planning is learning but so is doing. Plan a little, do a little, learn a little, keep iterating.

Motivated people, devolved authority, clear constraints and a need for action. Isn’t that what every team would like?

Perhaps it is also a check list:

  • Are your team motivated?
  • Is authority close by?
  • Are the constraints clear?
  • And is there a need to act?

There is going to be more to learn from this war but lets start with that checklist.

By the way…

One of my pet hates is “what we can learn from the military” talks when the speakers have no military experience. I’m breaking my own rule here. In my defence, I do have a little first hand knowledge of both countries and peoples, I’ve a little contact with British military industrial complex and I read some credible sources (e.g. The Economist.)

Lessons from war: change, command and product development Read More »