Leaders at all levels are supposed to constantly balance the needs of the business against the needs of its workers. Business Technology’s resident U.S. blogger Keil Hubert suggests that it’s all too easy for leaders to lose sight of the impact that their decisions have on the people most affected by them.
I’m no bleeding-heart liberal, but I do have a strong sense of commitment to the workers occupying the lowest level of a company’s organisation chart. When I joined the Army as a gormless teenager, I started off as a Private E-1. Truck tyres had more military value than I did back then; my only job was to help carry the wounded from one tent to another. It took two years of shut up and do X before I started having any say at all in my work life. That experience helped me learn subordination and humility in the pursuit of a higher purpose. It also helped me understand what it’s like when literally everyone else has the ability to dictate how you go about living your life.
That’s why I’ve made it a point to keep the line-level worker in mind every time that I try to build something, whether it’s a department, a product, or a way of doing business. Call me an idealist if you like; I expect everyone holding power to keep the grunts in mind, too. We’re invested with power to achieve the company’s business objectives; that doesn’t mean that we have any right to ignore the needs and expectations of the people working below us (regardless of whether or not we have any authority over them).
Sometimes good people lose sight of that principle. Those incidents raise my blood pressure something fierce. As an example:
It was late spring, first thing in the morning, before the official start of the duty day. I’d just finished a gruelling conference call when the manager of the next team over – let’s call him Armando – entered the cubicle farm and noticed that I was visibly building up to an explosion. He suggested that we stroll across campus to the company canteen for a takeaway coffee. After we’d gotten the usual morning pleasantries out of the way (e.g. ‘How was your weekend?’, ‘How are the kids?’, etc.) Armando asked me what the hell had just happened to torque me off.
I explained that I’d been burning the midnight oil for weeks trying to completely overhaul our division’s out-of-date doctrine library. I had dozens of policies, process guides, and procedure drafts in my queue to work that were all overdue. We had critical publications in production that had been obsolete for years. This was making it hard to satisfy auditors that we knew what we were doing. I’d discovered that I had to comprehensively rewrite all of our core publications since they all contradicted each other and were out of sync with actual production-floor practices.
Armando nodded. He seen all of the internal Requests-For-Comments messages that I’d been sending to the department about new drafts. By his count, we had a half-dozen new publications in-work – more new content in the previous week than the team had created in the previous year.
I nodded, and explained that the unexpected con-call had been initiated because the last three process guides that I’d submitted to the company’s technical review committee had all been rejected on an administrative technicality: ‘Apparently,’ I said, ‘the powers that be changed their publications standards recently and have decided that all process-level documents won’t be forwarded to the next stage of review unless they each include a RACIST chart.’
Armando told me that he understood how frustrating it can be to have your work undermined by an abrupt change in official standards – and agreed that it’s double frustrating when you waste days of work because no one told you that the standards had been revised.
We walked in silence for a while before things clicked in Armando’s brain. ‘I’m sorry,’ he said, ‘but what kind of chart did the committee want you to incorporate?’
‘They said that every process guide now has to include a bloody RACIST chart,’ I said.
‘Er,’ Armando said, ‘are you sure that you don’t mean a RACI chart?’
‘That’s what they call it,’ I said. ‘But they’re wrong.’
After a few seconds of awkward silence, Armando said ‘We are talking about the table that outlines who-all is responsible, accountable…’
‘…consulted and informed,’ I said. ‘Right.’
‘Um…’ He took a long drag on his cigarette, then said: ‘I’ve always heard it pronounced RAY-cee.’
Armando was doing his level-best to be supportive without antagonizing me. I adored him for the effort, but I couldn’t resist the opportunity to troll him just a little. Besides, I actually had a point to make and wanted to be sure that he remembered it.
‘Everyone pronounced it that way,’ I said, ‘but that abbreviated version of the acronym ignores the two most important groups affected by a doctrinal control.’
If you’re not familiar with the term, RACI charts [1] are tools used to define the levels of involvement that various stakeholders have in a complicated process. The most common type of RACI chart that I’ve seen lists the different offices or agencies across the top axis (e.g. legal, HR, janitorial, etc.) and then lists all of the core tasks in a long column. The rest of the table shows who does what for each task in turn in the form of an intersecting grid. If nothing is listed at the intersection of a task and a role, then that group isn’t involved in that step of the process. If a group is somehow involved, the intersecting cell will show one (or more) of the four role codes:
- R for Responsible. This is supposed to represent the people doing the work to complete the task.
- A for Accountable. This is whoever is ultimately answerable for the task getting done, even if they don’t actually do any of the work.
- C for Consulted. These are people who have to weigh in on some aspect of the task.
- I for Informed. These people are told what’s happened with the task but don’t do the work or offer any input on it.
Every place that I’ve worked does these charts differently. Some places insist that there can be only one code for a given cell; other places allow combinations (like ‘AR’). Some places insist that every cell has to be filled with at least an ‘I’ code; others disagree and can have all four codes in one block.
The largest point of contention that I’ve encountered has come from disagreements over which role is the pivotal one: one camp believes that there can only ever be one group responsible for completing a task, while multiple groups can simultaneously be accountable for getting it accomplished. This makes sense for something like new employee processing: both HR and Security get held accountable by their respective regulators for conducting background checks on new hires, but only one recruiter actually performs the background check on behalf of both stakeholders. The other camp takes the opposite position and insists that many different groups can be responsible for a task while only one can ever be accountable. This works when you declare that the first authority figure sharing dominion over all of the action groups has ultimate culpability for all of the individual functions. Personally, I don’t see why it’s worth arguing over – insisting that there can only be one right way to structure work is as silly as declaring that’s there’s only one way to paint a portrait. Misters Picasso and Pollack would poo-poo anyone insisting that there are inviolable ‘correct’ painting styles. But I digress…
All that said (I told Armando) the idea of incorporating a RACI chart doesn’t bother me overmuch; they’re occasionally useful tools for clarifying primary responsibility during a complicated sequence of back-and-forth activities. That said, I strongly disagree that they’re worth the effort that it takes to write them – especially when they leave off the two most important bits of the formula.
‘RACI’s fine for getting started,’ I said, ‘but it’s incomplete and not viable until you add the S and the T.’
To his credit, Armando just blinked and waited for me to drop the other proverbial shoe.
‘The S stands for, “Who’s getting S*** on?” by each step of the process.’ I waved Armando off before he could assemble a protest. ‘No, hear me out: we only ever codify processes in order to articulate what people must do when whatever they’re currently doing somehow doesn’t meet a standard. Management demands that people change their behaviour. That means that it’s probable that the newer, more efficient, more regimented way of doing things is going to inflict unwanted, burdensome or annoying requirements on someone somewhere, almost always at execution level.
‘I’ve found that it’s usually not the people listed as “responsible” or “accountable” that suffer when a new process is mandated,’ I continued. ‘Those are usually managers and other functional heads. The head of HR is accountable to get new-hire packages processed, but it’s the lowest-level clerks who type all the forms. Therefore, it’s critical to identify who-all is going to get metaphorically crapped on when the new standard goes into effect. Those are the people that you need to train, to encourage, to watch out for and to listen to when your new academic ideal is forced into production.’
Armando nodded, politely letting me rant until I ran out of passion.
‘That leads us to the T: “Who’s getting Terminated when this process goes pear-shaped?” It’s never anyone with an R or an A mark; those are always people in power. When you launch a new mandatory process, there’s a probability that the people affected by it will resist it – either on principle or because your new process sucks. That’s why we codify doctrine: so that we can hold defiant employees liable when they fail to follow it. That being said, the golden rule of corporate survival is to never take responsibility for the bad work performed by your direct-reports. Every high-visibility job gets a scapegoat; someone that the boss will pin the blame on and jettison in order to save his or her own hide.
‘These people marked for sacrifice often know who they are,’ I said. ‘People aren’t stupid. They know when they’re being used by the boss as a bullet shield. They resent being put in that position and they look for ways to escape their fate. That’s why you have to know who these marked people are in order to address their predicament and maybe minimize their exposure to unfair risk if you want them to help you ensure that your new process is adopted.’
Armando said that he could see my point. He didn’t like my acronym (conceding, however, that it was much easier to remember). He said that he understood and agreed with my assertion that effective process improvement required a great deal more focus on the impacted workers than on the managers, directors and executives that were abstracted from the actual labour while simultaneously benefiting from it. Armando had spent his years in the trenches as an individual contributor and shared my belief that work standardisation needed to be written with the execution level in mind first, last, and always. Doctrine that was written without the actual workers in mind usually only existed to make auditors and inspectors check a box – not to actually support work. We both considered pro forma documentation to be a waste of everyone’s time.
That’s where I had the most heartburn over the new bureaucratic roadblock: part of me was incensed that I hadn’t been at least informed that we were changing doctrine-writing policy so that I could address in the new required content before I submitted my drafts. Mostly, I was furious that I was being made to add a bunch of useless new content that added no value whatsoever to the final product and didn’t provide any benefit at all to the people who actually needed to read and heed the new performance standards.
Yes, we had certain products in the company that benefitted from the inclusion of a RACIST chart. I’d rewritten a complex interdepartmental security incident management protocol earlier that year that transferred responsibility back and forth between different groups at key process milestones. In that publication, it was critical to know who actually ‘had the stick’ on the operation at any given moment. Most of the doctrine that I’d written, however, didn’t receive any benefit from the inclusion of a RACIST chart; the same manager or director was in charge of the entirely of documented operation from start to finish. Crafting a complex chart and then arguing about it with an approvals committee was a huge waste of everyone time. It also took up space in a publication that was supposed to be short, terse, and focused on task execution.
Objections aside, we wound up obeying the bureaucrats-on-high. The review committee got their charts. The workers eventually got their doctrinal products. I never choked anyone out over the imposition of unnecessary work. Everyone went away happy.
More importantly, I got my point across to Armando. Hopefully, I’ve gotten it across to you, too. Odds are good that you’ll never be able to read about, hear about, or even think about a RACI chart again without mentally swapping the term ‘RACI’ for ‘RACIST’. Yes, it’s an awful, emotionally-charged word… but it works fiendishly well as an acronym for reminding people to consider the poor workers labouring at the bottom tier of the organisation when crafting a new process. Always remember the S and the T! If I’ve helped inspire you to be more compassionate and thoughtful when designing or revising work protocols, then I’ve done my good turn for the business community.
Moreover, if you can make some pretentious MBA spew his or her £8 Frappuccino in abject horror by casually mentioning to ‘RACIST charts’ in a process development meeting then we all win. Remember the argument and strike a symbolic blow for the dignity and glory of the grunts down in the trenches.
[1] Or ‘Responsibility Assignment Matrices’ or ‘Linear Responsibility Charts’, all of the terms and variations on the design refer to the same bloody thing.
Title Allusion: Harper Lee, Go Set a Watchman (2015 Book)
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on Twitter at @keilhubert.
You can buy his books on IT leadership, IT interviewing, and Horrible Bosses at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
–
