Lesson #18: You can't and shouldn't put a number to everything
Discover more from Lessons in Engineering Leadership
Lesson #18: You can't and shouldn't put a number to everything
Hello and thanks in advance for reading lesson #18 of Lessons in Engineering Leadership! Thank you to the 2,477 of you who have subscribed so far! If you’re new here, Lessons in Engineering Leadership is a bi-weekly(-ish) newsletter on a variety of engineering leadership topics that can be read in under 5 minutes.
If you would like to receive longer form newsletters and access to the tools I’ve created over time, you can become a paid subscriber.
I’m glad you’re here!
First off, some news!
I’m launching a course on Engineering Management! You can sign up for the waitlist here. I’m preparing the curriculum for this course now. If you looked at this before, look again! I updated the landing page with some more information on what I cover. I’m hoping to launch my first cohort this fall.
You can't and shouldn't put a number to everything
First off: I know I haven’t sent one of these in a minute. I’m sorry. I often preach consistency and I let this one slip on my own. Turns out balancing a full-time job with three additional freelance projects all shipping at the same time isn’t the best move.
Now for our (updated) regularly scheduled programming.
Yes, I am talking about the McKinsey report titled “Yes, you can measure software developer productivity”. Gergely Orosz and Kent Beck did a great job responding to this report with a two-part series (Part 1) (Part 2) so I’m not going to regurgitate everything they just said, but I will summarize two points that stuck out most to me and why this matters for you as an engineering leader.
1. Developers are more than just code.
I’m going to start with the end of the McKinsey report here, because this idea actually made me laugh out loud:
For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.
First off… what?!
Second… those “noncoding activities” are extremely valuable for engineers to build cross-functional muscles and relationships with those outside of engineering. Morale sinks when engineers are forced to work in a silo and focus on code and code only. They also miss a lot of context when they aren’t aware of what other teams are working on or how their work may impact others or the business.
I do think it’s important to minimize the number of meetings engineers have per day so they have the time they need to focus on the work at hand, but the idea that this time spent doing noncoding activities is time not well-spent is nonsense.
2. Measure at the team level, not at the individual level.
I can’t speak for every team out there, but I can speak for my team in that while I do my best to avoid context switching from one project to the next, engineers will occasionally have to jump into another project to help get it over the finish line if it has a tight deadline we’re working against. Engineers are working on projects with different levels of complexity – some, for example, may be updates to an existing feature, or some may be net new – and as a result, one engineer may appear to be “doing less work” than another. This is why lines of code, story points, etc. will never work as an accurate attribute. If you give someone the rules, there will always be people who will find a way to game the system.
This is why it’s significantly more important to measure success at the team level. Are projects getting shipped on time and according to schedule? What sorts of regressions are you facing, and how quickly are they remedied? Are these repeated regressions? How much time is being spent on net new work vs. infrastructure upgrades vs. bug fixes?
Any engineering manager can tell you who on your team may be pulling less weight. It’s obvious when you have boots on the ground.
And I think that’s the crux of the issue here. The McKinsey report wasn’t written for engineering leaders. It was written for C suite executives outside of engineering to try to fit a round peg in a square hole. Metrics are not one-size-fits-all – you cannot apply the same rules to Sales or Recruiting as you do to Engineering. Doing so sets a dangerous precedent for your team.
What I’m reading
Last time I wrote a newsletter I was on Season 4 of Vanderpump Rules. Proud to say I’m just about done with Season 8.
As far as reading goes, I candidly haven’t been reading much at all these days while I focus on wrapping up some freelance projects (the reason why I haven’t written a newsletter in a while).
Check out the full book list for recommendations and an ever-growing reading list.
Note: Links to books in this section are affiliate links to help support the purchase of the rest of my books :)
What I’m working on
It’s Groundhog Day again – also known as it’s somehow already time for me to begin working on our next SOC 2 audit. Wish me luck.
If this email was forwarded to you, be sure to subscribe to receive bi-weekly emails in your inbox that can be read in under 5 minutes!