This message was deleted.

"lies" 🤣

Makes sense, I was curious since I see it everywhere now and it feels overused and disingenuous to me, and wanted to see if others felt similarly.

I think of automating toil work and looking at the value stream to see what's getting in the way of their work. Usually the easiest win for a team's productivity is roadblock removal.

Run….! lolsob

Removing TOIL …. I think its important that any ‘productivity improvements’ come from places where developers experience day-to-day pain.

Yeah, removing toil is pretty much how we see it too vs trying to monitor how much developers are actually working, seems like doing things that make developers happier makes them more productive (Shocker huh). Just a bit tough to get higher ups to buy into that idea sometimes, but the results speak for themselves.

As you say, there’s a pretty simple story that underpins this, which I think anyone can get … happy devs write better code. I’ll often spin this around away from “productivity” and instead make it about waste. You’re paying top dollar for the best developers, yet you have them doing repetitive, menial work that they hate. If you keep going then they’ll leave and you’ll pay yet another recruiter to buy a new BMW. Or…. you could automate that stuff, make your developers happy, etc.

removing waste paints an excellent analogy in the mind of a non tech savvy person, instead of metaphorically standing over your developers with a whip and telling them to be more productive, thanks Bryan 🙂

Does that metaphor work well? I've tried it and sometimes get "🤷" from folks who are fine with waste / slack as a cost of "agility" or because they are "small scale"

I think it just really helps with the mindset shift Bryan talked about from galvanizing your team to work harder, and changing it to making the work they do easier and more engaging, which will make them more productive. If you're trying to run as fast as you can, maybe move the hurdles first before asking why aren't we getting faster

All my customers are pretty big, so they’re usually tuned into cost … or at very least, the lost opportunity of having your team running at capacity. In terms of “cost”, I try to have a word to their HR team about how much it costs to hire someone - in terms of their own internal labour, third parties, consultant fees, onboarding cheques, RSUs, training, etc. I find that most IT leaders don’t know that figure, so I’m able to come with something of value to them. The figure is usually a big surprise. Unfortunately, it’s also often absorbed centrally, so a ‘selfish’ manager might not care.

Leveraging configuration policies to take the guess work out of yaml configuration.

allow developers to do focused work. Reduce the context switching is super important. Either with different projects or even inside the same project (responding to e-mails, status reports, doing design, helping someone here or there….then coding, then more urgent emails, then slack threads, etc). It’s hard to implement this and needs strong protection of developers time.