The lowest-level manager has significantly more accountability than anybody else (i.e. most likely to be fired without 8 months notice a director would get) with few upsides (lower pay per hour of work, worse career trajectory, greater stress, will be forbidden from having negative opinions about anything the company does, more likely to be scapegoated for a boss's mistake).
this feels incredibly familiar. either youre promoted to a lead, given no training, and fired or demoted when you dont succeed, or you're slowly just "recognized" as the lead without any overt assertion from management. The latter is the worst, because after a few month or even a year there is a tacit communal agreement among leadership that you're secretly the lead without ever defining what that is. pretty soon you're charged with everything from random powerpoint presentations to some midlevel managers incident/action reports with no real idea why its happening other than you're a 'subject matter expert.'
It has a scarring effect ive found, anecdotally. Ive spent 12 years as a systems administrator in various contexts (traditional, devops, contract, etc..) and I've already declined a leadership role on the pretext that its just going to be system administration with the expectation with added clerical ditch-digging for the real management team.
this feels incredibly familiar. either youre promoted to a lead, given no training, and fired or demoted when you dont succeed
I don't see any difference between not getting any leadership training and not getting technical training throughout your career.
When I want to learn a new technology, I don't wait for the company to train me. I train myself. When I got thrust into leadership (see a previous comment to this story), I started training myself.
"you're slowly just "recognized" as the lead without any overt assertion from management"
can't you just ask for official recognition or find a new job that is a better fit for what you actually do? there are billions of jobs in software, if you have the skills to should be able to do so
A well run organization should also be mandating regular bi annual meetings between employees and managers for goal setting. Both as an employer and as an employee you want to know what each others expectations are, so you should be following up on this continually. It's crucial for job satisfaction on both ends.
I think you may have meant semi-annual (every 6 months). In my opinion, every 3 to 6 months is a good checkpoint for a more formal evaluation, but that ongoing communication should take place through regular meetings every 1-2 weeks.
I'm not impressed by this. It presents all the standard management cliches (set expectations, have empathy, learn to delegate) without ever addressing the real, valid conflicts that are so common.
i haven't listened to this but will at lunch for sure. I'm in the process of making the switch to management after accepting a new role around last Nov. It's painful, one of the hardest parts for me is knowing when I've had a good day or bad day, there's not a good measure, things are very subjective. The mentoring and leadership aspect of management I've really taken to and didn't expect to enjoy so much. Pairing up a Sr. and Jr. dev and watching the Jr. dev bloom and the Sr. dev become a better communicator, to the point i've put them in front of a client, has been the highlight so far.
When I moved from programming into management, the hardest thing I found was to change from flow-driven work to interrupt-driven work. I started with the golden rule: "Manage people the way you would like to be managed." That lasted about ten minutes. I changed it to "Manage people the way they want to be managed" which was much more succesful.
To me the hardest part of moving into management from engineering came with the realization that "accomplishment" is a much squishier thing. Almost every action as a manager ends up as a compromise across several different very soft-skills variables.
Recognizing the core of what matters and not getting hung up on other distractions seems to be the difference between success and failure. I don't focus on my career at all and have found that it usually takes care of itself so long as I don't bypass any opportunities.
Here's my checklist I use to see if I'm doing a good job (by my own measure), and these are not in order of priority but must be balanced simultaneously:
- put your staff first, leadership is a service function
- ship, on time, and within budget -- exceed expectations
High Output Management by Andy Grove. Read that book and the “First Break All the Rules” book mentions ones elsewhere. Most of the rest is duplicative or crap.
Also, just be you. People see potential in you and how you work. Don’t surrender your soul to management books — management is like organization, there’s lots of “management porn” that makes it easy to procrastinate through reading. Most of the guidance you see is ego-driven and conflicting.
The indirect thing you should consider working on that was hard for me and many other tech people is networking and relationship building. I’m at a director level position now, and my ability to pick up the phone and have someone do something is an increasingly important part of my job. Making that happen is time and work.
Thanks for the advice. I love to take in new information, but try to make sure I'm thinking critically about what I'm learning.
I'm moving from a large organization to a smaller one, by an order of magnitude or more, so I'm looking forward to having the ability to know everyone on some level and be able to reach out directly when needed.
The Slack group is request only - you will see a mention of it at the bottom of the weekly email - you just send a reply to the email requesting access and you will be invited in.
"First, Break All the Rules." The title sounds dumb, but trust me, it's full of good advice. It's based completely on research and interviews with successful managers.
The Manager's Path is a book i found on Amazon, I really like it. Basically, each chapter is one rung up the management ladder. You can read the whole thing or just up to the chapter where you're currently at.
Product management, sales, marketing etc coupled maybe with some business school training. Sometimes these are better paths into management, because you get sufficient product knowledge to help you understand the nitty-gritty details of what you will be managing or becoming a executive for.
I know of two options if you are willing to work your way up slowly:
1. Become a domain expert and work in the domain and then move into product management. Kind of a round-about way to go about it, but if you like the domain then why not.
2. There are also a lot of low level project coordination jobs out there. It's not really management and it's really stressful work as you get a lot of responsibility, but not a lot of power. But if you don't burn out then you'll slowly get more and more clout and move up the hierarchy.
You know, a large proportion of companies don’t even have developers employed or much to do with software, yet they still have people in management. This implies that there are multiple ways!
Do not get an MBA unless your company will pay for it and you're going to a top 10 school. It's a networking opportunity first, an education opportunity second.
I worked for a large company that paid for my MBA, and then I was caught up in a mass layoff immediately after graduating. Strange. Still working as an individual contributor Software Engineer (albeit a well paid one) all these years later. Can't seem to land a lead position.
I've known people who were promoted only when they threatened to quit. One was a relatively new hire - I couldn't believe it worked in her case (who demands a promotion/raise after 2 months on the job)?
One thing I've learned far too late in my career is that it's amazing what you can actually get if you just go up to the right person and say you want it.
I'm in my 40s, been developing for over 20 years professionally and was programming in assembly since the late 80s in middle school and felt the same way.
I kind of stumbled into a job as a lead. I was looking for a job, thought I was applying for just another senior developer job and I started asking my version of the Joel Test * to my now manager. I realized after a lot of questions about architecture, strategy, and mentoring that he was looking for someone to basically create a modern development shop. Luckily I knew enough to talk intelligently about it to make it through the interview without planning.
It's been a great but humbling experience. The great part is that I'm only working on green field projects and I don't have to deal with the technical decisions by others. I was able to mold the department in my own image - I'm always reading about best practices and asking advice from former coworkers.
The humbling part is that I realized two things, I'm good at teaching and working with the smart developers who had been there for awhile working on a legacy system that were just learning newer technologies, but I sucked at figuring out the types of people when I was hiring that were "smart and gets things done"
I was even worse when it comes to the project management side of things. Luckily, the developers who had been there for awhile were self managing and knew the business process inside and out.
Alan Kay said that people who are really serious about software should make their own hardware. I feel the same way about becoming an architect or team lead. If you really want to be a good developer, you should really be a team lead. As a team lead, you have more leverage than as an individual developer.
Your only option is to always work for a company that builds products.
Consultancies are not an option: they depend on buying cheap man-hours and selling then for a profit. As you age, your monetary need will increase and consultancies won't be willing to pay you more... unless you become a manager.
Product-builders are less shy to pay better wages for two reasons: 1) They dilute their wage expenses into a lot of customers and 2) They assume you're a good hire both for them and the competition, so hiring you means getting some leverage against competitors.
All that does is raise the ceiling slightly. The number of specialists with compelling skills earning much more than typical ICs is dwarfed by the number of senior directors, VPs and C-suites earning as much or more as the specialist can.
Most developers, say, do not have any career path that ends them up in the C-suite, so holding that up as a comparison isn't very useful.
If you finish out your career as a middle manager or a technical specialist, it looks much more similar. It's a path to consider for many people, but realize there are far fewer opportunities (and less lateral mobility).
Tip #1: be content with your current salary. Otherwise you'll have to do something outstanding, so that your higher ups will pay you more even though you're "just a developer".
FWIW many companies have parallel tracks for ICs and management. The upside for ICs is that you can become as senior as a VP with zero reports. The downside is that there is no comp bump just for managing people: it's only extra overhead so it becomes a labor of love at these companies. (You do it because you enjoy shepherding people's careers, not because it will get you a raise.) At some companies I've even seen PMs prevented from managing people until a super senior level in order to keep them focused on execution and the org structure flat (another byproduct of making management offer principally intrinsic rewards is that fewer people do it and those that do tend to be better at it).
In most companies I have seen the technical track is incredibly hard to advance on. You have to be incredibly good to make the same money mediocre managers make.
I thought people are being paid for the value they provide. Being in a technical role is not just fun and games. There is a lot of responsibility and stress too. I would argue that good technical people provide more value than some middle manager so they should get paid accordingly.
But in general, they don’t. You have to be very, very good for your contributions as an IC to outweigh the value of a merely decent manager.
What I’m saying is they the pay tends to mostly reasonably represent value, in my experience. With a slight discount due to ICs often being bad negotiators (bit so are technical managers). As an individual, you have to consider what the job does for you, not just the other way around. If you want to increase your salary, absolutely you should be considering how you can change what you do to make a compelling argument that you are (or will) bringing more value.
Which isn’t to say that a great IC can’t bring a ton of value - it’s just that they are also rare.
What makes it harder is that typical IC ‘s lack both the visibility and experience to estimate value well (in the bottom line sense). So without infrastructure around it, you are at high risk of spending expensive time on the wrong things.
Seems both of us are saying the same thing: if you want to make more money you probably have better chances to accomplish this by going into management. Going the tech route is harder.
Yes, I think we are mostly on the same page. There are more routes to a bigger paycheck through management. But there are non-management routes for some. Also, very few people are motivated exclusively by salary.
The lowest-level manager has significantly more accountability than anybody else (i.e. most likely to be fired without 8 months notice a director would get) with few upsides (lower pay per hour of work, worse career trajectory, greater stress, will be forbidden from having negative opinions about anything the company does, more likely to be scapegoated for a boss's mistake).
See the Gervais principle: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...