Things I've learned transitioning from engineer to engineering manager(blog.pragmaticengineer.com)
blog.pragmaticengineer.com
Things I've learned transitioning from engineer to engineering manager
http://blog.pragmaticengineer.com/things-ive-learned-transitioning-from-engineer-to-engineering-manager/
91 comments
This 100%. The best manager I had I likened to a good platoon commander. Understood importance of morale, respected and trusted us, was transparent when he asked us to do something hard, and would never ask us to do something he wouldn't do himself. Many a times he went to bat for us against upper management and pushed back on death marches, and fought for resources like dinner and extra time off for us after a late night deploy.
He understood we were a team, and we weren't stupid. Your employees are working in a technical, educated field. They can smell bullshit a mile away. If you try to take advantage of them they will shit your bed and leave
He understood we were a team, and we weren't stupid. Your employees are working in a technical, educated field. They can smell bullshit a mile away. If you try to take advantage of them they will shit your bed and leave
In the military junior leader's get taught Adair's theory of Action Centred Leadership: that Task, Team and Individual are separate things to deal with and yet mutually dependent.
Which to make the primary focus can and should switch up. If you are firefighting on a submarine all that matters is the task - the team are all dead if you fail. The individual does not matter there and then.
Back in the land of computers we have less extreme but analogous problems. There are times when you do need to focus on the task, however if you're a good leader you've used the times when that isn't the case to focus on building a Team and developing each Individual so that they can, and are willing, to dig out to achieve the Task.
Which to make the primary focus can and should switch up. If you are firefighting on a submarine all that matters is the task - the team are all dead if you fail. The individual does not matter there and then.
Back in the land of computers we have less extreme but analogous problems. There are times when you do need to focus on the task, however if you're a good leader you've used the times when that isn't the case to focus on building a Team and developing each Individual so that they can, and are willing, to dig out to achieve the Task.
My favorite managers were always similar to the one you describe. But I also noticed these managers didn't get promoted as the more "pointy haired boss" types.
That's the difference between "managing up" and "managing down". The PHBs and those who get promoted rapidly spend their time kissing ass...
I would disagree. My boss has the record of fastest promotion of junior developer to executive and he fights for us against other department/team heads and upper management on a regular basis. Its because he makes sure to deliver such value to the company that the management can't ignore him and his team
Op here. I agree team morale is absolutely essential. At the same time, as a manager you should understand how your team adds value to the company - and if it doesn't, fix that.
I write this from personal experience, having seen teams been disbanded who did a great job shipping... stuff that brought in zero value to the company. This is something I personally would want to avoid if possible, hence me putting "company first" as #1.
Of course no two situations and companies are the same, so there might be cases when having a healthy team trumps doing what the company (thinks it) needs. For now I'm personally sticking to aligning all three where I can: have a great team building things that matter with satisfied members.
I write this from personal experience, having seen teams been disbanded who did a great job shipping... stuff that brought in zero value to the company. This is something I personally would want to avoid if possible, hence me putting "company first" as #1.
Of course no two situations and companies are the same, so there might be cases when having a healthy team trumps doing what the company (thinks it) needs. For now I'm personally sticking to aligning all three where I can: have a great team building things that matter with satisfied members.
> I write this from personal experience, having seen teams been disbanded who did a great job shipping... stuff that brought in zero value to the company.
How do you get to this point? I have never been on a team where someone further up the business wouldn't come up to us at some point and ask, "Uh, what is the business value of what you are doing?"
How do you get to this point? I have never been on a team where someone further up the business wouldn't come up to us at some point and ask, "Uh, what is the business value of what you are doing?"
"We need this refactoring/migration to enable feature X"
> have a great team building things that matter with satisfied members.
Cherish this, and secretly examine every nuance of its ups-and-downs while you can. The basis of all of your future management efforts will be to get back to something similar to this point.
Just remember, a manager is a well-organized servant leader who is ultimately never responsible for success.
Cherish this, and secretly examine every nuance of its ups-and-downs while you can. The basis of all of your future management efforts will be to get back to something similar to this point.
Just remember, a manager is a well-organized servant leader who is ultimately never responsible for success.
Usually #1 and #2 are not in conflict. The whole role of a manager is to translate company goals into engaging team projects.
The point I think the author makes is that it is not the desires of the team that set up priorities at this point, and that it is contrary to what you are expected to do at the dev level (i.e. advancing your team projects first)
The thing is, if a manager does not set goals for it's team, it will find some by itself (refactor that old code, clean the doc, improve that funky demo, test out the latest shiny equipment) that are not necessarily the best choice for the company.
My experience has been that in that situation, very often, the team is relieved when it receives new instructions. It is not a "team or company" thing It is just an ordering of priority goals that makes sense to everybody.
The point I think the author makes is that it is not the desires of the team that set up priorities at this point, and that it is contrary to what you are expected to do at the dev level (i.e. advancing your team projects first)
The thing is, if a manager does not set goals for it's team, it will find some by itself (refactor that old code, clean the doc, improve that funky demo, test out the latest shiny equipment) that are not necessarily the best choice for the company.
My experience has been that in that situation, very often, the team is relieved when it receives new instructions. It is not a "team or company" thing It is just an ordering of priority goals that makes sense to everybody.
Thank you for saying this. I just want to add how this becomes super hard in an early stage startup. People underestimate how hard it is to translate company goals to engaging team projects, when a startup is in a lot of flux. The goal post moves so much. It's super super hard to keep an eye on the goal post, translate that goal to the team, and a couple of weeks later tell the team that no the earlier tasks are no longer valid, here's a new set. Rinse repeat until you hit PMF.
> Far too often I've seen the manager put the company way ahead of the team
Hear! Hear! This completely, followed by managers being too lazy or being too ignorant and just never "getting it".
After many years, I've come to the conclusion that:
1. I sucked as an engineering manager.
2. Most people suck as engineering managers.
3. The only thing that works is a flatter structure with really exceptional managers as actual engineering managers that do what's right and stand up for the team, with a set of people under them that don't actually have management authority, but they can organize things, stay on top of efforts, and communicate status to those that can. This works because really exceptional managers are extremely hard to find and are paid well, so if you try to do anything but this, you will hire bad managers.
Hear! Hear! This completely, followed by managers being too lazy or being too ignorant and just never "getting it".
After many years, I've come to the conclusion that:
1. I sucked as an engineering manager.
2. Most people suck as engineering managers.
3. The only thing that works is a flatter structure with really exceptional managers as actual engineering managers that do what's right and stand up for the team, with a set of people under them that don't actually have management authority, but they can organize things, stay on top of efforts, and communicate status to those that can. This works because really exceptional managers are extremely hard to find and are paid well, so if you try to do anything but this, you will hire bad managers.
It's really great to think your team is the most important thing, but you don't pay their salaries, the company does.
Your team's health can absolutely be the number one vehicle you use to get the company the results they are after, but you can't forget the fact that the company employs you, and them for reasons other than their happiness.
Your team's health can absolutely be the number one vehicle you use to get the company the results they are after, but you can't forget the fact that the company employs you, and them for reasons other than their happiness.
This is very much the case. Also, though many on HN might not like it, software developers are not special. There are many, many people with sufficient skill and interest to replace most developers in most companies.
That said, it's a mistake to treat developers like commodities or to dismiss their concerns and desires as second to the company, in my opinion. Churn hurts, and demoralized teams have negative impact on develpment.
That said, it's a mistake to treat developers like commodities or to dismiss their concerns and desires as second to the company, in my opinion. Churn hurts, and demoralized teams have negative impact on develpment.
If software engineers are really so easy to replace then why hasn't it happened? They're currently paid more then most professions so clearly businesses would take a cheaper path if available.
It happens all the time, especially outside of anomalies like the Bay Area. Even in the Bay Area it happens frequently enough. Pay is higher in the Bay Area and similar locations because of artificial constraints from the demand-side, not because of a lack of supply. Outside the Bay Area (and similar places) developers aren't paid that much better than any other college educated, skilled worker. I came from outside the Bay Area. This world is...very different from the software world in most other places.
The median pay across the whole US for software engineers is quite a bit higher then the median income for all professions. Or are you referring to a different country?
He may have meant “professional occupations” which means doctors, lawyers, accountants, etc.
I know people working for the railroad as track workers that make more than the median salary for a software engineer in my area.
So, take 'professional occupations' with a grain of salt. There are high-paying occupations that don't require a 4-year college degree.
So, take 'professional occupations' with a grain of salt. There are high-paying occupations that don't require a 4-year college degree.
Doctors have an extra 4 years of very expensive school plus an extra 3-7 years of training. Lawyers have an extra 3 years of very expensive school and only make about 15% more on average than software developers. Accountants make on average about 30% less than software developers.
It is happening in the long term. Software engineers are in the long term often being replaced by other software engineers. The process does not exists in world where people change companies before the companies could realize they need to be changed or where companies lifecycle is short (e.g. startups which die before 2 years and participants move to other positions.)
Software engineers being replaced occurs in a more indirect way. Usually through automation and third party SaaS. Companies replace their own devs with technology and other companies devs rather.
> There are many, many people with sufficient skill and interest to replace most developers in most companies.
Of course. The vast majority of whom are already employed at market rates.
I can easily be replaced but the company will be eating close to $100k in costs as well as taking on more short term risk.
Of course. The vast majority of whom are already employed at market rates.
I can easily be replaced but the company will be eating close to $100k in costs as well as taking on more short term risk.
[deleted]
But here's the thing: as a manager you only can control your team. Companies (especially public companies) are capitalistic machines that want to show growth each quarter. Good management is the only thing keeping humanity in the picture.
Lots of companies die because they pursue quarterly growth. Team-focused managers focus on long-term health of the company.
Lots of companies die because they pursue quarterly growth. Team-focused managers focus on long-term health of the company.
How I would like this point to be true! It sounds plausible but I do not have a proof.
Right, and the #1 job your company employs you to do as a manager is... manage your team. You absolutely have to look after your team first, because the company's health follows the health of it's components.
I disagree with both of these as absolutes. My manager's job is to advocate for work for his team, to make sure our work is aligned with the company's strategic and tactical goals, and to keep the individual contributors' morale as high as possible. The latter is looking after the team, of course, but realistically sometimes the needs of the company and the desires of ICs on the team diverge. In that case a manager's job is to transition those members who aren't in alignment off the team, preferably to another in the company if their talent merits but out of the company is a good solution also.
I agree with your disagreement. If you don't care about your people and team and don't put them first then it's highly unlikely you'll actually be in any way productive to give the company what it needs.
I guess the way I view it is that company is the destination and team/people is the journey.
This way isn't the only way though, I've seen teams run 'company first' it generally involved a lot of unhappy people and I didn't like it, so I avoid that style personally. A friend of mine seems to pride himself on being a 'hard driver' and being 'brought in as the hammer', ; but to each their own.
I guess the way I view it is that company is the destination and team/people is the journey.
This way isn't the only way though, I've seen teams run 'company first' it generally involved a lot of unhappy people and I didn't like it, so I avoid that style personally. A friend of mine seems to pride himself on being a 'hard driver' and being 'brought in as the hammer', ; but to each their own.
As with most management things, there’s probably a lot of nuance to how you can approach this.
I’ve had managers make it clear that me and my teams were a distant #2 to the company needs. It was pretty demotivating (as you said).
On the other hand, part of a managers job is to align their teams with the organizational priorities.
Maybe it comes down to how you achieve that alignment?
I’ve had managers make it clear that me and my teams were a distant #2 to the company needs. It was pretty demotivating (as you said).
On the other hand, part of a managers job is to align their teams with the organizational priorities.
Maybe it comes down to how you achieve that alignment?
I think this is a red herring all the way. Before you think about this problem, the first thing you have to ask yourself is: "Why do we have managers"?
Let's start a thought experiment. We'll start a company with one person. What will that person do? Manage? Of course not. There is nothing to manage, because there is only one person. Instead, although they have to plan and prioritise their work, if they aren't actually spending most of their time working, then nothing will get accomplished.
What if we have 2 people? Should we make one person a manger and have the other person do the work? Of course not. The manager will have virtually nothing to do while the working person will be overwhelmed. Although you may shift some responsibilities depending on who likes to do what, or who has various skills, unless both people are working then you will have lots of problems.
At what point do we need a manager? Well, we need a manager when the communication overhead and day-to-day chores impacts development. We only need that manager when there is enough work that they will be able to spend almost all of their day doing that work.
So what will they do? Basically anything that is stopping the workers from getting their job done. If there is a problem with communication, then the manager needs to organise things so that everybody has the information they need. If there is a lack of prioritisation, then the manager needs to prioritise/plan the work. If there is conflict on the team, the manager must find ways to resolve the conflict. I'll stop here as there isn't much point enumerating all the things a manager must manage.
The point is that everything a manager does is a result of coordinating large numbers of people or disparate information sources. Their job is to coordinate, prioritise, reduce conflict and communicate so that the workers can concentrate on getting their work done. The manager is there to "take one for the team" so that the team doesn't get embroiled in drama, trivia, or complications.
Getting back to the original problem: "you'll need to put the company first, team second and your team members third". Sorry to be rude, but that's just naive. Your function is not, through force of your will, to make all the workers do what the company wants. Your job is to coordinate information and reduce conflict so that the members can be successful. Your job would not exist if you did not have team members or teams.
And as impolite as this is, I can't finish without asking managers to contemplate the following: Is there more or less drama due to your actions? Are you demanding team members organise information for you, or are you organising information for the team members? Are you resolving conflict as it occurs, or are you creating conflicts in order to get your way? Do you ask your team to jump through hoops in order to solve a political problem, or do you jump through hoops to solve political problems for your team?
As an engineering manager, you can not succeed if the team does not succeed. It is true that your team can succeed for short periods even if some team members do not succeed, but it is an unsustainable condition. If your team members are not successful, then you have failed. <- Notice the full stop.
Let's start a thought experiment. We'll start a company with one person. What will that person do? Manage? Of course not. There is nothing to manage, because there is only one person. Instead, although they have to plan and prioritise their work, if they aren't actually spending most of their time working, then nothing will get accomplished.
What if we have 2 people? Should we make one person a manger and have the other person do the work? Of course not. The manager will have virtually nothing to do while the working person will be overwhelmed. Although you may shift some responsibilities depending on who likes to do what, or who has various skills, unless both people are working then you will have lots of problems.
At what point do we need a manager? Well, we need a manager when the communication overhead and day-to-day chores impacts development. We only need that manager when there is enough work that they will be able to spend almost all of their day doing that work.
So what will they do? Basically anything that is stopping the workers from getting their job done. If there is a problem with communication, then the manager needs to organise things so that everybody has the information they need. If there is a lack of prioritisation, then the manager needs to prioritise/plan the work. If there is conflict on the team, the manager must find ways to resolve the conflict. I'll stop here as there isn't much point enumerating all the things a manager must manage.
The point is that everything a manager does is a result of coordinating large numbers of people or disparate information sources. Their job is to coordinate, prioritise, reduce conflict and communicate so that the workers can concentrate on getting their work done. The manager is there to "take one for the team" so that the team doesn't get embroiled in drama, trivia, or complications.
Getting back to the original problem: "you'll need to put the company first, team second and your team members third". Sorry to be rude, but that's just naive. Your function is not, through force of your will, to make all the workers do what the company wants. Your job is to coordinate information and reduce conflict so that the members can be successful. Your job would not exist if you did not have team members or teams.
And as impolite as this is, I can't finish without asking managers to contemplate the following: Is there more or less drama due to your actions? Are you demanding team members organise information for you, or are you organising information for the team members? Are you resolving conflict as it occurs, or are you creating conflicts in order to get your way? Do you ask your team to jump through hoops in order to solve a political problem, or do you jump through hoops to solve political problems for your team?
As an engineering manager, you can not succeed if the team does not succeed. It is true that your team can succeed for short periods even if some team members do not succeed, but it is an unsustainable condition. If your team members are not successful, then you have failed. <- Notice the full stop.
One way to look at "why do we have managers" is the decentralized "feudal management".
Everything starts from the owner ("king") who then delegates things to managers at various levels (starting from the board and executives) who then do their thing and either manage tasks, people and processes directly or delegate them further to lower level managers.
In a decentralized approach, if you need a small task done, you can hire me, give me some resources (money, workspace, equipment, whatever), and expect some results - but mostly leave me to myself. If you want more results, that's going to take more resources - and at some point these resources go from a salary and a desk to a budget and headcount, but in a larger manner, nothing changes; you have given me resources (more of them) and need results (more of them), and you can stop worrying about the details of how these results are achieved. In this approach, the engineering manager role becomes something like a CEO/COO of a small development shop doing custom software for their customers - and the main significant difference between this shop being internal or external is the (lack of) legal contracts required.
Everything starts from the owner ("king") who then delegates things to managers at various levels (starting from the board and executives) who then do their thing and either manage tasks, people and processes directly or delegate them further to lower level managers.
In a decentralized approach, if you need a small task done, you can hire me, give me some resources (money, workspace, equipment, whatever), and expect some results - but mostly leave me to myself. If you want more results, that's going to take more resources - and at some point these resources go from a salary and a desk to a budget and headcount, but in a larger manner, nothing changes; you have given me resources (more of them) and need results (more of them), and you can stop worrying about the details of how these results are achieved. In this approach, the engineering manager role becomes something like a CEO/COO of a small development shop doing custom software for their customers - and the main significant difference between this shop being internal or external is the (lack of) legal contracts required.
Another theory is that middle management's only purpose is to act as a buffer between the workers and the owners. The middle manager is just a useful idiot to the owners.
Right out of the manager's playbook: "Well, you see, I'd love to give you more than a 3% raise, but, you know, budget is tight. No one is getting more than that. Most people are getting less, you should feel lucky to be getting 3%." You know he's reading from a script that he was coached to read from.
Same strategy as calling into the support line at Time Warner cable or United Airlines with a real beef. You are immediately worn down and dejected because you realize you're talking to someone with zero authority to do anything. So what do you do? Suck it up and keep working, or quit.
Right out of the manager's playbook: "Well, you see, I'd love to give you more than a 3% raise, but, you know, budget is tight. No one is getting more than that. Most people are getting less, you should feel lucky to be getting 3%." You know he's reading from a script that he was coached to read from.
Same strategy as calling into the support line at Time Warner cable or United Airlines with a real beef. You are immediately worn down and dejected because you realize you're talking to someone with zero authority to do anything. So what do you do? Suck it up and keep working, or quit.
I think your penultimate paragraph, the one where you ask managers to ponder, basically, if they are helping the team to roll it just push it, is very important and clarifies things. Of course, the whole comment, albeit larger than average for HN, is helping to make things clear.
We don't live in an ideal world though, and I do not know if the managers who prioritize the long term goals are more successful than the ones who focus on the short term goals (and who, frankly, usually are basically self-serving). Maybe it depends on the definition of success.
We don't live in an ideal world though, and I do not know if the managers who prioritize the long term goals are more successful than the ones who focus on the short term goals (and who, frankly, usually are basically self-serving). Maybe it depends on the definition of success.
Thanks for the insightful comment. I especially like that you derived it from the most basic assumptions.
Agreed, first rule of management: take care of your people.
A huge confounding factor for this discussion is the big-5 personality trait Agreeableness. It's essentially how people make tradeoffs between their own needs and short-term interpersonal conflict.
"Put the company first" is another way of getting at "Engineering managers need higher trait Agreeableness in order to succeed". It's not maximizing Agreeableness, just putting it at a higher level than individual contributors. And for good reason.
The overall goal is to make smart tradeoffs and find win-wins. You've got yourself, your managers/executives, and your team. They each can get varying amounts of acclaim, compensation, and terms of employment (ie, hours worked). I kind of want to say that the company matters here, but it doesn't really. Well, at least not until you get to a large enough company scale that your reputation among people at the company starts to matter. Say ~100 people or so.
"Put the company first" is another way of getting at "Engineering managers need higher trait Agreeableness in order to succeed". It's not maximizing Agreeableness, just putting it at a higher level than individual contributors. And for good reason.
The overall goal is to make smart tradeoffs and find win-wins. You've got yourself, your managers/executives, and your team. They each can get varying amounts of acclaim, compensation, and terms of employment (ie, hours worked). I kind of want to say that the company matters here, but it doesn't really. Well, at least not until you get to a large enough company scale that your reputation among people at the company starts to matter. Say ~100 people or so.
Agreed. I'm going through the motions of a tranistion and the team is far more important than the company. If you focus on the company first you will lose the pulse of your team and if you lose the pulse of your team you're compromised in your ability to lead effectively especially when you inevitably need to debug your team.
The devil may be in the details.
If your team is excited to build a service (say, for the technical challenge or the potential reputation gain) that objectively should be done by a different team (say, they have the right background, have already started, or whatever) -- do you put the teams interest first (and do it) or the company's (and don't).
I've faced this situation a lot. I used to pick the former. If we have more impact, how can that be bad? Good for company & so on.
It frequently did end up good for my team, but not always good for the company.
Once I adopted the "good for company" mindset, I found I could often achieve what was good for both, but I did find value in putting the company first.
To put another way: the local optimum is not always the global optimum. As a manager, you need to think about the global & favor that over the local.
My two cents.
If your team is excited to build a service (say, for the technical challenge or the potential reputation gain) that objectively should be done by a different team (say, they have the right background, have already started, or whatever) -- do you put the teams interest first (and do it) or the company's (and don't).
I've faced this situation a lot. I used to pick the former. If we have more impact, how can that be bad? Good for company & so on.
It frequently did end up good for my team, but not always good for the company.
Once I adopted the "good for company" mindset, I found I could often achieve what was good for both, but I did find value in putting the company first.
To put another way: the local optimum is not always the global optimum. As a manager, you need to think about the global & favor that over the local.
My two cents.
My motto is : if it succeeds then it's the team, if it fails then it's me.
(now go figure why I'm burned out :-))
(now go figure why I'm burned out :-))
I don't think assigning a pecking order and then debating it is important because in my opinion, an Engineering Manager has the job of connecting the business to the engineers. For this to work he/she needs to engage both.
What to do when "conflicts of interest" arise is the measure of an Engineering Manager and where the line is drawn is defined by the individual at a personal level.
What to do when "conflicts of interest" arise is the measure of an Engineering Manager and where the line is drawn is defined by the individual at a personal level.
> When your team is performing, the company profits. F
Not if it does so at the cost of another team.
Not if it does so at the cost of another team.
"As an engineering manager, you'll need to put company first, team second and your team members third."
I wouldn't make this into a priority list -- whether it's right or wrong, I think it's the wrong mindset. Priority lists are hard to apply in practice because it's rarely clear who might be losing from a given decision.
For one thing, putting the "company" first is a little vague and hard to internalize. Is that the CEO? The long-term success? The stock price? With a "company" first mindset, you'll probably fall into some political games.
Instead, you should start with the actual users of the product and keep that in view. This will help solve the problem where your team executes on a project perfectly and then nobody wants it, or it gets canceled for some mysterious reason. It will also lead you to what's best for the company, make the team successful, and (hopefully) lead to rewards for the team members.
I wouldn't make this into a priority list -- whether it's right or wrong, I think it's the wrong mindset. Priority lists are hard to apply in practice because it's rarely clear who might be losing from a given decision.
For one thing, putting the "company" first is a little vague and hard to internalize. Is that the CEO? The long-term success? The stock price? With a "company" first mindset, you'll probably fall into some political games.
Instead, you should start with the actual users of the product and keep that in view. This will help solve the problem where your team executes on a project perfectly and then nobody wants it, or it gets canceled for some mysterious reason. It will also lead you to what's best for the company, make the team successful, and (hopefully) lead to rewards for the team members.
This 100%. The customers are completely out of scope in this article. They are are essential. You're not engineering stuff just because the CEO of the company likes it. You're doing it because you can add value to your customers. This should always be priority #1, because otherwise you might as well drop everything and go home.
Yes, customers seem to have been overlooked. A telling omission, I think.
> A couple of months ago I moved from a senior engineer position to being an engineering manager
There's some useful advice here for newbie managers (manage your time!), but as a manager, most of really important things you work with -- like building teams and careers -- operate on much longer timescales than a few months. Looking forward to the next update 5 years down the line.
There's some useful advice here for newbie managers (manage your time!), but as a manager, most of really important things you work with -- like building teams and careers -- operate on much longer timescales than a few months. Looking forward to the next update 5 years down the line.
> As an engineering manager, you'll need to put company first, team second and your team members third.
Remember that a "company" is an imagined reality that works because a lot of people believe it. "Team" is as well, but fewer people need to believe it. (Compare those to "nation").
Your team members are real though.
Remember that a "company" is an imagined reality that works because a lot of people believe it. "Team" is as well, but fewer people need to believe it. (Compare those to "nation").
Your team members are real though.
The idea that the company doesn't exist was first highlighted to me in "The Software Hegemony" and it's been a super useful mental crutch since.
You are absolutely right. The company doesn't make you promises, offer you raises, or in fact owe you anything, people do.
You are absolutely right. The company doesn't make you promises, offer you raises, or in fact owe you anything, people do.
> "The Software Hegemony"
Do you mean this? https://www.daedtech.com/developer-hegemony-the-crazy-idea-t...
Do you mean this? https://www.daedtech.com/developer-hegemony-the-crazy-idea-t...
What's an ant colony then -- imaginary or real? And if imaginary, who is doing the imagining?
I'm not sure I understand your position.
I'm not sure I understand your position.
You see thousands of individual ants, and call that colony.
What if I went around the forest and picked one ant out of thousands of colonies and put them all together? Will you still call this a colony? Even if they begin fighting each other?
I wouldn't. It's the behavior of the ants that makes them a colony, which isn't a "real" physical thing.
What if I went around the forest and picked one ant out of thousands of colonies and put them all together? Will you still call this a colony? Even if they begin fighting each other?
I wouldn't. It's the behavior of the ants that makes them a colony, which isn't a "real" physical thing.
Isn't the fact that you can't pick a thousand random ants and trick me into thinking they're a colony evidence that there's more to there being a colony than mere imagination on my part?
Unless you're alleging that the ants conceive of a colony, the colony is a machine made out of pieces -- it's like saying a puzzle doesn't have a physical reality when clearly it does: a thousand random pieces don't make a puzzle, and that distinction lies in the physical reality of the system under examination.
In so much as it makes sense to talk about ants, and not clumps of mobile cells or automata of particles, it makes sense to talk about ant colonies. After all, it's the behavior of the particles that appears to make the ant an entity -- the ant isn't real, only the particle behavior.
Your point seems to depend on those entities which we can immediately recognize as entities being more real than other kinds of entities, but that has no logical basis and is an outright appeal to emotion.
Unless you're alleging that the ants conceive of a colony, the colony is a machine made out of pieces -- it's like saying a puzzle doesn't have a physical reality when clearly it does: a thousand random pieces don't make a puzzle, and that distinction lies in the physical reality of the system under examination.
In so much as it makes sense to talk about ants, and not clumps of mobile cells or automata of particles, it makes sense to talk about ant colonies. After all, it's the behavior of the particles that appears to make the ant an entity -- the ant isn't real, only the particle behavior.
Your point seems to depend on those entities which we can immediately recognize as entities being more real than other kinds of entities, but that has no logical basis and is an outright appeal to emotion.
Imagination is certainly not the right word here. But we seem to agree that "there's more" to a colony than just the physical reality of many thousands of ants in a pile. I can't touch it or extract it from the pile of ants.
If I take half the ants, do I still have a colony? If they now form two colonies, where did the second one come from? How many times can I divide the ants and still have a colony? Where did the colony go if I no longer have one?
Of course "all the ants that form the colony" is a real physical thing, just the same as all the cells that form the ant, but that's arguing in circles. You need to have the "idea" of the larger (or smaller) entity in the first place to be able to point at it.
And it's not the point of the OP anyway, because the ants certainly themselves don't have any concept of the whole colony and don't freely decide if they are one or not. That's just an external observation and classification we made after the fact.
If I take half the ants, do I still have a colony? If they now form two colonies, where did the second one come from? How many times can I divide the ants and still have a colony? Where did the colony go if I no longer have one?
Of course "all the ants that form the colony" is a real physical thing, just the same as all the cells that form the ant, but that's arguing in circles. You need to have the "idea" of the larger (or smaller) entity in the first place to be able to point at it.
And it's not the point of the OP anyway, because the ants certainly themselves don't have any concept of the whole colony and don't freely decide if they are one or not. That's just an external observation and classification we made after the fact.
Late reply, but --
My point is that what makes the colony distinct from the pile is the chemicals, genomic structure, etc that the ants share and are in their environment -- things which all themselves are quite physical. That collection of shared structure between the ants and environmental factors creates a system distinct but made from the ants. Corporations have similar physical components that their constituent humans interact with.
It seems to be begging the question to assume that humans require imagining the corporation but ants do not need to imagine the colony -- it's simply a dynamic system/entity in its own right that happens to have constituent "ants". (Similar in nature to the relationship between cells and animals.)
My point is that what makes the colony distinct from the pile is the chemicals, genomic structure, etc that the ants share and are in their environment -- things which all themselves are quite physical. That collection of shared structure between the ants and environmental factors creates a system distinct but made from the ants. Corporations have similar physical components that their constituent humans interact with.
It seems to be begging the question to assume that humans require imagining the corporation but ants do not need to imagine the colony -- it's simply a dynamic system/entity in its own right that happens to have constituent "ants". (Similar in nature to the relationship between cells and animals.)
Everything at some point has a physical manifestation that can be broken down further and further until we explain things with (according to many physicists) strings.
Every thought, idea, dream or lie could be described as neurotransmitters moving between neurons, but that's very rarely the level of detail we use.
Yes, corporations have physical manifestations. And if we use a formal or legal definition, you could maybe break that down to some database entry at some government branch or paperwork in a cabinet etc. Very real and physical.
But then I could hack the database and insert a new company and fake the paperwork, and arguably the result is not a real company. Or delete a real company and destroy the paperwork, but arguably the company will still exist.
If we imagine I could create or delete a company perfectly in all its physical aspects, documents, electronic records, inventory, products etc - but not modify anybodies thoughts or memories -, you would be very clearly be able to tell if the company is "real" or not.
If nobody knows about it ("believes" it exists) and nobody works for it, it's not real. The office, machines, computers and a bunch of (fake) employment contracts do not result in anything if nobody shows up.
If everybody still believes it exists and just continues to work, they might need a few new staplers and other things, and at some point get the paperwork corrected.
Every thought, idea, dream or lie could be described as neurotransmitters moving between neurons, but that's very rarely the level of detail we use.
Yes, corporations have physical manifestations. And if we use a formal or legal definition, you could maybe break that down to some database entry at some government branch or paperwork in a cabinet etc. Very real and physical.
But then I could hack the database and insert a new company and fake the paperwork, and arguably the result is not a real company. Or delete a real company and destroy the paperwork, but arguably the company will still exist.
If we imagine I could create or delete a company perfectly in all its physical aspects, documents, electronic records, inventory, products etc - but not modify anybodies thoughts or memories -, you would be very clearly be able to tell if the company is "real" or not.
If nobody knows about it ("believes" it exists) and nobody works for it, it's not real. The office, machines, computers and a bunch of (fake) employment contracts do not result in anything if nobody shows up.
If everybody still believes it exists and just continues to work, they might need a few new staplers and other things, and at some point get the paperwork corrected.
There's nothing more real and physical than the behavior of creatures that choose whether to bite you.
This phrasing sounds like the book Sapiens (that I'm currently reading and does not live up to its hype for me). I also think thats a superflous way to describe the world though.
I read it recently, and it was a major influence, that passage. It's a bit too ambitious to describe everything we do as a species, so the book does get a bit stale partway through.
The central idea isn't wrong at all. It's quite clear that we've created a bunch of cultural shared "items" like the the limited liability corporation and such, which are useful but don't really have a physical existence. That doesn't mean they're easy to create or destroy either.
The central idea isn't wrong at all. It's quite clear that we've created a bunch of cultural shared "items" like the the limited liability corporation and such, which are useful but don't really have a physical existence. That doesn't mean they're easy to create or destroy either.
"A Manager's Path" is outstanding on this topic: https://www.amazon.com/dp/B06XP3GJ7F/
Definitely recommended if you are considering making the transition - or if you are like me and just want a better understanding of how your manager works.
Definitely recommended if you are considering making the transition - or if you are like me and just want a better understanding of how your manager works.
If we're on books, I'll always suggest "Up the Organization" by Townsend. It's a classic for a reason.
https://www.amazon.com/Up-Organization-Corporation-Stifling-...
https://www.amazon.com/Up-Organization-Corporation-Stifling-...
s/A/The
I'm always shocked when people end up not knowing things like what they are being asked for by the company if they become an Engineering manager.
Here you go, the simple formula for your management success: it's more software, of better quality, made faster, for less money.
Here you go, the simple formula for your management success: it's more software, of better quality, made faster, for less money.
Here's the simple formula for startup success: build a company that earns billions. The hard part is working out how to do that.
Bonus points if you make sure you team is building the right thing. Sadly it's too easy to spend lots of dev time on something that will never make the company any money.
I don't think that's a bonus point. That's the most important point.
Better to spend more time and money building the right thing than wasting time building the wrong thing.
Better to spend more time and money building the right thing than wasting time building the wrong thing.
Too bad for me that this thread started at monday morning, so I can't put my concerns here in a detail and take a feedback. In short, I failed our small's company big project last year, being pushed to top-and-only engineering manager for the first time, now instead of being fired in shame or simply leaving, I do quick and dirty project that will keep us afloat for awhile (it is ready after two months of hacking, deadline today). I can not understand now how good software and success are related, because it seems that no one really wants or needs it (the former, of course). I was like team-oriented, human-oriented all the time, project-oriented, but not for company/success. My current guess is that success is success and engineering is engineering. I'm not that kind of both worlds person, and I don't actually like success, because my inner engineer contradicts what I've done under time pressure. I better not finish my side projects than allow them to become that. Most confusing point is that requirements are mostly met, and now I have lot of time to polish it and get back to the main goal.
It's not an official advice to anyone, but if you see what can be improved in your workplace, then go improve, but blindly accepting a position may throw you in your personal hell. All many years before I went that route, invested my time in tools and approaches and it paid back making me and my coworkers happy to do our job. High-stake goals do not work that way, and I can't clearly see what you can achieve by breaking yourselves core. For me it seems like a path to personal failure while making some "dirty" money. Reality strikes back.
This is my personal anecdote on this subtopic, ymmw.
It's not an official advice to anyone, but if you see what can be improved in your workplace, then go improve, but blindly accepting a position may throw you in your personal hell. All many years before I went that route, invested my time in tools and approaches and it paid back making me and my coworkers happy to do our job. High-stake goals do not work that way, and I can't clearly see what you can achieve by breaking yourselves core. For me it seems like a path to personal failure while making some "dirty" money. Reality strikes back.
This is my personal anecdote on this subtopic, ymmw.
Holy shit, that's sad.
Not if your company goes out of business waiting for the Right Thing.
Technical line management is a separate skill set to product & project management, dumping all that on a new manager is an express ticket to burnout city.
edit let's also remember that being promoted from a senior engineer/tech lead to dev manager means you need to find a replacement to hand off technical responsibilities to, managers can't time manage & code and expect to excell at both.
Technical line management is a separate skill set to product & project management, dumping all that on a new manager is an express ticket to burnout city.
edit let's also remember that being promoted from a senior engineer/tech lead to dev manager means you need to find a replacement to hand off technical responsibilities to, managers can't time manage & code and expect to excell at both.
I've hit mid-30's and I am still an individual contributor. People tell me ageism be real and I would face the music real soon.
How do people become managers, should I just tell my manager that I want to be a manager now. Would he be thratntened that I want his job ?
How do people become managers, should I just tell my manager that I want to be a manager now. Would he be thratntened that I want his job ?
I've hit mid-40s and I'm still a happy individual contributor. So you aren't necessarily doomed to a management role, and you shouldn't rush into it if that's not what you want.
I've always told myself that I'll code until I can't keep up. So far that hasn't happened. Once it does, I will happily transition to more of a management role to be of the greatest value that I can. Along the way (and even now), though, I've had a good number of management-like responsibilities which will help a lot. So, I encourage you to take advantage of those opportunities as they come along. There isn't a bright, hard line between management and individual contribution. There is a space between.
A good manager will look out for your career path and help you get to management, if that's what you want.
I've always told myself that I'll code until I can't keep up. So far that hasn't happened. Once it does, I will happily transition to more of a management role to be of the greatest value that I can. Along the way (and even now), though, I've had a good number of management-like responsibilities which will help a lot. So, I encourage you to take advantage of those opportunities as they come along. There isn't a bright, hard line between management and individual contribution. There is a space between.
A good manager will look out for your career path and help you get to management, if that's what you want.
I think there's something to a good manager's experience in working with those in their 40's, 50's, and beyond. The problem is that experience is usually going to be less the higher that number gets, and you're potentially dealing with more difficult career moves because the experience level is increasing all the while. I do wonder if that fact has something to do with the "aging out" we see.
The trick is to be in a growing company where new management seats are materializing by the day. Then your manager will be delighted for the help as his number of directs grows beyond what one person can reasonably keep track of.
You have options...
Join a rapidly growing organisation and help other people to do their jobs better. You will be a manager before you know it.
Alternatively move company and apply to be a manager and probably say you had more management experience than you really do. I'm sure at 35 you've had to coach some people to be better and do interviews, these can be highlighted.
Do not tell your boss you want his job/to be a manager because anything you ever do that makes her feel threatened from then on will be noted and used against you. People move companies to gain good promotions for a reason.
Join a rapidly growing organisation and help other people to do their jobs better. You will be a manager before you know it.
Alternatively move company and apply to be a manager and probably say you had more management experience than you really do. I'm sure at 35 you've had to coach some people to be better and do interviews, these can be highlighted.
Do not tell your boss you want his job/to be a manager because anything you ever do that makes her feel threatened from then on will be noted and used against you. People move companies to gain good promotions for a reason.
> apply to be a manager and probably say you had more management experience than you really do.
That's not great advice. Don't lie to get a job.
> Do not tell your boss you want his job/to be a manager
Every company I've worked at has needed more great engineering managers. There's more than enough work, and anyone who says "I want to help" is my hero.
Where I work, when engineers say they want to become managers, we give them gently escalating management responsibilities, enroll them in management training, and give them a mentor for guidance. And later we check to make sure it's still something they want -- it's truly a different job, so they should be able to say "not for me" and go back to being an IC.
That's not great advice. Don't lie to get a job.
> Do not tell your boss you want his job/to be a manager
Every company I've worked at has needed more great engineering managers. There's more than enough work, and anyone who says "I want to help" is my hero.
Where I work, when engineers say they want to become managers, we give them gently escalating management responsibilities, enroll them in management training, and give them a mentor for guidance. And later we check to make sure it's still something they want -- it's truly a different job, so they should be able to say "not for me" and go back to being an IC.
I think this very much depends on the organization. Many managers are political creatures who view any desire by ICs to move up the non-technical ladder as a direct threat to them. Take the anecdote for what it is, but I've experienced that personally, and have had friends who have as well. It doesn't necessarily end well. In my case, I started seriously considering a constructive termination suit until I finally found alternate employment (it took almost three months--I wasn't in the Bay Area at the time).
My current employer is more like what you describe, however, and I'm thankful for it.
My current employer is more like what you describe, however, and I'm thankful for it.
> Every company I've worked at has needed more great engineering managers.
Has every company you've worked at been successful or at least rapidly growing? There's plenty of cake to go around in a company doubling in size every year, but the daggers come out when there are layoffs twice a year, particularly when the people being laid off aren't SV software engineers with tons of other options.
Has every company you've worked at been successful or at least rapidly growing? There's plenty of cake to go around in a company doubling in size every year, but the daggers come out when there are layoffs twice a year, particularly when the people being laid off aren't SV software engineers with tons of other options.
> That's not great advice. Don't lie to get a job.
It wasn't advice. I was saying it is one of the ways I've seen people transition into management. Interestingly, the way you said management training happens at your company, I've never seen that happen anywhere, so it sounds like a fantastic place to work. How many people who have been through the management program now have a team?
It wasn't advice. I was saying it is one of the ways I've seen people transition into management. Interestingly, the way you said management training happens at your company, I've never seen that happen anywhere, so it sounds like a fantastic place to work. How many people who have been through the management program now have a team?
Wow that's smart and awesome. What company does this?
>"Do not tell your boss you want his job/to be a manager because anything you ever do that makes her feel threatened from then on will be noted and used against you. People move companies to gain good promotions for a reason."
I don't entirely think that piece of advice applies if your manager/boss is ambitious. If they're ambitious, then they're most certainly looking for their own replacement. Heck, someone that can in the interim do their tasks while they focus on "moving up".
I don't entirely think that piece of advice applies if your manager/boss is ambitious. If they're ambitious, then they're most certainly looking for their own replacement. Heck, someone that can in the interim do their tasks while they focus on "moving up".
I started by taking responsibilities for small teams and discrete portions of projects. From there, responsibilities expanded. Now I run a team of around 100 and focus most of my day on admin and training instead of actually creating work product. I like the role, but it's not for everyone. Managing is great when things are good, but can quickly get tough when things aren't.
Don't tell your boss you want their job. Tell them you'd like to have an opportunity to contribute in a greater capacity and how you can do that. If there's something specific that thrills you, ask to do that. Put 100% into making sure that thing gets done well.
Don't tell your boss you want their job. Tell them you'd like to have an opportunity to contribute in a greater capacity and how you can do that. If there's something specific that thrills you, ask to do that. Put 100% into making sure that thing gets done well.
Depends on your relationship with them.
I think it's normal and professional to have a conversation along the lines of "I'd like to start getting experience managing people, do you think there'd be a chance for me to do that?". If they're threatened by that conversation, I wouldn't want to work for them frankly.
The reality is there's a lot of older coders out there, I think it matters more what you _want_ to do.
I think it's normal and professional to have a conversation along the lines of "I'd like to start getting experience managing people, do you think there'd be a chance for me to do that?". If they're threatened by that conversation, I wouldn't want to work for them frankly.
The reality is there's a lot of older coders out there, I think it matters more what you _want_ to do.
This depends very much on the engineering and leadership culture and your manager's view. Also company size matters. Managers are necessarily fewer in number than individual contributors. If the organization isn't big enough there might not be room now. There might be in the future, though, so it may not hurt to make your desire known.
LEAD your Junior Engineers and MANAGE http://www.netmba.com/
> As an engineering manager, you'll need to put company first, team second and your team members third.
I think a good manager sees the second two as an important factor in putting the company first. Demoralized teams are bad for the company.
I think a good manager sees the second two as an important factor in putting the company first. Demoralized teams are bad for the company.
Why do software companies promote people to managers !? All those years of experience wasted. And he still doesn't know what he's supposed to do besides putting the company's needs before it's employees.
What's the alternative? Having people who don't know how to create software managing the creation of software?
I think an experienced developer is worth much more then an inexperienced manager. And I also believe in flat organizations when it comes to software.
Because some people want to transition? One of the things Google expouses is to have managers who code because it builds empathy. I'm a manager and I still code daily, and I think I'm a better manager for it.
> senior "software" engineer position to being an "software" engineering manager
I disagree with this a ton. The best managers I've had flipped #1 and #2. When your team is performing, the company profits. Far too often I've seen the manager put the company way ahead of the team, and that leads to attrition within your team or a major lack of motivation.