A background on bureaucracies
By definition, large companies employ a lot of people. Large companies also tend to become bureaucracies in order to manager all those employees. Therefore, lots of people are working in a bureaucracy.
At least in my experience, bureaucracies usually:
- Require a lot of red tape, which in turns hurts cross-team coordination
- Split people into specific roles and teams ("separation of duties"), so they must constantly coordinate with others
- Encourage escalation of problems instead of individuals finding immediate solutions.
- Require many people to approve a specific decision
- Regulate most activities
- Are very risk-adverse, and hence punish risk more than it awards innovation
- Are very big
Bureaucracies tend to have a negative connotation, sort of like living out a Dilbert comic strip. So, if bureaucracies have such a bad rap, then why would a company ever become one?
- As the company grows, it's an understandable way to govern masses of people.
- If a company employees micro-manager personalities, the bureaucracy is a natural consequence.
- Big companies can't afford risk: People will sue them, Hackers will attach the security of their systems, millions of users depend on their product, etc... So bureaucracies use red-tape as a safety net.
To help appreciate the positive tips of how to deal with a bureaucracy, let's first explore some futile approaches.
- Whining sessions - Everyone will complain that it's a mess, but nothing will get done.
- Emotional appeals - Bart in IT feels your pain that your 1GB workstation is slow, but he's not allowed to give you an upgraded memory chip.
- Asking someone to do something outside their role - Ok, so maybe you get lucky and Martin, the local DBA, helps install a virtual machine, but in general you can't expect this.
Practical Tips
Besides common sense (be polite, do your homework, communicate clearly, etc...), here are 11 tips for dealing with a bureaucracy:
- Know what each role should do. In a bureaucracy, each person has their role, and that is all you can expect them to do. It is not an entrepreneurial start-up where everyone does everything they can to make the team succeed. While you may get occasionally surprised, you can't expect someone to go above and beyond. For example, perhaps only the legal/procurement team can purchase tools, or only the security access team can give your user account rights to the Customer database, or only Support can view production data, or only the Graphics department is allowed to create the official icons used in the application (despite you could do it yourself with your 5 years of hobbyist Photoshop skills), etc... You can't expect a fish to fly. Each person has a role, and a bureaucracy beats people into fulfilling just their specific role.
- Know how information is passed between departments. A major side-effect of a bureaucracy is that it takes many departments to do even simple things. This means that even the most mundane request could bounce through 5 departments like a ping-pong ball. How does the request get passed along? Is there some official ticket/issue software that tracks everything, are official emails sent, does it only happen in face-to-face meetings? For example, if nothing happens until "a ticket is opened", then learn how that ticket system works and be prepared to open tickets. Even if you go directly to your buddy in security access to help resolve something, he'll still need a ticket to track his time against. A dozen hallway conversations with the senior VP herself may have less impact than that one ticket you actually submit. You need to leverage these communication channels, else you're just screaming in the wind.
- Allow time for requests to percolate through the system. Because even a simple request may need five signatures from five departments, requests can move slower than molasses. Therefore, when you're designing a solution, try to determine what ticket requests you'll have as early as you can, and then submit those as soon as you can. While those tickets are dripping through the system, you can flush out the internal details of your design. Sometimes, submitting the ticket "reserves your place in line", and you can update the ticket with more details as you find them (think of it as giving that department a "heads up"). The last thing you want to do is calculate every possible edge case, and then (two days before the deadline), submit a flood of ticket requests.
- Let the person causing the pain feel the natural results of it. - Where possible, when someone is blocking the project due to some artificial rule, let them feel the natural consequence of that project being blocked. I.e., don't enable bad behavior. For example, if someone in sales keeps entering data the wrong way, consider not enabling them by writing an automated script to continue cleaning everything up. If you do, they'll essentially think that their current approach is working, and why would they ever change?
- Distinguish between roles and titles. Say "managers don't have access to source control", but you (a new manager) really need access. If your company allows one person to play multiple roles, then perhaps you can pass muster with "I'm not asking you to change the security chart and give managers access to source control, rather I'm trying to (temporarily) contribute with the developer role, which needs access to source control."
- Make red tape problems known to your manager. Don't be malicious or whiney, but simply report the facts to your manager. "I can't complete the report module until procurement gets the Amazingnator rendering engine." Don't just eat it yourself and try building your own Amazingnator rendering engine over the weekend. Sure, it may make you today's hero, but the continual burden of not getting the proper resources because another department is broken will leave you bitter and exhausted.
- Know the people who approve the tickets - Even the biggest bureaucracy ultimately boils down to individual people. If a ticket is languishing in the Data Services department, it's beneficial to ask Marge from Data Services if she's heard anything about the ticket, and if she has any advice.
- Where feasible, keep skills in your own team - Because cross-team coordination is often slow in a bureaucracy, having the skills in your own team such that you don't need to go to another team can be a good ace-up-your-sleeve. I remember a web consulting gig when .Net first came out where the manager split development into separate roles - C# guys and SQL guys. He thought this would be easier to staff ("you only need devs with one skill or the other"), and result in higher quality ("each dev is an expert in their niche"). The problem for applications at that time was that C# and SQL were so intertwined that one without the other was like trying to run with only one leg. Coincidentally, some sub-teams secretly had their own SQL guys, and those teams flew.
- Stack the deck - You know when you ask the procurement department to purchase a tool, that they're going to want forms filled out - how much does it cost, what's the business justification, does your manager approve, are there alternatives, etc... Ask upfront what forms they need, and have those ready. Else, you may be "sent to the back of the line", and need to wait days (weeks!) to get your chance again.
- Focus on what people can do without spending money. This is related to knowing what each role does. Maybe that department can't give you what you your request because it costs money (more staff, purchase a tool, additional hardware, etc ...), but they can do helpful things that cost nothing, such as: provide "temporary" security access so you can run a test yourself, let you borrow a resource that they're not currently using (such as a VM server you can log into), switch the order of two tasks that has no impact on them but simplifies your life, offer information such as who you should unofficially talk to "make it happen". Ironically, although time is money, it is often easier in a bureaucracy to get time than get approval to spend money.
- Mentally prepare yourself that it is inefficient. People can psychologically deal with crap if they're in "I need to deal with crap mode". So, just set your expectations and prepare yourself that bureaucracies are slow and inefficient. If things do go well, then congratulations, but if not, at least you'll be psychologically prepared for it.
See Also:
No comments:
Post a Comment