It’s fairly common, in technology organizations, for there to be an elaborate hierarchy for prioritizing bugs and features, ranging from “P0″ (severely important) to “P4″ (not at all important) and for work items to be labelled as such. Of those five levels, the typical meanings are something like this:
- P0: severely high priority. This gives management and, ideally, the team, the right to be pushy in getting the issue resolved.
- P1: high priority. This is often an indecisive mid-level between P0 and P2.
- P2: default (average) priority. This is the classification that most features and bugs are supposed to be given.
- P3: low priority. Unlikely to be done.
- P4: very low priority. The black hole.
I would argue for getting rid of three of those levels: P1, P3, and P4. I don’t think that they do much good, and I think that they can actually be confusing and harmful.
Against “P3″ and “P4″
P3 and P4, in most companies, are effectively “will not fix” labels. It would be an embarrassment for an engineer to work on a P3 or P4 issue, because the corporate fiction is that every worker will always work on the highest-priority task (to the company, of course). Ergo, labeling a bug or feature below the default priority means that anyone who performs it is signaling that he or she has no P2-or-higher work to do. That’s not a good look. Even it’s the case (of having no P2 or higher work) one does better by finding work that serves one’s own career goals than by completing low-priority work in the backlog The only way it becomes socially acceptable to complete a P3 or P4 item is if it happens incidentally in the process of achieving something else.
If the issue, despite being labelled as low in priority, becomes an irritation to the developer, it’s often best to silently fix it and then close the bug later saying, “heh, I already did this, 6 months ago.” To do that is to feign not having been aware of the item’s low given priority, and to appear so productive and prescient as to have silently fixed bugs or completed work without even knowing that others noticed them.
What’s wrong with P1?
The case for getting rid of “P1″ is that it’s fundamentally indecisive. As far as I’m concerned, there are two meaningful levels for a task: Default and Escalated. “Default” is exactly what it sounds like: the typical, average level for work items. Except in a crisis, the majority of feature requests and bug reports will be at this level. At the Default level, it’s the kind of work that can be done without informing or tipping off management: you just go and do the job.
The Escalated level is one that requires the double-edged sword of managerial power. The workers need management to get involved and tell other teams to do things for them, pronto. It means that management has to suspend the right of the workers (which, during normal conditions, they ought to have) to prioritize work as they see fit. Toes need to get stepped on, in other words, or the work can’t proceed in a timely manner (or, in many cases, at all). It goes without saying that this shouldn’t occur for unimportant or even default-priority work, because the manager expends political capital in interrupting people (often, people who report to someone else) and asking them to work on things other than what they’d prefer. Since people on other teams are going to take hits, and the manager is going to spend political capital, it’s only fair that the employees who decided to escalate the work shall also prioritize the task above other things. This means that if they face deadlines and status pings and a support burden, they did at least ask for it by ringing the alarm bell.
In essence, the P0/Escalated level tips off management that the work item is very important, and pushes the manager to interrupt other teams and make demands of people elsewhere in the company, in order to have the task completed quickly. It’s a fair trade: information (that may be used against the worker or team, in the form of deadlines, micromanagement, follow-on work, meetings and future questioning) is given to management, but the manager is expected to pound on doors, get resources, and use his or her political power to eradicate bureaucratic hurdles (“blockers”). Setting a task at P2/Default level, on the other hand, conveys almost no information to management, but also asks for no political favor from the boss. It is, likewise, a relatively fair deal.
The indecisive mid-level of “P1″ combines the worst of both worlds. It tips off management, enough to get them interested and concerned, but doesn’t implore them to take immediate action and do whatever they can to fix the problem. It’s giving information without demanding (perhaps requesting, but that is different) something in return. It’s good to share information with managers, when you believe they’ll use it to your benefit and especially when you need a favor from one, but it’s rarely wise to take the risk of calling in a manager (or, Xenu forbid, an executive) if neither is the case. To do that is just to add noise to the whole process: it causes anxiety for the manager and chaos for the workers. The manager might not interrupt or change one’s way of working, but it’s a risk, and when you don’t need that manager to interrupt or change other people, why take it?
P0 says, “I’m willing to take your direction and commit to fixing the problem, but you need to trust me when I say I need something.” P2 says “things are under control. You can leave me alone and I’ll keep working on useful stuff.” Both are reasonable statements to take to management. P1 says “this is important enough to be watch-worthy but not that important.” With that, you’re just asking to be micromanaged.
What I am not saying, and what I am
In the above, it might sound like I’m taking an adversarial approach to managers, and that I advocate withholding information. That’s not what I intend to imply. “P0″ and “P2″ are artifacts of formal, written communication in a corporate context. In such a theater, less said is usually better. To put something in writing is to give the other person more power than to say it. To put something in writing in a corporate context is, often, to give power to a large class of people, because that information will be available to many.
If you have a good manager and a strong working relationship, you can verbally convey nuances like “I marked this as P2/Default but I consider it really important” or “here’s what I intend to prioritize and why”. There are good managers as well as bad ones, and it’s typically not the best strategy to withhold all information from them. That said, the more persistent and widely read a piece of communication will be, the more one should tend to hold back. Even if the information is helpful to the people receiving it, distributing it in such a way often shows a lack of care or self-preservation.
The information itself is often less important than the semiotics of furnishing it. To give information without expecting anything in return means something. It does not always lower one’s status or power; in fact, it can raise it. However, to give information formally, and in a context where the person is free not to read it and therefore cannot be expected to act on it, is generally a submissive move. To give information that expects little commitment from the other person but offers one’s own commitment (labeling a task “P1″ is implicitly promising to prioritize it) is quite clearly a subordinate action. And while it is reckless and often harmful (i.e. it will often get you fired) to be insubordinate (as in, disobeying a direct order) to management, it is likewise detrimental to be eagerly subordinate. The best strategy is to take direction and show loyalty, but to present oneself as a social equal. Toward this aim, “I won’t burden you with information unless it’s mutually beneficial for both of us” is the right approach to take to one’s boss. Over-volunteering of information is to lower oneself.
… and, while we’re at it, fuck Scrum.
I didn’t intend to go here with this post, but I’ve written before on the violent transparency— open-plan offices that leave the engineer visible from behind, aggressive visibility into day-to-day fluctuations of individual productivity– that is often inflicted upon people in the software industry. It’s actually absurd– much like the image of an Austrian duke wearing diapers and being paddled by a toothless, redneck dominatrix– that people can be paid six-figure salaries but still have to justify weeks and days of their own working time under the guise of “Agile”. It shows that software engineers are politically inept, over-eager to share information with management without any degree of self-auditing, and probably doomed to hold low status unless this behavior changes. So fuck Scrum and fuck “backlog grooming” and fuck business-driven engineering and fuck “retrospective planning meetings” and fuck any “whip us all harder, master” engineer who advocates for it to be imposed on his own colleagues.
… but back to the main point …
Prioritization is power, and so is information. Management has the final right to set priorities, but relies on from-the-bottom information about how to use that power. It’s probably true that all human organizations converge on oligarchy; democracies see a condensation of power as blocs and coalitions form and people acquire disproportionate influence within and over them, but dictators require information and must promote lieutenants who’ll furnish it. There are many ways to look at this, some optimistic and others dismal, but from a practical standpoint, it’s probably good news for a savvy underling in a notionally dictatorial organization like a corporation. It means that CEOs and bosses, while they have power, don’t have as much as on paper. They still have a need from below, and the most critical need isn’t the work furnished, because work itself is usually pretty easy to commoditize. It’s information that they require.
I am certainly not saying that information should be withheld from management, as if it were some general principle. I’m saying that it shouldn’t be furnished unless there is some tangible benefit in doing so. To furnish information without benefit is often harmful to the person to whom it’s given: it can cause anxiety and overload. To furnish information without personal benefit (although that personal benefit may be slight, even just the satisfaction of having done the right thing) will either confuse a person (and a confused manager often becomes a nightmarish micromanager) or show weakness.
Moreover, there’s a difference between personal, “human to human” communication that is often informal, and communication in the context of a power relationship. Many software engineers miss this difference, and it’s why they’re okay with a regime forcing them to put minutiae of their work lives on “Scrum boards” that everyone can see. If you get along with your boss, it’s OK to give up information in a human-to-human, as-equals way. At lunch, you can discuss ideas and relay which work items you actually think are most important. That’s one way that trust is built. If doing so will make you more trusted and valued, and if it doesn’t hurt anyone to do so; then, by all means, give information to that manager or executive. However, when you’re relating formally, in any persistent medium, the best thing to do is keep communications to “I need X from you because Y”. This applies especially to bug databases, work trackers, and email. Peppering a manager with extraneous information is not only going to identify oneself as a subordinate, but to add anxiety and extend the invitation to micromanage you.
When giving information to a person higher in the corporate ranks, it’s important to do it properly. One must communicate, “Hey man, I’m a player too”. That requires making communication clear, decisive, short and directed to an obvious mutual benefit. (It’s unwise to try to hide one’s own personal benefit; you lose little in disclosing it and, even if your request is denied, you’re more likely to be trusted in the future for doing so.) Communication should also be sparse: clear and loud when needed, nonexistent when unnecessary. One may choose to ring an alarm bell, demand response, and accept that some of the managerially-imposed inconvenience is likely to fall on oneself: that’s the P0/Escalated priority.There is also the option not to ring the alarm bell, but just to perform the work: that’s the P2/Default priority. Taking the middle and giving that bell a half-hearted ring is just silliness.
