I just had an epiphany. I realized how prioritization problems in IT organizations are related to people’s tendency to avoid personal responsibility.
First, let me describe the problem. In IT organizations I’ve worked in, or with, or heard about (and I can’t think of any specific reason to question my assumption that most other companies are the same) there’s a great deal of juggling going on. Also known as firefighting and multi-tasking. It’s not just multi-tasking that is indicative of an issue (that’s a subject for another rant), but its ad-hoc nature. By “ad-hoc” I mean that there’s usually no well-defined process nor guidelines nor accountability structure for making prioritization decisions.
You could argue that some prioritization is always done. We (sort-of) prioritize PROD tickets against each other based on their urgency level. We (sort-of) prioritize enhancements to be included / excluded in the release based on LOE. We even (sort-of) prioritize different projects against each other as they converge on single “resource” (developer). Yeah, that’s kinda true, but only to a certain degree.
In the simplest case, when developer works on single project, and all work is funneled to that dev through his direct manager, prioritization is usually done. Let’s leave aside exact methodology for now, at least it is being done. Although, let’s remember that even in this simple environment typical manager will try to get away without making explicit prioritization decisions. If dev asks, which one should he work on, the manager will try to respond with something vague, like “this one is more important, but you should not stop your work on another one”. If dev asks which specific task should he work on now, the manager will finally be forced to make the call, so he will make it. More on the how later.
In more complex cases, when developer switches between maintaining old projects and working on 1-2 new ones, the manager is no longer the only channel the work arrives on. There are usually some requests for assistance from colleagues. Some action items from meetings with stakeholders of other projects, especially if meeting does not include one’s direct manager. Some PROD tickets and/or emails directly from Help Desk or Support Desk. Some requests directly from users (this is typical if users are internal “business” users). Some personal requests from manager’s manager and other higher-ups (“hey, Jack, can you think about this in your spare time?”). Et cetera. This multitude of work gives manager good cover to avoid making prioritization decisions. Indeed, unless developer is aware of, concerned with, or has burned himself on, the topic of prioritization, it’s much easier for him to assume priorities based on his own limited understanding of matters than to go and ask his manager every time such question arises. Add to this that managers are usually busy in meetings, and that many of the requests are of “we need this yesterday” kind, and you will understand why developer might rather shut up and work, than go seek his manager to make that prioritization call.
Even if he is full of determination to catch his manager and press him to make an actual prioritization decision (instead of “they’re all equally important, just split your time between them”), once he has tried it several times, he will eventually fall back to the implicit way. Why? Because from his perspective the decisions are made in a very inconsistent fashion. What looks like random guessing though, is in fact the application of three most popular prioritization methods: “squeakiest wheel gets most grease”, “cover my butt”, and “kiss-up to boss”. Which gets us to the actual topic of this post: avoiding personal responsibility.
– “Need to decide between these two? Let’s ask the business.” — transition the risk of decision making to the other department’s head
– “This one is clearly more important. The client complained about it” — who will argue that the client’s needs are foremost?
– “This is Bill’s personal request” — clearly the CIO won’t fire you for making his request a priority
– “Everybody knows this is a pain, so let’s do it first” — something widely known always wins over something obscure, just because it’s easier to justify and find support for
Why do this happen? Very simple: people are afraid. Afraid to show their lack of professionalism, afraid of being laughed at, afraid at their decisions being challenged, afraid of making a wrong decision and getting reprimanded for it. People are much more interested in their job security than in the performance of their organization. Naturally, taking responsibility for decision is percieved as risky.
How can we fix it then? In my opinion, by introducing a well-defined, almost mechanical, process that formalizes decision-making procedure. Most importantly, making sure this process gets buy-in and support at the highest levels of the organization (i.e. “the business” executives). Some people get freaked out at this point, thinking that taking responsibility off people and defining the rigid process kills accountability and agility. I say: it does not have to, if the process itself is agile and adaptable, and the people are made accountable for the overall performance of the process, not for individual prioritization decisions. More on this in a future post.
Making real prioritization decision is hard. It requires evaluating both tactical as well as strategical factors. And what is the most important strategical factor? Pleasing the client and the boss. Just kidding! It is, evolving the platform for stable sustainable growth of the business. Does it involve PR and politics? Yes. But don’t let the tail wag the dog.
