That's not to say they wont be thankful for your work - if you solve one of their problems or a problem plaguing the company, definitely alert them to it. By slack or email. Get those virtual high fives.
No need to gather people 'round to present.
(3) here seems to be the most important from my experience - and I'd reword it: demo your product through the lens of business value. Is this going to reduce toil letting engineers further up the stack move faster? Tighten feedback loops? Reduce pager fatigue? Reduce head count growth as the business grows?
My demos almost always have extra engineering work dedicated to the demo, visual aids, and a story that shows the evolution of the problem domain: how did we find ourselves working on this and what happens to the business if nobody solves this problem space?
Demos of obscure backend tech are most powerful if you can root them in language directors, VPs, and execs hear from the tech org on a regular basis. Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime will win you friends and get you valuable feedback on aligning/calibrating your work to business need.
From that perspective, I'd add: use graphs to tell the story. attach graphs of the system to business objectives. Make sure there's a solid communication around what the graphs mean (and what they don't mean, aren't measuring, etc).
All situation dependent, but solid data is something that's generally appreciated throughout the business.
> Attaching your work to the reasons they hear for things taking too long, costing so much, or causing downtime
> if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed
This comment reads grounded in practical, pragmatic, real world experience.
Talk backend stuff to decision makers and they will find a way to avoid (or worse pretend) to listen. Don't talk and they will never know your worth.
The middle ground here is to connect. My hack; I maintain 2 lists of key words from town halls, skip levels, one-on-ones and company-wide communications. A green list of things we want (targets, goals, visions). A red list of things we don't want (downtime, op costs, hardware cost, incidents, bad customer feedback, etc.)
Connect each chunk of backend work to at least one green item. If not, connect to the absence of 2 red items. Ideally both.
A slide with "Customer support costs from our last quarter's town hall meeting was at x cents per customer interaction. This self-help feature should avoid 3 of the top 5 common customer questions reducing the load on our customer service teams, dropping costs" delivers the message strongly as compared to a demo about the ingenious AI based (ugh!) routing mechanism.
The harder stuff is where things get expensive before the get cheaper.
Senior roles get harder. The work that actually matters is never discussed and impossible to define well.
But once we get around the nuances, there's way more impact that can be engineered from senior positions (while also distancing from the politics tarpit that people managers find themselves in)
On the other end of the spectrum we are being to forced to think of backend development in terms of user stories
- didn't identify the user - did't identify why the user needs a more generic api - what a more generic api would look like ... etc
Granted, it was just a quick demonstrative HN post, not an actual user story being handed to an engineer -- but it was very much framed as a incredibly open ended task.
I personally have mixed feelings on user stories vs tasks when it comes to the backend. Most managerial folk I've dealt with have an aversion to using anything internal to the company as a 'user' -- taking 'customer' a bit too literally.
In the grand scheme of things, I don't care...I've reached an exhaustion point with pedantry around tickets. Is it clear what needs doing? Is it clear what done means? Great.
As an internal user I want a more generic API So I can do more generic things
Is not a real user story :) Neither is:
As a CFO I want the API to be rewritten in Rust So I can pay less for hosting
They might be phrased like one, but user stories are meant to address specific user tasks or journeys, which doesn't work well for generic improvements.
I recently joined a startup, There’s about a dozen of us. Eng demos are scheduled weekly, which feels like a blog post so I won’t get into it here.
Sometimes there’s UI to click around and yes, people are slightly more engaged. However, we’ve had successful demos of infra / API stuff. The key, unsurprisingly, was to surface impact on tangible business goals. No point in trying to explain how Terraform works, but there is value in demoing why it works for your team, how it helps ship and operate infra with confidence, how it helps with repeatability, makes infra changes reviewable, etc. Of course, it’s incredibly important that the group sees demos as inviting and bring their curiosity to the room. If that’s not happening well, that’s a whole other problem.
Good rule of a thumb I tend to use is “half the presentation time for each X% of non-engineer audience”. If there’s 20 min of demo for eng peers, that needs to boil down to 10min as soon as one or two non-eng people join. Less time forces me to focus on value added rather than tech details. X will vary from org to org.
And of course it’s always good to offer more detailed demo in a more focused group later on (e.g. “for those interested in the details of how we use Redis, I can do another demo in a smaller group right after this call”)
Customers want to know what they are paying for.