Hacker News Reader

When you interview ask how many people with MBAs and no programming experience you'll be working under.

That is a good heuristic for future pain and frustration.

Managers who are good engineers don't always manage well. Managers who have never been engineers are usually worse.

> When you don't know whether a direct report is doing good or not because you don't understand what their doing, by definition you cannot manage them

Especially middle managers, if they are not the owner and have their own managers on top of them, who also don't know how engineering works, there will be trouble. Because they are stuck in the middle. They have to please the ones on the top, without understanding how the programming actually works. So they'll make promises then turn around to you and tell you to work 70 hour weeks.

> So long as the "people managers" are biz guys who don't understand engineering

It is hard. The more time they spend managing and coordinating the less time they spend writing code. The less time they spend writing code the further they move from understanding what is involved. They just forget, or practices and tools change.

Besides leadership is the key. That is as much learned as it is just a personality trait. It ties into how they relate socially to others, how they solve social and political problems. It requires empathy, but also harshness and coldness at times. I can be learned by I wouldn't discount it too trivial.

>When you interview ask how many people with MBAs and no programming experience you'll be working under. That is a good heuristic for future pain and frustration.

My experience has actually been the exact opposite. Working with an engineering manager and an engineering team can be just as frustrating since they often want to build the "perfect product" instead of getting a working model up and running first or a decent prototype.

It can also mean that we have to use the engineers pet technology instead of something that may work better for the task at hand.

Right now I am in some trouble because I used an alternate and quicker technology(flask) to get a prototype up for some customers. It took weeks instead of the usual months to get stuff up and running. Business is happy and understand this is a prototype. Engineering manager is pissed because we should only have built it with our standard framework and not have had the prototype.

> When you interview ask how many people with MBAs and no programming experience you'll be working under.

If someone asked that, I would probably consider that a red flag, that they are mistrustful of "business types" and probably difficult to work with.

> I would probably consider that a red flag

I would not. I would assume they want to work under people with experience in their field and learn from them.

The thing about your advice (and mine, and most all interview advice) is that it's mostly useless. It's only beneficial to people interviewing you, and if it's beneficial to them, it's bad for you. After all, if they would ask that question, but they know not to, they are still that person you would mistrust.

The reality is, people should ask these types of questions. If you wouldn't hire them because of that question, it's likely the would not enjoy working at your company.

There are other less direct ways to pose the question.

Why even ask it. My method is find the org chart depth with log_1.5(company size). Then divide that number by 1/2 execs, 1/2 managers. Guess the roles then go look at random people on linked-in. You can get a good feel for how the company is internally based on that.

It's easy enough to skip the question altogether and do a quick google search on the people with whom you would be working.

Oh, I think it's ok if the manager, with an engineering background, spends a lot of time managing and not a lot of time writing code. They may be further away from understanding the details of the product, but that's ok.

I experienced this personally when I architected a product, the team grew and the product grew and before long there were modules that I had never worked on.

I don't think the manager of engineers needs to be as strong as the other engineers on the team, but they have to understand engineering on a fundamental level, and be able to look at code code and comprehend it, even if they don't know the whole product, or all the details.

While I agree with the basic tenet that experienced developers make better direct managers for other developers, I strongly disagree that "any programmer can do it", or that "biz guys can't learn programming", much less the assertion that "business" is somehow trivially easy compared to coding.

Doing a good job as a manager is hard. You need to triangulate between a lot of disparate opinions and viewpoints, negotiate compromises, and help your team develop and advance without hurting the larger group's goals. It takes empathy, good communication, and the ability to squelch your own opinion when circumstances call for it. None of those attributes are universal in engineers.

In fact, just about everything in a startup is hard: sales, recruiting, design, marketing, etc. Pretending otherwise or asserting that only engineers have something special to contribute is IMHO toxic and short-sighted.

Yup. Both you and the op of this thread are correct.

Managers not knowing enough about the field they manage can cause problems.

In the same way employees not knowing enough about managing can also cause problems.

Essentially, if either side views itself in some way superior than the other (the manager usually views his job as more important in the grander scheme, and naturally is in a position of control and thus thinks himself superior, the employee views himself as the one who actually knows how/is doing the work and thus views himself as superior) problems can and probably (at some point) will occur.

Respect for all the different fields that go into making a company work is a very necessary thing to keep everything running smoothly--this way the company is only battling what the world throws at it/unavoidable risks and problems that occur--not itself.

I think this is a really good insight, a lot of the problems people in this thread have complained about can be attributed to bad managers. Balancing business requirements and technical requirements is a difficult thing to do, all the while ensuring everyone feels special/validated/acknowledged.

Parsing out what each camp feels is the most important thing to do, and translating that to something each camp can understand is one of those critical management skills that is hard to teach.

Every programmer needs to know management- even if to just manage oneself. But the better you can communicate the reality of of your technical requirements, the better the business unit will be able to prioritize their requirements. It shouldn't be us vs. them.

"toxic" is such a great word in this context. I've seen this kind of disrespect for other parts of the organization take down a small company that was otherwise performing just fine.

The real tragedy is, learning business is not hard. Any programmer can do it.

As a person who's switched back and forth between the technical person, the manager, and the business developer - I can tell you that all of the roles in the company take skill to do properly.

I agree. All the roles are hard to master.

Why have I, in the past 5 years, learned a tremendous amount about markets, equity, accounting, law, pricing, and I don't even know what else. But the business masters (all of them) I've been working with still can't update a webpage?

Just one person's experience, I know. But it's still funny to me.

I'm with you both in the fact that I started from engineering and learned about many other disciplines as I went along. Also, I'd agree that most other disciplines don't bother to learn engineering/programming.

When you're an engineer, the ugly truth is that to increase your salary and opportunities, you normally need to branch out and learn other things like management and sales.

When you're a good salesperson, you can reach great heights financially without worrying about how to update a web page.

You're right, but it's no doubt much easier for an engineer to learn business and sales than for a business person to become good at programming and write production code daily.

Learning a little programming isn't any harder than learning something about management or sales - it's just that most people don't bother to do it. My mom was 60 when she started learning HTML and javascript. She does just fine updating web pages, forms, etc. for her quilting and singing groups.

I have a lot of respect for good engineers, good managers, and good salespeople. Saying that one discipline is harder than the other is like saying that being a good violin player is any harder than being a good piano player.

Hm. I would say it's easy for either role to learn at the entry level.

I am entirely confident that an engineer who had the desire to learn some business could pick up the basics fairly easily, just as I am confident a business/sales person who had the desire to learn programming could pick it up fairly easily.

But, it is no doubt just as difficult for the engineer to learn how to manage enterprise sized operations as it would be for the Sales guy to learn how to architect a complete system. In both cases a great deal of persistence and time is required--things often seem easy to us when we haven't really delved into them. As you really immerse yourself in a given field you begin to realize how much you don't know and the massive amount of things you can still learn.

I think it's also the dunning kruger effect - the "I am a person working in a business, thus I'm an expert, qualified to judge business people".

This also applies to a lot of other disciplines and professions, really.

I'm not sure what you mean by "slip lower and lower in status". The software industry has worked pretty much the way you describe as long as I've been a part of it, and I haven't noticed any sort of diminution of status for software engineers. If anything, the trends go the other way: the industry has embraced the idea of a non-management career development track for engineers. Big companies like Microsoft, Google, and Amazon have very well established high-level engineering roles which do not involve people-management, precisely so that they can allow engineers to continue developing as engineers.

I think he means within an organization, not in the industry as a whole. I've noticed this, too. When a company is small and engineer-heavy, the engineers generally have a lot of autonomy and influence over the what and how of the product. As the company grows and layers of management are added, the "leaf node" engineers lose a lot of influence, and their opinions on what the company should be building tend to be less regarded, and often ignored.

"Software engineers are low status" is a thing I've seen start to pop up a lot more recently, the reasoning seems to be, basically, 'field's full of nerds and society is run by jocks', and is often used as an apology for why women don't go into computer science.

It sounds like you're implying that GitHub has "incompetent management" where "people mananger are biz guys who don't understand engineering".

However, Zach doesn't appear to say any of these things, so it seems a pretty unfair implication to make.

I think two things you are overlooking is (1) not all engineers want to manage others, and (2) not everyone who "learns business" can be a good manager.

Forcing engineering people into management roles after they have accrued a certain amount of experience is not the answer.