Once again, at potentially the worst possible time for my team, we are being forced to adopt a new company-wide process. My boss is encouraging everyone to participate early and get involved, that way we can provide feedback that will hopefully push this new process in a direction that will work better for everyone involved, but I could see the exhaustion and loss of morale on my coworkers’ faces as what was supposed to be a quick aside turned into an hour-long discussion. To be entirely fair to my coworkers, the only reason I wasn’t having a bad time is because it didn’t impact me and I’m already a heavy user of the tool being forced to fit everyone else. You see, the tool in question is a software development and bug tracking product with a well-built database and plenty of customizability, one that the software developers and testers have been using for over half a decade, to the degree that we barely think about it anymore (I’m not going to name names or get more specific than this for reasons of plausible deniability and keeping my writing away from my work life). What sucks for me specifically, though, is that there is rumor going around that all of the people who HAVE been using the tool in a way that works really well for us are going to be forced to use it this other way, that everyone else is using it, just so everyone uses the tool the same way.
To make it quite plain, that would make everyone’s lives miserable. This is, after all, a software for tracking software bugs and their fixes. Sure, you can adapt any system to do whatever you want if you’re loose enough with how things are defined and don’t really care about representing what you’re actually trying to do in any way that makes sense to anyone who hasn’t been specifically trained to use it in this exact way, but this software had a purpose and using it for things other than that purpose is necessarily going to create friction. A system like this, with accountability, history tracking, and a database that means information is never truly deleted, will do a lot of good when it comes to proving to some of the higher-ups at the company that R&D aren’t the ones clogging up the development process all the time, but that same goal could have been met so many other ways that it is incredibly mind-boggling that THIS is the way the person charged with implementing this system has chosen to do it. I don’t envy this person (someone I know in passing who is doing their best with the bad situation they were given) their task, but I can think of a few ways that they might have done to improve how they implemented things, such as actually talking to the people involved and soliciting feedback about what those people need or are looking for or how some kind of tool like this might be turned into something that will make their lives better rather than introduce a bunch of drudgery and pointless form-filling into their days.
Normally, I’m a fan of process. It can do a lot of good for people if it is designed well and maintained in order to ensure it isn’t becoming just another box to check. Most of the work I do doesn’t really need a process since testing is a lot of being actively engaged with what you’re working on, improvisation, and developing new test cases. There’s only a little bit of my day-to-day work that could possibly benefit from additional process, but I’ve done none of that work in at least a year thanks to the projects I’ve been working on. I’ve created a lot of processes along the way, though, most of which I’ve left in my wake to be worked on once the projects I’m doing are done and I have time for work that isn’t both important and urgent, so I’m sure I’ll be back to more regular, process-oriented work in the future.
Which is why this company-wide process bothers me. I’ve got a lot of experience creating processes for my team and trying to come up with good processes within the company I work for, so it feels very frustrating to me to see a lot of that work swept aside as the company tries to force something through with a bulldozer. There has been no attempt to find any needs to fill other than “one system” and this absolute lack of benefits to the people tasked with USING the system (rather than those who want to only have to go one place to see what’s going on in the R&D process) means people are going to need to be dragged into it. Worse, even, is that this system is complex and specific enough that it is absolutely not intuitive. Sure, once you’ve been trained on it and give yourself time to adjust to or explore it, it can actually be a great system, but I know of no one on my team who has the time to do anything like that right now. We’re in the middle of a massive, super-high-priority project with no end in sight, so the thought of needing to spend even an extra half an hour a day grappling with a new system that no one else in the company will be using yet (which means lots of duplicate work in the old systems and processes while everyone slowly gets brought on board over the course of who knows how long) soured their mood immediately upon being told what was expected of them.
This isn’t the first time my employer has done something like this. Last time, it was just the software side of things being shoehorned into a single system when every team was already working well with what they had and it went so poorly that eventually everyone stopped using it, found a new set of tools, and slowly converted to the one we’re using now. Everyone was supposed to wind up using it before too long, but it was a process of years and teams slowly changed when it was convenient for them and, since there was no one enforcing anything, everyone wound up using it differently until one team figured out a horrible, slap-dash way of using it that sorta worked that everyone eventually copied until the program had become such a bloated, unworkable mess that everyone swore off it outside of very specific uses. Which is also basically how things went with the testing software my company uses, except we testers figured out how to make it work and are unimportant enough that no one would ever approve for any of us to make any changes to how our teams work.
On a more personal level, I went through great pains to get both those systems working well for my team, even going so far as to work with our system admins to get customized versions of the software for us to use that better fit what we wanted out of the programs. I’m more willing than most to toss a bunch of work away when something better comes along or because someone shows me that I’m doing things poorly, but this new process doesn’t prove anything. Our reasons for being forced to adopt it are “because we said so” and nothing gets my goat quite like that kind of change. I hate doing things “because that’s how we’ve always done them” more than anything else, but “because we said so” is a close second. Things like this should be a conversation developed via feedback from those impacted, all held within the knowledge of what those people actually need (rather than what they say they need) as a result of observing them and knowing the systems you can build to support them well enough to give people what they want as a result of giving them what they need. Clearly, I’ve got VERY specific ideas of how to build and establish a process “correctly,” but doing just that is one of the things I’m the most proud of in my time with my current employer and one of the two things I’ve done that has made things better for the entire team. It’s just frustrating to see yet another example of why saying the word “process” will get people to immediately walk away from your conversation or, at best, just tune you out. It doesn’t need to be this painful! There’s another way! I guess that Active Listening view of process creation just isn’t really compatible with most company executives who all believe they got their jobs because no one else was suited for them rather than because no one else has been around as long as they have been or because they’re good at office politics. Confirmation bias is one hell of a drug.