How to reward skilled coders with something other than people management

That's not your worth. It's your worth to that particular employer. It is defined by what value you can deliver and how much the other side needs that value.

It sounds pedantic but I think it's a very important distinction.

sliverstorm• 12 years ago

But what if you are worth more, managing a group of engineers?

Sure, it is a bit of a new skill, but the ace engineer who can guide a team with his engineering wisdom is way more valuable than the engineer who just works by himself.

sheepmullet• 12 years ago

That's a false dichotomy.

You can guide a team while "just" being a member of the team. Leadership and management are not the same skill.

I guess what you are saying sort of makes sense in teams with a high ratio of junior:senior engineers. But I'd question whether that is a good way to structure a team if you are working on complex tasks.

netcan• 12 years ago

There is an underlying assumption to a lot if this thread that it's the person that is "worth" an amount. But, worth depends on what you do and price depends on how hard it is to find someone else to do it.

Managers are worth a lot and the difference between the best option and the second best one is greater, at least that's what the market seems to be saying. You are worth x doing X job and y doing Y job. It may also be true that you are worth more to employer x than y.

It's ok to make decisions not solely based on price.

girldevninja• 12 years ago

Great article!

jaunkst• 12 years ago

Give me equity stake. I don't want to manage, I want to come out of the end ready to start my own venture or retire and do what I love and build and awesome open source project to give back to the community.

ultimape• 12 years ago

If money is a means to an end, why not just find an employer who provides and supports that kind of work directly?

seanmcdirmid3• 12 years ago

Those jobs are hard to find. If you have one, hold on to it.

cookiecaper4• 12 years ago

Because having the actual money lets you determine the end and implement it by your own definition.

icyfenix5• 12 years ago

Well yeah on the dollars++ and the equity++ - often that's a harder sell, existing managers usually have to have some kind of thing to point at in order to make those things manifest - a lot of non-coders don't know how to quantify your contributions- these strategies are supposed to add up to raises, promotions, bonuses, etc., and make getting the tangibles you want easier. Plus, if the tangibles don't come with the thought leadership recognition, someone else will usually come along, and recognize you in the way you want to be recognized.

azimuth11• 12 years ago

Thanks for this, it helped me think through some very specific things that I have been struggling with at my startup. I joined out of school as one of the first engineers excited as hell, but have been somewhat sad/depressed/etc. over the last few months because I've felt a lack of direction and proper guidance.

Over lunch, president asks me if I wanted to become an engineering manager or something of that nature as well as take management coaching classes. It was a very sad thing to hear someone say to an engineer.

We want to lead by example. Thought, learning, and then code. We want to set or be a part of an engineering culture that has the freedom to be creative in our space. Some roles that jump out at are the developer advocate type roles. Not just "Hey, look at what you can do with our APIs", but be learning and sharing that knowledge with our peers and others around the web (recruiting).

Maybe it's time for a change.

redmattred• 12 years ago

I'm really curious to learn more about the different directions you're thinking about and what kind of guidance you wish was there, but you don't feel you have. For my own startup, I'm trying to dig into the career challenges and questions developers have and try to build a product that helps them in their journey.

If you have a moment, shoot me a note at matt@codejobs.io

Also, Drive by Daniel Pink is worth a read if you haven't read it before. It's main hypothesis is that Autonomy, Mastery, and Purpose are the keys to happiness in your career.

firebones• 12 years ago

Compensation, equity and when those are ultimately satisfactory, autonomy.

clueless1233• 12 years ago

If a sales guy sells 10x, he gets 10x commision.. If a coder produces 10x, pay him 10x.

What is so hard to understand about that ?

zevyoura• 12 years ago

It's much harder to measure the production of "coders."

waterlesscloud4• 12 years ago

And even harder to measure the production of executives, yet they don't seem to have any trouble pulling in the big paychecks.

jtietema• 12 years ago

It is not hard to understand, but it is hard to measure.

Do you reward writing more code, better code, code with less bugs? There is no one axis to measure along where as in sales you just measure the sale price.

jaredhansen• 12 years ago

The challenge from the business side is to evaluate reliably how to measure "10x" in this context. While there is widespread agreement that some programmers are significantly more productive than others (maybe even 10x as productive), there is much less agreement on how, exactly, such productivity is measured.

With sales, it's very easy: you count Dollars In The Door. Maybe you also count something like New Customer Logos Acquired or something like that, but generally speaking it's just cash. The salesperson brought in new marginal cash, and you're paying some portion of that back to him/her.

With code, it's hard to know what to measure: lines of code? Features produced? Ratio of LoC/bugs discovered? Mean time between when a piece of code is written and when we recognize that it needs to be refactored? It's just a much messier process.

None of this is to argue against incentive comp for engineers. It's just to point out that in sales, you're measuring and paying for output. Output is much harder to measure in engineering than it is in sales, and compensation is fuzzier as a result.

waterlesscloud4• 12 years ago

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.

clueless1233• 12 years ago

Sales deals can be quite complex to measure as well.. IMHO is just that sales guys tend to be better negotiators, so they ask to get rewarded properly o go somewhere else with their skills.

notastartup• 12 years ago

you are actually a cost saver, not a profit generator. sales generate profit, a coder does not do this directly (e.g. selling).

cookiecaper4• 12 years ago

The coder may be a cost saver in some cases, but not necessarily all; if that sales guy is selling software that the coder wrote, then the coder is just as much of a profit generator (actually more) as the sales guy who just sold the product that someone else made. The manufacturer and salesperson are both important. Generally speaking, the value of these positions is about even; specific situations may slightly favor one position over the other.

philwelch• 12 years ago

Produces 10x what? Lines of code? Don't make me laugh.

clueless1233• 12 years ago

Measuring productivity by lines of code is like measuring aircraft quality by weight added..

Never met someone that is 10x more productive than the rest?

parfe• 12 years ago

People hand the company money when sales do their job. No one hands the company money because you wrote an extra 1,000 lines of code this week down in your cube on B2. Just like the janitor who doesn't get paid 10x as much if he spends some extra time scrubbing the bathrooms.

marcosdumay2• 12 years ago

No?

Then why does your company employ you? Are they doing charity?

Joeri• 12 years ago

Sales need something to sell. Jobs are paid based on the perception of how difficult it is to find someone to do it. CEO's are paid ridiculous amounts because the perception is almost no one can do the job. Janitors are paid little because the perception is almost anyone can do the job. The result of this is that many buildings are cleaned poorly, so nxt time you see a dirty bathroom, don't blame the janitor, blame the person hiring the janitor. The supply of good janitors is much more restricted than it appears, but that's because the person hiring typically can't see the value in paying more.

For programmers it's the same. Good programmers can make or break a business by building software which sells itself, or by building software with 10 times less effort, turning loss into profit, but many people hiring the programmers don't see it that way, so many programming jobs underpay, and many people paid to program have no business being anywhere near a keyboard.

uaygsfdbzf• 12 years ago

Science says that will give you worse results:

http://www.ted.com/talks/dan_pink_on_motivation

zobzu2• 12 years ago

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 why you have open source projects right?).

gumby• 12 years ago

This is why IBM created a separate path back in the 1950s so good technical people didn't have to become managers in order to be promoted.

There are many ways to provide leadership, and not every manager leads much.

tjl• 12 years ago

I recall that Nortel had parallel tracks as well. One of the guys I worked with did the technical track.

analog313• 12 years ago

The Fortune 500 company that I work for has parallel tracks. I actually moved from the management track to the technical track, and was promoted in the process.

I was probably an OK manager, but didn't feel that I would move up any further without doing some things that I didn't want to do, such as relocate.

Our managers don't actually spend a lot of their time managing people. Rather, they work on administrative and information processing tasks, and step in as small project managers.

maxxxxx• 12 years ago

My company has a technical track in theory but over the last 2 years I have observed that mediocre managers keep getting promoted regularly whereas only absolutely outstanding engineers move up. If you want to make decent money, management is the way to go. At least in my company.

lacker• 12 years ago

At many companies, including Facebook, there are parallel individual-engineer tracks and management tracks, with the pay scale equivalent between the two. It isn't good to nudge engineers towards management for financial reasons.

peteretep• 12 years ago

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

seanmcdirmid3• 12 years ago

I've only done programming and research for my career and shudder when I look at my boss's job. Heck, I get stressed just being assigned an intern. People management isn't for everyone.

snoman• 12 years ago

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.

mitchty• 12 years ago

I'm technical and I'm not that naive. The good bosses pull way over their weight in gold in what they do. Its not for everyone though.

cookiecaper4• 12 years ago

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

ownagefool• 12 years ago

Not really, it just depends on where you've worked in the past. If you came up under a decent management structure, you've had it easy. If you didn't, you get all the BS in addition to trying to solve potentially complex tasks.

I've had 1 good manager who I was too inexperienced to appreciate. Beyond that, the better managers I've had was too soft that the other departments were able to play politics with or hijack their staff and the worst did their best to keep you ultra stressed 24/7 because they thought you'd deliver more work that way.

We've all came up in different ways, unless you've had multiple lifes experiences, it's really hard to decide that's the way it is for everyone.

Bahamut3• 12 years ago

To add some more details - being a good manager can be a delicate dance. When you are a manager, you start to become responsible for high level tasks that have huge impact to a company. However, if you micromanage too much, you create an awful culture of fear and hamper developer productivity.

So how do you inspire developers to execute in a timeframe dictated by others? You have to be a leader who inspires the engineers to complete the task, even if it requires putting in extra hours. This means setting the example, looking out for your engineers' welfare, being able to provide answers and not problems, and being someone who can be easily approached.

The moment something goes wrong, the burden is on the manager to make the right decision - the wrong decision can have negative ramifications over months, if not years. The moment you micromanage, something is broken in your process, or with the people involved.

I recently had to start wearing a technical lead & director hat - the intense pressure of the startup world bore down on my whole team in order to get a working product in order from scratch in about 1 1/2 months of coding. The resources became scarce since the technical lead got sick & had a family death, while two other senior engineers had babies in the time period. It then was left to two junior developers and me to do the lion's share of work until the other engineers could get back to work. I let the junior engineers work mostly normal hours (until close to our deadline) - I ended up taking the burden largely on myself, with mostly 75 hour weeks (even after the other engineers were back as well). During regular hours, I did some work, but was more focused on mentorship and any tasks that were blockers. The early and late hours were when I busted out complex code.

At the engineering level, good management shows as incredibly important, especially for startups. Pressure deadlines on engineers are taxing for all - good management by top level engineers is vital for preventing burnout in everyone else, which can make it easy for people to decide to leave a company, especially when compounded by salary that does not match what the free market has to offer.

frostmatthew• 12 years ago

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.

As someone who was a banquet manager before switching careers I can assure you that you are 100% absolutely correct. My most stressful days (of which there are very very few) as a developer don't come close to my least stressful in my previous career.

mtrpcic• 12 years ago

This is definitely true. I recently made the transition from full time Engineer to Engineering Manager, and there's a lot more stress involved. It stems from a few different things:

* In most cases, the Manager acts as the communication layer between different departments. They abstract all that stuff away so developers can write code without being interrupted by various people. They then have to communicate that information back down to their team when needed (and in the right way)

* As a developer, you have a deadline, but missing it is often just a "Well, we didn't have the time" or "We tried, but just couldn't quite get there". As a Manager, it's your responsibility to explain why something was late, how it can be remedied in the future, and answering the inevitable "Well when will it be done then?". You're responsible for the overall project, including deadlines.

* Meetings. Not only are there a lot more meetings, they're often made for the schedule of other departments who don't have "the zone" in the same way that developers do. I still write code in my day-to-day, but a 60% reduction in programming time ends up being an 80% reduction in output because you get interrupted, side tracked, and generally don't have time to "ramp up" for >2 hours at a time.

There are many more reasons, but the stress level in the Management role, in my opinion, is a bit higher.

zobzu2• 12 years ago

ive done both and the stress depends on where you work a lot.

Note that this include the "tech lead" stuff. That said on average for me and my close colleagues its largely always been easier and less stressful as a manager or director.

eeeeeeeeeeeee2• 12 years ago

Thank you for posting this. I do think some companies undervalue their engineers, but it's crazy how frequently managers are disparaged on this site.

erikb• 12 years ago

I absolutely dig the money argument. A bad junior manager will probably make much more money than a jedi developer. Therefore many people choose to be a bad manager instead of a happy, good, developer.

hell-ban-me2• 12 years ago

Wow, where do you guys come from? At my current gig, as a contract engineer I make two times more than the department director, who is 4 levels up in the hyerarhy.

jules• 12 years ago

Yes, the only way around this is to become an independent consultant or start your own company.

marcosdumay2• 12 years ago

And then, you become a manager.

smsm42• 12 years ago

I have no problem with getting less money for doing something I'm good at and not doing something I know I'd hate and probably suck at. After all, I gave up a career of a hedge fund manager and a billionaire already to be an engineer - probably for the same reasons, because I suspect I'd actually suck at hedge fund managing and won't become a billionaire. In the same vein, if I tried to become a director knowing I'd suck at it, I may briefly enjoy the benefits of higher salary, after which my incompetence and my dissatisfaction with the job would become apparent and I'd be asked to leave. So long term it is probably a bad plan, unless people I'm going to direct over and report to are exceptionally obtuse and won't notice me reaching my Peter ceiling. That happens, but why would I want my life to depend on it?

And remember, we're not talking about vow of poverty here exactly. 150K gets you in top 10% easily, and if you have a household with two 150K salaries you're pretty close to the much envied 1%. Maybe there's a point where more money wouldn't actually make it better if it comes with more frustration?

As for why directors get more money - again, I have no problem with people doing what I can't and won't do getting more money than I do. My life is not a competition with them, it's a competition with my last year self. If I win that, I'm good. Which means, if the company wants to keep a good engineer who thinks like me, they should be able to provide some track for me to be better next year - position-wise, money-wise, respect-wise, responsibility-wise, however it goes - than last year, without forcing people into doing something they may suck at.

JimboOmega• 12 years ago

Am I the only coder who's always wanted to move into the business side eventually? I go back and forth on if I want to pursue an MBA every couple years or so (though I doubt the education would be worth it, it'd be a stamp on my resume for wanting to go that direction).

Working with brilliant people and managing people problems are very complex and interesting to me.

pyre• 12 years ago

Am I the only coder who's always wanted to move into the business side eventually?

I doubt it. The idea of not wanting to manage people gets more noise because 'moving into management' seems to be default path, and in some organizations if you don't move in that direction, you are punished. So people complain more loudly about these issues.

patio11• 12 years ago

There's quite a bit of variety on "the business side", FWIW. Getting an MBA does not necessarily get one increased access to it, depending on what you want to do and where you want to do it.

Dave McClure had a really good discussion once on starting a startup as the new MBA: far more interesting to hear you talk about how you sold $200k of sales than hear about how you read about someone doing the same. This also gives you a lot of opportunities to directly apply engineering skills in the service of your business goals. Those opportunities exist (in quantity!) in real life, but may not in any given MBA program.

jlees• 12 years ago

And for the management side, growing an engineering team from 1 to N will teach you more about people and (early-stage) organizational dynamics than any number of case studies. However, learning by doing -- and potentially failing -- doesn't appeal to everyone, and you can certainly balance the "on the job" learning with book-learning too.

I did an executive MBA, and plan to move into people management at some point. I enjoy it and I love the feeling of empowering a team to be excellent. At the same time I feel that you need a solid base as a respected individual contributor, especially if you are leading the team technically rather than playing bug-assignment Tetris -- which is what I'm focusing on for now. Management can seem like a dirty word in engineering, but some of us like doing it.

watty• 12 years ago

No. In fact, every coder I know who also has good social skills seems to want to go the business route.

analog313• 12 years ago

My observation is that the MBA degree is primarily valued by other MBA's.

blumkvist2• 12 years ago

That really depends on where you got your MBA.

alttab2• 12 years ago

Im with you dude. I began programming when I was 10 and have been doing it my entire life. Once I began working in organizations instead of on my own projects I was fascinated as to how the code I wrote was only a piece of it. I moved into management and I haven't really looked back. I still get to code, but its when I want to.

dmfdmf3• 12 years ago

This is a problem not just for coders but almost any technical area. A loooong time ago when I was still in engineering I worked for Big Corp, Inc. and they had a designation for master technical talent, I forget the name, so let's just call them Jedi Masters. It was a non-management path for those who didn't want to go the management route but it recognized their value to the company. If you reached this level you had no manager and had no assigned work but people from other projects could come to them for advice, help, consultation, etc. and they could choose what they wanted to work on.

Often the Jedi Masters were tapped to teach intro engineering course to new engineers on the specifics of the type of projects this company worked on, so this was a quasi-academic and quasi-consulting gig for the best of the best engineers.

As a fairly new engineer, I got assigned to a new group and invited to a meeting that could impact the system I was working on. I show up and it is a meeting with an engineering partner (outside company) that was contesting some calcs regarding the pipe strength and mounting requirements for an installation (multi-billion dollar project). Their engineering team was insisting on assumptions that would have quadrupled the cost of a system that our group was responsible for, not to mention weeks or months of delays to recalc and redesign the system. Unbeknownst to me, this dispute had been at logger heads for months with no resolution.

One of the Jedi's, let's just call him Fred, taught me years before in the intro courses and I had remained in contact with him over time. Based on the courses Fred taught I thought he might have the expertise and interest in this area to take a look at this problem so I met with him and gave him the technical details. He agreed to attend the next meeting and advise but he made me do all the calcs, presentation and etc. for the next meeting but all under his guidance. So I go through my PPT presentation and at the end the other company's engineers have all sorts of objections, disagreements, etc. So our Jedi steps in and starts fielding questions and asks them to justify their position. It turns out that their reference text they were using to justify their position was actually written by Fred! I can still hear the other engineer say, "you mean you are Fred XYZ that wrote book ABC" with awe and respect in his voice. It turns out they were missing some important exceptions and qualifications later in the book that Fred cited and the meeting and conflict was resolved.

So the moral of the story is to always have a Jedi in your corner? No.

The moral of the story is that engineers and problem solvers (and I assume coders) have different motivation than the "success" of big, showy career managing a lot of people. We (technical people) love to solve problems and management is projecting their values onto technical people when they offer them management positions as "promotions".

icyfenix5• 12 years ago

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.

dmfdmf3• 12 years ago

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; After this meeting technical colleagues praised me for bringing Fred in to get the problem resolved. Manager types praised ME for resolving the conflict. It was really a big deal and really advanced my career and Fred was happy to let me get the credit which is why he made me do the presentation but he got respect from the people "in the know" and that is all he really cared about.

choppaface2• 12 years ago

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.

dmfdmf3• 12 years ago

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.

Bahamut3• 12 years ago

I think the most important thing is to have a conversation with your employees - ask them what do they want to do, and how do they want their career to evolve. Constantly keep in sync with your employees' desires, and you should be fine.

Whitespace• 12 years ago

Having just become a co-manager for ~50 engineers, this is really interesting and timely advice. I don't pretend to have all the answers about how to reward great engineers, so hearing more people speak about this is really useful to me.

My initial reaction is "reward them with more things they can say no to" but that ends up being project management-y if not outright manager-y. I'm very curious to hear more specific examples where this isn't the case.

If anyone in NYC and is in a similar situation to me, I'd love to meet up for coffee to share notes. Or in SF, for that matter (I'm here about once a month). Email in my profile.

luckydude• 12 years ago

It's late so I'm going to screw this up but there are coders and there are leaders. The leaders think about other people and how to make those other people be successful. The coders are more about themselves. Which is fine, I'd just look for people who are trying to make other people be awesome.

vinceguidry• 12 years ago

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 trick to it is to realize that it's not, actually, a skill, when you break it down. It's an opportunity to structure part of the operation of the company the way you want to structure it. You can take all those ideas you have about how to run the company better and put them into practice on a small scale. You do not have to give up engineering, you're just also engineering at a bigger level than just with machines. You can and should still program, and still avoid pointless meetings by bringing your laptop to them and working through them.

You're engineering human systems now too. There's no conflict with the other machine-type engineering, because the two are intended to work in concert. So don't create one where it didn't before exist. Humans are easier to engineer than machines in many ways. You can tell a human to do what you mean, humans are smart and machines are stupid, a machine will only do what you tell it to do. You can't tell a machine to exercise judgment or grant them power or flexibility, they wouldn't know what to do with it. But grant flexibility to a human and he'll make your job much much easier.

Power necessarily involves freedom and flexibility, if you've an expectation to meet a responsibility without giving yourself the latitude to meet that expectation your own way, including the willingness to put your foot down to ensure your turf is protected, then you are putting yourself through hell. It's simple, decide what you need to get the job done, then acquire the resources, then follow through. If the expectation is unreasonable, then change the expectation. It's not hard, all you have to do is explain to people that it's unreasonable and offer an alternative. As an engineer, you should have already learned the skill of dazzling people with techno-babble. As a manager, they have to take your arguments seriously and compromise with you. You can't promote someone to management and then proceed to ignore their opinions. That's the whole point of the promotion.

I go home after eight hours. My boss will put in ten hour days but I won't volunteer to. I fully expect my new report will go home after eight like I do. When I wanted to move to flex time I just started coming in later and when my boss noticed, I just said I was going to choose my hours from here on out. My boss insulated me from office politics until I was ready to deal with it and I will extend the same protection to the new guy. I was somewhat worried that the promotion would come with strings attached. If anything they're more worried that I'll get cold feet than they are that I won't measure up. So they've been kissing my ass extra hard lately.

icyfenix5• 12 years ago

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.

cookiecaper4• 12 years ago

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.

icyfenix5• 12 years ago

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

noname123• 12 years ago

Just came to say that I really appreciate this comment and an example why I still read HN despite all of the signal-to-noise of startup hoopla's.

I want to second and say that when I was very young, I had the perspective of the coder who thought I was being meritocratic when I judged my lead or project manager by their technical worth, ability to lead, whatever; and thought what a dumb naive and pandering move my PM would do by bring Dunkin' Donuts Munchkin's to our morning meeting, but the truth is I judged him unconsciously for those Munchkin's; and after learning the hard way, I'm bringing out all of the proverbial Munchkin's of pandering/cajoling/politicking to everyone at work now.

I'd say for myself that I had once retreated to a purgatory of technical "proving ground". But it was a false purgatory with empty promises, and I'm slowly coming back to the harsh reality of the physical pecking order of lunch tables at junior high cafeteria. But it bothers me less because I realize now how petty both technical and social people are in their own ways.

spopejoy• 12 years ago

Great anecdote about the perils of mgmt. But I think it shows that management in an org or sub-org that has a terrible culture is ... terrible.

I've been in and out of management, and how awful it is comes down to who's above you. I've had upper mgmt that was mercurial and weird, but ultimately fair and supportive when the chips were really down. Result: stress but no bullshit.

I've had upper mgmt that was "cool" and had me over to their $3m vaca house and threw great parties. When the shit hit the fan, things were weird, uncertain. In the end I was thrown under the bus. Result: foreground "mellow", background stress, bad outcome.

Whether or not I bought donuts for my directs had nothing to do with it. My approach toward employees was 1) service 2) work queue mgmt 3) technical mentorship. In so far as I stayed on the ball this worked out fine. Most issues were my mistakes, not some horrible political gaming fail.

chuckcode• 12 years ago

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.

jefffoster• 12 years ago

Whilst I agree that technical leadership is one aspect that skilled engineers can develop (and I agree that it's important for all engineers) there are many more.

For example, developers can grow into great product managers. Some can deep-dive into a topic and develop by sharing that knowledge through conferences, blogs etc. Some are interested in the people management side of things (scrum, kanban etc). All of these (and much more) are incredibly valuable and increase the value to the company they work for.

The challenge for companies is to recognize all these degrees of value (and reward them appropriately). I did some work to try and capture this with a visualization called a skills map (http://blog.red-gate.com/skills-maps/). Any feedback greatly appreciated!

known• 12 years ago

Pay his taxes

atlantic• 12 years ago

I worked for a while with a software consultancy, as a .NET consultant. One of the nicest things about the company what that they had two distinct career paths for developers - one technical, the other in project management - and they asked us up front what our preference was, and directed our work accordingly. I always thought other companies could take a leaf from their book in this respect.

ZenoArrow• 12 years ago

Perhaps more companies would benefit research teams, who work on the next generation of products with less management interference. Being promoted to the research team could be a useful incentive to keeping talented engineers around. If they do stick around, the maintenance team could still consult the research team about the previous system they built.

gvb• 12 years ago

My summary/option: Technical leaders should be front-running the team so that, when less experienced engineers run into problems, the technical leader knows in what direction to point the team to find the solution to the problem.

Having technical leaders stuck on legacy Sisyphean tasks (a) sucks up the time that should be used front-running the team for solutions to future problems and (b) removes opportunities for less experienced engineers to learn new ideas and skills, hindering their education and development.

icedchai• 12 years ago

My experience has been that most managers wind up going to meetings all day and stop contributing technically.

I briefly (a couple years) managed a small team (<5 developers) and it was torture. Not worth the relatively small increase in $.

How do you reward your skilled coders? Let them do real, interesting work and not deal with bullshit (this includes all the time wasting "agile" meetings.)

mathattack• 12 years ago

When I was at BigCo, they officially had 2 paths - one involved people leadership, the other technical leadership. The reality was technical leadership stopped a level below director, and only 2 or 3 even managed to make it that far. After 3.5 years there, it had a formative impact of pushing me away from both the company and technology. I recovered on both, but it's something one should take seriously on taking a job. I'm not sure that creating "Mega-consultants" works either, as it takes the emphasis away from delivery ownership.

That said, here are a few ideas in rank order from easy/feasible to crazy/radical:

1) Technical leaders of a certain level can not be overruled on technical decisions by non-technical leaders in the department.

2) Encourage the best to share their work outside the firm.

3) Smart people like to be with smart people. Pay up for a culture or cohort of superstars, not an individual superstar.

4) Provide time and monetary budget for architecture and technical debt that is owned and allocated by the best in the organization.

5) Allow technical stars to have the ability to change assignments at their will with a given notice period. (Yes it may cause problems, but the free market is always giving them offers)

6) Enable managers to raise technical pay without concern for bands. For example, the VP should be able to say, "I can hire 4 engineers for 100K each, or I can hire someone in the open market for 200K. Instead I will pay my internal superstar 220K since she will do it the best, even though it's way out of bands of someone with her seniority and level."

thwarted• 12 years ago

One thing you definitely don't want to do is take a team away from people who consider themselves to be engineers who happen to be in a people manager role (and have been for a long time and are considered by their team and the wider engineering org to be successful at it). And if you want to do this, you have to make sure the person, and their team, is on board with making that change.

This can be especially problematic if you don't have a culture of the organization being driven by engineering; where becoming a "manager" affords more success (making decisions, getting things done) purely because you're a manager now (because of the political aspects). Removing the people management leadership position then can feel like a demotion.

morgante2• 12 years ago

A lot of people in this thread are pointing to the possibility of a technical track, but I just don't buy it.

Any technical track stops far short of the management track, even in the most enlightened of companies. Taken to an extreme, you don't get to be CEO off the technical track.

Ultimately, if you want more money and influence, you have to choose the management track. The technical track just exists to keep technical talent from leaving——look at any companies with technical tracks (ex. Facebook) and you won't find their top earners on it.

tdaltonc• 12 years ago

Some people value autonomy and freedom from obligation more than money and influence.

morgante2• 12 years ago

Some people value autonomy and freedom from obligation more than money and influence.

Of course I know & respect that. My point is just that having a "technical track" does not remove the incentives many engineers see for moving into management.

cardiffspaceman• 12 years ago

You may be right, but you might find plenty of managers wielding their power and/or influence, who wish they made as much as the guys at the top of the technical track.

billmalarky• 12 years ago

This is just a matter of scale. Sure you might be a "10x" developer, and such a developer does provide a tremendous amount of value to an organization. But if you are such an effective manager as to raise the value of a team of engineers significantly, then you are going to generally provide more value to the company than a single rockstar engineer. Of course there are outliers (IE Carmack) but generally skilled technical management scales better than skilled individual technical talent.

smenko• 12 years ago

Err... Money???

Most people will (rightfully) settle for money. Because people need love, and to demonstrate love you need to show that you care, that you're willing to give something up in a hard situation. And the only thing a company cares for is money. So, I want said company to give me money. More money than the 'manager'. Because I can do their job just as badly as they are doing it, but they can't do mine at all.

I don't want your stupid titles and shit - those are cheap. Cash is what will hurt you. Pay up if you care!

And when people realise they have to pay you or lose you, then you get respect. Priceless!!!

How to reward skilled coders with something other than people management

Related Stories