How to give backend developers some limelight?

Question

Recognition is one of the main topics discussed after employees surveys in our organization. One of the points raised in a recent survey is, developers want to get more chances to be seen and recognized by others outside the team. It was cited that project managers get the chance to present the delivery of cool stuff in All-hands meetings (where senior managers are present) and usually given the credits (at least in public) for all the hardwork done by the technical experts. Wether the developers are after promotions or not, I believe it is a fair demand to get an equal chance to hear a praise from senior management. As a manager myself (first level), I try to do my part. However, as part of big organization, being recognized by senior management is a motivational factor (I have been there myself), and it is a ticket to the next career move

We raised this point to our senior managers multiple times. There has been a positive change. In the last All-hands meeting, one developer demoed a web application. However, the challenge I am facing now is the following:

Most of my team work is about building APIs. We build some web applications with frontend. But that is once or twice a year. APIs are too technical for our senior managers and they would not be interested in them. I recently had discussion with my manager. He suggested a good idea to demo the application which uses the APIs. Which is great, except these application built by other teams and usually come few months or sometimes a year after the APIs are delivered.

My question, how to help backend developers show their work to senior managers (who are not technical)

Note: I know there are multiple ways to motivate developers. My question is about the specific factor of recognition

Answer 1

Modern API and backend developers do have the tools to showcase their efforts.

• API documentation apps like Swagger (demo) and Redoc (demo) are, IMO, the bare minimum required for a handover of an API to another team
• The many popular operational dashboards can be used to display realtime stats via Grafana or whatever. If you're not tracking stats, then you can't demonstrate that your team has improved them
• Stats can be hooked into an ELK stack or whatever you use.

and that's leaving aside the more elaborate plays, like running up an internal hackathon to showcase some new APIs or make a public-facing third-party developer hub with fake data.

tldr; people like graphs and web sites, so use them

Answer 2

I simply expect people to do their job. And the more they make, the more I expect them to do their job. I expect senior management to do their jobs. I expect them to know that their web sites don't just work but that there is someone with lots of brains that makes it work. And that you don't notice them because they are doing their job well. (That's one thing that Microsoft got completely wrong during their destructive phase under Ballmer).

Doing work for the sole purpose of having something to show to senior managers is frankly pointless. Have a talk with your senior manager and put the onus on him.

Answer 3

What will the technology you've built enable?

The solution here is to present the team's work in the senior managers' language: business value. That's the focus of their job, that's what they'll give credit for.

The technical details are important, but they're the focus of your job, not that of senior management. A demo of the API conveys plenty of detail that's relevant to you, but nothing relevant to them that you can't simply tell them - it has this feature, it's reliable, it's fast, etc.

When presenting, focus only on what business value the tech you've built unlocks. Talk about what it'll enable to be built months and years into the future, and why that matters. Importantly, just because it's not a tech demo, doesn't mean engineers shouldn't be the ones to do it - they built it, and can absolutely be the ones to articulate the business value and take credit for that.

A final note, the fact that the concrete business value takes months to arrive isn't actually a problem. Again, frame it for the audience. Senior management are quite used to the model of doing something today, but only realising its value in several quarters' time. Far from being a problem, projecting months ahead is very much speaking their language!

Answer 4

This question reminds me about an old advertisement on tv. Can't remember what it was for, but the ad itself I remember. (I suppose that makes it a bad ad? But still a good example).

The ad shows an overly happy engineer running around the company, showing everyone he comes across a nickel and shouting "We now save a nickel on every transaction!"

He just gets confused looks from everyone that he tells this to, and everyone seems to think he's just a weird engineer come out of his cave being proud of some weird technical achievement.

It's not until the end of the ad, that he tells a few higher-ups this and they also seem annoyed, until one of them looks at the others and mentions "But, we make over one million transactions per day..."

So if you build APIs and you get the chance to show them to upper management, be that last guy. Don't talk about what you did. Talk about what the things you did mean to the company.

You didn't save a nickel on each transaction. You saved the company $50.000 per day. You didn't enable secure logins over the internet, you fixed the last hurdle towards securing Giant Bank Corp as a customer. You didn't expose some images to the web, you allowed customers to preview your products and thus raised sales by 15%.

The technology we build means something to others in the company. Focus on that meaning. (You really should do this even from before you build it, of course, but it's extra important when dealing with staff who don't care about technical details)