The fast track tip

Well, "duh"

Summary

When you work for a small entity, or a bigger but one with a strong culture of employee empowerment, everything is fluid.

If you then migrate to the corporate world, things start to slow down, layers to pile up.

You cannot solve the entire company's culture, but you can make it better for your team by adopting a few workarounds.

Fast tracks are simplified procedures for specific cases that you know should not warrant the full-blown process.

E.G: you probably don't want to create a Jira ticket for adding a comment.

Systematically implementing fast tracks will take some effort, but will result in a much more streamlined work experience for everyone in the team.

Growing pains

When your organization grows, or when you join one that is already big, there is often a cost in flexibility.

Suddenly merging code may require a ticket, a PR and a review.

Or maybe you cannot just talk to somebody in the other office, you ask for an appointment for "a call".

Sometimes you gotta check with legal first, or check that you are following the code of conduct.

In those situations, fixing a typo looks like a lot of work.

Many people have expressed their frustration about this over the last decades. Not that it didn't exist before, but in our line of work, where you can create ex nihilo something just by thinking it and then acting on it, it creates a big contrast.

If you are not part of the decision process, there is not much you can do about it, except nudging your life in the direction that will put you in a job that fits your needs.

Plus, not everybody hates this, believe it or not. Structure has appeal.

However, if you are, then it may be time to set up fast tracks in your culture.

Allowing for shortcuts

There are good reasons for all those layers. Reviews will keep the quality of the code in check in a team that is not homogeneous. Legal will save a very exposed company a lot of trouble down the road.

But it still doesn't help with the typo.

All those things affect productivity and morale, and they are particularly gnarly when their cost gets close to the cost of fixing a problem itself.

If you have to take 10 minutes to rename a variable, guess what, nobody will do it, and the code base will accumulate cruft while the devs will accumulate frustration.

This is where adding explicit, official workarounds is useful. It doesn't solve everything, but it helps a bunch.

In Ferris' "The four hours work week", he explains that people working for him should ask for his approval when needing to refund a client. But only if the refund is more than 100 dollars. If it's less, just refund them, no questions asked. Don't bother checking. Assume good faith.

In dev, it's the same. There are things you want to check on, but depending on the scale, it's just not worth doing it. At some point you have to trust your team. And this will avoid thousands of grains of sand to come grinding the project's gear.

So you need to take every single procedure you have, and check if there are situations within it that doesn't warrant an exception to by-pass it.

Sometimes it's risky. Sometimes it doesn't pay off. But most of the time it does.

Provided you are not a hospital or NASA, of course

Examples of fast tracks

I regularly have to work with corporate clients that will have a full-blown decision diagram for merging code. It starts with something like a Jira ticket, and ends with a 4 eyes process or some other type of review.

Once I gained their trust, I suggest to setup a system of "fast-track" branches. A fast track branch must be named "fast track something", and contain only minor changes. We decide together what minor means, but it's what you expect: typos, renaming private symbols, docstrings, etc.

The fast track branch has one rule: show it to a colleague that will say "yes this is fast track". If it is, no need for a ticket, for a review, you can just send it to CI for tests and merge. In practice we have a chat for that, and when a notification pops in, one of the colleagues will pop in, have a look, and approve.

Some gets rejected, it's easy to slip more work than a fast track would warrant, but that's the point. Seniors love it because it doesn't waste their time. Juniors love it because they can be the approvers, and they usually jump on it: it makes them feel useful.

We have also have a documentation branch. If it modifies only something inside the "doc" directory, you can commit and push directly to it. Not even need for any check.

Nobody likes writing docs, so we want to make it as easy as possible, and it's trivial for CI to ensure only one folder is affected. Unless your threat model include an evil colleague, but then you have bigger problems.

Same for talking to people. We have discussed about how people want to interact. Being interrupted sucks, but having to set up a meeting to ask about a comment line 187 sucks as well.

You get the idea.

Again, you cannot obliviate the overhead. If this is unbearable to you, the only right move is not to play, and change companies.

But it does make a difference.

Make the geeks talk

Functional teams all have one thing in common: they naturally communicate well.

That's one of the reason keeping a team small is productive, as it makes sharing information easy. But not every company is 37signals. In fact, most are not, and so you will have to work in settings where the culture has not been built, but has emerged. Not always for the best.

Putting things on the table is one of the easiest moves you can make, and yet it's so rarely done. It's so simple to ask what makes work unnecessarily hard. It's quick to say "do you prefer to be called on the spot, or do you prefer a note in a chat and you get back?".

Every fast track process is born from discussing with others, and finding where the process makes no sense.

It's also important to talk about it because some fast tracks are not in line with the company policies. Doing it will make everybody happier and more productive, but if your boss' boss hear about it, you'll get blamed.

So people must know what they are getting into.

Yet again, most functional corporate teams work around one company policies or another. It's necessary to get the work done and stay sane. The company is not always right, it usually does what's best for the company itself, not for the people inside.

The corporate world being very controlling, it has an infantilizing effect on the workers. You don't have to accept it.

It's easier when you are a freelancer, and go from gig to gig, I'll admit. I get to see very different types of orgs, and when I'm fed up with processes, I can always work for a start up.

Still, making bypasses official has lots of benefits. It delimits the border of your margin of maneuvers.