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."
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.
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?).
> 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 suspect that the reason for the perpetuation of this myth is that, if a manager is doing their job really really well then all of that stress and BS is hidden from their directs.
Indeed. The best managers I've ever had were the ones that completely shielded the rest of us from the absolute BS that always exist. Go figure, those were the companies where the rank & file didn't think political BS existed - surprise, your manager was protecting you from that!
So essentially managers are people sysadmins. They make sure everyone is working, try to resolve conflicts and ideally make sure that everyone is running the right tools. What would be a people engineer in that vein?
Yes. Although in my case when I was talking about my 'best managers', they were also the people who were brilliant and were really good at the tech side too. These people all just had a natural ability to navigate through the political BS while still being extremely competent software folks.
Yes, as much as I hate that term it really does apply here. And I'm really only thinking of 2, maybe 3 folks. These were the people who managed to be the most productive members of the team while dealing with all of the manager BS. When you find one of those you do what you can to stay under them.
So to continue the IT parallel, that'd be setup (hiring and training) and maintenance/debugging (hr complaints and problem resolving) imo. My personal hunch would be that viewing the whole thing in a systems context, the EOs would be engineering. After all, they decide how the company is run at a top level, and either assemble a functioning "people stack" or set guidelines for doing so. In that vein, components/prospective employees are churned out by the education system as a broader whole, and the raw material for that...alright, i think that's taking the metaphor far enough.
Managers create the BS, so they can hardly be credited with shielding people from it. They also create a lot of BS for their own reports such as playing the "your job is to make me look good" game, or having devs do a bunch of leg work so they can present everything as their own ideas.
Those are stereotypical bad managers, not ALL managers. I know a lot of great managers who are not like that. And even the ones that failed didn't fail due to malice or vanity. Most people I've encountered want to build cool things, even the managers, and they often know their strength is not in coding.
> As a programmer, let me tell you: people who have only ever done programming for a career have no clue how relatively easy they have it.
As someone who was a banquet manager before switching careers I can assure you that you are 100% absolutely correct. My most stressful days (of which there are very very few) as a developer don't come close to my least stressful in my previous career.
To add some more details - being a good manager can be a delicate dance. When you are a manager, you start to become responsible for high level tasks that have huge impact to a company. However, if you micromanage too much, you create an awful culture of fear and hamper developer productivity.
So how do you inspire developers to execute in a timeframe dictated by others? You have to be a leader who inspires the engineers to complete the task, even if it requires putting in extra hours. This means setting the example, looking out for your engineers' welfare, being able to provide answers and not problems, and being someone who can be easily approached.
The moment something goes wrong, the burden is on the manager to make the right decision - the wrong decision can have negative ramifications over months, if not years. The moment you micromanage, something is broken in your process, or with the people involved.
I recently had to start wearing a technical lead & director hat - the intense pressure of the startup world bore down on my whole team in order to get a working product in order from scratch in about 1 1/2 months of coding. The resources became scarce since the technical lead got sick & had a family death, while two other senior engineers had babies in the time period. It then was left to two junior developers and me to do the lion's share of work until the other engineers could get back to work. I let the junior engineers work mostly normal hours (until close to our deadline) - I ended up taking the burden largely on myself, with mostly 75 hour weeks (even after the other engineers were back as well). During regular hours, I did some work, but was more focused on mentorship and any tasks that were blockers. The early and late hours were when I busted out complex code.
At the engineering level, good management shows as incredibly important, especially for startups. Pressure deadlines on engineers are taxing for all - good management by top level engineers is vital for preventing burnout in everyone else, which can make it easy for people to decide to leave a company, especially when compounded by salary that does not match what the free market has to offer.
Thanks for sharing your story. This is part of why I love HN: I can learn from the experiences of people who're interested in similar things to what I'm interested in, but who're much further along in life.
Also wow, well done on shielding your junior engineers from the worst of the death march. Did you suffer much from burnout during your heroic effort? How did you cope?
I have a lot of resilience from a lot of life experiences. This not having been my first crunch time also helped me cope - I focused on getting as much of a good night sleep as I could (typically 6 - 7 1/2 hours a night, usually ended up closer to 6 - 7 1/2 is my optimal amount), and dosed on lots of caffeine if not well-rested. Exercise is also important.
I did have to sacrifice all other interests thought during the time period though. All I know is, I'm definitely taking a vacation in two months.
Not the OP, but similar situations. My coping strategy involved vitamins - a generous dosage of B-complex, and a mandatory eating and sleeping regimen. Survived potential burnout myself, and won concessions for team recovery. I've done this a few times now, difficult, but still works.
I've only done programming and research for my career and shudder when I look at my boss's job. Heck, I get stressed just being assigned an intern. People management isn't for everyone.
Not really, it just depends on where you've worked in the past. If you came up under a decent management structure, you've had it easy. If you didn't, you get all the BS in addition to trying to solve potentially complex tasks.
I've had 1 good manager who I was too inexperienced to appreciate. Beyond that, the better managers I've had was too soft that the other departments were able to play politics with or hijack their staff and the worst did their best to keep you ultra stressed 24/7 because they thought you'd deliver more work that way.
We've all came up in different ways, unless you've had multiple lifes experiences, it's really hard to decide that's the way it is for everyone.
I don't think you can make that kind of generalization. It really depends on the organization. Ideally neither position will pull an unequal amount of weight.
Remember that in many cases, the software developer has the same kind of weight on his shoulders; some bugs and errors can cause huge amounts of lost revenue, lost jobs, etc. Software plays no small role in the day to day operations and programmers carry a lot of weight on their shoulders, especially in companies that don't have strong testing and review methods (read: almost every company in existence).
This is definitely true. I recently made the transition from full time Engineer to Engineering Manager, and there's a lot more stress involved. It stems from a few different things:
* In most cases, the Manager acts as the communication layer between different departments. They abstract all that stuff away so developers can write code without being interrupted by various people. They then have to communicate that information back down to their team when needed (and in the right way)
* As a developer, you have a deadline, but missing it is often just a "Well, we didn't have the time" or "We tried, but just couldn't quite get there". As a Manager, it's your responsibility to explain why something was late, how it can be remedied in the future, and answering the inevitable "Well when will it be done then?". You're responsible for the overall project, including deadlines.
* Meetings. Not only are there a lot more meetings, they're often made for the schedule of other departments who don't have "the zone" in the same way that developers do. I still write code in my day-to-day, but a 60% reduction in programming time ends up being an 80% reduction in output because you get interrupted, side tracked, and generally don't have time to "ramp up" for >2 hours at a time.
There are many more reasons, but the stress level in the Management role, in my opinion, is a bit higher.
ive done both and the stress depends on where you work a lot.
Note that this include the "tech lead" stuff. That said on average for me and my close colleagues its largely always been easier and less stressful as a manager or director.
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.
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.
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.
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.
Wow, where do you guys come from? At my current gig, as a contract engineer I make two times more than the department director, who is 4 levels up in the hyerarhy.
Whilst I agree that technical leadership is one aspect that skilled engineers can develop (and I agree that it's important for all engineers) there are many more.
For example, developers can grow into great product managers. Some can deep-dive into a topic and develop by sharing that knowledge through conferences, blogs etc. Some are interested in the people management side of things (scrum, kanban etc). All of these (and much more) are incredibly valuable and increase the value to the company they work for.
The challenge for companies is to recognize all these degrees of value (and reward them appropriately). I did some work to try and capture this with a visualization called a skills map (http://blog.red-gate.com/skills-maps/). Any feedback greatly appreciated!
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".
This is exactly the sentiment I was going for - people who want to stay engineers should be compensated for their badassery, and respected for it, which is usually all they want. That right there is exactly the "power to say No" I was talking about.
And how do you know if an engineer wants to stay an engineer or not? By asking them.
I don't want to disparage the whole management class but I think part of it is that manager types don't really get the motivation to solve problems. They think that if someone doesn't have a manager telling them what to do then they won't do anything, but that is just psychological projection. Fred was one of the happiest (and busiest) guys at this company and many strived to achieve his status.
Regarding respect; After this meeting technical colleagues praised me for bringing Fred in to get the problem resolved. Manager types praised ME for resolving the conflict. It was really a big deal and really advanced my career and Fred was happy to let me get the credit which is why he made me do the presentation but he got respect from the people "in the know" and that is all he really cared about.
(pure) managers don't attempt to solve technical problems because such action usually obstructs individual contributors. What's apparent here is the substantial difference in perspective between managers and ICs. Managers tend to see social equilibria and the network effects of tech problems. ICs can see much, much more deeply into specific (and usually key) aspects of tech problems. A lot of classic conflicts arise when ICs-turned-managers overestimate the depth and completeness of their comprehension and try to lead the technical effort rather than compliment it. Hence a lot of managers are 'uninterested in problems.'
> They think that if someone doesn't have a manager telling them what to do then they won't do anything
As someone who has moved from being an IC to being a manager, I can assure you that's not true. What we do think is that an engineer won't necessarily work on the right things. Engineers have a tendency to work on something until they've solved it, which isn't the same things as finishing it. This is why personal projects usually end up being unfinished and unpolished. Engineers also sometimes let the perfect become the enemy of the good. The oft-cited Malcolm in the Middle episode (http://www.youtube.com/watch?v=RHpJFROEOmg) illustrates this well.
As a manager, I don't see it as my job to keep my team busy or even productive...they do that on their own. I see it as my job to keep them focused, particularly on the tasks that will provide the most benefit for the business.
I don't think you are talking about the introspective capabilities of a whole class of employees (managers) but rather describe the percieved dynamic of an employee-manager relationship in a particular company culture.
Lots of industrial management theory offer this strategy oriented top-down command and control structure as the ideal dynamic for a BigOrg but my personal view is that it is the one that is most easy to describe academically and is probably best (best application for model, not the best model for...) for doing scalable things in a technologically fairly static setting.
If the company is structured around this top-down command tree then I imagine it's not as much necessarily about how the manager internally models peoples motivations but rather about the management culture of his colleagues and superiors within which he works.
>>This is the problem: manager types
>>There is no such thing, it is an absurd invention.
Of course there is. Management as a career track attracts certain types of people, just like engineering. Every manager is different but they share a lot of common traits. Hence, "manager types."
These 'types' exist only to allow academia administrivia to be more open for profit. There is not such a thing as a 'manager type of personality', or 'a tech type' - this is an invention, utterly arbitrary, and a product of a corrupt education system that allows such a mythos to occur in order to cater to industrialization of human economy.
Each company will have desired traits in their managers, whether they go for the servant leader or the authoritarian delegator, their desired traits will limit who they view as suitable for managerial positions. There will be "manager types," and to people who have worked for that company for 10, 15, 20 years, that is the "manager type" for all companies, in their view.
There are also some traits that _are_ required for managerial work, certainly not enough to define a personality type, but without them, people could not function in a delegating, influencing, or persuading position. They're the traits that allow people to perform those functions.
I'd certainly be willing to concede the point that those aren't even personality traits, but skillful applications of personality that could be developed.
TLDR: I agree with you, but there's enough nuance in what "types" could mean that you're looking at a discussion about very subtle things that many people might not consider at first.
At the base of typecasting/stereotyping is prejudice. If you prejudge someone as being 'a manager type' before they've done any actual, you know, management - then you are prejudicial in your approach. Just because someone doesn't wear a tie and conform to social normatives, does not mean they cannot do things "typically associated with" socially-constructed norms, or 'types'. This is the biggest problem with manager-culture today: that bigotry and prejudice is still very much a factor in human interaction.
Thanks for sharing!! Like this story a lot better than the linked blog article. A positive example of real evidence is so much more effective than an essay of meta.
I am glad you liked it. I know HN doesn't like the supposedly contentless "thanks for sharing" type of comments but I appreciate it and think it is important to express such sentiments. In fact, about half way in to writing my comment I almost deleted it -- thinking no one would really care. I am glad I was wrong and that I completed it.
I should add that HN doesn't like brief, content-free "+1" or "this" comments, but a few sentences explaining why you liked a comment, and why it was exceptional in some ways, is almost never a problem, and are often greatly appreciated.
For example, you'll note that choppaface's comment has not been downvoted below 0, and probably has a few upvotes.
By the way, I also very much enjoyed your comment.
I loved it entirely. It was literally the first thing I read after the front page (I always read comments before the article).
I understand HN reason for not wanting countless thanks as it adds to scroll and doesnt add to the discussion... but it would be nice if they had a simple collapsible thread like reddit so once you got the gist or saw things are getting repetative you could jump down to the next main comment
Incidentally, it was this comment thread that led me to find this[1] for the same reason you list. The lack of collapsible threads has bugged me for a bit and I have been considering doing my own bookmarklet for a while but never got around to it.
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.
> 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.
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.
When: Straight out of college, or after working for a while?
How: Online or in-person?
In my neck o' the woods, there's a general sentiment that the MBA degree is more valuable (i.e., marketable) if you get it after already establishing your success in the business world. The route of going to business school directly after college is associated with the suspicion that you couldn't get a job, and still need to come up to speed in a business environment.
The people I know who have done this are mostly techies of some sort, and the conventional wisdom seems to be that business school is "hard" because of the math involved (finance and also some basic statistics), so if you're good at math, then it's not very hard.
From what I can tell, online programs from prestigious schools are gaining acceptance.
I don't know if the rule of thumb about graduate education applies to MBA programs: Don't attend grad school unless somebody else is paying for it. A benefit of getting an executive MBA while working, is if your employer is willing to reimburse you.
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.
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.
> 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.
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 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.
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.
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.
The figure 779,000 makes sense if you could take a programmer today and have him travel back in time to 1999. While the programmer was back in 1999 he(or she) would have access to everything that is available in 2014. The programmer would have access to the frameworks, the infrastructure(AWS), and everything else that we have available.
The reason average programmers today don't make on average 779,000 dollars a year, is because like many things, programming hours and talent have been commoditized. There are many people that can learn how to perform these programming tasks. It's easier and more accessible than ever.
An easily commoditized skill can still generate a tremendous amount of value. However, the worker is unlikely to capture most of that value. In fact, if a worker captures all of the value, there would be no benefit to the employer.
The point of the post is that we aren't in a labor bubble, because the amount of value created by a programmer is much higher than the programmer's salary. For instance, suppose that a contractor installing marble countertops on luxury houses out in the desert gets paid 100k a year. It turns out that the value of those countertops is below 100k a year. This could be used to suggest that the jobs themselves will disappear (or salaries must drop dramatically), as the value they generate isn't sufficient to justify that pay.
Now suppose installing those countertops generate 200k a year in value, but that it is relatively easy. That would suggest that salaries could drop even though there is a surplus of value in the existing salary structure. However, it wouldn't suggest that salaries need to drop because value generated isn't sufficient to justify the pay level.
I think that's the point here - that the amount of value generated is so great that programmer salaries could remain high. It doesn't necessarily mean then will, just that we aren't in a salary bubble where salaries are higher than value generated.
because like many things, programming hours and talent have been commoditized.
True. We should have fought it. We should still be fighting it. If commoditization is doomed to happen, then there's a structure (called a union) that enables it to happen on our terms rather than theirs.
The most obvious flaw, a programmer is only worth 5.7 times their 1999 salary if their work is generating 5.7 times as much revenue as it would have in 1999. I see no evidence that this is the case. If it were the case, and the vast majority of programmers are earning 1/6 of what their work is worth, then there is a huge opportunity that you can exploit to get rich. Go for it, and let us know how it works out.
Didn't a lot of major corporations get in trouble recently because they colluded to stop engineers from correcting this imbalance?
Your argument seems to ignore that market forces agreed that engineers were underpaid, and it was only by illegal collusion that their wages were kept to what they were.
To me, the strongest evidence that programmers are worth considerably more than they are typically paid comes form the absolute insistence from silicon valley companies that there is a "shortage" of programmers at the market rate (or well above the market rate).
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.
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.
Very true. We have the value-add potential that, on paper, would justify upward of $700,000 per year. Unfortunately, most of us are managed ineptly and so much of that value is squandered. There are plenty of ways that the surplus generated by our talents could be spent (expansion, higher salaries) but right now it's wasted on a high tolerance for mismanagement.
With all due respect, you're interpreting what I say in the most negative light possible, and I don't think you understand the point that I'm trying to drive through.
Programmers can add immense value relative to the cost of employing them. There are many ways in which this surplus could be reinvested. Unfortunately, it tends to be invested in tolerance of mismanagement.
We're capable of adding value at 5x our base salary (and that's a low estimate; 20-100x is defensible) but this gives corporations an excuse to run us at ~20% efficiency.
It sounds to me like the value is coming more from management than the programmer. After all, you admit that few people have the skill to deliver that value and the programmer can't deliver it themselves.
I would argue that many programmers can deliver that value directly. However, most corporate management filters get in the way.
The percentage of managers in technology/software who add more than they take away is small: maybe 5 percent. Another 15 percent or so are essentially neutral, and the other 80 percent do more damage than they add.
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.
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.
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).
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.
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.
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!!!
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.
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.
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.
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.
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.
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.
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.
Sales deals can be quite complex to measure as well.. IMHO is just that sales guys tend to be better negotiators, so they ask to get rewarded properly o go somewhere else with their skills.
Almost any process that measures human output will be gamed (optimizing for measured output rather than overall success). It's basically impossible to game sales without resorting to outright fraud, whereas there are all kinds of ways to game individual engineering output measurements, in ways that do not align with the business objective.
Sure. That's all true. But it doesn't change the situation.
There are difficulties, but there are difficulties in any job. It's still the job of management to evaluate the performance and contribution of their employees.
The more rote the process, the worse it will be, since, as you say, it will be able to be gamed. As a general rule, I've found larger organizations are worse at it because they have more rote processes, with complicated matrices, charts, etc.
I've been a cog at small, medium, and large orgs. I've been team or project-level management at small and large orgs. I was happiest being management at the small level. Much less politic-y stuff and more freedom to manage the way I saw best. I enjoyed being managed most at the mid-level company. Less room for managerial whims that small companies can suffer from. (Yes, I know I'm playing both sides on that. Heh.) And less of the 7,000 item Employee Evaluation Form Of Doom that big companies have.
It's hard, no doubt. But a manager saying they can't accurately evaluate their employees is literally saying, "I can't do my job." Any manager should always have a very, very good idea what's going on with their employees and their contributions.
Sure you can game sales to some extent. You can game the specific commission system. That's why it's very important for the specific incentives of the commission system to match the specific goals of the company.
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.
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.
Sales need something to sell. Jobs are paid based on the perception of how difficult it is to find someone to do it. CEO's are paid ridiculous amounts because the perception is almost no one can do the job. Janitors are paid little because the perception is almost anyone can do the job. The result of this is that many buildings are cleaned poorly, so nxt time you see a dirty bathroom, don't blame the janitor, blame the person hiring the janitor. The supply of good janitors is much more restricted than it appears, but that's because the person hiring typically can't see the value in paying more.
For programmers it's the same. Good programmers can make or break a business by building software which sells itself, or by building software with 10 times less effort, turning loss into profit, but many people hiring the programmers don't see it that way, so many programming jobs underpay, and many people paid to program have no business being anywhere near a keyboard.
The coder may be a cost saver in some cases, but not necessarily all; if that sales guy is selling software that the coder wrote, then the coder is just as much of a profit generator (actually more) as the sales guy who just sold the product that someone else made. The manufacturer and salesperson are both important. Generally speaking, the value of these positions is about even; specific situations may slightly favor one position over the other.
I worked a while as an "engineer who accompanies the sales guy to potential clients". Not really a sales engineer, as I didn't do actual salesman-y stuff and didn't manage accounts or anything. More as the guy who answered tech questions, gathered requirements, communicated back to the engineering team to get feature request time estimates, that kind of thing. More a 'liaison to the salesguy' than anything, though I would sit in on sales meetings.
It was fun, really. Lots of travel, lots of meeting people, lots of finding out what they really wanted us to be offering.
Anyway, I learned a lot about the art of sales, and while I was admittedly jealous of the money our salesguys made (some in 7-figure-land), I also learned it takes a specific kind of person to do it well.
And I could easily see why so many of them were such heavy drinkers. Combination of having to be very social and having the pressure of the revenue riding personally on your shoulders. I think as engineers you don't feel that pressure so directly. Certain execs in a startup, sure, but they're also part sales, in a way.
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.)
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.
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.
Just came to say that I really appreciate this comment and an example why I still read HN despite all of the signal-to-noise of startup hoopla's.
I want to second and say that when I was very young, I had the perspective of the coder who thought I was being meritocratic when I judged my lead or project manager by their technical worth, ability to lead, whatever; and thought what a dumb naive and pandering move my PM would do by bring Dunkin' Donuts Munchkin's to our morning meeting, but the truth is I judged him unconsciously for those Munchkin's; and after learning the hard way, I'm bringing out all of the proverbial Munchkin's of pandering/cajoling/politicking to everyone at work now.
I'd say for myself that I had once retreated to a purgatory of technical "proving ground". But it was a false purgatory with empty promises, and I'm slowly coming back to the harsh reality of the physical pecking order of lunch tables at junior high cafeteria. But it bothers me less because I realize now how petty both technical and social people are in their own ways.
Great anecdote about the perils of mgmt. But I think it shows that management in an org or sub-org that has a terrible culture is ... terrible.
I've been in and out of management, and how awful it is comes down to who's above you. I've had upper mgmt that was mercurial and weird, but ultimately fair and supportive when the chips were really down. Result: stress but no bullshit.
I've had upper mgmt that was "cool" and had me over to their $3m vaca house and threw great parties. When the shit hit the fan, things were weird, uncertain. In the end I was thrown under the bus. Result: foreground "mellow", background stress, bad outcome.
Whether or not I bought donuts for my directs had nothing to do with it. My approach toward employees was 1) service 2) work queue mgmt 3) technical mentorship. In so far as I stayed on the ball this worked out fine. Most issues were my mistakes, not some horrible political gaming fail.
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."