3 ms·
I'm not sure I agree. It depends on the reason for doing a demo - if it's just for high fives or a pat on the back, probably not a demo worth doing. But a compa
by r3trohack3r 4y ago
I'm not sure I agree. It depends on the reason for doing a demo - if it's just for high fives or a pat on the back, probably not a demo worth doing. But a company needs bottom up leadership as much as top down leadership. It's important that backend engineers be able to surface critical work up through the org chart to get buy in on technical direction. Budget doesn't just manifest and if you don't align incentives with your work through bi-directional communication you're going to find yourself eternally understaffed at the expense of your teams health and the company's effectiveness.
(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.
- chrsig 4y agoFair enough points 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.
- gofreddygo 4y ago> what happens to the business if nobody solves this problem space > 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.
- rjbwork 4y agoThank you for this. I've recently been promoted into a very senior engineering role and feel out of my depth, especially WRT communication and politics. I think this is a really insightful way of connecting oftentimes invisible engineering work to the concerns of the business.
- gofreddygo 4y agoCongratulations on your promotion. 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)