Experienced Devs

3956 readers

1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

snowe@programming.dev

jmk1ng@programming.dev

drewsiferr@programming.dev

How do you measure the business impact of your engineers work? (programming.dev)

submitted 1 year ago* (last edited 1 year ago) by sn1pr0s@programming.dev to c/experienced_devs@programming.dev

14 comments fedilink hide all child comments

I've noticed something interesting about most of the engineers I know—they often lack a deep understanding of the business implications and overall impact of their work. As someone who recognizes the significance of the "bigger picture," I find myself spending a considerable amount of time explaining and demonstrating the real-world effects of our projects.

I often gather data from various departments, particularly sales & marketing, and present it to the engineers. It's amazing how engineers who grasp the big picture become more engaged and excel in their roles.

However, I face a challenge in collecting this "big picture" myself. I constantly find myself having to follow artifacts and communication channels from other departments, which can be quite overwhelming.

So, fellow leaders, I'd love to hear your thoughts on measuring the business impact and ensuring that our engineers are aware of it. How do you tackle these challenges in your own organizations 🚀💡

you are viewing a single comment's thread
view the rest of the comments

[–] canpolat@programming.dev 22 points 1 year ago* (last edited 1 year ago)

This can only be solved at organization level. First, I don't think there is a reliable way to measure business impact of an engineer's work. But I don't think that's necessary anyway. The organization should focus on the team, not the individual. Only real measurement you get is the customer feedback. And the best way to make it matter is to shorten the feedback loop. If in your organization some people write stories and then send them to engineers, your engineers are essentially not in the loop. Engineers need to be present (and asking critical questions) when you are defining the features. Only then can you expect the team to deliver what the customer wants. And that generally requires organizational changes (cutting the middle man, giving the team more autonomy in their work and developing a trust culture).