It always seemed to me that people with more of a managerial background would be better managers - is software/system development the only field where masters of their craft ultimately become directors?
People with managerial backgrounds have....what? Nothing really. They have to guess at any plan presented by technical people, are always suspicious they are being screwed over on estimations and real problem areas, and are unable to correctly identify when people are doing good work -- thus also being unable to set a healthy engineering culture for success. That's why most managers are demoralizing for engineers. They just don't get it.
It's interesting to note that alot of the most successful startups in SV are not from MBA's but engineers with masters or PhDs....it's not a coincidence I think. They have the practical experience to lead a real world venture to success.
Managers are good at managing departments like insurance claim processing or bad debt collections, which any human can learn in a few weeks fundamentally.
People with managerial backgrounds can become quite adept at helping you:
- Identify blindspots in your biases and behavior that keep you from peak performance
- Avoid working on stuff that's not valuable to your team
- Settle disputes within a group
- Motivate you and keep you engaged/fulfilled with your work
- Get unstuck with personal problems
This is not an exhaustive list and you don't have to have a 'managerial background' to master stuff like this. I am an engineer who has had to learn management as a startup founder. I used to distrust the whole management thing but that kept me from growing as a teammate. Management is not only useful in 'non technical' jobs, it's useful in all human endeavors it's why we study it so much and why it has so much leverage.
Managers in the middle of the food-chain are all about power-struggle and social games they play to out-compete each other.
That is especially the case for non-technical managers who don’t have a sense for the underlying technical challenges. They have all their bandwidth available for political positioning and social games.
It would be great if all managers where “serving the team” in the sense of your bullet points. But alas many don’t see it that way.
IMHO many startups are successful because they have a technical person at the top. Who is capable to understand, evaluate and positively reward technical work within their organization.
In tech and pretty much every company I've worked at, you need to get into a managerial position to be able to have a say in what get built and how much you get paid. Programming fatigue and frustration with being told what to do also sets in after a while. The two together convinces people who are terrible with their people management skills to chase a manager-path career.
Essentially, you're diagnosing the symptom to be the cause.
- Cannot identify blind spots that keep you at peak performance, only another engineer with more experience (tech lead or senior) can do so. They can only identify behaviors that make them look bad or are inconvenient when viewed from the point of view of their peers -- other managers.
- A non technical manager has literally no idea what is valuable to delivering complex technical work. They can only guess, and often guess badly. Again only a senior or tech lead with experience could do this.
- How could a non technical manager motivate any engineer, without an understanding of their difficulties, problems and ways to solve these problems practically? I just don't buy it. "Let's do overtime on the weekend guys..."
- Managers should not be involved with people's personal problems. I've met so many managers that are extroverted and managing sensitive introverted teams, that all they ultimately do is the equivalent of hammer on the aquarium glass. Remember that sign in the pet store: "Don't tap on the glass"? It's true of technical teams that are of a totally different temperament than managers.
Thanks for the detailed breakdown and no name calling :D
> Cannot identify blind spots that keep you at peak performance, only another engineer with more experience (tech lead or senior) can do so. They can only identify behaviors that make them look bad or are inconvenient when viewed from the point of view of their peers -- other managers.
Given you have different levels of skill in the team, a good manager would convince you and the other teammate to help each other out with the learning. Lubricating these interactions given everyone has responsibilities is not always trivial. I'm less experienced on the politics but I believe what you're saying about politics distorting incentives. I'm conveniently side-stepping this issue bc it applies to all positions in a corporate structure.
> A non technical manager has literally no idea what is valuable to delivering complex technical work. They can only guess, and often guess badly. Again only a senior or tech lead with experience could do this.
A non technical manager can know very well what's valuable to the product/company. That they don't believe their team on the value of a specific piece of technical work to enable that seems like something else is at play here (lack of trust).
> How could a non technical manager motivate any engineer, without an understanding of their difficulties, problems and ways to solve these problems practically? I just don't buy it. "Let's do overtime on the weekend guys..."
By reminding/reframing/convincing re:impact their work has on their team, personal growth, customers, society or personal preferences. Doesn't have to be only technical; they can help you deal with any self-inflicted discomfort regardless of the subject matter.
> Managers should not be involved with people's personal problems. I've met so many managers that are extroverted and managing sensitive introverted teams, that all they ultimately do is the equivalent of hammer on the aquarium glass. Remember that sign in the pet store: "Don't tap on the glass"? It's true of technical teams that are of a totally different temperament than managers.
Agree to disagree. I've had great conversations with peers when/if we're open to talking about non-work stuff - both ways not just me 'giving advice'. It's not binary and depends on the relationship. A skilled manager can care for reports beyond work, create genuine bonds and be respectful when they have not been given an opening to engage in these subjects.
Trust is a difficult commodity to build, a lot of company culture issues stem from lack of trust. It's particularly key to the manager/team relationship.
When you have a non-technical manager directly over technical teams it's particularly difficult to build trust. People, emotionally, want to have someone really understand them. Someone who doesn't, at a fundamental level, understand the actual work you're doing is going to be at a disadvantage as the work is crux of the purpose of the interaction.
Not to say that it is impossible, someone with well above average people reading and listening skills can still build that trust and get it. But it's definitely going to be more difficult than someone who really knows the turf.
I’ve seen multiple times my careers were dozens of people no will work for months on something that just isn’t important.
Being able to put things in terms like this feature will cost us $1 million in developer time. We can expect a return of $50,000 over the life of the product. Or vice versa.
Stuff that many developers don’t think about.
Reminds me of “What would you say you do here?” https://youtu.be/m4OvQIGDg4I
After that, you have a set of "programming tools" (I don't want it to sound mechanistic, because it is the opposite of that), which are your team and reports, and they will be able to fill in the details (and the details here can be significant pieces of design and architecture by themselves). And your role is to choose the right tools, and allow them to work to their full potential. This means clearing obstacles, clear communication, technical help at times, mentorship, aligning expectations and giving them clear paths for growth.
All these things can be considered engineering at a larger scale. You want to get a really big system shipped and productive? This is the work, these are the skills you need.
Because those tinkerers get to a point where they want to be the ones making the decisions, controlling the culture, technology, and direction of the company. Without position you have no power and without power you can't affect change.
I don't know enough to say whether this is a common pattern or not, but if it is, it could perhaps be that tinkerers tend to gather a vast breadth of knowledge that can be very useful when making strategic decisions. They reach the point where they know enough to understand what questions to ask on many topics, even if they are an expert in only a few (or none) of them.
I don't know how else you pick up the skills to be an effective technical manager
It's a lot easier to spot developers or contractors bullshitting when you've been in their shoes.
The distinction dates back to the industrial revolution, where you had manufacturing line workers and line managers. A manager would usually be an owner's relative or someone they trusted – more loyal to the company than the unions.
This distinction perpetuated well into current age, just notice how much implicit bias there is about "programmers don't have people skills" to keep workers accepting a career ceiling. Most managers aren't skilled either, and not respected by the workers due to it, but companies won't keep them from managing because they need someone to be responsible for plans, estimates, OKRs, etc.
I guess in software it's "more" common due to survivorship bias – the business of software is so messed up and people have so little idea how to manage it, that companies without experienced leaders have a smaller chance. Strong companies and teams in the field have leaders with enough hands-on experience to have natural authority.
Probably ambition. At a certain level of experience, you realize you cannot create your technological dreamscape by yourself.
Becoming lord of a technology company and directing its resources is like programming the ultimate computer.
I didn't get the impression that he's your typical CTO and completely hands off with code and development. If anything, it sounded like he's still very much in the trenches but has learned how to delegate work well and pick which problems are worth the time investment.
When it came to his work on Oculus and the work he's about to do in the field of AGI it sounded like he'll definitely be making direct contributions. It's entirely possible that I misunderstood his stance throughout the interview though and he's a more hands off guy now.
I'd love to be able to find folks that can do what I do -- it's probably our #1 issue holding us back -- and direct them to meet some business and technical goals, but I've yet to work at an organization that supports that mode of management.
Theatre and Cinema are two other fields where folks have been known to work their way up to director/producer/megalomaniac...
I think Weinberg in "The Psychology of Computer Programming" talks about the performative nature of writing code.