Enabling Policies: The Cure for Meta-Work
In the workplace I'm very much a Maverick. Scratch that. Just "I'm a Maverick".
Even when I think I'm not going to be. Even when the project isn't 'my baby'. Even when I try to just go with the flow - except that I don't, because I just can't.
Bureaucracy, bikeshedding, and red tape are everywhere - and they're always out to get me.
Ironically, I think this is due to a lack of enabling policies.
Yes, I just said that.
But it's not what it sounds like: It's like the case of "the man eating shark" vs "the man-eating shark" except that "enabling-policies" looks weird and makes the skin of the grammar nazi inside of me crawl a little.
Let me explain.
Most Decisions Don't Need to be Made
Grace Hopper, the mother of computer programming, said it ever so well:
It is easier to ask forgiveness than permission.
Usually, the very act of asking for permission to do something is a life smell; one that reeks with the same stench as premature optimization.
Assuming that something needs a "decision" is assuming that it's a big deal and that it needs weigh in and consideration.
More likely, it's a result of fear of a discovery - you've found something new that you haven't seen other people do, and so you assume that others either aren't doing it because it's wrong or dangerous (which seems to be what most people assume when they come across a new idea that hasn't already occurred to them), or otherwise bad and so you want to seek approval.
Don't make a "decision" out of it. Just do it and if it doesn't work well you'll find out quickly (most likely) and you've wasted no expensive time or resources.
Delay Decision Making: It's Expensive
Formal decisions (involving multiple people) are expensive.
If you get 3 or 4 people into a room for a few hours, that decision is costing you hundreds or thousands of dollars.
It costing the time of each person while they're in the room, and even more due to the time-cost of context switching and getting back to flow.
Meta-Work: The #1 Workplace Allergen
I think that everyone has had the experience where you're in a room full of people supposedly discussing a problem, and then you (yes, you) have this distinct pause and sensation of confusion as you realize that you're pretty sure that there isn't actually a problem at all.
The only problem is that you're in a room with a some number of people who are convinced that there's a problem - or that there will be problem - and feel the need to decide what to do about it.
It's all too meta and hypothetical. It's the dreaded temperature check on a relationship. It's pulling over and looking at a map just because someone is asking, yet again, "are we there yet?"... but we still aren't.
It's premature optimization of organization.
By this I mean policies that enable: Empowerment with a ceiling.
I mean policies that alleviate the fear of "newness" and "differentness" to reduce conflict and decrease expense, which eliminate prematurely halting positive action for the purpose of promoting it to a managerial decision.
Policies that reducing the need to ask questions or involve others until it's much more likely that there will be a clear cost benefit.
Here are some examples of enabling policies:
- Rubber duck with a teammate before asking direction.
- Experiment before rubber ducking.
- Assume that any formal discussion will disrupt some number of people for some number hours of their valuable time. Make a back-of-the-napkin calculation, and then spend at least half of that (i.e. 6 hours if it's reasonable that it will involve 3 people and turn into 2 hours of bikeshedding) trying to come to a conclusion of whether or not it's worth it.
- Money is cheap, time is expensive. If you need (or want) to utilize (or evaluate) a paid tool or product in order to complete a task, just get it as long as the price is less than the cost of discussing it - with some sort of cap - say $50 per employee per month, $500 per team. If the evaluation goes well and there's a recurring cost that will need to be addressed and budgeted for, do that after the evaluation.
- Wait until a problem arises to address it (in other words: don't assume worst-case scenarios). It is highly unlikely that overnight, suddenly, every single employee is going to immediately seek to abuse these enabling policies by looking for ways to excuse themselves for spending an extra $50 each month.
- If it's not part of core business value, allow it to be open source. A quick litmus test: Do we sell this now? Do we plan to sell this? Does this reveal proprietary business process? If no, no, no, then it's fine to open source. Your most creative employees don't want to give you exclusive rights to their finest creations, but they'll be more than hapy to share. Let them bring the value of their nights-and-weekends projects in, and let them take the improvements back out.
- Let stakeholders decide. Don't promote individual or pair decisions to team or managerial decisions prematurely. Let the coders on the project decide the language and framework. Let things start mall and, if necessary, acquire them as they grow. Or let them die peacefully. Tools and processes should be designed to help the employees they affect, not hinder them - so don't force it. If people aren't using a tool, it's probably not a good tool for the job, so forcing it probably won't help.
- If "money is expensive" and "time is cheap", either your company is too small to employ policies like these or your team is to large and you need to let some people go. Otherwise, these apply.
By AJ ONeal
Did I make your day?
Buy me a coffee