Hacker News Reader

Comment by ryandrake | Hacker News Reader

The day I decided to make it a goal to switch from developing software to management: I was sitting at my desk at 8:00 at night fixing some bug and I looked across the sea of gray half-height cubicles at a someone 30 years older than me doing the same thing with the exact same job title, probably not making much more than I.

At 95% of companies, there is zero career development and advancement once you become a "Senior Software Engineer". Fix that and you'll see more engineers stay put (where they're likely happier and more productive).

View on HN

True in my experience that managing developers paid better and had other perks like more equity and some control over priorities and projects that was nice. Technical or pure software companies seem to do a better job of valuing engineering talent and how core they are to business but still not as good as they could. The two things I've seen over and over are:

1) Pure technical people are under appreciated and in general under compensated in most organizations. Often management doesn't understand how important they are.

2) Good managers/management are under appreciated by most engineers. It is hard to measure quality in management and it is one of those jobs that when you're doing it best it appears like you're not doing much as you're avoiding bad projects/crisis in the background and putting your people forward to make sure they get their credit and are enabled to get their work done.

I'd like to see some more courses to help technical people be better at management as it isn't something you'll necessarily be good at just because you're really smart. I'd also like to see a technical 101 course for management types so they can better appreciate their true tech talent.

On a side note I thought Havard's article about management research at google and related hacker news comments were interesting. Most management philosophies I've seen weren't in the tech space and I'm not sure the production line and sales team techniques transfer over to software. https://news.ycombinator.com/item?id=6762222

Maybe developers valuate themselves too low more often than management, at least when it comes to negotiating salaries? In general they might think more in terms of what they need (or "should earn"), than what they could earn. That is kind of a mistake.

This is a contributor to the 'gender gap' in pay.

Certainly everyone has the responsibility to make sure that they like the deal they entered into and ask for more compensation when appropriate.

I think that good management realizes that things will end badly for them if they don't compensate employees well, but I for one though have never seen a corporate dashboard that tracked how fairly the developers are being paid. Management often seems genuinely surprised that they can't just replace the talented technical person who left and that they can't hire top talent for median wages.

> Good managers/management are under appreciated by most engineers. It is hard to measure quality in management and it is one of those jobs that when you're doing it best it appears like you're not doing much...

Oh, the irony!

Can we just agree that any job that require expert judgment of context-rich situations to take decisions - versus the raw application of fixed rules - is simply not suited to Taylorist evaluations???

The 8:00pm bug is why I had volunteered to transition into project management at my job. Actually, I kind of just took on the job informally. I balanced a ratio of coding/project management until I wasn't really coding anymore.

I'm not sure what entices a developer into pursuing management. As the above post pointed out, they didn't see a viable career path. I'm going to guess another reason is that many are fed up with how things are currently being done at their workplace, and they feel they can do a much better job than their current manager. This was my case.

Maybe the next statement is a little naive, but if you want to make things better, than just do it. Insert yourself wherever possible. Learn what you need to learn. If you end up hating it, at least you tried. It's a lot of effort to support yourself, but it can be well worth it. For me, I was able to introduce a Wagile workflow for our team, which had dramatic effects in just a month. I'm now actually starting to do product work as well as transition everyone into a full Agile approach.

I've been places where I was there for the 8:00 PM bug (or later). At most of those places, my manager/supervisor was still there, too, trying to help us figure it out. If nothing else, they were there for encouragement and food runs. (If your engineers are working through dinner, feed them.)

Doing management right doesn't mean that you no longer are there at 8 PM. It means that you're there at 8 PM more often than any one of the people under you.

Doing management right means your team does not have to work until 8pm every day.

True. But it doesn't mean that your team never has to work until 8 PM.

You are right about the salary. but what is your opinion on job security and employability. the way I see it, in a tech role, as long as your are flexible and open to learning whatever technology is thrown at you, you will always be employable. But in management,especially in junior management and especially in very large organisation, managers are in most cases dead weight. they don't do much.Don't they feel the insecurity?

Totally agree. A good tech resource is hard to find. The guy who makes you go to a meeting once a week to tell you the floor plan is changing a little? Not so much!

So a good tech resource is harder to find than a bad manager? Hard to argue with that.

Perceiving a manager—no matter how junior—as simply "dead weight" signals a failure in the organization, the individual manager, and/or your own perception. In addition to ensuring accountability, a good manager also helps to shield subordinates from the bureaucracy that is inevitable in large organizations. This work may not always be visible.

Bureaucracy inevitably leads to inefficiency.

If a primary purpose of managers is to "shield subordinates", then you have a much bigger problem within your organization.

But chaos is also inefficient. The best possible management minimizes both the chaos and the bureaucratic inefficiency, to get optimum output from their organization. This does not happen without management - the "natural state" of an organization is not as efficient as the optimal state.

Good process adds some latency, but reduces risk.

Definitely not as many available jobs. Every company in the Valley seems to be looking for engineers by the truckload, but there are not so many openings for [people|project|product] managers. Apparently, engineers now self-organize and products simply leap from their fingertips onto store shelves.

As for job security, I guess I'll find out eventually. My gut feeling is that in software companies, it's easier to get laid off/fired as a manager, and it's the opposite in companies where software/IT plays a peripheral or supporting role.

Yeah, this is my gut feeling too. Unspoken is the fact that productivity tools like Asana, Trello, Slack are innovations to replace management.

If you think you can replace managers with Trello, you clearly have had some very awful bosses in your career.

I don't need anyone to tell me to keep working on my TODO list. On the other hand, someone who grasp the big picture is useful to have around to tell me in what order to tackle the task in the TODO list. Its even better when said someone has the clout to go poke a 3rd party that is blocking me so I can keep working on the TODO list.

But the very best managers I have had are the ones that are willing to bite the bullet and say "No, X cannot go into the TODO list as it is now. Let's work together to define what realistic actionable items need to happen for X to be accomplished and then we can put those in the TODO list."

Ah, but the managers are usually the ones that decide who gets fired. If they fire you, you can be back on the job somewhere else in a few weeks. If they fire themselves, what other manager would hire a former manager who even implied that a manager was the least productive employee in the unit? That's crossing the thin green line, man!

Half of a manager's job is justifying the importance of management to the employees, and the other half is justifying their own importance to their superiors.

Let's put it this way. I have never been kept around long enough to see my own manager get fired. And I have been through 3 mergers.

There are a few good managers. Everyone else is a boss. Boss's are detriment to an organization.

Managers manage. They don't wait until there's a fire and then start running around tossing the blame ball. Boss's do that.

I would say the type of manager you describe could be more aptly called a leader: visionary (motivating the team behind ideals), willing to do the hardest work (as opposed to handing it down apathetically), respectful (building trust and such) and more.

"Leader" is usually reserved for a different kind of work. A leader determines where the organization should go; a manager ensures that everyone under him is marching in that direction. They require very different skillsets - leading is an outward-facing, synthesizing, strategic role, while managing is an inwards-facing, empathizing, tactical role. To use Ben Horowitz's terminology [1], leaders are Ones and managers are Twos. The CEO's usually the most visible leader in the company, but you'll often find them at lower levels as well, like the tech lead trying out a new experimental Skunkworks project.

Both of them are distinct from "boss" as the grandparent describes it, which is usually what happens when you get a manager who lacks empathy, awareness, and flexibility. Both leader and manager are highly cognitively-complex, pro-active roles that require constant information-gathering. Boss is what happens when you get someone in that position who lacks the confidence or skillset to stay on top of all that information and then reacts through command & control techniques when things go wrong.

[1] http://www.bhorowitz.com/ones_and_twos

"a manager ensures that everyone under him is marching in that direction"

That sounds like a boss to me (and not just because you used an unnecessarily gender-specific word ;). One of the anecdotes in the article is about this person, as a manager, acting as a listening board and ultimately conduit for an engineer when discussing the importance of a specific project at Twitter, and raising questions that came from that engineer that ultimately resulted in the project being cancelled. I think that advocacy role is important management – where the manager advocates both up and down (and ultimately you can't "tell" people what to do, you can only fire them or convince them, so it's "advocacy" both directions).

Difference between a "manager" and "boss" is entirely in how they go about getting everyone on the same page. For any given strategic direction, there are a lot of different ways that could be achieved. A good manager takes in information from all her reports (including their preferences, fears, concerns, and goals) and then figures out a plan that keeps all of them happy while also achieving the strategic goals coming down from above. A bad manager takes the goal as the only input and then outputs commands to achieve it.

> At 95% of companies, there is zero career development and advancement once you become a "Senior Software Engineer". Fix that and you'll see more engineers stay put (where they're likely happier and more productive).

In many companies I see more undermanagement than overmanagement, so starving out the management track doesn't sound like a great strategy. And if a company is going to have better career development and advancement, it's managers who will make that happen. The pithy answer is "why don't you become a manager so you can fix that?" – and maybe you don't want to and that's fine, but you should hope that some other enlightened person chooses differently.

Re: advancement: to have greater impact than a Senior Software Engineer you need to do more than hack or stay late to fix bugs. What we define as "management" might not be the best way to do that, but it's got to be something. And at a certain point impact based on individual skill is hard to scale. I don't think we have a very good model for what it means to be more than that, so there's something precarious about the upper levels of the technical track. I recall seeing an article describing the developer equivalent of "The Wolf" (the character from Pulp Fiction), and have encountered people in that position; it's kind of like a wildcat manager role, diving in to fix problems that are typically both technical and organizational. There might be other models of what it means to go beyond Senior, but I think they aren't as well understood as they should be. And a lot of them will look somewhat like management because a large component is doing work that makes other people more productive.

OP is not saying to starve out management. Providing a meaningful career track for experienced engineers as technical experts rather than managers does not require reducing the number of managers. It does, however, require accepting that there's such a thing as a non-management job that might actually pay more than one higher up the org chart.

Often, organizational and technical challenges are intertwined. We become susceptible to certain technical pitfalls because of the unique weaknesses of our organization and its technical leadership (or lack thereof). I concur that many senior engineer roles will look like management. One thing that distinguishes them is that the senior engineer is not involved in the minutiae of HR decisions that line managers make for their employees (salary & promotion, approving vacations, etc.) nor in the broader allocation of corporate resources that consumes so much manager time, but rather on high-level but still distinctly technical tasks.

In my industry (power engineering), it is very common to see giant engineering companies that have gutted the senior engineer role. They are made up of hordes of interns and junior engineers and lots of hotshot bosses and nothing in between. The quality of work they can produce suffers noticeably.

I guess my sense is that in some fields – software development specifically – the management track is generally starved. Sure people enter management, but they do so reluctantly (which itself causes many problems), or for the wrong reasons, and that's in part because there's not enough people interested in entering that track.

I think it's a case of different people having different priorities.

For example, I have zero interest in career advancement. I just want to draw a paycheck so I don't end up homeless and so I can afford to buy the occasional cool gadget. It'd be nice if my work was interesting so I'm not completely bored while I'm working for my paycheck, but advancement is definitely at the bottom of my list of what to look for in a job.

Worth noting is that it's not just about titles. Titles matter, but they can also become a joke. It's easy to imagine a company, realizing that its best seniors are underpaid, inventing a new title to justify paying them only 10% more instead of the 30% they should get.

The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business". Hence, all that Agile/Scrum bullshit in which engineers just churn tickets, rather than making meaningful technical decisions and building projects of increasing scope. No one who has any leverage and talent wants to work in that way. This becomes self-perpetuating, because even though there are good people who stick around (usually, with kids in expensive private schools, or uninsured sick relatives) the assumption becomes that good engineers leave after a certain point and, thus, that anyone left isn't any good.

For me, I only enjoy coding if it's part of a bigger whole, and if I am proving something in doing so. If I'm stuck in a ticket shop and can't leave for 2 years for some reason, I'm going to manage (preferably officially; unofficially via aggressive delegation if necessary) because I was done with that junior-level business-story coding several years ago. I graduated out of it long ago, and I won't be put back there like Billy Madison.

Totally agree with your second paragraph.

Good technical people at large companies (ran by non-Technical management) are often undervalued. I see over and over again how an engineering team gets a non-technical PO/Manager - who is just a very bad proxy. They can't bring any important insights into technical products and can't easily fix inter-team dependency. That's why all Google's APMs are technical (most with CS degrees).

This gets worse when top level management is not technical for a technical company. Since they are not technical, they don't have good vision about where the industry will go in 10 years and what are the limitations. Ex. Microsoft under Steve vs Satya. One only had a vision for next quarter and the other seems to think longer term (and knows where the technology is going).

> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business".

Isn't that the inherent nature of a lot of the programming jobs, though? For example, I'm currently contracting at a e-commerce company. My day to day work is as you described - closing tickets that get assigned to me in the Sprint. I also suggest new tickets, but they're solely limited to technical issues (mostly addressing technical debt, trying out new technologies etc.).

Honestly, I wouldn't know how to suggest anything on the business side - I don't know a first thing about how the market we're in operates (except that it's very competitive), and we have a separate person (Product Manager) whose only job is to think of new features for our team to implement. I think that's the only arrangement that works for non-technical products, which is what vast majority of programmers work on.

I was thinking about the same sentence you highlighted, and I think you're right.

The problem is that it's often bundled with a similar but patently false and demonic idea---that the business and technical sides can be siloed without ill effect. They can't.

Someday someone will write a best-selling business book about how it's valuable for management to have technical expertise, and it'll have some catchy term like the "mangineer" or something.

Some of the better VC firms (eg. a16z, YCombinator) are already putting this in play with their investment decisions, but they would rather profit off it than write a best-selling book. There's a reason why the conventional wisdom in the Valley - at least among firms in the know - is that you need a technical founder who also thoroughly understands the business.

Then empower yourself by learning how the business/market works, or if that sounds stupid and boring, leave for someplace where it wouldn't be.

I'm not the OP, but the point I think is that as long as you are content to be a "code monkey" (no disrespect meant at all, but that's what it sounds like) that just does what they're told for 40-50 hours per week, you can't expect to have any upward career growth.

Engineers, speaking generally, are more than happy to work with the business.

Where there's divergence is that engineers don't want to work for the business as a subordinate, or for compensation that justifies working on something less interesting or career-beneficial than what one would prefer.

In this kind of setting there is no career growth though. You're either a 'code monkey' or someone like a technical product manager, or you manage people. They are all different paths, with none of them being inherently better or worse than others. Money-wise, a lot of code monkeys are contractors, which means that they take home as much or more than senior management.

Honestly, I'm not even sure how "upward career growth" could look in a company structured like that. I don't think I saw a single programmer in here who empowered himself with business domain knowledge to a degree where he could make meaningful contributions. I guess we're all comfortable with where we stand.

> The bigger problem is that most companies view "engineer" as "implementor of ideas that come from the business"

This is exactly what I tell people when they ask why I'm applying to business school instead of being a career software engineer. Engineers will almost always just be implementers of other people's strategy decisions -- and they will be largely fungible -- but the strategy decisions are where you can have a real lever effect on organizations as an individual.

Reply on news.ycombinator.com