Ever been a Systems Administrator? I have (first job I ever had!), and I have to tell ya, it's a pretty thankless gig. I mean yes, there is the satisfaction of a job well done, the joy of knowing that everything is up and working to spec, etc., but, behind all of this, you are left with the knowledge that Nobody Cares Till It Breaks đ.
Mind you, it's not that they don't care at all. It's more like, from their perspective, "It's Working" is normalcy, steady-state, the way things should be. You don't get into a Toyota Camry, and say to yourself
"Hmm, I wonder whether the engine-block will fall out of the car on the way to work".
Engine-blocks remaining in the car is the default state of existence, and if one does happen to fall out of the car, then hey, it's definitely Bizarro-City!
And that, my friends, is what SysAdmins - and software engineers in general - deal with all the time. As far as users are concerned, systems are Toyota Camrys, and are supposed to Just Work. The only time they ever think of the engineers is when stuff doesn't work, and then, of course, it's the engineer's fault.
Mind you, what they donât see is all the sweat and blood that goes into making sure that the systemâs remain up and JustWork-ing. Put yourselves in the engineerâs shoes â youâre working your butt off, and the only time anybody reaches out to you is when something breaks, and there is always an undertone of âYou broke it!â in the reach-out. What youâre definitely never getting is any thanks for making sure that stuff worked the other 364 days of the year đ¤Ź.
But wait, it gets worse - as an engineer, youâre not just building new stuff, or maintaining existing stuff, youâre also making sure that bad stuff doesnât happen!Â
From planning scale-outs in response to user growth, to building out redundancy to deal with AWS regional outages, to having firewalls that can deal with DDoS attacks, to⌠well, you get the point. The engineering team is constantly working to make sure that bad stuff doesnât occur.
The thing is, nobody remembers catastrophes that were avoided! People donât care, because the bad thing didnât happen, the engine-block didnât fall out of the car, the user-base grew 10x without the system stumbling, the DDoS didn't take everything down, and so on. And this, in the end, is why Marketing is critically important for an engineering team.
You need to make sure that people know what the engineering team is up to, why they do what they do, and how essential it is. This includes both the work that is being done to maintain existing systems, and, the effort that goes into avoiding catastrophes.
Use all your channels â brown-bags, weekly reports, all-hands meetings, etc. â to spread the message. And for all thatâs holy, tell a story! Dry facts (story points covered, user stories completed, burn charts, whatever) don't help do anything beyond pointing out that there is activity going on.
Remember your audience â theyâre still thinking âToyota Camryâ, and itâs up to you to make sure that they understand that Toyota Camrys donât JustHappenâ˘, that there is a ton of work involved in design, and development, that youâre constantly testing for current and future issues, that youâre proactively monitoring for things that might happen, and that in the end, itâs hard to make things look easy!
And for this to work out, you need to get them to identify with the engineering team, to feel the work involved, and to relate with the engineers. So yes, always, always frame this as a narrative.
Incidentally, if you need any help learning up on Marketing skills, remember that youâve already got help â thereâs probably a marketing team (or, at the very least, âpersonâ) at your company thatâll only be too happy to help!
Mind you, this all assumes that your organization is operating in good faith. If, OTOH, youâve got a whole bunch of bad-actors, then, if youâve got agency, get the hell out of there, because things will go south eventually!