Sometimes, especially when dealing with government bureaucracy, it feels like all of the rules, forms and arbitrary steps are designed to make your life difficult. In fact, you could be forgiven for thinking that process is being used as a way to exercise power, as a kind of weapon or mechanism of control. While it's true that bureaucracy often makes you feel powerless, I would argue the opposite: that processes and rules are designed to restrict powerful entities.
The thing is that being powerful normally means less restrictions on what you can do. In fact, I would define power as being the extent to which you can get what you want. Someone who is powerful can exert control on their environment, and someone who is supremely powerful can do so without restriction. However, most people don't like the idea of unchecked power – or, at least, of other people having unchecked power. So we build processes and rules to limit the power of government, who in turn build processes and rules to limit powerful corporations and individuals.
Within an organisation you will often find internal bureaucracy for much the same reason: that organisation delegates a certain degree of its power and resources to employees, and needs to limit their ability to abuse that power. A manager is allowed to spend the company's money, but has to go through a purchasing process to do so. A loan officer at a bank is empowered to issue loans, but has to follow a strict process to evaluate those loans. That processes doesn't just protect the company from that employee abusing their power, it also protects the employee: if something goes wrong, but they followed the process, they won't be fired. (At least, in a country where the company's power to fire is limited by process).
And similarly with the government and its love of forms. Those forms aren't to restrict your power when you're doing your taxes or applying for a passport – what power? Rather, they are to protect you from the government's power. If you fill out the forms correctly and according to the process that the government has set out, then the government is required to give you your passport or charge you the correct amount of tax. If that process didn't exist, there wouldn't be any forms, but maybe the government would decide to not give you a passport because they don't feel like it today.
That's not to say that all process is good and necessary. In fact, I think the main reason we see process as disempowering is the way that it tends to be used as a kind of cargo cult signal of power. Power is often limited by process, so you invent processes in order to feel powerful. Or worse, you see powerful people institute process when they delegate power, so you create unnecessary processes to feel powerful. Bad managers are infamous for implementing arbitrary reporting or process requirements on employees just because it's what they think managers do.
There's an even more pernicious kind of process abuse that genuinely does limit power as designed, but does it to people or groups who should have power. In that sense it is the kind of weaponisation or control theory of processes I argued against, but it's not things like complicated forms to get your driver's license. It's processes like voter registration that add more process, and thus more limits to the voting power of people over their government. In a democracy, the flow of power should be from people to government via voting, so anything that limits that power is inherently concerning.
You might argue that there are processes that are used to exercise power, like America's civil forfeiture program. That program allows police officers to sieze property on a very flimsy burden of proof and requires a protracted and complicated legal process to resolve. However, my argument is that these situations are just examples of not enough process. To see why, imagine that asset seizure did not have any restrictions, even the current flimsy ones: the police would take even more than they do now! They are the ones with power, and process is what limits that power.
I think this can be a particularly useful way to analyse both process and power. Of power: what processes are in place to limit it? And of process: what power does it limit? And if it doesn't limit anything, do you need it?
There's a neat trick that turns up in a lot of places where there is a large delay between an action and its result. Let's say I want to send my friend a postcard but it will take a week to arrive. It's kind of annoying that it takes so long, but we could make it better by pipelining. If I send my friend a postcard once it will take a week, but if I send my friend a postcard every day they will receive a postcard every day. Magic!
Pipelining is used successfully in areas as diverse as video games, CPU design and space travel – and one place where I don't think it's recognised: motivation. If you've never run before and you go for a run today, it's probably going to be pretty hard work. You get back from your run, tired and sweaty, and are you the fit bronzed god you hoped? Nope. In fact, there's been no appreciable difference in your fitness. Only after weeks of rewardless toil do you start to see results. But from that point on, your previous exercise works its way through the pipeline. Every time you exercise you get fitter immediately – or so it appears.
I think an underappreciated benefit of habits is that they exploit this effect. Not only do you reinforce a particular behaviour through repetition, but after a while you can feel like you have removed the gap between the behaviour and its results. Everything feels like it pays off right now which, thanks to the vagaries of our hyperbolic discounting, is much more powerful than things that pay off later.
But as much as it might seem like you've eliminated the delay, it's important to remember that it's only an illusion. If something happens today, your friend still won't get a postcard about it for a week. And if you stop exercising today, you won't suddenly get out of shape either. If you change your exercise routine, you might even be disappointed and conclude that it hasn't done anything. That's the dark side of the pipelining illusion: it messes up your ability to make good decisions.
The worst is when you're comparing a pipelined task to a non-pipelined one. If you've been working on an existing project for so long that your old gains are still catching up with you, and thinking about starting a new one, you get lots of weird and paradoxical effects. Working on the new project seems like an unquestionable loss; why start something new for a reward later when you could do the existing thing for a reward now? And by induction, it may never seem worth starting anything.
I'm not sure if you can think yourself out of the pipeline illusion by just recognising it. It would be nice to think so, but I suspect it's one of those things that creeps into your decisions without you noticing. For habits that you want to keep or change, I think it would just come back to an exercise in discipline to keep things going until the pipeline catches up. As for their effect on risk, perhaps the best answer is to set another habit: to seek out and embrace discomfort.
And if you did that for long enough, I imagine the benefits of seeking out discomfort would start to feel immediate too.
I wrote before about shoulding and the ways that obligatory thinking is pathological. Locked inside every should is either something that you want to be doing, or something that you don't actually have a good reason to do. Unfortunately, focusing on the obligation makes it hard to see whether there is any motivation of substance underneath. Worse still, I've realised lately that shoulds have a few ways of propagating into other areas and obscuring your motivations there too.
The first is that shoulds propagate through dependencies. If you feel obligated to take out the garbage, but first you are going to finish reading your book, the obligation spreads: now you have to finish your book so you can take out the garbage. Maybe you truly enjoy the book, but if you don't really want to take out the garbage then every page you read is bringing you closer to an unpleasant situation. On the other hand, there's also now a degree of pressure on finishing the book that you didn't have before. Reading it used to be something you wanted to do, now it's something you have to do.
The second way is through substitution. It's not uncommon that you will bump one activity for another, better activity. With an obligation-free activity, that's no problem. I wanted to read, now I want to go for a walk. But when a should is involved, it propagates implicitly: you must be at least as obligated to do this new thing as the old thing it replaced! I understand you can't come to my party because you have to work; I recognise your superior obligation. But if you ditch my party because you're too tired, I'd better not find you online later in the night. You are obligated to sleep by substitution!
There are a couple of ways I can think of to mitigate these. I covered reducing dependencies before, but another possibility is to just reorder things as much as you can, so the shoulds happen first and can't contaminate anything else. I covered something like that in motivation-driven development. As for mitigating substitution, perhaps the best I can suggest is to separate the two decisions: drop the old thing unconditionally, then pick up the new thing.
But all this is just more reason to avoid shoulds, in my opinion.
I've been thinking a bit about goalpost optimisation in the wake of my most recent writing failure. It's tricky to avoid optimising your goals if those goals only exist in your own head, or don't seem real. The antidote is to commit to those goals in a way that prevents you from easily changing them later.
The most common way to do this is having some kind of commitment partner. In more traditional work that often takes the form of a manager or boss who sets your goals. For people in more creative arrangements it's usually other people in a similar situation: a mentor, or a group you can commit in front of. I've tried those methods and, while they work, there's something inherently unstable about needing a particular person or group to set your goals properly. What if the person gets busy, or you don't see the group for a while?
Writing goals down seems to get a little bit of the way there, but I don't think it goes far enough. I'd like to suggest a better answer: public commitments. Unlike a particular person or group, the idea of public isn't particularly vulnerable to change. Public commitments are something akin to performance. In a sense, you're performing your goals in public rather than practising them in private. I think this method could be a significant improvement over commitment partners; although people are still better for discussing goals, a public commitment is a stronger and more reliable way to set them.
What I would really like is a platform for making public commitments. Obviously I could write about them here, but I'd rather keep this space for more interesting things. You could presumably use social networks or other things to make public commitments, but they aren't really designed for it. A public commitment platform would give you a particular page that would list your current commitments, as well as integrate with social networks and provide widgets you could embed to show your commitments in whatever public place you feel is useful.
So I'd like to publicly commit to making that platform. Not all of it all at once, of course, but something that at least has the bare functionality of collecting and showcasing what you've committed to. It'd be wonderful to commit to making a public commitment platform using that public commitment platform, but that obviously runs into certain difficulties. Instead, I'll commit to it here.
I remember there used to be a lot of talk about dependency hell, when you have lots of software packages all depending on each other. It's usually considered a good thing to have lots of small packages instead of large monolithic ones, but it led to problems like multiple conflicting versions of a single package, or dependencies that went around in a big circle. These days the tooling has gotten a lot better so you don't hear much about dependency hell, but I still like it as a metaphor for systems that are over-burdened with interconnections.
In Stateless I wrote about the value of minimising the temporary state you carry around, and I see dependencies between things as one form of that. We've all experienced that ridiculous string of dependent goals where your lightbulb's broken so you go to replace it, but you're out of bulbs so you go to the shops to get a new one, but you realise you need to put money on your bus card so you go online, but the wifi's being slow for some reason, and suddenly you find yourself changing a lightbulb by fiddling with your router settings.
That example is obviously silly, but in other situations we are willing to accept just as much complexity. Often our explicit plans look a lot like a chain of dependencies: "we'll do X, then Y, then Z". Or the way we understand people and social situations: "if Dave does A, then I'll do X, but if Dave does B then I'll need to do Y and Z". If you combine the two of those you can very quickly approach a level of dependency hell only imagined by the Windows developers of the 90s. Sometimes those dependencies are unavoidable, but there are times when you can redesign your plans to remove them.
One of the easiest tricks is giving your tasks some way to bail out. So "I'll finish writing this, then I'll do the washing" can be replaced with "I'll write this until 4pm. At 4 I'll do the washing." Now instead of washing being dependent on writing, they're two distinct tasks. If your writing takes too long it won't affect the washing, so you've made the two independent. However, this only works if you have a plan for how to bail out of the task when it runs over. With writing you can just put down the pen, but if you're halfway through a conversation with a friend it might require a little more finesse.
Another trick for external dependencies is to come up with ways to make invariant decisions. Instead of "Once Mary calls back I'll know whether to go to the cafe or not", an invariant version would be "I'll go to the cafe either way, and if Mary can come too all the better." It's invariant because your decisions don't vary based on the external outcome. You could also say "Since I haven't heard back from Mary, I'll abandon that plan and start doing something else. If she calls later we'll make a new plan." The bailout trick can be useful here also: "I'll wait for 5 minutes and then do something else".
It's not always possible to eliminate dependencies in this way, but I think it's fruitful to try. Each extra dependency is another constraint that you have to consider, and an extra way that your plans can fall apart. Escaping dependency hell makes your plans more resilient in the face of failure and frees you up to concentrate on the things you're doing, rather than their complex connections to everything else.