9 ms·

How to reward skilled coders with something other than people management

414 points by koopajah 12y ago

icyfenix 12y ago
Ah sweet, thanks for the share. I hope this helps engineers do things that make them happy.
fein 12y ago
For me its pretty simple: Pay me what I'm worth. None of this managerial shite, just dollars. I will be happy.
- goodreel 12y ago
  That's only simple in a fictional world where everybody agrees on what you're worth.
  - hell-ban-me 12y ago
    Hm, Best Korea is real.
- jshen 12y ago
  What are you worth?
  - michaelochurch 12y ago
    http://michaelochurch.wordpress.com/2014/05/24/whats-a-mid-career-software-engineer-actually-worth-try-779000-per-year-as-a-lower-bound/ http://michaelochurch.wordpress.com/2014/05/24/whats-a-mid-c...
    - jshen 12y ago
      That's flawed reasoning in so many ways.
      - ionforce 12y ago
        How is it flawed?
        jshen 12y ago
        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.
        ObviousScience 12y ago
        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.
        jshen 12y ago
        My point still stands. If this is true there is an enormous opportunity for you to get rich. Try it and let us know how it goes.
        hueving 12y ago
        The imbalance was mostly on the management side. Even then, it wasn't almost an order of magnitude like that silly blog post suggested.
        frozenport 12y ago
        It's even worse because you might code up a storm and not add any value. You might work a dead project and only loose the company money. I have seen many a John Henry try to save a project from technical failure when it was a business failure.
    - petercooper 12y ago
      I don't disagree with the initial premise of the article, but I think it misses that while developers have become substantially more productive, it has also become substantially easier to be a productive developer which has caused the value to maintain its current equilibrium.
- baddox 12y ago
  You're worth any amount of money that both you and your employer agree on.
  - enraged_camel 12y ago
    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 12y 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 12y 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 12y 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 12y ago
Great article!
jaunkst 12y 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 12y ago
  If money is a means to an end, why not just find an employer who provides and supports that kind of work directly?
  - seanmcdirmid 12y ago
    Those jobs are hard to find. If you have one, hold on to it.
  - cookiecaper 12y ago
    Because having the actual money lets you determine the end and implement it by your own definition.
icyfenix 12y 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 12y 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 12y 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 12y ago
Compensation, equity and when those are ultimately satisfactory, autonomy.
deleted 12y ago
[deleted]
clueless123 12y 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 12y ago
  It's much harder to measure the production of "coders."
  - waterlesscloud 12y 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 12y 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 12y 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.
zobzu 12y 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 12y 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 12y ago
    I recall that Nortel had parallel tracks as well. One of the guys I worked with did the technical track.
  - analog31 12y 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 12y 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 12y 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.
JimboOmega 12y 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 12y 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 12y 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 12y 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.
dmfdmf 12y 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".
OGC 12y ago
Nah, fuck you, pay me.
Bahamut 12y 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 12y 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 12y 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 12y 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.
chuckcode 12y 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 12y 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/ http://blog.red-gate.com/skills-maps/). Any feedback greatly appreciated!
known 12y ago
Pay his taxes
atlantic 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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.
morgante 12y 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 12y ago
  Some people value autonomy and freedom from obligation more than money and influence.
  - morgante 12y 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 12y 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.
- deleted 12y ago
  [deleted]
- billmalarky 12y 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 12y 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!!!

414 points by koopajah 12y ago

icyfenix 12y ago

Ah sweet, thanks for the share. I hope this helps engineers do things that make them happy.

fein 12y ago

For me its pretty simple: Pay me what I'm worth. None of this managerial shite, just dollars. I will be happy.

goodreel 12y ago
That's only simple in a fictional world where everybody agrees on what you're worth.
- hell-ban-me 12y ago
  Hm, Best Korea is real.
jshen 12y ago
What are you worth?
- michaelochurch 12y ago
  http://michaelochurch.wordpress.com/2014/05/24/whats-a-mid-career-software-engineer-actually-worth-try-779000-per-year-as-a-lower-bound/ http://michaelochurch.wordpress.com/2014/05/24/whats-a-mid-c...
  - jshen 12y ago
    That's flawed reasoning in so many ways.
    - ionforce 12y ago
      How is it flawed?
      - jshen 12y ago
        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.
        ObviousScience 12y ago
        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.
        jshen 12y ago
        My point still stands. If this is true there is an enormous opportunity for you to get rich. Try it and let us know how it goes.
        hueving 12y ago
        The imbalance was mostly on the management side. Even then, it wasn't almost an order of magnitude like that silly blog post suggested.
        frozenport 12y ago
        It's even worse because you might code up a storm and not add any value. You might work a dead project and only loose the company money. I have seen many a John Henry try to save a project from technical failure when it was a business failure.
  - petercooper 12y ago
    I don't disagree with the initial premise of the article, but I think it misses that while developers have become substantially more productive, it has also become substantially easier to be a productive developer which has caused the value to maintain its current equilibrium.
baddox 12y ago
You're worth any amount of money that both you and your employer agree on.
- enraged_camel 12y ago
  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 12y 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 12y 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 12y 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 12y ago

Great article!

jaunkst 12y 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 12y ago
If money is a means to an end, why not just find an employer who provides and supports that kind of work directly?
- seanmcdirmid 12y ago
  Those jobs are hard to find. If you have one, hold on to it.
- cookiecaper 12y ago
  Because having the actual money lets you determine the end and implement it by your own definition.

icyfenix 12y 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 12y 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 12y 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 12y ago

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

deleted 12y ago

[deleted]

clueless123 12y 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 12y ago
It's much harder to measure the production of "coders."
- waterlesscloud 12y 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 12y 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 12y 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.

zobzu 12y 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 12y 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 12y ago
  I recall that Nortel had parallel tracks as well. One of the guys I worked with did the technical track.
- analog31 12y 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 12y 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 12y 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.

JimboOmega 12y 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 12y 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 12y 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 12y 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.

dmfdmf 12y 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".

OGC 12y ago

Nah, fuck you, pay me.

Bahamut 12y 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 12y 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 12y 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 12y 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.

chuckcode 12y 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 12y 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/ http://blog.red-gate.com/skills-maps/). Any feedback greatly appreciated!

known 12y ago

Pay his taxes

atlantic 12y 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 12y 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 12y 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 12y 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 12y 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 12y 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.

morgante 12y 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 12y ago
Some people value autonomy and freedom from obligation more than money and influence.
- morgante 12y 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 12y 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.
deleted 12y ago
[deleted]
billmalarky 12y 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 12y 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!!!