People have multiple sources of information available all the time, and they hop freely from one to another. Authors don’t dictate the reading order, readers do. And with every hop, readers arrive at a new page one.
Mark Baker, Every Page is Page One
The internal IT team at most organizations gets killed by user support.
Okay, those are strong words. Truthfully, it’s not so dramatic. And if you’ve got your eyes open, your user support will help you grow valuable experience far quicker than it drags down your engineers.
But user support is a significant challenge that can stymie project progress. And unfortunately most of the problem is self-inflicted by organizations. We build and deploy buggy systems. And we allow buggy work processes to continue.
Bad QA. Or none at all.
You need someone to take responsibility for that. Product companies have teams of software testers and other folks with a primary job function to ensure quality. But somehow organizations don’t do that for their internal systems development. Quality may be viewed as a shared responsibility, but nobody executes their daily work with commitment to quality as the driving force. And a typical engineer or manager simply isn’t trained to ensure quality or to reliably identify process problems that allow quality to degrade.
Meet the QA Evangelist.
Not every organization is going to be big enough to have one. (Smaller organizations can partly make up for QA problems by being agile enough to quickly fix them, together with a collective willingness to accept unsolved problems.)
For organizations where it makes sense, the QA Evangelist is not a manager, and not an engineer. This role should be able to work across multiple teams, and should do so from the point-of-view of a subject matter expert who excels in promoting a quality mindset. But no good burying this role in the trenches as the only poor soul who has to do QA (engineer), or kicking them upstairs where they’ll be so embroiled in politics they can’t make a difference (manager).
QA should be approached not as a top-down mandate to eliminate all problems, but as a grassroots, consensus-based, pragmatic process whereby quality grows out of the team’s strengths, and in ways that make the team feel positive about the change.
Everyone thinks quality should be better. Everyone thinks it’s everyone’s job. But without someone in tech whose primary motivator is quality, your only chance at quality assurance will be to have an endless supply of nagging users who are very tolerant of unsolved problems.
Get ahead, and evangelize the solution!
It’s been a long walk through a lot of technology jobs and roles over the years.
Lately there’s been a trend in tech to create a role called “DevOps” – meant to bridge the gap between traditional development and traditional operations. So, when done right, it should align the goals and outcomes of “what gets built” and “what gets used.”
But it seems like the role usually gets applied to a very narrow field of technology – mostly the Unix / Linux world, and mostly about server deployments and rollouts.
I might be simplifying things. (But, hey – what’s wrong with simplifying things? :-))
I’d say, this idea of bridging gaps and aligning goals between “what gets built” and “what gets used” should apply to… everything that gets built, and everything that gets used!
In my various tech roles, I started out doing all sorts of desktop and server support. At the time, I always wanted to be a programmer. So at some point I became a programmer, then shifted back to more admin stuff for a while, then did a longer stint as a programmer. Following that I had a time as the guy responsible for making sure software quality was high (Quality Assurance) – that’s a kind of bridging of gaps between dev and ops, right?
Finally, I’m at a point in my career where I’m trying to pull it all together. Trying to use all the various bits of tech experience and organization know-how to add a type of value that most organizations seem to lack.
DevOps, in my view, is about ensuring that everyone in the tech department has the best tools available to build, do, and support their jobs.
Doing that requires knowledge of and experience with nitty-gritty configuration and service details, as well as the tools and brains to be able to query, modify, deploy, monitor, investigate, and support all the systems and engineering projects that depend on those details.
The field of DevOps spans development, quality assurance, operations, server support, user support, desktop engineering, application engineering, systems integration, software architecture, etc., etc…
Sound exciting? Yep, it is. 🙂