Excellent article, well thought out, a parsimonious distillation of the essence of day-to-day management. However it ignores a crucial issue in all management jobs, and that is credibility erosion. "Boss doesn't have a clue about the code". Which leads to "I'm cleverer than the boss" and creates a big management problem. So once in a while the boss has to show why he's boss, that he's amongst the best at the line-functions of the job. Nothing worse for team morale and productivity, than professional managers who do everything Tom Bartel has said here perfectly, but have no operational competence or credibility in the actual domain that the the team operates in.
In general, I agree, but it's also important for the manager to put together a team that respects him for his managerial ability rather than his ability to do the individual contributor's job. No respectable athlete evaluates his coach on his own athletic skill.
While your analogy is true, in that elite athletes do not evaluate their coaches on their current playing ability, the reason for this is obvious.
In almost every elite physical sport, the optimal age of physical participation, before the hardware starts to fail, is much lower than the age of the coach.
But in every elite sport, physical or otherwise, a coach is pretty much always someone who has previously been an elite player or participant. The reason for this is pretty obvious: the experience gained in the activity by the coach, the efficient passing on of higher orders of knowledge, and the gains from the division of labor/economies of scale from the coach/sportsman unit.
Indeed, if a coach can still compete, they don't become a coach, but split off and become a player/team, who then outsources the coaching aspect of his regime to a coach, but I digress...
Indeed, you see this or similar patterns in practically all professional activity that meets two requirements:
1. Requires a high amount of skill
2. The amount of skill required is easily objectively demonstrated/measured/competed against.
Be it sport, or cooking, or crafts, or trades.
Programming, I put forward, is no different. That is to say, the skill/craft of programming. If the art of programming and its application is what is desired, then skillful young programmers want skillful older programers as their managers/mentors.
The catch, is that employment of programmers is not in most corporate environments about the application of a skillful craft to produce a quality application.
Indeed, only in the corporate, tech, and political environments, do you see anything so obscenely parody-like as suggesting a coach/manager/superior be hired that doesn't have extreme knowledge of the field in which they are leading. For good reasons, if you suggested this in any other field that meets the criteria up there I suggest, you would either be laughed out of the profession, or naturally fail and be expelled anyway.
And that's because the norm of the corporate and business world does not meet the criteria I listed above, and is not about the application of skillful programming. It stems from two main problems:
1. The inability to easily measure connect a programmers/corporate teams/managers inputs to outputs and their relative values.
2. The real skill being applied in most corporate and business hierarchies being political savvy and salesmanship.
Thus we are stuck with the world of modern business theory and programmer application in a business context:
The idea that it is perfectly acceptable for a modern manager to have no knowledge of the thing they are managing. And if the main goal of a manager is politics and value-extraction, in a sad way, its actually true.
But it has nothing to do with the craft of programming itself. For that, I return to my original analogy: you want a highly experienced technical expert leading your team. I don't care how "accepted" it is that this is not the case in the corporate world, because such a position is not borderline insanity, it is literal insanity, and it would not be taken seriously for 5 seconds if it was the application of the skill of the team of programmers to their problem domain that actually mattered.
> in every elite sport, physical or otherwise, a coach is pretty much always someone who has previously been an elite player or participant.
It's a common refrain in many team sports that great players rarely make great coaches.
The majority of NFL coaches have no NFL experience. A handful didn't even play at the college level, and most of those that did played in "non-elite" college divisions.
If that is true (forgive me, I'm not from America and know nothing about NFL at all), then forgive me for being an ultra cynical bastard.
At some level, I'm taking it you're still telling me that they at least all played the game to some level, which is still a distinctly different level from common corporate messages that you wouldn't even have had to play or understand the game of the team you're managing. So it sounds to me like there's still some level of fundamental skill attribution there, though maybe not to the levels found in other sports/professions.
It is also true that the correlation between coach and skill is not perfectly bi-directional/symmetrical. Great skill does not necessarily imply great manager/coach. But my contention is that great manager/coach has some necessary correlation/causative connection with having great skill and that this connection grows stronger the more an activity relies upon high skill and the direct measuerable application thereof.
It is the nature of this connection, that one (coach) requires the other (skill), but that one (skill) does not imply the other (coach), that makes such positions so rare in highly valuable high-skill-verifiable games.
Of course, the other dimension of this analytically is the supply side: what is the shape of the skill curve (does it taper off quickly or is there a long tail), and how many people/resources are put towards producing people in this game.
As an ultra cynical bastard though, I think it would raise for me some interesting questions about the nature of NFL coaches, remuneration, players, how easy or hard it is to measure their skills and value their contribution to a team's success, how directly their skills affect an outcome of a game, how important/connected this application is to a team's success, and how much such things are the things being chosen for.
Now I should state that I've done a little bit of analytics on sports (primarily rugby and tennis) in my own time over the years, so the notion that such positions and remuneration in team sports is tied more to stereotypes, marketing, showmanship, reputation advertising and superstition in the team sports vs the individual ones/frequent contest/high-verifiable ones is actually what I would expect to see, rather than as something I think invalidates my theory. If you put sports on a spectrum, the variability and difficulty in finding empirical relationships between skill and game contribution does become increasingly difficult the more you move away from the frequent contest, high skill (by which I mean in a technical sense: the amount of variance in an outcome directly attributable to some kind of notion of measurable skill rather than randomness), individual participant games.
There's a whole lot more I haven't touched on.
/I also think, although I haven't put effort into analyzing it, so I accept it as a personal bias/belief at this stage, but I haven't found anyone else that has been able to demonstrate it, so I think i'm pretty safe, that there is almost no demonstratable connection between higher corproate executive remuneration and actual measurable skills/outcomes, and that this is this culture/phenomenon that explains where the "non-technical manager" idea comes from...
Just because I was curious, here's the actual breakdown:
Highest level of play by current NFL head coaches
NFL: 10
Division I: 7
FCS: 6
Division II: 2
Division III: 4
High School: 3
This is pretty generous bucketing, i.e. the NFL bucket includes people like Sean Payton (played 3 games as a replacement during a strike) and Gruden (practice squad player).
The DI/II/III breakdown is also based on the school's current NCAA status (not when the coach played), which is probably inaccurate in some instances as well.
I agree. Perhaps another way to generalize it is to say:
The ability to critique and improve the product of others is only loosely correlated to the ability to produce a high level product yourself.
Another place you can see this is in art production (written or visual, particularly). Many great art critics have only moderate ability as artists themselves.
Like I said, it's important for those managers to put together a team that doesn't have this attitude about their managers, and instead respects them for their ability to organize and lead the team forward, not nitpick other individuals for their lack of technical expertise. To recognize the difference in skill set is the mark of a great programmer. There are many, many examples in the industry of great non-technical leaders leading technical teams, Steve Jobs being the most famous one.
I'm a Perl dev and at my previous job my PM was an ex java dev, while the department manager didn't even had technical background (he was an economist).
This meant that the management had to completely trust us regarding the tech part of the project (estimations, technical solutions, overcoming obstacles, etc) while we trusted them with regards to the non technical issues of the project - mainly the non tech interactions with the customer.
The relationship between developers and managers was one of collegiality instead of a boss-subalterns one where everybody knew their role.
They were our facilitators and enablers, not our bosses, while we were doing our best to put them in the best position possible to the client.
Domain experts who have no clue about tech are doomed. They are still very numerous in business, treating the tech people as support staff, rather than strategic staff. Generally sprinkling tech in a haphazard way on top of an existing organization, instead of reinventing it. This is exactly why disruption has been so successful in so many industries. It's been, generally, just a case of swapping the hierarchy around in favour of tech. That said, I am of the opinion that tech experts who have no specialization in a specific domain, are also increasingly doomed. Being an awesome coder, by itself, is no longer enough because there is so much global competition in a skill which has low barriers to entry for millions of talented people. You have to operate at the nexus of tech and domain and therefore know both really well.
==
A good project manager is one who elegantly and deftly handles information. They know what structured meetings need to exist to gather information; they artfully understand how to gather additional essential information in the hallways; and they instinctively manage to move that gathered information to the right people and the right teams at the right time.
There are humans who are really good at this. They thrive on it. Engineers have difficulty believing this – it’s the same issue they have with managers. They see these strange humans focusing furiously and scurrying hither and yon and they wonder, “What are they actually building?” They’re right. Project managers don’t write code, they don’t test the use cases, and they’re not designing the interface. You know what a good project manager does? They are chaos destroying machines, and each new person you bring onto your team, each dependency you create, adds hard to measure entropy to your team. A good project manager thrives on measuring, controlling, and crushing entropy.
==
The way I feel about it after all these years is that you can have two different approaches, or types of bosses. One type is highly respected for their technical knowledge – let's pick Linus Torvalds as an example – and get respect that way. The other type is the boss who leads by morale: s/he might not even have any real technical competences, but is smart, nice and willing to listen, so you want to keep them happy.
A boss doesn't always have to understand the technical details, if they get can get respect by just generally being a wise person with a good grasp on general goals.
When you're a deeply technical person, it's often a good idea for a boss to stay out of your way, while still reminding you of the bigger outlines of the project.
It may just be my company, but over three engineering managers on three different teams, none have had a technical background enough to do any of the "line-functions" you refer-to to occasionally demonstrate technical expertise. There is a dynamic that has not been discussed that I think is important: Engineering Managers rarely have the experience or skillset of Senior IC's and it isn't about faded technical chops they once had. I disagree with the simplicity of the author's framing of an Engineering Manager "letting someone else do the execution". This can be toxic when the Engineering Manager presents this type of delegation to the rest of the organization and a Senior IC report is left undervalued and misrepresented.
If you are a 100% manager, then you will not be able to pair program for a long time as your programming/technologies competences will fade away quite rapidely.
Competence required in pair programming may be very different, though. A lot of times, a co-pilot who understands the fundamentals well, but doesn't know particular framework/library would still be a great service, just for asking the right questions.
There's only one measure of management productivity and that's the output of their teams. The go-to book on this subject is High Output Management by Andy Grove [1]. It is hands down the best book on management. I highly recommend this book to anyone who is transitioning into a role where you'll be leading people.
26 comments
[ 0.22 ms ] story [ 64.0 ms ] threadFor some reason this sentence took a while to make sense
If you spend a lot of your time coding, you are preferring an activity that others _also_ can do to something that only you can do.
If you spend a lot of your time coding, you are preferring an activity that others can _also_ do to something that only you can do.
Or maybe just change the whole phrasing:
If you spend a lot of your time coding, you are preferring an activity that someone else could do to one which only you can do.
In almost every elite physical sport, the optimal age of physical participation, before the hardware starts to fail, is much lower than the age of the coach.
But in every elite sport, physical or otherwise, a coach is pretty much always someone who has previously been an elite player or participant. The reason for this is pretty obvious: the experience gained in the activity by the coach, the efficient passing on of higher orders of knowledge, and the gains from the division of labor/economies of scale from the coach/sportsman unit.
Indeed, if a coach can still compete, they don't become a coach, but split off and become a player/team, who then outsources the coaching aspect of his regime to a coach, but I digress...
Indeed, you see this or similar patterns in practically all professional activity that meets two requirements:
1. Requires a high amount of skill 2. The amount of skill required is easily objectively demonstrated/measured/competed against.
Be it sport, or cooking, or crafts, or trades.
Programming, I put forward, is no different. That is to say, the skill/craft of programming. If the art of programming and its application is what is desired, then skillful young programmers want skillful older programers as their managers/mentors.
The catch, is that employment of programmers is not in most corporate environments about the application of a skillful craft to produce a quality application.
Indeed, only in the corporate, tech, and political environments, do you see anything so obscenely parody-like as suggesting a coach/manager/superior be hired that doesn't have extreme knowledge of the field in which they are leading. For good reasons, if you suggested this in any other field that meets the criteria up there I suggest, you would either be laughed out of the profession, or naturally fail and be expelled anyway.
And that's because the norm of the corporate and business world does not meet the criteria I listed above, and is not about the application of skillful programming. It stems from two main problems:
1. The inability to easily measure connect a programmers/corporate teams/managers inputs to outputs and their relative values. 2. The real skill being applied in most corporate and business hierarchies being political savvy and salesmanship.
Thus we are stuck with the world of modern business theory and programmer application in a business context:
The idea that it is perfectly acceptable for a modern manager to have no knowledge of the thing they are managing. And if the main goal of a manager is politics and value-extraction, in a sad way, its actually true.
But it has nothing to do with the craft of programming itself. For that, I return to my original analogy: you want a highly experienced technical expert leading your team. I don't care how "accepted" it is that this is not the case in the corporate world, because such a position is not borderline insanity, it is literal insanity, and it would not be taken seriously for 5 seconds if it was the application of the skill of the team of programmers to their problem domain that actually mattered.
mic drop
It's a common refrain in many team sports that great players rarely make great coaches.
The majority of NFL coaches have no NFL experience. A handful didn't even play at the college level, and most of those that did played in "non-elite" college divisions.
At some level, I'm taking it you're still telling me that they at least all played the game to some level, which is still a distinctly different level from common corporate messages that you wouldn't even have had to play or understand the game of the team you're managing. So it sounds to me like there's still some level of fundamental skill attribution there, though maybe not to the levels found in other sports/professions.
It is also true that the correlation between coach and skill is not perfectly bi-directional/symmetrical. Great skill does not necessarily imply great manager/coach. But my contention is that great manager/coach has some necessary correlation/causative connection with having great skill and that this connection grows stronger the more an activity relies upon high skill and the direct measuerable application thereof.
It is the nature of this connection, that one (coach) requires the other (skill), but that one (skill) does not imply the other (coach), that makes such positions so rare in highly valuable high-skill-verifiable games.
Of course, the other dimension of this analytically is the supply side: what is the shape of the skill curve (does it taper off quickly or is there a long tail), and how many people/resources are put towards producing people in this game.
As an ultra cynical bastard though, I think it would raise for me some interesting questions about the nature of NFL coaches, remuneration, players, how easy or hard it is to measure their skills and value their contribution to a team's success, how directly their skills affect an outcome of a game, how important/connected this application is to a team's success, and how much such things are the things being chosen for.
Now I should state that I've done a little bit of analytics on sports (primarily rugby and tennis) in my own time over the years, so the notion that such positions and remuneration in team sports is tied more to stereotypes, marketing, showmanship, reputation advertising and superstition in the team sports vs the individual ones/frequent contest/high-verifiable ones is actually what I would expect to see, rather than as something I think invalidates my theory. If you put sports on a spectrum, the variability and difficulty in finding empirical relationships between skill and game contribution does become increasingly difficult the more you move away from the frequent contest, high skill (by which I mean in a technical sense: the amount of variance in an outcome directly attributable to some kind of notion of measurable skill rather than randomness), individual participant games.
There's a whole lot more I haven't touched on.
/I also think, although I haven't put effort into analyzing it, so I accept it as a personal bias/belief at this stage, but I haven't found anyone else that has been able to demonstrate it, so I think i'm pretty safe, that there is almost no demonstratable connection between higher corproate executive remuneration and actual measurable skills/outcomes, and that this is this culture/phenomenon that explains where the "non-technical manager" idea comes from...
Highest level of play by current NFL head coaches
NFL: 10
Division I: 7
FCS: 6
Division II: 2
Division III: 4
High School: 3
This is pretty generous bucketing, i.e. the NFL bucket includes people like Sean Payton (played 3 games as a replacement during a strike) and Gruden (practice squad player).
The DI/II/III breakdown is also based on the school's current NCAA status (not when the coach played), which is probably inaccurate in some instances as well.
The ability to critique and improve the product of others is only loosely correlated to the ability to produce a high level product yourself.
Another place you can see this is in art production (written or visual, particularly). Many great art critics have only moderate ability as artists themselves.
http://randsinrepose.com/archives/entropy-crushers/
== A good project manager is one who elegantly and deftly handles information. They know what structured meetings need to exist to gather information; they artfully understand how to gather additional essential information in the hallways; and they instinctively manage to move that gathered information to the right people and the right teams at the right time.
There are humans who are really good at this. They thrive on it. Engineers have difficulty believing this – it’s the same issue they have with managers. They see these strange humans focusing furiously and scurrying hither and yon and they wonder, “What are they actually building?” They’re right. Project managers don’t write code, they don’t test the use cases, and they’re not designing the interface. You know what a good project manager does? They are chaos destroying machines, and each new person you bring onto your team, each dependency you create, adds hard to measure entropy to your team. A good project manager thrives on measuring, controlling, and crushing entropy. ==
If someone is promoted among his peers, they tend to get credibility if they showed assertive behaviour amongst their equals before.
If they were always subordinate and stayed out of conflict, they aren't recognised as a leader when they get promoted inside their group.
A boss doesn't always have to understand the technical details, if they get can get respect by just generally being a wise person with a good grasp on general goals.
When you're a deeply technical person, it's often a good idea for a boss to stay out of your way, while still reminding you of the bigger outlines of the project.
If you are a 100% manager, then you will not be able to pair program for a long time as your programming/technologies competences will fade away quite rapidely.
[1] https://www.amazon.com/High-Output-Management-Andrew-Grove/d...