Why The Future Is Modu.lar

Modu.lar Delivery

Becoming CTO for Modu was a no brainer for many reasons, but a key one was one of Modu's founding principles:

There are no industry best practices. Playbooks and blueprints and process dogma are some of the biggest risks to the timely delivery of business value

You won't necessarily hear it stated that bluntly on a Modu sales call, because a more constructive way to put it is this:

Every business, product, team and problem is unique. The route to finding delivery solutions must reflect that. And the answer is modular patterns.

Modu may be the only consultancy on the planet that tacitly engages with clients admitting that it has no delivery blueprint to sell.

That may sound like madness (if there's no delivery blueprint, then what are we selling?) but it's a critical differentiator for success.

For two reasons.

Reason 1: Transformational not transactional

When you start a consultancy it's accepted practice that you first decide what you are selling. And most opt for a customised, standardised and repeatable delivery model. It might be based on Scrum, Extreme Programming, SAFe or a hybrid of whatever the founders believe to be best practices. And that's what you sell. You lead on sales calls with a description of the approach and why it's better than your competitor's variant.

That's transactional consultancy:

Buy X from us, for £, because we believe X beats Y

The customer doesn't even figure into it.

Modu tends to hire people from client-side industry that have received this pitch, and sometimes bought it and experienced it. Occasionally it works. But it feels very much about time, materials, overruns, change control and invoices and not much about value.

Consultancy should be transformational, not transactional. We're all just people who want to achieve change. When I visit the doctor, the last thing I want is for them to have decided how to cure me before I've told them what the problem is. If I know the cure I can go to a pharmacist.

Consultancy should be more like working with a good doctor: someone that listens, understands, knows the full range of possible treatments, and side effects, and plans a course of treatment tailored to me.

Reason 2: Patterns

If you have no blueprint then what do you do? Well, it's not easy. It takes patience, experience and empathy. It requires thoroughly exploring the problem, the people, the context, and the business. It requires a decomposition of the problem into its constituent parts (each with its own characteristics). And it requires access to a vast array of composable, modular delivery patterns. These may then be connected and applied in ways that actually feel to the client like best practice (because they are, but only for that business, for that problem, at that time).

But what are patterns?

I'm glad you asked. Linda Rising defined a pattern as "a named strategy for solving a recurring problem." It's basically a technique that's been tried and tested against some known subset of problems.

We take delivery pipelines for granted in tech these days, but the concept emerged as a pattern to solve the recurring problem of how to manage lots of developers committing changes to a codebase that then needed to be reliably built, tested and deployed somewhere. Patterns tend to be fractal in nature (a delivery pipeline is made up of lots of patterns, e.g. how and when tests are applied). Does every pipeline in every organisation look exactly the same? No, of course not. Could the unreliable and slow pipelines learn something from the ones that are not? Yes, but it doesn't follow that they should blindly copy the solution directly, only explore the pattern to see if it fits the local context.

You can use patterns everywhere. Have an awkward meeting coming up? Add food. To quote Linda Rising in More Fearless Change:

Sharing food plays a vital role in almost all human societies to bind people together and increase the feeling of group membership.

If you have ever presented an idea to a board you will be familiar with the pattern of talking to all the members individually ahead of time to get them comfortable with it. We don't do it with every board decision, but it's a wise protocol if you don't want any nasty surprises on the day.

So, does this make the Modu approach inconsistent?

Another great question. It does and it doesn't. I think a better way of thinking about consistency is: would you rather have a process that did the same thing every time, even when some of the steps clearly add no value and waste effort? Or would you rather focus on the principles that should be unassailable? One of the reasons the implementation of agile delivery fails in so many organisations is that people follow process over principles. The manifesto deliberately didn't come with a process diagram. We have to do that for ourselves. And that's how it should be. People solving problems together.

The patterns are the process and in practice working like this actually feels very consistent. If you set a principle that no code will go into production without it having been seen by four eyes then you could start with manual code reviews, move to pull requests, then to pair programming, or a mixture of all of them. The principle remains consistent, the practices change to suit you. And I might say don't do manual code reviews because it's not the 90s, but you might say it works for you. And for now, you'd be right and I'd be wrong.

The Future is Modu.lar

The great thing about Modular Thinking is it gives you the freedom to do the right thing. And to do that you have to first ask a lot of questions that illuminate the problem from all angles. It means talking to each other and challenging the choice of one pattern versus another. It means pathfinding the route from here to there and plotting the patterns along the way. It's both dynamic in its approach and consistent in its outcomes.

It's a way we've all wanted to work for so long we're building the business around it that we always wanted to work in. A business that doesn't hide behind process and rigid dogma but instead uses modular patterns, tailored for each client, that provide direct and immediate feedback on how we're doing.