The thing about these types of posts is that no matter what you’re doing at work, you need to make sure that:
The things you’re doing are the things your direct manager expects you to be doing
The things you’re doing are written into the job description/goals you’ll be evaluated on at performance review time
The things you’re doing are trackable/measurable for showing to both your direct manager and other people in the performance evaluation loop
Tim did not almost get fired because management was clueless. Management may in fact have been clueless, but Tim almost got fired because both Tim and the author of this piece did not understand the above list.
Tim also is not “measurably unproductive”. You can measure what Tim does! Plenty of organizations know how to! As a lot of people are saying, what Tim is doing is really not that different from the typical high-level IC job description at many companies. And you can turn that into trackable, measurable, demonstrable-to-someone-else metrics. For example:
You can do code reviews, which have the names of reviewers attached to them and which most code-hosting/reviewing sites will spit out stats on.
You can take notes on and document pairing sessions, which will have the names of the participants attached.
You can codify discussions into documentation, which will have the names of the authors attached.
etc.
And that’s without getting into the “technical” artifacts, which someone at the higher IC levels still ought to be producing at least some quantity of. Some common examples:
Help to trailblaze on things that are new to the team. If nobody on the team has ever done <thing>, then guess what: as a senior IC it’s part of your job to be able to do the research and exploratory coding to figure it out. And that will leave behind artifacts with your name on them.
Implement libraries or other reusable solutions to common problems. They’ll have your name on them!
And, yes, do some “ordinary” line-of-business dev work. At senior IC levels you are expected to be a multiplier for your colleagues, and you can’t do that if you don’t know what might be slowing them down. Taking on normal feature development or bug fix work from time to time keeps you in touch with that and helps you spot the papercuts that you’ll then go and fix.
So. If you know a “Tim”, or think you may be a “Tim”, the thing to do is to get “Tim” to proactively have discussions with the manager about what the role looks like and how to measure the impact and making sure those are the things that are written down to be evaluated on. Because if that doesn’t happen, the default evaluation criteria for “Tim”’s level may be a completely different set of things that will get “Tim” quickly fired for not doing them.
The thing about these types of posts is that no matter what you’re doing at work, you need to make sure that:
The things you’re doing are the things your direct manager expects you to be doing
The things you’re doing are written into the job description/goals you’ll be evaluated on at performance review time
The things you’re doing are trackable/measurable for showing to both your direct manager and other people in the performance evaluation loop
I mean, yes, this is very good advice for not getting fired, but I don’t think it’s great advice for managing. Part of management’s job should be to identify when the above list conflicts with actual progress or benefit — which is what the author of this piece did. Yes Tim almost got fired because he wasn’t operating under this list, but I think the other half is the author of this piece not noticing and acting on this conflict before Tim was almost fired for it.
Tim sounds like a good staff/principal engineer doing “improve the team” work.
But, a minor caution.
The cruel equations come down to this: if you have four developers and a Tim, then the amount of extra work you get out of them by letting Tim mentor instead of deliver has to exceed what Tim would do as just a line developer. Say you have 4 developers who can each do 10 story points. Tim pairs with them, and they can now do 15 while pairing. If Tim can deliver 20 story points when not mentoring, then that’s a debuff of 15 points to the team (30 + 15 + 0 vs 30 + 10 + 20)!
This analysis doesn’t hold true all the time for various reasons, like:
The juniors retain their buff when Tim isn’t pairing
Tim is only occasionally putting out 20 points, but is usually 5 or less because he’s depressed and lonely and not mentoring
Juniors without Tim’s mentorship are unable to work on a story (for example, they can’t deliver without some base level of explanation of a legacy system or similar)
The really tricky part is that it’s comparatively easy to fake being a Tim if you have some social skills, and then you can easily ask basic questions (consider Eliza Tim: “And how do you know that this is the right data structure?”) and flatter people and help them feel like you’re mentoring them, and that’s the social proof you need to avoid having to do real work. These Fake Tims (and they can happen accidentally from developers who misunderstand their mandate!) take up valuable space in an org chart and left untreated can silently tank the efficiency of your team.
If you don’t believe that this is possible, consider a common way that orgs fail their juniors: letting them pair with people all the time and yet never drive or get their names on the work/tickets…so when perf review time comes around, there’s no concrete evidence of their competence that can be used to justify raises or promotions. The mechanism of action is similar.
This makes sense if you think of productivity as the amount of code that is created.
However, code is technical debt. What a computer engineer actually provides is maintenance of a codebase, availability of a service, and health care of a distributed system. If Tim carries a pager, then Tim is doing most of what he is paid to do!
A similar calculus applies to senior engineers (or any engineer, really) prioritizing internal tooling over feature work.
The main difference there being that typically once a tool is created everybody can use it, so it tends to be a team-wide buff, and also that it by default survives the departure of the creator (until systems change).
It’s also possible that the tool moves the team to another Pareto frontier (much like how a mentor can, if the mentees hang on to what they’ve been taught, move the entire team to a new level).
It’s so depressing making internal tooling that works and does increase productivity when used, but then failing at the adoption step because people are too busy to train. The soft skills for pushing adoption through the org take you even further from the feature work. It’s definitely a trap that you can fall into if you aren’t careful.
For some reason, I always end up finding myself in this position in every org I join and I’ve noticed that getting people to use your tooling is another soft skill you learn by experience, but I think there are some common principles:
Make the tools extremely accessible! If it’s possible, deploy the tool as a public web application behind OAuth, it should be one bookmark away and zero mental overhead to reach it. Or if it’s a CLI application, make it accessible without any effort. My tools can usually be run by nix run github:myorg/sometool, zero installation or update effort, one bash alias away. Whatever the medium, make it zero effort to access the tool.
Mention it all the time, everywhere without asking people to use it. In every single PR or Slack message that you use it, include the full instructions to access the tool and the steps you followed with the tool. Of course don’t spam communication channels, instead put the details in Slack threads or <spoiler> tags on GitHub. When someone decides to give it a try, they should have a million examples to look at and the examples should show up all over the place.
It’s generally the “third generation” that fully adopts the tool. You are the first generation, the people you teach are the second generation. The second generation will never make full mental commitment. They’ll always think of it as the thing you know about. If you follow the previous two points they’ll start using it here and there, but they won’t ever read the README or –help. But the people that learn from the second generation, aka the third generation will see the tool as a treasure trove of valuable functionality they can learn to impress the second generation.
So, make it accessible and mention it without pushing it and then be patient, your real users will come after a delay.
I think of this in terms of additive and multiplicative effect. How much do you add to the team by your own work and by how much do you multiply the efficiency of other people. Some developers have multiplicative effects less than one. They make everyone on the team less productive. For junior people, that’s fairly common but the hope is that it’s a short-term thing: you train them and their multiplicative effect at least reaches one (they do work, they do not positively or negatively affect other people’s work) and ideally reaches more than one (they make everyone else’s work better by doing glue activities).
Like every tool, when poorly used, it gives poor results.
Management is all about human beings ; if a manager doesn’t know their direct subordinates well enough to realize that one of them is actually a coach for the others, then the team has a critical management issue, whether it comes from the manager or the organization.
The thing about these types of posts is that no matter what you’re doing at work, you need to make sure that:
Tim did not almost get fired because management was clueless. Management may in fact have been clueless, but Tim almost got fired because both Tim and the author of this piece did not understand the above list.
Tim also is not “measurably unproductive”. You can measure what Tim does! Plenty of organizations know how to! As a lot of people are saying, what Tim is doing is really not that different from the typical high-level IC job description at many companies. And you can turn that into trackable, measurable, demonstrable-to-someone-else metrics. For example:
etc.
And that’s without getting into the “technical” artifacts, which someone at the higher IC levels still ought to be producing at least some quantity of. Some common examples:
<thing>, then guess what: as a senior IC it’s part of your job to be able to do the research and exploratory coding to figure it out. And that will leave behind artifacts with your name on them.So. If you know a “Tim”, or think you may be a “Tim”, the thing to do is to get “Tim” to proactively have discussions with the manager about what the role looks like and how to measure the impact and making sure those are the things that are written down to be evaluated on. Because if that doesn’t happen, the default evaluation criteria for “Tim”’s level may be a completely different set of things that will get “Tim” quickly fired for not doing them.
I mean, yes, this is very good advice for not getting fired, but I don’t think it’s great advice for managing. Part of management’s job should be to identify when the above list conflicts with actual progress or benefit — which is what the author of this piece did. Yes Tim almost got fired because he wasn’t operating under this list, but I think the other half is the author of this piece not noticing and acting on this conflict before Tim was almost fired for it.
Tim sounds like a good staff/principal engineer doing “improve the team” work.
But, a minor caution.
The cruel equations come down to this: if you have four developers and a Tim, then the amount of extra work you get out of them by letting Tim mentor instead of deliver has to exceed what Tim would do as just a line developer. Say you have 4 developers who can each do 10 story points. Tim pairs with them, and they can now do 15 while pairing. If Tim can deliver 20 story points when not mentoring, then that’s a debuff of 15 points to the team (30 + 15 + 0 vs 30 + 10 + 20)!
This analysis doesn’t hold true all the time for various reasons, like:
The really tricky part is that it’s comparatively easy to fake being a Tim if you have some social skills, and then you can easily ask basic questions (consider Eliza Tim: “And how do you know that this is the right data structure?”) and flatter people and help them feel like you’re mentoring them, and that’s the social proof you need to avoid having to do real work. These Fake Tims (and they can happen accidentally from developers who misunderstand their mandate!) take up valuable space in an org chart and left untreated can silently tank the efficiency of your team.
If you don’t believe that this is possible, consider a common way that orgs fail their juniors: letting them pair with people all the time and yet never drive or get their names on the work/tickets…so when perf review time comes around, there’s no concrete evidence of their competence that can be used to justify raises or promotions. The mechanism of action is similar.
This makes sense if you think of productivity as the amount of code that is created.
However, code is technical debt. What a computer engineer actually provides is maintenance of a codebase, availability of a service, and health care of a distributed system. If Tim carries a pager, then Tim is doing most of what he is paid to do!
This study seems to be about some of the more self defeating aspects of measuring productivity that way
https://lobste.rs/s/fza8kq/it_s_like_coding_dark
A similar calculus applies to senior engineers (or any engineer, really) prioritizing internal tooling over feature work.
The main difference there being that typically once a tool is created everybody can use it, so it tends to be a team-wide buff, and also that it by default survives the departure of the creator (until systems change).
It’s also possible that the tool moves the team to another Pareto frontier (much like how a mentor can, if the mentees hang on to what they’ve been taught, move the entire team to a new level).
It’s so depressing making internal tooling that works and does increase productivity when used, but then failing at the adoption step because people are too busy to train. The soft skills for pushing adoption through the org take you even further from the feature work. It’s definitely a trap that you can fall into if you aren’t careful.
For some reason, I always end up finding myself in this position in every org I join and I’ve noticed that getting people to use your tooling is another soft skill you learn by experience, but I think there are some common principles:
nix run github:myorg/sometool, zero installation or update effort, one bashaliasaway. Whatever the medium, make it zero effort to access the tool.<spoiler>tags on GitHub. When someone decides to give it a try, they should have a million examples to look at and the examples should show up all over the place.So, make it accessible and mention it without pushing it and then be patient, your real users will come after a delay.
I think of this in terms of additive and multiplicative effect. How much do you add to the team by your own work and by how much do you multiply the efficiency of other people. Some developers have multiplicative effects less than one. They make everyone on the team less productive. For junior people, that’s fairly common but the hope is that it’s a short-term thing: you train them and their multiplicative effect at least reaches one (they do work, they do not positively or negatively affect other people’s work) and ideally reaches more than one (they make everyone else’s work better by doing glue activities).
Like every tool, when poorly used, it gives poor results.
Management is all about human beings ; if a manager doesn’t know their direct subordinates well enough to realize that one of them is actually a coach for the others, then the team has a critical management issue, whether it comes from the manager or the organization.
Agile Manifesto says this another way:
… meaning that processes and tools can obviously be used, but not without human wisdom and goodwill.