#platform-culture
Hello Platform Culture, Was wondering what the fi...
l
Hello Platform Culture, Was wondering what the first thing that comes into your mind is when you hear the phrase, "Improve Developer Productivity"
n
"lies" 🤣
"Improve Developer Productivity" has become very generic at this point. When coupled with the fact that a lot of places specifically don't invest in the things that make up developer productivity, there's an initial take that makes it sound like a disingenuous call to implement productivity metrics
I often want to her things like "reduce time to deploy," "lower friction in $process," and "treat the devex as a product feature" in the same sentance as examples of what is going to improve
l
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.
s
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.
c
Run….! lolsob
TBH - first thing (if that is not settled already) better hardware, like enough and big enough screens and powerfull machines. Second thing - optimize inner loop for local work. Third thing - have someone care for all needed collab tools and remote connections that are not yet self-service. Basically… let developers code 🙂 Oh… and then - platform engineering!
b
Removing TOIL …. I think its important that any ‘productivity improvements’ come from places where developers experience day-to-day pain.
l
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.
b
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.
l
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 🙂
n
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 do belie that linking developer productivity to distinct outcomes that solve real problems tends to be the best selling point.
l
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
the other neat thing is that you can tie that back into overall cost with looking at how much each developer is paid, and how many hours you save them from toil/year = total waste recouped
b
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.
c
Leveraging configuration policies to take the guess work out of yaml configuration.
b
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.
119 Views