[fwr]

Even John Carmack - an ultimate prototype for a nerd - has evolved into a CTO (and from the linked Fridman interview he sounds like a really good one). What is it about tinkerers being put into these positions as a natural progression?

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?

[hungryforcodes]

Tinkerers are basically technology generalist, and have tinkered in probably everything. So they can map out solutions and have good ideas of what will work and won't.

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.

[jrvarela56]

This is an overly cynical view of management. Distrust and "screwed by estimations" are signs that the dynamic needs tweaking, not that all dynamics are like this.

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.

[hungryforcodes]

A cynical or experienced view? I'm in management and have seen good managers and bad, but the bad ones are quite a few. To address your points, managers with a non technical background:

- 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.

[jrvarela56]

> A cynical or experienced view? I'm in management and have seen good managers and bad, but the bad ones are quite a few. To address your points, managers with a non technical background:

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.

[BackBlast]

> 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).

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.

[jpfr]

As a startup founder you are automatically at the top of the company food-chain.

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.

[8ytecoder]

Part of the reason for that - especially in tech - is we keep hiring people utterly unsuited to manage others. Pretty much every manager I've had is a software engineer in the past. But, only one manager was a true manager who helped me with the technical stuff, career and personal growth. The rest were all great people but totally inadequate as a manager.

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.

[treeman79]

Just figuring out what is important / not important to the company alone is enormously important.

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.

[shrimpx]

> People with managerial backgrounds have....what? Nothing really.

Reminds me of “What would you say you do here?” https://youtu.be/m4OvQIGDg4I

[larve]

I feel that turning to leadership (tech leadership, but also pure engineering management) can be a natural "tinkerer" progression. If you want bigger impact, you turn to more "abstraction", and use tooling and patterns to fill out the details. In this case, you can consider that your role is to give broad directions. They are very important directions, because they shape the "design space" of the problem you are trying to solve.

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.

[PainfullyNormal]

> What is it about tinkerers being put into these positions as a natural progression?

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.

[guhidalg]

Software isn't the only field where practitioners get promoted to management, but it is one of the fields where technically incompetent managers and executives will kill a company with unsound decisions.

[dnadler]

> What is it about tinkerers being put into these positions as a natural progression?

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.

[convolvatron]

I'm not the worlds greatest manager - but after you've worked with hundreds or thousands of people and seen seen hundreds of projects come and go you start to develop some insight about how things go and how they can go bad.

I don't know how else you pick up the skills to be an effective technical manager

[theshrike79]

When a manager promoted or advances through the tech track to a CTO or Architect position, they still keep their base-level knowledge.

It's a lot easier to spot developers or contractors bullshitting when you've been in their shoes.

[hcarvalhoalves]

> It always seemed to me that people with more of a managerial background would be better managers

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.

[bob1029]

> What is it about tinkerers being put into these positions as a natural progression?

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.

[_gabe_]

> Even John Carmack - an ultimate prototype for a nerd - has evolved into a CTO

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.

[moonchrome]

You get to scale up your impact by managing people.

[powerhour]

In my case my impact plummeted. Sometimes going in to management means having your hands tied -- you are the ones allowing higher ups to scale their impact. It was awful.

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.

[oaiey]

And here your organization has failed you. In our org we split engineering career at a certain point into three careers: engineering, people and architects. Up to the VP level their grading run in parallel. The architects are optimized for tech and business impact while the people managers are good in managing people. and yes engineering tracks and architecture track optimize certain skills but are not necessarily a hard separation

[ebcode]

> is software/system development the only field where masters of their craft ultimately become directors?

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.

[zenlot]

Who's programming 12 hours a day. He never ever said in that interview, that he's going away from programming. He's been "CTO" in the early days too. You misunderstood the whole conversation if you think he's turning into an "architect" only.

[robertlagrant]

My impression is lawyers and doctors also get promoted for core skills rather than management skills.

[baby]

Carmack did end up moving from Meta VR (although he still works there one day a week). I presume it is because he was not doing enough engineering work. I used to read all of his posts internally and he really did seem to be an amazing CTO.

[edmundsauto]

It's not they are tinkerers necessarily - it's that they want their impact to scale larger than what they themselves can create. Solo coder -> tech lead -> CTO is like going from single CPU -> multiple CPU -> distributed systems.