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

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

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!

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

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

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.

Pay me what I'm worth. None of this managerial shite, just dollars. I will be happy.

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.

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.

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.

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

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.

What is so hard to understand about that ?

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

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.

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.

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.

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

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.

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.