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).
Experienced Devs
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
Fellow leaders.
Business impact.
Tackle challenges.
ππ‘
nope.png
A lot of organizations seem to focus on tailing indicators such as lines of code written, or the number of bugs found, and I think that's part of what fuels the perception that being an engineering leader is one of the most difficult roles in modern companies because they don't paint an accurate picture of how things are today.
The first thing is to get data that tracks key performance metrics. Many organizations often start with DORA metrics to create "slides for the board" that show the overall health of the engineering organization. This is a great place to start, but you can take this further by incorporating your project tracking into the data to measure how you allocate resources across the engineering function and whether or not that allocation is enough to meet product delivery timelines. There are a handful of tools out there that make this easy, like Sleuth and LinearB. A quick search should surface other solutions for this too.
I always explain what our software is about, i always talk about why we are implementing that feature and who is going to use it. This leads to sometimes they arguing with me about why should we make such feature and that is just a matter of the user getting used to
But usually this helps motivating them and give them a better picture overall of what we are doing. Sometimes having a meeting talking about the future roadmap of the product itself and how the planned features align to this also helps a lot for them to get the bigger picture and how their work is impacting
This is a struggle. I've found it helpful to use skip-level 1:1's to discuss this topic, and make sure my skip level knows ahead of time (and on an ongoing basis) that building this map (and helping to guide others through it) is a priority of mine so they can prepare at their level to provide information that I might be missing.
It's also a great opportunity to provide that same skip-level with the perspective from the engineers in the organization on the "flip side' of that coin. You're facilitating communication and alignment in both directions.
Hi friend, sounds like you should join us over in [email protected] :)
It is important, and effective, to properly track and show to teams what effect their code changes have to the system and what "their team's process" looks like to an outsider with meaningful data.
More here https://programming.dev/post/80365