Marketing the Engineering Team

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 JustWork™. 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.

/via https://xkcd.com/705/

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!