Acronyms are there as easy to remind references for extended topics and obviously to somehow summarize them, and that’s great especially when you can use them as new words to quickly express relationships and get straight to the point (mentioning for instance a SLA, KPI, SOA, ROI and so on). Moreover, they could also be used as a simple and basic criteria to check their real appliance (which indeed is the part I like the most): if you claim to apply the SRP (Single Responsibility Principle), I could then check whether is there a single responsibility or not in the concerned component; if you claim to be an PM (Project Manager), I can check it against your acronym, whether is there a project and an effective management. If the applied acronym doesn’t really match the particular case, then something is wrong or at least it’s an alert to investigate further.
And you can actually perform that simple and basic check within companies, departments and projects (and on your own role as well, repeatedly over time) as a coherency and healthy control.
Among others, the most common broken acronyms we can encounter are:
- R&D (Research&Development): probably among the most abused ones. If research is indeed developing ideas and concepts, if yet developing a new product involves indeed research concerning the right technologies stack, approach, design, if hence research and development look so strongly coupled, then we should clearly always use such an acronym for any development team and as a consequence development should always be fun and challenging. But that’s obviously not true and it often happens that an R&D team should be actually called F&M, Fix & Maintenance, because that’s exactly what the team may be daily providing. Research is just an activity (and normally performed by just few members of a team) within the wider and more complex domain of development. It might sound cool, it might look promising and appealing, but in most of the cases R&D would easily be a broken acronym. If you fancy a change, consider PD (Product Development) or SD (Solution Delivery) instead, wouldn’t it be more honest and clear?
- HR (Human Resources): often disappointing, the human resource department mainly provides administration and coordination services, they will certainly be your (starting) contact point for interview, payroll and specific cases indeed, but focusing much more on the Resource part of its acronym, easily forgetting about the Human one. You can then meet HR assistants with a degree in Physiology or Sociology but concretely working with MS Excel, daily filling numbers and checking budgets, amounts, allocations. An RA (Resource Administration) would be much more precise when managing the human capital of a company. HR officers should focus on people empowering instead, not just organizing a company event but actively reviewing manager’s performances and their impact on teams and engagement (which also impact benefit and productivity of the company by the way). If you didn’t see your HR contact since years, if you didn’t even need to exchange emails or the communication is reduced to a recurring template (about time-sheet, about reimbursements, and so on), then it’s all about Resources, not much of Human indeed.
- TL (Team Lead): sadly, it happens to see leaders ending up just assigning tickets and caring about their final status, focusing on project deadlines, roadmap and business needs. It might be because of their workload or even due to a lack of soft skills, but when there is no follow up nor coaching, as long as there is no active team interaction nor cooperation, then that acronym is broken because team doesn’t simply mean pool of resources and leadership is something more complex than task assignment. TM (Task Manager) or RL (Resource Lead) would be more appropriate in such a case or you may also consider the PO (Product Owner) introduced by Scrum, to a certain extent though. Of course, you can’t pretend that each leader would act as a resonant leader, because that’s not an easy accomplishment indeed (neither impossible though), but you can however try to remind that acronym and focus on the Team as well, your subordinates will certainly appreciate, positively impacting on motivation and commitment (and, again, company benefit and productivity as well).
Conclusion
It might sound something silly, but verifying whether someone or some company’s entity is actually acting according to its acronym or not it immediately provides a quick and simple confirmation about evolution of responsibilities over time and proper working attitudes, about what somebody was supposed to do (or the initial intention of the role) and what he/she actually doing (any encountered gap could be a point of improvement). It should probably be the starting point of any peer review as well: remind me your acronym, now tell me what is your main activity, how do you accomplish it and in which part of your acronym you are weaker/stronger; if something sounded broken, then something should change, quickly.
| Reference: | Broken company acronyms from our JCG partner Antonio Di Matteo at the Refactoring Ideas blog. |
