The Last Target Operating Model You’ll Ever Need™

I first wrote this as a comment on Joel Bailey’s excellent blog post titled ‘This thing called agile might kill us all’ but thought it worth re-hashing and expanding here.

For context, Joel writes about “working for a big high street bank. The brief is to redesign the ‘end to end mortgage experience’. The timescale is to reach a business case, with a roadmap of delivery waves to achieve minimum viable product, within 6 weeks. ”

He floats the idea of a Target Customer Experience as counterpoint to that change management staple, the Target Operating Model.

I’ve had recent experience with a “TOM”, attempting to intercept with an agile, digital project. It left me puzzled, and I’m grateful to Joel’s post for helping me clarify my unease.

In case you haven’t come across one before, the TOM is a Thing in the world of “change management,” defined on Wikipedia as:

a description of the desired state of the operations of a business. Typically a TOM also includes the roadmap over time that specifies what the company needs to do to move from the “as is” to the “to be”.

For the service designers among you, a typical TOM covers similar turf to Alex Osterwalder’s Business Model Canvas, only with fewer sticky notes and more spreadsheets.

As an aside on his nascent agile project, Joel writes about the toll it takes on participants:

someone needs to write a Marxist evaluation of agile. Yes the outcome is better and it’s all very sexy and new and ‘oh so right’, but I suspect the cost on the worker is high as essentially it speeds production and works the asset of production (you and me) harder.

… which immediately set me thinking that if people are using “agile” to mean doing the same process only faster, even at the risk of burning out their people, then they’re Doing It Wrong.

I reached for the 8th of the Agile Manifesto Principles:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

And that’s when I realised the real challenge to peddlers of TOMs and the like: agile transformation isn’t a one-off thing that you do to get from A to B – it’s a continuous culture of iterative improvement.

Agile organisations succeed through sensing, not planning.

  • They are in touch with their actual customer experience (not just some brand fantasy). This is the dirty secret of much Target Operating Model work. A warts-and-all “as is” picture is far more valuable than any amount of “to be” prognostication – but even if that’s what executives secretly wish for, no consultant can afford to say out loud “I’ll tell you the time if you show me your watch”. Sadly the picture TOM processes do generate is often missing empathy, the key ingredient that spurs the organisation’s people on to make things better for their customers.
  • They truly understand their operating model (clue: it won’t look like a flow chart). Organisations are nothing more than systems made of, and by, people. They’re complex social constructs that operate on emotional as well as financial planes. This is what agile understands when it says “individuals and interactions over processes and tools”. To map an organisation by decomposition is to follow in the footsteps of the early Cartesians, dissecting a dog to prove it has no soul.
  • They have the capacity to make very frequent adaptations in response to their ever-growing understanding of customer needs. Being able to respond quickly to what you learn beats any amount of predicting and planning. Embracing diversity means pushing decision-making to the frontline. This in turn reduces the waste inherent in standardised processes. Let’s cultivate this as a core competency of every organisation. If we never get stuck in a rut, we’ll never require a “change programme” to jolt us out again – and that should come as a relief to all concerned.

All of this poses problems to an organisation addicted to discontinuous change. We’ll have to break down the Berlin Wall between the bits of an organisation that create “strategy” and the bits that do “operations”. Likely, product development can no longer be capitalised, so the balance sheet might appear worse before it gets better.

But I’ve come to the conclusion that this is the only sane way to run an organisation.

Learning by doing: it’s the Last Target Operating Model You’ll Ever Need™

Three things a city in charge of its destiny ought to know about software

2015 promises change in the way that Leeds, Yorkshire and England’s north are governed. Not before time, decision-making and funding are to be brought closer to us, to the cities and localities where we live, learn, play and work. This new settlement will arrive at a time when cities and governments everywhere are challenged to design and deliver service differently. It also comes just as, in Marc Andreessen’s words, software is eating the world.

Over my Christmas break I’ve been thinking about the malleability and abundance of software; what this looks like at the scale of a 200-year-old post-industrial city; and how it should shape the ways we decide and deliver things together. This is the first half of a 2-part ramble. Part 2 (still an outline in my drafts folder) will probably look at the structuring principles of the internet and the web, and how we might apply them at city scale. But before I can get to that story, I want to tell you this one: three things a city in charge of its destiny ought to know about software…

Light Night 2014 - Some rights reserved by CarlMilner

1. The clue is in the name

The first thing to know about software is… it’s soft: the opposite of hardware, malleable, endlessly changeful. When we shift the dominant logic of a thing from the hard layers to the soft we open it up to unpredictable new uses and reuses. We move from a world where things must be finished before use to a swirl of beta versions, A/B tests and updates on the fly.

  • Google repurposes links between pages as votes to rank websites’ authority, and in so doing grows a multi-billion dollar business based on an algorithm tweaked constantly to stay a step ahead of the SEO industry it has spawned.
  • The half-finished world of Minecraft is released missing its game mechanics and becomes a sandbox for the imaginations of millions of children.
  • Strangers collaborate to make Wikipedia at a pace of 10 edits per second across 4.6 million articles in the English version alone.

Massive though these software-driven behemoths may seem, they exist only as long as people choose to interact with them: the moment they stop moving, they begin to wither away. Remember Friends Reunited? Microsoft Encarta? The Yahoo Directory? Software facilitates the delivery of service in the moment, with value created at the point of use. It does not produce assets that can be hoarded in a warehouse or on a balance sheet.

This service-dominant logic of software poses a special challenge to the traditional imaginings of the world’s first industrial cities, synonymous as they are with unprecedented accumulation of hard, fixed capital. Here, the newly rich industrialists staked their claims on history’s grand sweep with facades designed to endure for centuries. Victorian navvies raised 18 million red bricks high above the River Aire so that 21st Century trains could rumble right into Leeds city centre. Little wonder that when today’s businesspeople and politicians want to symbolise a northern revival they reach first for the nostalgia of industrial museums and commitments to big infrastructure projects. This is, however, a misdirection that we need to avoid.

Leeds Brick Man maquette - Some rights reserved by nualabugeye

I’m a sucker for steam engines, but there are other stories that we should surface if we are to make sense of the era of software. The history of city after city is that people settled first, and shaped the infrastructure around them afterwards. And while they were waiting for the mod cons to arrive, they had to figure out how to get along together, how to raise the next generation, how to look after the old, sick and poor. To organise service for so many people demanded new forms of social software. The first mutual societies, trade unions, public health boards, and even modern local government arose first in cities like Leeds. Keep hold of those stories. Seek out more of them.

Surrounded by very concrete ruins, we overlook the intangible skills and habits of service that remain intact here. Let no one tell us that service is a new concept for the formerly industrial cities – it’s what we were doing all along. Renewing our cities in the 21st century should be more about these things – the soft, changeful ones – than about hard, physical infrastructure projects.

2. There’s a lot of it about

The second thing about software is abundance. It is infinitely copiable, an embodiment of human knowledge. The more it is shared, the greater its utility. Every day, more is added to the store of freely available code. When the team behind GOV.UK released their code on Github they enabled the people of New Zealand to re-use it for their government website, at no cost to British taxpayers. Indeed we Brits may even benefit further, if the New Zealanders improve on our code and share it back with the world.

Leeds Santa Dash - Some rights reserved by Old Bluebeard

Not only is software plentiful, but so, increasingly, are the skills needed to create and use it. In Leeds alone there are thousands of people working in-house with organisations and across digital agencies and service providers. Our universities and colleges train hundreds of students in software disciplines. Moreover, in almost every office there are people without this formal training who can wrangle a spreadsheet or paste in some HTML formatting. There are people who go home from day jobs which have nothing to do with software and spend their evenings running websites for their football clubs or churches.

This is how platforms are made in the age of software, not by fiat of a central authority but emergently with layer built upon layer in response to the needs of users and the growing capabilities of makers. As platforms build they can raise everyone up to levels of attainment previously only available to a privileged few. They don’t so much lower the barriers to entry as help us to scramble over them – by wrapping up what used to be hard in easy-to-use packages.

  • Freeserve pioneered a pay as you go model that made dial-up internet accessible to millions of Britons.
  • Blogger, Typepad and WordPress made everyone a writer on the web.
  • Ebay and Paypal made everyone a seller who could accept card payments.
  • Satnav endowed everyone with the knowledge of a London cabbie.

Software in all its abundance can and should be made accessible to all in our city, without mystery – but this is not something that happens by default. There are players in the software world who don’t want you to know about abundance. They seek excess profits in the gaps where people haven’t yet cottoned on that something formerly hard and expensive has now been rendered easy and cheap. Before you know it, a major systems integrator is charging the government £30,000 to change a logo on a webpage.

At the height of the early noughties DotCom boom, I knew the game was almost up when I met a consultant whose business card proudly declared “Because It Really Is Rocket Science”. It wasn’t even then. It certainly isn’t now. As cities, we should demand platforms that raise the knowledge, confidence and capability of all our citizens, without leaving us in hock to snake oil salespeople.

3. Don’t ask if it will scale

“Yes, but will it scale?” is a common challenge when evaluating the commercial potential of a new service. I’ve come to believe this is the wrong question. Focusing too soon on scale leads us down the road of the lowest common denominator. In my private sector career I’ve seen multinational companies blow millions of euros and lose market share because of global “solutions” that were wholly inappropriate to the realities of business on the ground. I’ve seen the error compounded by bending good local services out of shape to spare the embarrassment of the people who specified the wrong things from the centre.

The so-called economies of scale claimed for big IT solutions turn out to be largely illusory. Their business cases begin with wrong-headed, goods-dominant accounting copied from the world of manufacturing, where buying stuff in bulk really can be cheaper. Wishful thinking by people remote from the frontline carries these projects forward unchallenged. But by the time complex shared services have been tailored to the needs of the people and teams who use them, they can actually increase costs substantially.

This is an important point to understand when thinking about efficiency at different levels of government. We should be suspicious of those who tell us that devolution will lead to duplication between cities. Given that software is cheap and abundant, duplication is the least of our worries. In fact, two neighbouring cities doing things in slightly different ways would present a wonderful way to learn what works in each context. We should resist pressure to merge IT services between neighbouring authorities – that would dilute quality as well as blur democratic accountability.

revengance on aire street - Some rights reserved by Johnson Cameraface

Instead of asking “will it scale”, ask a better question: “Does it gracefully handle massive diversity?” The old paper form to claim Carer’s Allowance handled the massive diversity of people’s caring needs and relationships, but it did so gracelessly – by asking many questions not relevant to all carers. By doing user research, and diving into the detail of the application process, the digital exemplar team were able to remove 170 questions from the application process and structure the service so that users are only asked things relevant to them.

This is not to say that scale doesn’t matter. Rather, understanding diversity is the better starting point. The diversity question accommodates scaling; the scaling question tramples all over diversity.

Our cities are havens of diversity (not that you’d know it from the white, male, middle-aged-dominated board of our local enterprise partnership). The only way to understand and serve diversity is to go and see the users, learn what really matters to them and start to meet their needs. The good news: with software eating the world, with its inherent malleability and abundance, there’s never been a better time to get out of the bubble and do just that.

Postscript – a couple of days after I published this, JP Rangaswami posted a beautiful piece on his blog. I can smell the printer’s ink too: Bureaucracy as a platform? The power of diversity

On wellbeing in a smart city: when I hear the word dashboard…

On Friday, a group of us spent a couple of hours chewing over the question of wellbeing; specifically wellbeing in a smart city; more specifically still wellbeing in a smart city that happens to be coterminous with the Metropolitan Borough of Leeds.

We were talking about this stuff thanks to Tim Straughan and the “Smart Cities – Health and Wellbeing Leeds Task and Finish Group” whose draft report bears a lofty ambition to (deep breath!)…

make every asset count, remove certain existing legal barriers and commercial obstacles and develop new financially sustainable business models using a range of possible new institutions engaging a workforce with enhanced skills and empower our citizens and work with our local communities to deliver a shared goals.

Let’s not go into the overall definition of a smart city. I take it as read that most of us prefer some messy, inclusive, people-centred flavour, over the proprietary techno-utopias pushed by naïve systems integrator business development teams.

Let’s also not dwell here on the health side of the report, which if anything is too dominant. Jon Beech made a shrewd point about the root causes of frustration with our fragmented health service – and questioned whether more data, better understood and shared, would really address them.

Some fantastic wellbeing ideas came up in our discussion, especially the little oddball things that nevertheless speak of bigger integration challenges – special hat tip to Paul Simkins, what if a GP really could prescribe her patient a tree?

But the session wasn’t easy. As a Brackenist, I found the level of abstraction in the published draft report frustrating. Some of the solutions it contained didn’t seem very well adapted to the questions that were posed.

My hunch, expounded below, is that the response should be made of lots of small, practical experiments, plus a set of qualities, habits and behaviours that would make our city emergently smart. There are no dirigiste, politician-pleasing big ticket prizes to be won on this stall.

I felt we edged forwards, and afterwards I jotted down some thoughts in a personal manifesto. I numbered the points. It goes up to 11.

Manifesto for wellbeing in our smart city

1. Wellbeing is subjective. There is some fascinating work among statisticians in this area but the actual definitions remain more art than science. In the words of National Statistician Jil Matheson, “We must measure what matters – the key elements of national well-being. We want to develop measures based on what people tell us matters most.”

2. Wellbeing is socially constructed. It cannot be sustained in solitude. When two people meet, the first question is invariably “How are you?” More often than not, the answer comes, “I’m fine.” And yet both parties are acutely tuned to minute delays and inflections to know when “I’m fine” does not mean “I’m fine.” Cities – consciously smart or not – are settings where wellbeing is co-created every day.

3. Wellbeing is a moving target. It weaves in and out of work, play, learning and health. It tumbles up and down Maslow’s hierarchy of needs. It follows economic cycles and the fortunes of football teams. Wellbeing is a complex system. As W. Edwards Deming revealed, you cannot optimise a system merely by optimising its individual parts. We need a holistic view, but…

4. The word “holistic” begs the question of unit. A whole nation? A whole city region? A whole neighbourhood? A whole family? A whole person? A whole lifetime? A whole lunch-hour? I’m inclined to think we should start with individuals here and now, then work our way outwards, not the other way around.

5. A smart city would broaden its options. Its people would think beyond obvious wellbeing measures and narratives. It would draw in a larger number of actors and create more spaces for them to try new things. The high degree of uncertainty demands collective thinking and action research to better understand the territory.

6. Dashboards don’t do this. In fact they’re a design pattern for narrowing options down. In a car this is great – literally a lifesaver. We know where we’re going and need just a few well-understood metrics – miles per hour, revolutions per minute – to be sure things are working as they should. More than this would be a distraction, and most of the time we want to keep our eyes on the road, not on the dashboard.

7. An asset map is a much better metaphor. On a map, new information can be plotted. Multiple destinations and routes can be considered. There’s a big difference between a map and a dashboard. An asset map would increase the number of actors – so long as it could reach out beyond the usual suspects. The conversations inherent in creating the map would themselves change the territory.

8. New institutions are no sort of solution (though they may be an outcome). Organisational boundaries are what got us into this mess in the first place! If they constrain new approaches, we should set people free to do their best work regardless. New institutions may later emerge, to formalise working practises developed by empowered people. But creating new institutions to make up for the failings of old ones would be putting the cart before the horse.

9. Let’s take a user centred, agile approach. Let’s start with needs* (* – user needs, not government needs!). User needs for wellbeing will be many and varied. Some will be in conflict with others. If they’re not, we’re doing it wrong. Create a multi-disciplinary team (not a steering committee). Give them time and space. Let them try some things. Tell everyone. Iterate wildly.

10. If this is our devolution moment, we are woefully under-prepared. But that’s OK. Taking control of your destiny is not something for which one can plan a great deal. We’ll just have to do it, feel the weight of responsibility, fail fast, raise our game, start to improve. We can’t do much worse that the vacuum of ideas we’re replacing.

11. Cut us some slack. Learning to be a smart city demands that we put diversity ahead of efficiency. People can’t learn unless they can take some risks. There has to be slack in the system. Without that, the stakes will be too high for the iterative process that leads to new learning. One day we may get to a dashboard, but first we need to make the map.

Real work only begins when we break out of our bubble

David Vetter's space suit - Wikimedia Commons

“Boy in the bubble” David Vetter passed his life in a sterile enclosure breathing purified air and touched only with plastic gloves. While his parents and doctors attempted to make his life as normal as possible, they lived in fear of the tiniest exposure to common impurities and infections. He died aged 12 in 1984, after a bone marrow transplant given in the hope of building up his immune system.

Most of us can be thankful that we don’t live with a severe combined immunodeficiency like David’s, a condition so rare that his life inspired a John Travolta movie.

Peggy Noonan later brought the image into political parlance when she spoke about Ronald Reagan’s isolation in the White House…

“Do you ever feel like the boy in the bubble?” Ms. Noonan asked.

“Who was that?” Mr. Reagan replied.

“The boy who had no immune system,” said his speech writer, “so he had to live in a plastic bubble where he could see everyone and they could see him, but there was something between him and the people, the plastic. He couldn’t touch them.”

“Well, no,” Mr. Reagan said.

Then he thought it over: “No, but there are times when you stand upstairs and look out at Pennsylvania Avenue and see the people there walking by. And if I wanted to run out and get a newspaper or magazine, or just to walk down to the park and back . . . you miss that, of course.”

— William Safire, ‘ON LANGUAGE; The Man in the Big White Jail’

In medicine and politics, we pity people with this condition. Why then do we so often go to work as if in a bubble ourselves, cut off from human contact with users and the people who deliver everyday service?

  • Days and weeks of work are put into consultation documents, leaving only a narrow window for citizen feedback on a limited range of pre-defined questions.
  • Executives employ management consultancies to spend months putting together process models and business cases unchecked by exposure to the realities up on the shop floor.
  • Some organisations become so afraid of their customers that unmediated face-to-face engagement with the public requires a risk assessment, as if it were primarily a health and safety issue.

Let’s call this mode of operation “bubble work”. Like failure demand it’s a major source of waste and poor service in our society.

Bubble work is a waste of our own time. We think we’re being clever, applying our past experience, creating a good framework for activity. But until our guesses meet the real world, that’s all they are, guesses – when we can so easily go and find out for sure.

Bubble work is a waste of other people’s time. Every time we create a “straw man” or a “starter for 10″ we shuffle the burden of understanding onto other people, who are then obliged to unpick our web of assumptions before they can share their own realities.

Bubble work depresses quality. The more we elaborate and decompose our untested reckons, the more they crowd out the new ideas and innovation that we would discover from interacting with users and frontline workers. As designer Mike Laurie says, untested ideas are excess inventory.

Bubble work comes back to bite us. It can only ever defer the moment at which our cherished ideas meet the messy complexity of the real world. But the encounter is all the more painful when it comes. Not only are we more invested in the bubble work, we have less time to deal with the consequences.

I know all these things because over the years, I have lost months of valuable project time to bubble work. I have made complex multi-year business cases built on the tottering edifices of “expert” assumptions. I once worked on a project so super-sensitive that we were forbidden by lawyers from researching it with potential customers. Neither of those things worked out well.

We see this damaging pattern equally in the private and public sectors, and while it’s often a big organisation malaise, so-called “stealth start-ups” can easily fall victim to the same fallacies. The world is awash with bubble work, and it has to stop.

Here’s how…

Every time we’re tasked with a new mission, let’s start the clock. Let’s see how fast we can get to users. At Leeds GovJam every team achieved this within 24 hours. They surprised themselves by drawing up questions and making prototypes to get meaningful insights from people on the street – and came back with their ideas re-shaped by potential users.

While working even briefly in the bubble, let’s be single-minded about bursting it. We should stamp all our assumptions as such, and always be thinking of ways to test them with actual users. Every statement we write at this point is a hypothesis to be accompanied by the questions we’ll ask to check whether it’s true.

When we spot others doing bubble work, we must call them out. Let’s ask how they know what they know, when they last spoke to users, and what took them by surprise. If their answers are unconvincing, we should not be enablers. We should spend not a moment more of our days engaged with their assumptions.

Doing these things may feel like a risk. It may feel like we’re slowing things down, but the payoff later will be consistency of pace. It may feel like we’re undervaluing our experience, but the reward comes when we keep on learning and deepening our expertise in an ever-changing world.

We are not David Vetter; we are not Ronald Reagan. Getting out of the building has never been easier. It’s time for zero tolerance of bubble work.

Get out of the building

Sink or swim: a short story about failure demand and first world problems

swimming lesson direct debit terms

My local council wants me to set up a direct debit to pay for my children’s weekly swimming lessons.

When I arrive at the leisure centre one Saturday morning, I’m handed a paper form asking for bank details, plus the names and details of my children.

Paying by direct debit sounds like a good idea to me, and I’m happy to sort it out there and then. So I start to fill out the form.

But there’s a problem: I have 3 children, and the form only has spaces to list 2 of them. I go back to the reception desk and ask what to do.

This is failure demand, a concept defined by systems thinker John Seddon as ‘demand caused by a failure to do something or do something right for the customer’.

The leisure centre worker hands me a second copy of the same form and asks me to write the youngest child’s details on it. I do this and hand both forms back to reception.

Time passes.

Several weeks later I receive 2 identical letters, in separate envelopes, reminding me that the council is moving to direct debit and advising me that I need to fill in a form.

It’s not clear if this letter is a standard one being sent to all parents, or a specific chase-up for forms they haven’t got.

The next time I’m in the leisure centre I ask about the letters.

This is failure demand, so endemic in big organisations that we give it hardly a moment’s thought.

The worker at reception says I can ignore the letters. If I’ve handed in the forms they will be in “the system” – a nebulous and unseen edifice in which she and I must both place our trust.

Time passes.

I receive a third letter (this one addressed directly to my youngest child, who is 8) advising us that he will lose his place at swimming unless they receive a direct debit mandate.

Now he’s concerned that he won’t be able to go swimming any more. He likes swimming.

I’m also worried that the council may have lost a bit of paper containing the full names and details of my 3 children, along with my bank sort code and account number.

I email the leisure centre.

This is failure demand, and as citizens, consumers and workers, we shouldn’t put up with it any longer.

The leisure centre manager replies swiftly and comprehensively to my email, copying in several colleagues.

My youngest child is added to the direct debit details on the council system. The threat of being thrown off the learn to swim programme is lifted.

Life goes on.

Does this story read like a first world problem? It should do. In the USA, 3 out of every 4 jobs are now in the service industries. It’s nearly 4 out of 5 in the UK. With manufacturing outsourced to China and the developing world, the nations of the Global North have just one job – and we’re doing it terribly.

It’s time to turn our moaning about specific incidents into a movement to deal with the general causes of failure demand.

Delivering service is hard. It takes an orchestra of diverse talents to play the right notes at exactly the right moments – and to improvise each performance around widely varying users and contexts.

Service design has tools and techniques to make this process easier and better, if only more people knew to use them.

  • Did the person who designed that direct debit form wonder how it might work for users, for families like mine, the 1 in 7 with 3 or more dependent children?
  • Did they consider the form’s role in the wider service, it’s interaction with frontline workers on the sports centre reception desk?
  • Did they even realise that what they were doing was design?

Seeing over the next hill – a service design pattern

Over the years I’ve worked with digital services in different spaces, from sports performance to house buying to students on campus and training in the workplace. And there’s this one picture that resurfaces in service after service. I need to get it out of my head and into the world, where I hope others will help me develop it further.

image

It’s a picture of a pattern that goes something like this:

Seeing over the next hill

We meet much of the most valuable service when facing a change or challenge for the first time. But unless we know what to expect, it’s hard for us to make decisions in our best interests, or to trust others seeking to support us.

Sometimes the change is related to a life-stage – choosing a school or college, having a baby, retiring from work. Sometimes it’s simply something we may only do a few times in a lifetime – buying a car or home, opening a bank account or reporting a crime.

On one side, the person at the centre of these events has lots to think about, many (possibly conflicting) choices, short and long-term implications to consider.

On the other, the people delivering service are likely to see and do the same things time and time again. Their experience is valuable, but can easily give rise to jargon and preconceptions that obstruct communication and empathy with first-time users. Often the first step to improving service is to recognise and reduce this asymmetry of understanding.

Deliver service so that people can always see over the next hill, so they know what to expect, what good looks like, and who they can trust to help them along the journey. Specifically:

  • Cultivate empathy among people who deliver and design service day in day out. Find ways for them to see the service through the fresh eyes of a first-time user as frequently as possible.
  • Put first-time user personas at the centre of your work. Ask yourself what will shape their expectations and how might those differ from the way insiders perceive the service?
  • Test your service with people who have never seen it before. Over and over again. They can’t unsee what they’ve seen so it has to be new participants every time.
  • Follow up with service users before, during and after their experiences. See how their needs, wants and behaviours change as they go through their journey.
  • Record real-life experiences to share with future users. It’s much more compelling to hear from someone like you who has been there before.

As with all the reckons I post to this blog, I’d love to know what you think. Have you seen this pattern too? Who handles it well? What else could we do with it? Or am I making a mountain out of a molehill?

This more than that

Artefact cards

Inspired by Roo Reynolds’ post about technologies to focus on, I’ve been raiding my box of “things I mean to blog about some time” to work out what my own list would be. Less technology here, more attitudes to getting stuff done.

You know the deal – while I value the things on the right, I value the ones of the left more…

  • Service (singular) more than products (plural)
  • The minimum viable more than the grand projet
  • Humble historicism more than accelerationist exceptionalism
  • Execution more than ideation
  • Continuous improvement more than hit-and-run projects
  • Launching more than landing
  • Reflective iteration more than flashes of inspiration
  • Small stories more than big data
  • Variability more than scalability
  • Flood plains more than waterfalls
  • Agile more than PRINCE2
  • Opex more than capex
  • Teams more than resources
  • The training budget more than the R&D budget
  • The stationery cupboard more than the Intranet

What should I expand on? What did I miss?