I had this exact same conversation with a manager who seemed suprised when I told him people are not interchangeable cogs. He said that some people may be quicker at a particular technology / domain / whatever, or quicker to ramp up, or do slightly better work, but smart engineers can and do learn anything needed and do work that's good enough after a ramp-up that's short enough. Beyond that, he says, there are minor differences he doesn't worry about as a manager.
This is largely a natural difference in perspective.
The typical interaction between manager & engineer is that a manager tells an employee what to do, and the employee does it. From the manager's perspective, any employee that's reasonably competent will do: success is binary, either you did the assigned task satisfactorily or you didn't.
From the engineer's perspective, if you're good you considered a lot of alternative ways of solving the problem and finally settled on the best. It seems ridiculous that all employees could be interchangeable, because it's a pretty good bet that some engineers did not consider some of the alternative solutions you did. But remember that the whole reason the manager hired you was so that he didn't need to think about the details. All of those alternative solutions are outside of his conscious awareness; he's condensed his mental model of the problem to a binary "is this good enough to ship?", which frees up mental space for him to think about other stuff. Among those engineers that you think of as "not good enough", there are some who may not have thought of the brilliant solution that you came up with but still have code that is "good enough to ship" in the manager's estimation, and those are the irritating folks on your team who IYNSHO always produce shitty code but stay on the team because they have your manager's political favor. And then there are the folks who both you and your manager agree are too shitty to get the job done, and they're fired.
Who's right? Well, both of you, and neither of you. It's fairly likely that you're overestimating the quality requirements for the job, which is why a number of your shitty coworkers still have jobs. It's also fairly likely that your manager does not have complete visibility into all the long-term consequences of all the code being produced, which is why whole teams occasionally just catastrophically fail.
But it's worth remembering that every time you enter a transaction, you're having your work reduced to a pass/fail grade. It's the fundamental bargain you make when you take a job, and it also is the fundamental bargain you make when you sell a product (entrepreneurs are not exempt from this, and it's a major cause of startup failure among technical founders...including, quite possibly, mine). The advantage of producing better work is that it qualifies you for more different opportunities - which may or may not be relevant, depending on whether you take advantage of those opportunities.
> But it's worth remembering that every time you enter a transaction, you're having your work reduced to a pass/fail grade.
This is true as an employee and as a contractor and as a business. The nice thing about transacting as one of the latter two is there is no pretention of the transaction being anything other than a binary one.
I'm still working on the 2nd (or 5th, or 11th, or ~50th, depending on how you count)...not exactly ready to declare it a failure, just, well, a whole lot of pivots.
It's sort of true but a very one-dimensional view on an individuals contributions which is a bit worrying coming from a people manager. I think its funny people go around lionizing individual technical skill and at the same time insist that people are interchangeable.
In my experience most programming jobs don't really require deep domain expertise or share it by osmosis. Ideally a smart, dedicated person that gets a 40 hour a week crash course from experts in the field should get up to speed reasonably quickly.
In the absence of experts there exists a whole slew of technology that democratizes hard fields like game creation and machine learning. You can commit all sorts of sins and still end up with a well functioning product. Partly resting on technology developed as an enabler and partly resting on the sheer amount of available compute.
IMO people are far more easily replaced in terms of making an individual code contribution than they are as members of a team and it's the latter that is significantly more important. Good teams are multipliers for their members. Replacing a team member in a well functioning team is a super risky prospect. Yet we live in a world of frequent re-orgs, teams smooshed together haphazardly and overvaluing individual technical skill.
I don't see that changing anytime soon as it all sort of works and there is an endemic lack of interest.
Outside of truly unique skills, it's basically true - engineers are interchangeable with sufficient time to ramp up.
I learned this lesson pretty early in my career when most senior engineer on the team left. I and everyone else freaked out because he was the only one on the team who fully understood how everything works. But you know who was not freaked out? My manager. And he was right, we did not even miss deadlines. In two month everything was back to normal with other people filling his shoes.
Obviously you can't replace Principal engineer with fresh grad and expect success but most of the work done is not that unique or hard.
>Outside of truly unique skills, it's basically true - engineers are interchangeable with sufficient time to ramp up.
That qualification at the end makes it false.
If I have to give someone 1 year to learn all of the minute details of the behavior of TCP across the various operating systems clients use, the behavior of packet re-ordering in LAG algorithms, convergence times of BGP, etc, then they are most definitely not interchangeable with someone who does know these things.
Any manager who thinks this way is incompetent and will impose massive opportunity costs on the company by not fighting for raises for existing good employees under the guise that they can be easily replaced.
Everything's a matter of degree. So maybe it takes longer or shorter depending on how big the shoes are. But that bundle of knowledge you cited seems learnable in a year.
> I learned this lesson pretty early in my career when most senior engineer on the team left. I and everyone else freaked out because he was the only one on the team who fully understood how everything works. But you know who was not freaked out? My manager. And he was right, we did not even miss deadlines. In two month everything was back to normal with other people filling his shoes.
Have you ever looked around the room and asked yourself "gee, why do we have so many coworkers on this project?" Or said "isn't it nuts that there are some weeks when I can measure my productive output in a handful of hours?"
The current vogue in management is cramming teams into an open floor office and micromanaging scrum points; these measures are introduced because they demoralize and _average_ output, thus introducing slack into the system. That's not a bug -- that's a feature! When someone important leaves the workers can be motivated or "motivated" to increase their output until the proper amount of slack is reintroduced from a hire.
" I don't doubt that has been true on all the teams you've managed. My experience differs significantly, and there's a lot of data which indicates my experiences may have been more representative. Caveat Emptor, of course
I didn't know how to respond to that.