Hacker News Reader

Comment by phyzome | Hacker News Reader

Align it with business needs and observable outcomes.

Does the company suffer from outages? (Not just have them—but actually suffer from them.) When there's a production incident, do a root cause analysis. If some of the root causes are related to coding and deployment practices, make notes of that. Start aggregating that information. Soon you'll have evidence that you can reduce outages by changing practices.

Does Product feel frustrated by development speed? Start taking surveys. How much time is spent on fixing past mistakes/dealing with bad code/discovering broken tests? That can be used as evidence too, when you want to start a conversation with management about pausing in the race to tie your shoelaces.

View on HN

Also do 1 thing at a time. Do not try to do them all at the same time. That is a fast track to nothing being done. Put them in order highest to lowest pick of an 'easy' win. Make it easy for people to want to do the right thing. Once in place retro it. Is it working? Why not? CI/CD takes time to build. These devs probably have not done it before and have no interest in it. Because they do not see any benefit. Also be sure you want this. Because in a small group you will own it for a long time.

Agreed. I've found that part of the problem is how we (engineers) communicate value to non-engineers. It's not right to get upset with a laymen/business people without putting some effort into explaining. I've always found this type of communication effective:

- This database change will improve our page load time from 3s to 1s at the cost of 25% of a sprint's capacity.

- This library version change takes X amount of time because there are 45 sites in the code we need to change, and that impacts 120 test cases which we need to rerun.

- Not adopting this <security tech> puts us at risk of an incident like <example incident from the news>.

I've noticed that (low- to mid-level, at least) business, marketing, and other folks are generally a whole lot looser with their numbers than developers are. That is, they'll toss around measures that aren't meaningful—and not just in some quibbling sense of "well technically maybe these could possibly be wrong" but truly are very likely to be way off the mark—because they didn't properly control for confounders or are clearly measuring the wrong thing or whatever. They'll assign meaning to measures that could easily have nothing to do with what they're saying they mean, or mean the opposite.

... but this usually goes over just fine. Rarely questioned. I think if they didn't do this they'd be just as bad off as developers, if not worse due to (again, generalizing) having a worse understanding of how to measure things well.

Reply on news.ycombinator.com