The Briefcase Technique: Making Your OSS Experiences Compound

No two OSS projects are the same. One might have a different vendor stack, another a completely different organisational structure, another a different operating model or different vendors and architecture.

But they don’t need to be 100% identical to be repeatable and reusable. If 50% of the problem has appeared on one of your projects before, that’s 50% you don’t need to solve again from scratch.

Experience is the hardest part of building expertise in OSS. It can take months or years to acquire the judgement that comes from completing difficult projects.

The Briefcase Technique, which we’ll describe shortly, helps make those hard-won learnings compound.

.

Experience Is the Expensive Part

The diagram below shows a seven-step experience cycle:

Visually, each segment looks roughly the same size. In reality, they’re not.

Experience is by far the biggest, longest and hardest part of the cycle.

That’s the project itself. It’s what you learn when the projects go wrong, the difficult migrations, the data quality issues, the organisational constraints, the human factors, the architectural compromises, the operational surprises and the lessons that only become obvious after you’ve lived through them.

That’s where the real investment happens.

Everyone who’s done an OSS project has done step 1 in the cycle. Often multiple times.

The remaining steps, two to seven, are comparatively lightweight. They’re simply a systematic way of making sure that the value created through all that experience isn’t lost.

Yet this is where I think a lot of the OSS industry stops. Lots of step 1. Very little time invested into steps 2-7.

Why is that important?

Most people complete a project, gain the experience (step 1), then move on to the next project and start again. They might remember some of what worked. They might bring a few lessons with them. But often those lessons stay in someone’s head rather than becoming something that can be systematically reused.

.

Unique Doesn’t Mean Unrepeatable

There’s a good reason for this. OSS projects really do look unique.

The client is different. The vendors are different. The technology stack is different. The people are different. The org chart is different. The processes, constraints and politics are different too.

But if you look beneath the surface, patterns start to appear.

Maybe a project is 50% similar to something you’ve done before. Maybe it’s 75%. Maybe only one specific part of the project resembles a previous engagement.

That’s all still useful.

Repeatability doesn’t require two projects to be identical. It only requires enough similarity that some of the previous thinking, methodologies, questions, artefacts or techniques can be reused.

If 50% of the problem has appeared before, why would you want to rebuild or rediscover that 50% from scratch?

More importantly, once you recognise that something is repeatable, you finally have something that can be improved.

If every project is treated as a one-off, you get one shot at the methodology. There is no baseline from which you can refine.

If you capture the repeatable parts, the next project becomes an opportunity to make the method better.

.

The Briefcase Technique

This is where the Briefcase Technique comes in.

Whenever we encounter a new type of OSS problem, we try to capture the methodology behind how we approached it. Not every detail of the project, because those will often be client-specific. The aim is to extract the parts that are likely to be useful again.

We then turn those into reusable methodology packs.

Over time, that’s created a virtual briefcase full of approaches that have already been applied, tested and, most importantly, refined over subsequent iterations of re-use.

It was never our intention at first, but this has had a really interesting side benefit when talking with prospective clients.

PAOSS has yet to do any outbound sales. We rely on word of mouth and inbound enquiries, so we don’t know in advance what problem someone is going to contact us about.

But once we start the conversation, there’s a good chance we’ve seen some version of the prospect’s problem before.

At that point, we can reach into the briefcase and pull out a relevant methodology pack. We have dozens of them.

Not as a pre-packaged answer. Not as a claim that the client’s situation is identical to somebody else’s. But as a useful discussion pack that says, “We’ve seen patterns like this before. Here’s how we’ve approached them. Which parts apply here and which need to be refined for this specific client?”

That makes the conversation more tangible very quickly.

Diagrams like the one above are particularly powerful conversation points. As they say, a chevron diagram tells a thousand words.

.

Refine, Reuse, Repeat

Capturing a methodology is useful, but the real leverage comes later.

For me, Refine and Reuse are the most powerful parts of the cycle. Steps 6 and 7 are of next most importance after step 1.

Once a methodology exists, every subsequent use becomes another chance to re-use and improve it.

You discover questions that should’ve been asked earlier. You find assumptions that don’t hold in every environment. You identify steps that can be simplified. You improve the artefacts. You find better ways to articulate the problems and explain the approach. You add edge cases that weren’t obvious the first time.

Then the methodology goes back into the briefcase in a better state than when it came out.

The next engagement starts from that stronger position.

That’s when experience starts to compound.

You’re no longer just accumulating a collection of projects you’ve worked on. You’re building a library of methods that improve every time they’re used.

.

A Practical Example: Data Foundations

One of the methodology packs we’ll be sharing with you really soon is our Data Foundations pack.

It describes many of the techniques we’ve used to create trusted data foundations for clients across OSS environments. These include methods we use to reverse data death spirals and turn them into continual improvement cycles. This is a far more successful approach than treating data quality as a one-off clean-up exercise.

Our Data Foundations pack is a good example of the Briefcase Technique in practice.

The hardest part was gaining the experience across dozens of OSS data-related projects in the first place.

The value comes from making sure that experience doesn’t get used only once and can be shared with many people.

Experience is where most of the hard work happens. But experience only compounds when you take the time afterwards to capture what was repeatable, refine it and reuse it.