Trailblazing vs Process

Yesterday, I set up WiFi for our 4 unit apartment building's back yard. So this week I have the pleasant change of writing this morning from my back yard. (I didn't actually need the internet to write this, but the mind is strange, who knows where action springs from, Dumbo's feather, etc etc)

Last week I wrote about the idea of "trailblazing" technical work and documentation to put a name to what I found myself doing in a choral recording process, and contrasted it with "road building" technical work in library and infrastructure development. But a colleague put a bug in my ear about something I hadn't considered: what about process? Where does that fit into this scheme?

I think it's not uncommon to have a They Live sunglasses scene around process in building software: you can't unsee the good and bad effects of process. Prior to that, process is all obstacles to achieving individual goals. Afterward, one sees that a bad communications network or social rhythm will prevent those goals from being reached, or being useful and worthwhile. Whether one likes working at a giant company or not, they are crucibles for these kinds of hard lessons.

What Is Process?

Well, let's pin it down as an artifact first: let's say that a process is a written agreement that everyone will abide by. It will be framed in terms of some kind of goal a person or team wants to achieve, and it will set out prerequisites to achieve that goal: sign offs from particular people or teams, documents that must be produced, teams that must be consulted, meetings that should be had, or actions that must be taken.

So a process has two main modes of action:

• It connects. Connections inspire new effort and new conversations. I'm going through a classic example right now: instead of implementing whatever analytics events and names we like in engineering, with maybe a cursory look from our product manager, we're involving the data science team. The cost is that many more conversations are necessary to hash out an understanding; the benefit to our data science team, though, is that they don't have to worry about needing to backfill for 9 months next August because they weren't consulted about what questions they need to answer.
• It establishes accountability relations, and thus oversight and power relations. When security has to sign off on an effort, that gives them space to exercise authority.

Both of these modes of action slow down projects. But they both also serve to reduce large scale errors: doing the wrong thing, omitting crucial safeguards, etc. That is essentially what process is for: to reduce error.

And that points to the measure of a successful process: reduced error rates. What needs to be available is consistently available; the disasters that should not happen don't happen.

On The Other Hand, Trailblazing

Of course, trailblazing also tends to take the form of a written document. A trailblazing document will seem to have some of the same things: a set of recommendations, steps to follow, possibly people to be consulted, maybe even sign offs as well.

The difference is in the purpose to which the instructions drive. When a process is written, there's no concern about whether anyone will follow in your footsteps. The path is well trod, it's just loosy goosy. People are falling in quicksand; they're being bitten by snakes; they're being pickpocketed or eaten by tigers. But they're there.

That's not the case for trailblazing. Nobody is currently doing the work the trailblazer is concerned with. We may not even be sure what constitutes an error, because not everyone is doing it yet.

And that points to the measure of a successful trailblazer: did anyone follow?

Contrasting Successes

The biggest difference between these two is the importance of following instructions precisely.

In trailblazing, the greatest successes will diverge dramatically from the initial plan. New and unanticipated things will be built, perhaps doing things the "wrong" way. So many people will come along that great chaos will ensue, and people will cry out "Ahh, if only we had some process!"

In process, on the other hand, sticking to the process is extremely important. If people diverge from the process, that's a sign that things have seriously gone wrong. If PG&E says that they've done line maintenance, when they haven't, either the process is no longer necessary or PG&E is about to cause some serious problems. The greatest successes in process look like the US airline industry, where the odds of a plane crash are sufficiently low that worrying about them is probably worth talking to a therapist about.

I don't make planes, of course. But I do make software. And sometimes I cry out, "Ahh, if only I could write some crappy, broken software and not deal with all this process!" So I do that in my spare time.

Oh, and that choral collaboration I did that inspired last week's post? I tuned in to this week's Zoom service, and our choral prelude had been assembled in a video editor like I did! A fellow choir member had seen my work and the experience I shared, and decided to follow in my footsteps. So I guess I achieved my goal.