Let’s just get rid of these 3 badly named tech titles

I now see DevPrivOps. OK, I’m still with you …

What’s next, though, in the “DevInsertThingWeShouldBeDoingOps” trend? DevScaleOps? DevComplianceOps? DevTogaPartyOps?

Silly technical terms and job titles infuriate me, and this doesn’t stop at DevInsertTheBlankOps. Of course it’s the deeply technical and outwardly opaque world of software engineering where we have tried to overly specifically characterize the work we do and the roles we perform.

I’ve worked in product, UX and engineering for over two decades, and have held several of these titles myself, or have written job posts with these titles in them, and absolutely consider myself part of the problem.

More importantly, of course, is that behind these titles are wonderful humans who just want to make cool stuff. Nevertheless, let’s dive into where the best of intentions have left us scratching our heads, wondering how we ended up in this perplexingly esoteric panoply of titles and terms. My #HotTechTakes:

Hot take #1: The titles of product manager and product owner are confusing and ineffective.

About 20 years ago, we used to have business analysts (they figured out what the business would want) and engineering managers (they figured out how to build it).

This system worked. It was clear and simple, the biz analyst wrote requirements docs and used Microsoft Project to create lies for the execs, and the engineering manager messed around in — dear God, what did we have before Jira? I can’t even remember at this point, but it was truly awful — and figured out how to build it.

The point is, I see small startups hiring both a product manager and a product owner, and all that happens is they fight over who does what, and the engineering team feels left out of the whole thing as they have so little say in the remaining scraps. There is so little delineation in these roles it ends up creating nonsensical busy work instead of the two things needed: alignment on the outcomes needed from initiatives, and tactical plans on getting a build executed.

Plus, product manager abbreviates to PM, as does project manager and program manager — so that’s just chaos, too.

Hot take #2: The term “user experience” should never have been adopted.

Yes, I know the “UX” term has been around since the ’90s, but it really only got popular as a career and a job title in the past decade. Prior to that we had “designers.” True to the name, these designers had one job: It was to design stuff, and 99.9% of the time this was something on a screen and it was visual. It was the user interface, the UI, so they were “UI designers.”

In an effort to expand the remit of what designers did, and to make the practice holistic and consider more than just what was on the screen the industry moved from UI to UX. The UI term became looked down upon, as if designers weren’t considering the whole picture somehow. I get it; that’s good intentions.

Here’s the problem. UI designers and UX designers do almost exactly the same thing — so much so that now we’ve started to come full circle and you’ll see people talking about “new UX/UI,” “UX/UI bootcamps” and we have “UX/UI designer jobs.”

Let’s get real, UX and UI are the same thing, apart from that one time you designed a voice app. We all pretty much live in a world were tech is visual and on a screen. I find myself saying “UX/UI” often now, and I cringe every time I do.

Also we now have “UX researchers” which is a totally different practice altogether, and using the term UX with it just complicates things. When someone says “I do UX” I have to ask them what they actually mean.

Hot take #3: The term “agile” is so overused it has entirely lost its meaning.

Ever looked at a software engineering job post recently? 99% of them say that “we work in an agile process” like the company has collectively achieved cold fission and arrived at a new revelation previously unheard of. Let’s face it, unless you’re firing up a Gantt chart in Microsoft Project on Windows 95, we’re all either running a kanban or doing sprints at this point, so pretty much all software development is agile, at least for mobile and web SaaS, which is what I do.

However, what infuriates me is that “agile” has actually become a shorthand to doing two-week sprints using Jira, not committing to the work properly, badly estimating it it and not learning from retros. So agile now means poorly executed scrum.

Don’t get me wrong, I’ve nothing against two-week sprints. I even spent a delightful year with my former Comcast colleague Marc Ziss moving post-it notes across a whiteboard with a professionally trained scrum instructor and, while a bit heavy handed, the scrum framework by the book certainly does the job.

I’d just like to go back to the actual intention of agile. It would be refreshing to talk to someone running an agile software development process where they are pair program everything or write everything up on the whiteboard for the week on Monday and erase it on Friday (nod to my former colleague at both Comcast and Gopuff, Jack Beitler). That’s after all the intention of the word; to respond to change and learn as you go.