Today's transactions: not what should define your employees or their roles
Photo by Christa Dodoo on unsplash.com
The premise of this article: Viewing roles as transactional is an obsolete way of thinking based on a 1960s view of how the corporate administrative machine should work. “Transactional” is nearly synonymous with “static,” and it’s been decades since any role should remain static for long. Static elements of your enterprise are not really static at all – they, and the enterprise, are actually falling behind as everything around them advances.
You shouldn’t have roles you consider transactional. You can’t afford them.
I recently had a fantastic interview with, I felt, a high probability of landing the job. Alas, even though I impressed the panel they needed “to fill a transactional role with someone that would be willing and content with taking on that lower level responsibility.” My “insights into potential systems and solutions that sounded fascinating” were not what they were looking for.
I have multiple reasons for trusting that this feedback was truthful, the most important being that the day before I received it an agency recruiter said the same thing about my presentation style, practically word for word.
The feedback is dead-on accurate because it precisely identifies a disconnect between how I present myself in interviews and what employers are looking for.
It’s simultaneously dead wrong because there is no such thing as a “transactional role”. They do not exist. They have not for at least 20 years.
You’re baffled and incredulous because you have dozens, maybe hundreds, of transactional roles in your organization.
No – you don’t. You have transactional employees who’ve chosen to execute roles in a transactional manner. Often this is because they don’t realize that it is a choice, that there are other options.
But, you counter, “transactional” is defined into the role irrevocably by the tasks assigned to it. No, that too is incorrect.
In my last position the employer needed a temp to cut and paste thousands of lines of Excel data between workbooks for six months. I was to open emails from clients, save the attached Excel files, QA them, do a bunch of cut-and-paste and copy select data points to a master workbook. Repeat thousands of times. Transactional, right?
Wrong. Six weeks in I wrote a software package that eliminated the task, both for myself and for the permanent staff performing the same work. Initially saving 800 hours, 18 months later when the function was centralized I joined the new department where implementation of my code saved 2,300 labor hours per year valued at $180,000.
A one-off, freak occurrence? Okay, let’s go back to the job before that, when I was hired again as a temp to cover a receptionist’s medical leave. Answer the phone, greet visitors, file paperwork. Absolutely transactional! Nope. Two months later during an SAP R/3 implementation I was responsible for late payment expediting, handling all vendor communications related to late payments and eliminating the payment backlog.
Granted, there was a bit of luck in landing there just before they flipped the switch on SAP. But the “receptionist” who two months before had known nothing about procurement, accounts payable, IT or SAP was their best bet to solve this technically complex, highly visible PR problem because I viewed reception as a problem-solving, solution-delivering role – not the transactional role that the employer had defined for me.
If the roles of receptionist file clerk and Excel copy-and-paste monkey can be performed in a non-transactional fashion and deliver substantial additional value to the enterprise, I defy you to find a role that cannot.
If we’ve laid to rest the notion that some roles are unalterably transactional (I feel we have, but I may be in the minority here; nevertheless…moving on…) then we need to consider, who cares? What does it matter? And if employers want to see roles as transactional, why shouldn’t they?
The simple answer is: surviving the competition.
By definition a transactional employee in a “transactional role” will be doing the same things the same way a year from now (or five years from now) as they’re doing them today, unless management imposes change. (More on that in a moment). “Transactional” means that a year from now that employee and their function will cost more than they do today. Even without a pay increase their benefit costs and everything spent to maintain them is going up: rent, electricity, insurance, telecommunications. And every employee requires support: IT, HR, payroll.
If your competition jettisons the notion of transactional roles and instead welcomes those roles contributing cost reduction and profit growth, then their profit is going up while yours is going down. They’re winning.
But what about the role of management? Aren’t they responsible for job descriptions, tasking, setting direction and implementing change? Yes…but does that mean these must be exclusively in the management purview? (Should they ever have been?)
There are two reasons this “management” authority needs to be spread around in the modern enterprise.
First, if management is solely responsible for recognizing the need for, designing and implementing every change to every process performed by every employee in their organization, that’s narrowly focused, in-the-weeds work that takes time away from strategic planning. It’s not where management should be focused.
Second, when transactional type people are hired and then resolutely guided in a transactional direction of thinking about their roles, the result is people who are emotionally attached to a list of specific tasks. “Their job,” that they identify with, is a fixed idea that abides no change.
Why are whole books written about the angst of having someone come along and “move my cheese?” Why have numerous CEOs written memoirs focused on the topic? Why is change one of management’s biggest challenges? Because companies designed their staffs from the very beginning to resist change and make it a problem!
If, instead of hiring “transactional” people wedded to transactions, you hire non-transactional people wedded to a broader set of concepts, not only will you invest less effort defining what changes are needed (because your staff will be doing half that work for you), the implementation of change won’t have to overcome the dead weight of staff resistance and even sabotage-by-inertia based on their emotional attachment to a fixed set of tasks. When people self-define as change agents responsible for evolving a role rather than as transaction processors, your organization will focus on stepping on the change gas pedal instead of reflexively slamming on the change brake.
Applying a transactional mindset to any part of operations is a profit and opportunity killer. Ditch it.
Going forward with recruiting, look not for the machines you think will be happy grinding away at a set of fixed tasks, but for the innovators – at every level, from managers to clerks – who believe that their duty is not to tasks, but to achieving potential – their own, and yours.