How to reward skilled coders with something other than people management (opens in new tab)

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.

    > Plus.. the director job is generally going to mean a
    > more relaxed job

If you believe responsibility over people, budgets, liabilities and policy is less stressful than responsibility over systems, you're high. As a programmer, let me tell you: people who have only ever done programming for a career have no clue how relatively easy they have it.

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

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.

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.

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.

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

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.

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.

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

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.

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

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.

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

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

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.

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.

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.

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.

You're worth any amount of money that both you and your employer agree on.

That's only simple in a fictional world where everybody agrees on what you're worth.

What are you worth?

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.

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

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.

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

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.

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

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.

Science says that will give you worse results:

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

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

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.

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.