Live data from Hacker News

How to reward skilled coders with something other than people management

lizthedeveloper.com

61–70 of 158 posts

Re: How to reward skilled coders with something other than people management

#61
post #52

Earlier quoted context omitted.

This is exactly the sentiment I was going for - people who want to stay engineers should be compensated for their badassery, and respected for it, which is usually all they want. That right there is exactly the "power to say No" I was talking about. And how do you know if an engineer wants to stay an engineer or not? By asking them.

I don't want to disparage the whole management class but I think part of it is that manager types don't really get the motivation to solve problems. They think that if someone doesn't have a manager telling them what to do then they won't do anything, but that is just psychological projection. Fred was one of the happiest (and busiest) guys at this company and many strived to achieve his status. Regarding respect; Af…

(pure) managers don't attempt to solve technical problems because such action usually obstructs individual contributors. What's apparent here is the substantial difference in perspective between managers and ICs. Managers tend to see social equilibria and the network effects of tech problems. ICs can see much, much more deeply into specific (and usually key) aspects of tech problems. A lot of classic conflicts arise when ICs-turned-managers overestimate the depth and completeness of their comprehension and try to lead the technical effort rather than compliment it. Hence a lot of managers are 'uninterested in problems.'

Re: How to reward skilled coders with something other than people management

#62

As a coder that's soon to be taking on a management responsibility, I definitely feel the weight of it, but I'm up for the task of figuring out leadership. I might well be more suited to it than a lot of engineers would, but I also think that management and leadership is less hard than it seems and that engineers would actually be better at it than their superiors if they would just give themselves a chance. The tric…

While I agree that moving into management is just engineering human systems (hell, I do more management stuff than code stuff nowadays), it is definitely a skill. Writing "human code", by creating processes and things, requires you to be able to look at someone and understand their psychology, their motivation, their skills and understanding. It is best performed with the zen principle of Beginner's Mind, and other theory-of-mind type skillsets.

Not all coders have the ability to do theory of mind, because they're somewhere on the autism spectrum. I myself am autistic, and I've only learned this stuff through intense study. It was definitely a skill I had to get good at.

One of the most difficult things to do is understand what you personally are good at, to break down a skill you have and understand where it comes from, and what it looks like when someone doesn't have that skillset. Not to say that someone who doesn't currently have it will never have it, but they definitely will have to work on it in order to get there.

imho, there's a lot of skill overlap for certain kinds of people from engineering to management, and a lot of those people end up in management. This is why, to most managers, what an engineer is supposed to do "next" is become a manager. But this isn't everyone, and it's not even most engineers- so developing an understanding that what is easy for you is not easy for everyone is paramount. I figured that out by teaching, and it took awhile to get there for me, so imho it's a non-obvious thing.

Re: How to reward skilled coders with something other than people management

#63
post #60
post #50

Earlier quoted context omitted.

I suspect that the reason for the perpetuation of this myth is that, if a manager is doing their job really really well then all of that stress and BS is hidden from their directs.

Indeed. The best managers I've ever had were the ones that completely shielded the rest of us from the absolute BS that always exist. Go figure, those were the companies where the rank & file didn't think political BS existed - surprise, your manager was protecting you from that!

So essentially managers are people sysadmins. They make sure everyone is working, try to resolve conflicts and ideally make sure that everyone is running the right tools. What would be a people engineer in that vein?

Re: How to reward skilled coders with something other than people management

#64
post #14

One thing that always fails with that is that management always get more money. Wanna be a tech leader paid 150k? (fancy title, +- same salary as before) Or wanna be a director paid 250k? (fancier title, way bigger salary) Kinda difficult not to choose the "free tesla every year" isn't it? Plus.. the directory job is generally going to mean a more relaxed job (albeit less interesting for an engineer maybe, but that's…

> Plus.. the director job is generally going to mean a > more relaxed job If you believe responsibility over people, budgets, liabilities and policy is less stressful than responsibility over systems, you're high. As a programmer, let me tell you: people who have only ever done programming for a career have no clue how relatively easy they have it.

I don't think you can make that kind of generalization. It really depends on the organization. Ideally neither position will pull an unequal amount of weight.

Remember that in many cases, the software developer has the same kind of weight on his shoulders; some bugs and errors can cause huge amounts of lost revenue, lost jobs, etc. Software plays no small role in the day to day operations and programmers carry a lot of weight on their shoulders, especially in companies that don't have strong testing and review methods (read: almost every company in existence).

Re: How to reward skilled coders with something other than people management

#65
post #54

Earlier quoted context omitted.

Thanks for sharing!! Like this story a lot better than the linked blog article. A positive example of real evidence is so much more effective than an essay of meta.

I am glad you liked it. I know HN doesn't like the supposedly contentless "thanks for sharing" type of comments but I appreciate it and think it is important to express such sentiments. In fact, about half way in to writing my comment I almost deleted it -- thinking no one would really care. I am glad I was wrong and that I completed it.

I also enjoyed this anecdote. This is a story I'll keep in the back of my mind as I progress my career.

Re: How to reward skilled coders with something other than people management

#66

As a coder that's soon to be taking on a management responsibility, I definitely feel the weight of it, but I'm up for the task of figuring out leadership. I might well be more suited to it than a lot of engineers would, but I also think that management and leadership is less hard than it seems and that engineers would actually be better at it than their superiors if they would just give themselves a chance. The tric…

Ah, the innocence of the engineer on the cusp of a new management position.

This is more or less what every engineer thinks when they start a "bridge position". Very few survive, because the reality is that the management world is much different than the world we engineers are used to, even after we have a lot of experience as an employed engineer. We think that since we've seen a lot of bosses come and go and met and talked to a lot of them, we know what works and what doesn't, etc. It's not like that. Management plays by a whole different rule book.

When it comes down to it, management is primarily a psychological position. Soft things matter much more than hard, measurable things. Engineers live in a meritocracy, even if they think their employer is bad about that. The numbers and/or code work and have merit, or they don't. Someone is right and someone is wrong.

Management is the opposite extreme. Your job is to keep your reports happy so that they do the job the company wants to do them as well as possible. Yes, some of that involves acquiring resources and removing barriers to implementation (the part we engineers naturally think of, and have a lot of ideas about how to improve), but most of it involves making sure that everyone likes you as far as is possible, and that in cases where something that makes someone unhappy must be done, the lowest-value person is affected in the least direct way, such that they don't stay off your side for very long. When you are a manager, you are really a full-time politician. To be successful, you must always be campaigning, not on issues that matter or on the most correct or meritorious position, but on whatever will make you most liked, as broadly as possible.

When this was me, I didn't anticipate the heaviness of the political aspect. I thought as long as I was more or less right and proved myself, it would be fine. I thought that if I fought for righteous causes, the truth would bare out and we'd all win. What I had to accept is that this is not how the real world works. I was forced out before my first project even had a chance to wrap. I don't think I was overtly rude to anyone; the issue is that when you're a boss, people nitpick and look for things to be offended about. You have to actively counteract that. If you do something adverse to someone, even something you think is miniscule, you must do it in the most gentle way possible and really think about it. If you don't do anything bad but aren't as nice as some of the other bosses, that will come back to bite you too.

I made a powerful enemy just by politely taking a rain check on a lunch invitation. I thought that was fine and not a big deal, because everyone knew we're all really busy and that having lunch is not a major priority for most people. Turns out, it's not fine.

I made several not-powerful enemies because I didn't regularly pay for everyone's lunch or bring in donuts, cookies, or some other type of treat, which a couple of the other guys did. It doesn't matter that nothing in my job description involved procuring donuts or lunch for everyone. It doesn't matter that I was very generous in other ways. It doesn't matter that I would rather spend that half-hour that I would've spent waiting in line at the donut shop on actual work, like writing a few extra tests or even sitting in a pointless management-level meeting where nothing got decided. All that mattered was that some other guys did this thing, and I didn't. I was expecting people to note these other things and care, but they didn't care because they didn't benefit directly and personally. I wasn't running a tight campaign. A tight campaign wouldn't have let any other employee at any level be more popular or more important.

The problem, of course, was that I didn't go into it to be a politician; I went into it to build awesome stuff and have authority to see it done the right way. Once you're a manager, the only thing that you should care about building anymore is your personal reputation within the ranks. (I've found this to also be true if you want any room to negotiate as a non-management employee.) Doesn't matter if it's better for the company long-term. That's not going to help you. All it means is that they'll still be around to fire you. What matters is that you're exploiting your position to groom your personality cult. Nothing else will help you, because most people do not understand anything else.

One could argue that these are exceptional situations, but I don't really think they are. Maybe someone else would find some other minor thing to nitpick, but they'd still do it. Everything you do reflects back on you, and it's not about merit or correctness anymore. It's about feelings -- feelings that are completely and utterly unreasonable, as feelings often are. When you become a manager, you are the steward of feelings. It becomes your job to ensure everyone on your team is all good feelings and, furthermore, that everyone else in the whole company is all good feelings too, and it gets very personal. Most people cannot make a decision based on the merit of something, they can only make decisions based on appearances.

After trying my hand at this for a while, I decided that I'd much rather stick to coding. Managers become managers because they don't know what else to do with themselves. They are forced to live in the ghetto dictated by irrational, unpredictable human emotion that engineers usually consider something that was left in junior high. Once you get into pretty much any other field, any field where empirical thought processes are not a fundamental component of the day-to-day workload, you realize that ghetto never really got left behind by any of your non-technical peers; it's the only world they know how to live in.

Good luck man.

Re: How to reward skilled coders with something other than people management

#67
I really like the idea of "handoffs" that the article discusses It indirectly brings up what I see as a major problem for some of the most talented engineers I've worked with which is that some point they get too bogged down with the incremental features and maintenance on all the amazing stuff they've done in the past to work on new things. When it would take them a couple days to implement/fix X but weeks for someone else to come up to speed management just can't resist assigning it to them and eventually they become burnt out. Code reviews and mentoring can help this to reduce the time for new folks to spin up and contribute but I think a formal notion of handoffs is a really interesting idea.

Having been both an engineer and a manager, yes different tracks for different people are really helpful. The main thing I've learned is that different people want different rewards an there is no substitute for spending the time with people to figure out what sparks joy for them. Usually there is some baseline of money but often freedom, respect, and cool projects are just as important.

Re: How to reward skilled coders with something other than people management

#68
post #43

Earlier quoted context omitted.

It's management's job to be able to evaluate the contributions of their employees. If they can't, perhaps they're 0.5x managers.

Almost any process that measures human output will be gamed (optimizing for measured output rather than overall success). It's basically impossible to game sales without resorting to outright fraud, whereas there are all kinds of ways to game individual engineering output measurements, in ways that do not align with the business objective.

Sure. That's all true. But it doesn't change the situation.

There are difficulties, but there are difficulties in any job. It's still the job of management to evaluate the performance and contribution of their employees.

The more rote the process, the worse it will be, since, as you say, it will be able to be gamed. As a general rule, I've found larger organizations are worse at it because they have more rote processes, with complicated matrices, charts, etc.

I've been a cog at small, medium, and large orgs. I've been team or project-level management at small and large orgs. I was happiest being management at the small level. Much less politic-y stuff and more freedom to manage the way I saw best. I enjoyed being managed most at the mid-level company. Less room for managerial whims that small companies can suffer from. (Yes, I know I'm playing both sides on that. Heh.) And less of the 7,000 item Employee Evaluation Form Of Doom that big companies have.

It's hard, no doubt. But a manager saying they can't accurately evaluate their employees is literally saying, "I can't do my job." Any manager should always have a very, very good idea what's going on with their employees and their contributions.

Re: How to reward skilled coders with something other than people management

#69
post #56

Earlier quoted context omitted.

How is it flawed?

The most obvious flaw, a programmer is only worth 5.7 times their 1999 salary if their work is generating 5.7 times as much revenue as it would have in 1999. I see no evidence that this is the case. If it were the case, and the vast majority of programmers are earning 1/6 of what their work is worth, then there is a huge opportunity that you can exploit to get rich. Go for it, and let us know how it works out.

Didn't a lot of major corporations get in trouble recently because they colluded to stop engineers from correcting this imbalance?

Your argument seems to ignore that market forces agreed that engineers were underpaid, and it was only by illegal collusion that their wages were kept to what they were.

Re: How to reward skilled coders with something other than people management

#70

As a coder that's soon to be taking on a management responsibility, I definitely feel the weight of it, but I'm up for the task of figuring out leadership. I might well be more suited to it than a lot of engineers would, but I also think that management and leadership is less hard than it seems and that engineers would actually be better at it than their superiors if they would just give themselves a chance. The tric…

Ah, the innocence of the engineer on the cusp of a new management position. This is more or less what every engineer thinks when they start a "bridge position". Very few survive, because the reality is that the management world is much different than the world we engineers are used to, even after we have a lot of experience as an employed engineer. We think that since we've seen a lot of bosses come and go and met an…

Motherfucker, that was an amazing comment. You go write that shit in a blog post right the hell now.
Post reply on HN