Hacker News Reader

> It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.

I see this sentiment or implication that technical skills and people skills are somehow mutually exclusive often, even on here which is crazy. I think this stems from some broader trope that people are "balanced" like RPG characters or something, e.g. nerd vs. jock or artist vs. scientist, salesman vs. accountant, etc. The reality is that people who achieve in one area are more likely to achieve in others. If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.

They might. But it could easily take a few years, during which time they'll very likely be a mediocre to poor manager.

Expecting someone with five years of engineering experience to become an effective manager overnight - often with no training or mentorship at all - makes as much sense as expecting an intern to operate at the same level as a senior on Day 1.

Even really smart people with multiple talents need more of a warm up than that. And most people are neither that smart nor that talented.

But that's true of non-technical people too right? So the question is if you as an organization are considering investing a year or two to develop a manager, why not start with a subject matter expert?

Hopefully it is never an overnight switch and the engineer's career goals are respected. Any non-shite company is going to have engineers taking on leadership responsibilities at various levels they are comfortable with before turning them full loose.

In some companies, like Gore Industries, and other employee owned entities the engineers and operations people organically select their own supervisors by consensus and set pay democratically. I have been in environments that did that without explicit structure even, and it was very productive. Unsurprisingly,none of those were publicly traded.

That sounds fantastic, I wished it was easy to find places like that.

Pure luck.

> The reality is that people who achieve in one area are more likely to achieve in others.

Aptitude is in general going to be either uncorrelated or positively correlated across different areas, but time invested is going to be negatively correlated. Hence the stereotype of nerds with poor social skills: building social skills takes time and effort, and time and effort spent on building those skills is time and effort not spent on, eg, improving your programming ability.

Of course, people who have off the charts aptitude will be in the top percentiles across the board. But you're not going to find too many organizations staffed entirely by those people.

Yes, you make some good points here but I would argue that in most organizations that skills that make for effective engineering are aligned well with those required for managing. At a certain point, reinvesting into programming ability sees diminishing returns and ROI on e.g. mentorship, task planning and delegation out-paces improvement in technical skills dramatically. Of course, this is not universal and there are specialties, domains, and organizations that require technical competency and competitiveness above all else, but I don't think that's the general case for most engineers.

> At a certain point, reinvesting into programming ability sees diminishing returns and ROI on e.g. mentorship, task planning and delegation out-paces improvement in technical skills dramatically.

True, but this may not be seen as relevant to the individual if they enjoy engineering more than those other things.

It's fun to be a "star player" developer, but in terms of maximizing your own individual potential, you're always going to be able to produce more value by leading people than by your own output alone.

There are some technical mountains to climb which require superlative engineering talent, but in terms of impact it's hard to compete with a leader who is able to coalesce a team or organization effectively towards a single goal.

The savant/nerd engineer with poor social skills is a troupe which does exist, but so is the manager who washed out of the developer track because they couldn't keep up on the technical side, and they're not a better manager than they were a developer but those failures are harder to quantify.

I think even that "poor social skills nerd" engineer trope might be partially an example of Berkson's Paradox [1]. You have to have serious technical chops to compensate for a lack of social skills, and it's hard to see all of the people with weak social skills who aren't engineers.

[1] https://en.wikipedia.org/wiki/Berkson%27s_paradox

edit: removing markdown syntax

> But you're not going to find too many organizations staffed entirely by those people.

The number you are looking for here is zero, at least for organizations of any size. With a bunch of luck and money you can put a small team together like this; otherwise they are just too scarce.

> If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.

The "if they wanted" part is key. It's hard to become extremely good at something unless you really enjoy doing it. I'd imagine that most people who are top engineers would rather be doing engineering than anything else. If you make them a manager, they're going to enjoy that less and not be as good at it -- but a lot of people get pressured into becoming managers nonetheless.

> I'd imagine that most people who are top engineers would rather be doing engineering than anything else.

Really? I love software development, but I don't think just churning out random CRUD software based on some specs is very interesting. A lot nicer to solve problems of your customers, see how the product makes them happier and think about ways to improve their user experience.

Somehow I assumed that's how others felt as well.

If the top engineers at your company are churning out random CRUD software from specs, you may want to reconsider where you're working.

Good engineering is about understanding the problems of your customers, designing software that solves these problems, and improving their user experience.

Majority of jobs are going to be like that though.

The cool part about being a technical manager is that you can expand the scale of what you are capable of. So for instance if you ever had an idea like "if only I had infinite time and infinite energy I would do X", you can build a team which has the tools to provide that.

If your goal is to have an impact, you have to be lucky to do this as an engineer. There has to be a structure around you which converts your work into value. As a manager it's much more reliable that you can be the person to create that structure.

While aptitude correlates with aptitude, at a given level of accomplishment they may be anti-correlated due to Berkson's paradox[1].

[1]https://en.wikipedia.org/wiki/Berkson%27s_paradox

I agree, when I was working with small companies this kind of thinking was all too common: Can we make a Twitter clone in a week? “Yes it’s just a backend and a frontend.” Vs “with support for 187 million active users? Which level of accessibility? Will we have a cloud provider? Media upload support? Redundancy? What kind of login functionality? Do we have support if they loose their email account? Why are you looking at me like that? You know what: no we can’t do it. No I don’t care that your grandson thought anyone can do it”.

And the common question..."How quickly can you do it if I add 10 people....ok 11, but no more, because we have to be mindful of cost"

This question depends more on the manager’s motives than on their knowledge.

heh in the consulting world it's pretty common to be in a situation of "i signed a contract to deliver a twitter clone in a week, here's the kickoff date. get started."

> Can we make a Twitter clone in a week?

Yes.

The v1 isn't the hard part of building a competitor to Twitter. The hard part is scaling the user base, getting funding to keep the site running and being able to grow it.

V1 is a hard part, what you are talking about is the insanely hard part. ;)

I meant, cloning all of Twitter today is useless because you won't ever need the infrastructure to handle 100M+ users.

But a basic microblogging platform? It's not impossible to do in a week.

I believe you can do it in whatever time you want. You are the one setting the definition of done after all, not the manager.

> Can we make a Twitter clone in a week?

Why would you want to make one at all?

You can replace it with an in-house customer chat, if you feel the example is contrived.

But my point is, everything looks easy if you look at it shallowly, managers without professional programming experience will look at the problem from that angle.

The best will be able to help, the worst will have this shallow look and expect the moon by morning.

I agree, knowledge matters. It is pipe dream to think that empathy and people skills are enough for manager (or anyone) to compensate for lack of knowledge. Lack of technical knowledge does not imply neither peoples skills nor empathy. Technical knowledge does not imply lack of either

Moreover, I found that non-technical managers had often trouble in empathy and people skills departments. I think that a lot of issues stemmed from non-technical manager having basically inferiority complex, confusing disagreement with disrespect, being unable to distinguish between mistake and lie. Moreover, not understanding culture technical people tend to create or even not being aware that there is such a thing as difference of culture.

The cultural difference is a big thing - non-technical management in my experience value completely different things, ends up insulting engineers or otherwise creates difficult situations. All of that then implies that I as a programmer suddenly have to deal with interpersonal issues that manager created or is unable to deal with.

The thing is, the choice is not between non-technical person with people skills and technical without. The choice is between person with technical knowledge and one without, where the one without them has also disadvantages in peoples skills.

> having a thorough understanding of, or at least an accurate intuition around the subject matter.

> they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project,

There's a fairly large gap between those two positions. Personally, I'm a fan of a manager that knows enough to discuss the topic with me, but they don't need to know enough to analyze the problem itself. I want to be able to explain to my manager what the problem is, what the various solutions are, and which one I think is best and why. If they can understand all that, that's enough for me.

I agree with this up to a point. It’s been valuable to me as an IC, and I feel it’s a value I provide when the problem is so hard there isn’t a clear solution.

It’s nice to be able to say, “what do you think I should do?” as an IC, and nice to be able to analyze the problem if necessary as a manager.

On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.

> On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.

Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.

The reason I think it's good to have a product/project manager who can get down to this level if needed is that it increases the scope of possible solutions. With a strict division between tech and product, typically the solution space is bounded by the product requirements. But if you have a product manager who is able to operate on the level of implementation details, you can adapt the requirements in ways which are better on both a user side and implementation side.

It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.

> because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.

I think I understand the disconnect here. From my point of view it's the manager's job to figure out what problem the client is trying to solve. It's the developer's job to figure out what the possible solutions are, and recommend what they think is the best one. As a developer, I expect to be in the meetings with the clients long before the solutions are chosen.

>top-tier engineers are not generally qualified in terms of non-technical requirements

It's just that both sets of somewhat orthogonal skills are less likely to reside in one person.

An analogy from baseball is why are pitchers generally lousy hitters (even pre-DH)? Did they get less practice? Probably. But it's also the case that (again even pre-DH) any ability to do more than lay down a bunt was absolutely a nice little bonus but their job 1 and 2 and 3 is pitching the ball.

On the other hand, even the best fielding shortstop in the league still needs to have a half-way decent batting average, even if they can get away with a lower one than other positions.

This analogy is interesting because it kind of proves you're both 'right', depending on the environment.

In middle/high school, there is often 'that kid' who _is_ the best at all skills - they are the pitcher, they bat cleanup, they do everything.

In the pros, though, that's virtually unheard of these days, because the amount of time it takes to specialize in a skill sufficiently to make it to the majors is so extreme it precludes you from being able to do that for multiple skills, with rare exceptions.

Not disagreeing with you, or at least I don't intend to, but I definitely remember playing against 'that kid' when I played baseball in middle and high school. Same analogy for the kid who's great at several sports in HS but has to specialize to get the DI scholarship or go pro, etc.

>it's not only about empathy but also about having a thorough understanding of, or at least an accurate intuition around the subject matter.

I read the OP with a very different takeaway than what you may have inferred. I did not get the impression they were saying empathy and technical skills are mutually exclusive. By saying their best managers were in the top quartile, they are implying they were technically competent but not necessarily the most competent in a single domain.

Essentially a manifestation of bikeshedding. Yep, very common.

Yes and it can go especially poorly when you have a "problem oriented" person on the team:

1. Manager proposes low quality requirements

2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization

3. Endless discussion around this one detail

4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal

OR

4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline

Oof. The number of 4b's I've had to deal with in my career...

What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.

A couple approaches I have seen which can be effective are:

- Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B"

- Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C."

With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.

little bit of caution on "Yes we can do A, but that means we won't have the time/resources to do B" - this, along with Agile method of squeezing work every two weeks will lead to simply mediocre quality hacked together deliverables and accumulation of technical debt.

Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable

Sounds like the text book description of how to start wrecking a software project.

4b... Sums up the last 12 months of what should have been a 3 month project.

Even if two traits are positively correlated, they can end up looking negatively correlated when you are selecting on those traits:

https://twitter.com/page_eco/status/1373266475230789633

> It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.

True, but your top-10% engineer who's also a top-10% manager is going to be 10x rarer and harder to find.

And so will you then become a gradually worse leader as some of those engineering skills start to atrophy? The unfortunate truth is that you won't have the focus time to do large scale engineering tasks any more, unless you neglect your leadership responsibilities.

Very often when folks describe the ideal manager, they are describing themselves.

That’s an interesting idea.

Arguably my best manager had a graphic design and UI background. Where they excelled was having worked directly with software developers and non technical people for a decade they could understand the relevant tradeoffs without getting into the weeds.

However, former software developers where generally much better the deeper and more relevant their technical background. Seemingly because they understand what to prioritize, but perhaps it’s was simply easier to communicate with them.

A quote I stole from some conference talk that i think of all the time as a manager: "You become the manager you wish you had, you need to become the manager your reports wish you had."

Yes, and that's why worker self-management is the proposal one sees from any form of politics that doesn't care for managers -> https://en.wikipedia.org/wiki/Workers%27_self-management

To be honest, I would love to work for a place that implements self management even half hartedly. My understanding is that Valve is like that. Valve may not make things on the schedule that people want them to - but no one can deny that their quality is supreme.

My perception is that valve has suffered some negative experiences due to bad actors interacting with its radically libertarian labour practices. I don't have insider knowledge, so I could be wrong, but this is the sense I have gotten reading articles over the years about how the IP for VR was handled for instance

Sounds interesting, could you point to some readings on that aspect of Valve?

No I don't keep a curated list of every random article I have ever read to offer hand-picked readings to strangers on the internet, but search engines exist if it's something you're interested in looking into.

Hey, why so passive aggressive? I've already read quite a bit on Valve googling it, just thought you might have some specific insightful article or thread in mind.

My first reaction was to disagree, but then I tried to remember the embodiment of 'not-ideal' manager and, in my mind at least, they are basically everything I am not, or at least not want to be.