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.
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.
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.
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.
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.
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?
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.
1) My OKR Writing workshop is back on October and is booking now. This time I’m running with the help of my friends at Avanscoperta so all ticket bookings are through their platform.
All the details – and a discount is on the Avanscoperta website – where you will also find a recording of a OKRs webinar I ran last month.
In short we look at what makes a good OKR and what makes a bad OKR, then we get people writing OKRs and move the discussion onto how to measure key results. Simple really.
2) Meanwhile, I appeared on the Agile in Action podcastlast week and discussed how to introduce OKRs, how to use OKRs and my famous call to “Nuke the backlog”.
I keep hearing about the need to raise productivity on the radio – well, here in the UK we have a new government and raising productivity is one of their big themes. So I sat down with my pencil and paper and put a few ideas together which I thought I’d share.
It is actually quite difficult to pull out a stand alone “do this and you will be more productive” type thing. As many have said before: there are no Silver Bullets – or at least very few. Still, there are things you can do and there are people, like me, who are more than happy to help.
Before I get stuck in it is important to say is: measuring productivity by output can often mislead. More output isn’t necessarily more or better outcomes. Outcomes can be complicated things to pin down. While we can’t put a financial value on everything examining the money can be a short-cut. To complicate matters, sometimes doing less, even producing or doing nothing can raise value. Think of all the features Apple leaves out of its products which increase their value, or think of software bugs you don’t write. Fixing bugs can increase your output, and therefore your apparent productivity, but not having them in the first place give the customer a better outcome.
Now some thoughts…
1. New technology demands new ways of working
Sometimes you can buy a new machine which increases productivity – like the handheld food processor in my kitchen. This saves me a lot of time cutting up onions. But more often than not to get the full benefit of new technology you need to also update the way you work, the processes and practices.
While a machine may increase productivity there are almost always more benefits, more productivity, to be had if you change the way you work. This is true everywhere, and its why I’m having more conversations about how non-technology companies, often small companies, can benefit from adopting modern “agile” management ideas.
2. Do less to produce more
I feel like a broken record but again and again I see companies which would produce more if they tried to do less. In other words: Reduce work in progress.
The mantra is: Start one thing, do one thing, do it to the end. Then, only then, start another.
Time and time again I see companies, teams, and people which are simply trying to do too much at anyone time. The trick is to sequence them. If this describes you than please watch the Featureban video I released a few week ago.
3. Visualise, understand then improve your work
There are few single shot improvements to be had but if you spend time understanding your work, tracking it with a visual management system, collecting some statistics and analysing where the time goes there are always things you can do to improve it. Chances are time (and therefore productivity) is not lost because one step or person is slow, rather there is an impediment in the flow which needs fixing.
If you don’t already have one then create a visual board to see your work. I’m a big fan of physical boards but I accept most teams today want something online so I recommend KanbanZone.
Now I could talk and talk about how to set up such a board and I will happily do so if get in contact – but if nothing else create one and get everyone’s views on how to use it.
4. Separate work by variability and duration
Once you start to understand your work you will most likely find that there are different kinds of work take different amounts of time (answering one e-mail is quick, writing a blog takes time) and variability (most e-mails are quick, but occasionally one takes hours). Using this understanding you can separate the work into different streams and plan your time around the streams. This will increase productivity.
5. Sacrifice one person
In some cases it makes sense to “sacrifice one person” to do the seemingly random, late breaking, small pieces of work which so often arise. The rest of the team can then focus on the bigger, time consuming, stuff. Of course, make sure you rotate the sacrifice every week or two.
6. Daily reprioritisation
I start each day by rewriting my priorities. With clients I sometimes have team leaders review all team priorities at the start of the day (just before the stand-up meeting if you have one.) That might not mean you produce more but it should ensure the most valuable things get done which will increase productivity.
Now I could write a long list on Monday and work with that. But actually, taking a few minutes each day to go over priorities – even if they haven’t changed – is more productive.
Overall…
I’m sorry to say, these options might require investment and time. Chances are the most obvious productivity enhancing options have probably already been used up. So some time, and perhaps money, need to be invested. The good news is that your accountant should be able to capitalise expenditures so your net value increase.
Of course, the sooner you start the sooner you get the benefits. This is where I might be able to help so let me sell myself for a moment. I’ve helped many companies over the years improve the way they work so please get in touch.
I’m running a little survey – 5 minutes of your time – about the people and roles who decide what should be done, or perhaps what should be built. The people who are often called Product Owners or Product Managers, and often Business Analysts, perhaps Requirements enigneers or… a myriad of other titles. I’m generically calling these people Product Leaders or Product Authorities.
Anyway, if you can spare me 5 minutes it would be grate to have your answers – survey is here, just a few questions.
I recently stumbled across David Rogers’ book The Digital Transformation Roadmap and found myself nodding in agreement with page after page. Many of the points and arguments Rogers advances are expressed in my own Continuous Digital, I see two differences. First off Rogers is an established academic at Columbia Business School, so he approaches the topic with rigour. Second, he tackles the subject from a digital business starting point, Continuous Digital grew out of the agile and #NoProjects movements. Still, they end in the same place.
One of his models keeps coming up in my discussions with Product Leaders again and again, he calls it the Rogers Curve. Like I do in Continuous Digital he points out that the venture capital industry funds technology products very differently to corporations. A corporation minimises risk by doing lots of up front research, validation and planning. Then, if everything checks out authorises big expensive projects. When things go wrong (because the research missed something, validation was flawed, plans were too optimistic, delivery was more difficult than expected, or, importantly, the time spent making sure the money wasn’t misspent delays the work so much it has lost value) then it is difficult to cancel work because the momentum is high.
Conversely, venture capital firms invest far smaller sums of money on far less evidence, research and planning. Additional funding is only given if ventures make progress on validating the model and delivering. VC firms offset risk by placing many “small bets” which they expect to lose. As long as a few bets succeed big they will make money overall even if they lose most of the time.
In Continuous Digital I argue that all technology work should adopt this model. Rogers suggests something slightly different. His Rogers Curve combines the two. He says: when uncertainty is low then use the traditional project model with the upfront validation. However, when uncertainty is high then use the VC model.
Uncertainty might come from using a new technology, entering a new market, creating a new product for an existing market, or some other source. Naturally, certainty comes when none of these is true. Which begs the question: “why bother?”
Remember that much uncertainty is actually risk. According to economists: profit is the return for risk. If you eliminate the risk then eliminate the profit.
Imagine for a moment you see a market opportunity. You see that existing technologies can be repurposed to meet this opportunity. You easily ascertain that potential customers want the product and will pay. Best of all, you see that little work is needed to seize this opportunity. The stars align. You are in business. But, if you can see this opportunity and how to fill it the chances are others can too. If they haven’t already done this then they can quickly copy you. You have no defence from competitors. No risk, no reward.
Back to the Rogers Curve. This provides a great way of looking at future work: do we feel safe? Yes, then big up-front investment. Or do we feel uncertain, exposed to risk? In which case give it a little funding, review and refund often. And be ready to walk away.
One problem I do see with the curve is the “But we know” problem. Specifically, I remember one executive sitting opposite me and saying “We know what needs doing. We know who are customers are and what they want.” Needless to say they didn’t. The company became a lot more successful when they started acting as if they didn’t know (and sacked that executive.)
This happens all the time. People and companies are sure they know what is wanted – cognitive biases are at work. Version 2 technology rewrite projects are a classic example. These always have big problems. There is an assumption that the “only thing” version 2 needs to do is everything version 1 does, just on new technology. These projects always end up in trouble (but that is another post.)
Part of me thinks this curve is unnecessary because the little-and-often funding model will work in a certain world just as it works in the uncertain. But, corporations aren’t set up to work like that. Corporations are set up to fund and run big projects with lots of upfront work. In other words: corporations are not optimised at doing lots of small.
Jumping to a new model in one go is hard. Far better for the corporation to carve out some innovation money and a ring fenced a unit to spend the money. Call it an innovation unit, a lab, an incubator or whatever. Within this unit manage investments differently using a VC-style governance process. The money needed will be far less than one big traditional project to start with.
This unit can accept small innovative ideas with little market research, validation or planning. The minimally viable teams which are funded here are tasked not just to build the thing but to validate the ideas, exploring options, understand potential customers and everything else a start-up would do.
Now at this point some readers will be saying “We do that.” As Rogers points out, and I’ve seen myself, companies do do this but only sometimes. They don’t do it systematically. Nor do they do it repeatedly. Running these types of initiative, and more importantly governing them, is itself a skill set and process which needs developing itself.
Many companies can point to instances of innovative products managed in an innovative way. But such initiatives have to fight through a system which is designed to stop them. They succeed despite the system not because of the system. How much more successful could the company be if it created support mechanisms?
