Programmer to Manager
If you are moving from developer to manager at very young age, like after 2-3 year in starting of your career phase. Is it good? or should leave the job to find another challenged job which provides challenging technical work.
44 comments
I'm a manager these days, and I think it's two very different roles. While I was never the best developer (and probably will never be), the managerial role is kind of awesome because it's about amplifying others' ability to be great.
Management is much more of a service role (and much less of a directly creative role), but I've found it to be a good fit because you get to serve a bunch of wicked smart people, which is super fun.
Good management is all about reducing total cognitive load for your engineers: keeping stakeholders off their back, taking heat when things go awry, being a crap umbrella for the team so they can work, etc. Done right it's immensely rewarding, but definitely not in the way programming is.
Also - in my experience the number one thing you want to look for in vetting a 'good' management job is the quality of the executive you'll be reporting to. Are they a strong, fair leader? If yes, go for it. If no... you're gonna have a bad time.
Management is much more of a service role (and much less of a directly creative role), but I've found it to be a good fit because you get to serve a bunch of wicked smart people, which is super fun.
Good management is all about reducing total cognitive load for your engineers: keeping stakeholders off their back, taking heat when things go awry, being a crap umbrella for the team so they can work, etc. Done right it's immensely rewarding, but definitely not in the way programming is.
Also - in my experience the number one thing you want to look for in vetting a 'good' management job is the quality of the executive you'll be reporting to. Are they a strong, fair leader? If yes, go for it. If no... you're gonna have a bad time.
I did more or less exactly this - after two years working as a developer, I pushed myself into a "team leader" position, managing a team of half a dozen people in one location and semi-managing a few others in a different location. I did this for about 18 months for a large (and fast growing) organisation.
I managed to negotiate about 25% of my time for development (some of it quite high-level architecture, but often still writing actual code); the rest was personnel management, planning and organisation, liaising with sales and project management, sometimes attending sales pitches, and training other teams. I actually had a great time, met people from all over the organisation, got some travel out of it, and learnt a hell of a lot, almost all of which has been beneficial to me later in my career.
Personnel management was definitely a real challenge - in ways I absolutely had not predicted (we had some, shall we say, "interesting" characters on the team, and I got to know the HR people very well by the end of it).
After 18 months, I moved to another company to take a role which ostensibly should have been similar but ended up migrating back into a more-or-less pure development role as a technical lead. The skills I learnt then - especially anything to do with personnel, sales, and planning - are still extremely useful to me as a software consultant / small business guy today.
I don't know if this route is for everyone - I was already naturally pretty confident and articulate, and for developers who aren't especially born that way, I think a lot of management tasks and managerial expectations are probably scary and unpleasant. But for me, at least, I enjoyed it and have few complaints.
I managed to negotiate about 25% of my time for development (some of it quite high-level architecture, but often still writing actual code); the rest was personnel management, planning and organisation, liaising with sales and project management, sometimes attending sales pitches, and training other teams. I actually had a great time, met people from all over the organisation, got some travel out of it, and learnt a hell of a lot, almost all of which has been beneficial to me later in my career.
Personnel management was definitely a real challenge - in ways I absolutely had not predicted (we had some, shall we say, "interesting" characters on the team, and I got to know the HR people very well by the end of it).
After 18 months, I moved to another company to take a role which ostensibly should have been similar but ended up migrating back into a more-or-less pure development role as a technical lead. The skills I learnt then - especially anything to do with personnel, sales, and planning - are still extremely useful to me as a software consultant / small business guy today.
I don't know if this route is for everyone - I was already naturally pretty confident and articulate, and for developers who aren't especially born that way, I think a lot of management tasks and managerial expectations are probably scary and unpleasant. But for me, at least, I enjoyed it and have few complaints.
I think taking on team leadership roles (where you're still >=60% technical) is fine that early.
I wouldn't make a jump into pure management that early. I would fear that it would do two things, both bad:
1. Prevent you from developing the necessary technical experience, instincts, and judgment that will serve you well later in your career.
2. Prevent you from "tasting management" and deciding whether or not you like it. Many don't, and that's perfectly OK. I am in the category of "initially reluctant managers" which makes me both good and bad. Good because I'm not in it for the power or title. (Managers who are can be incredibly corrosive.) Bad because there are some parts of managing that are necessary but distasteful to me and so I naturally deprioritize them or am less than good at them. Things like figuring out something personal about someone on your team and figuring out how to motivate them or how to help them break through what's blocking them. Those can be a struggle for me, as I'm a natural engineer, not a "people person". I see some of my peers who got into management out of desire, and while they're not nearly as strong technically, they appear effortless when dealing with people and their idiosyncrasies.
Being able to "try on" managing a team at your current role is possibly great. If you like it and are good at it, you learned something, but you still should proceed slowly with the transition.
If you don't like it and decide to stay technical, there's no harm whatsoever in giving that up (at your current or next job). I hear in interviews pretty regularly, "they were pushing me into management and I like to stay technical". When I have a technical role (which is always), that's music to my ears.
I wouldn't make a jump into pure management that early. I would fear that it would do two things, both bad:
1. Prevent you from developing the necessary technical experience, instincts, and judgment that will serve you well later in your career.
2. Prevent you from "tasting management" and deciding whether or not you like it. Many don't, and that's perfectly OK. I am in the category of "initially reluctant managers" which makes me both good and bad. Good because I'm not in it for the power or title. (Managers who are can be incredibly corrosive.) Bad because there are some parts of managing that are necessary but distasteful to me and so I naturally deprioritize them or am less than good at them. Things like figuring out something personal about someone on your team and figuring out how to motivate them or how to help them break through what's blocking them. Those can be a struggle for me, as I'm a natural engineer, not a "people person". I see some of my peers who got into management out of desire, and while they're not nearly as strong technically, they appear effortless when dealing with people and their idiosyncrasies.
Being able to "try on" managing a team at your current role is possibly great. If you like it and are good at it, you learned something, but you still should proceed slowly with the transition.
If you don't like it and decide to stay technical, there's no harm whatsoever in giving that up (at your current or next job). I hear in interviews pretty regularly, "they were pushing me into management and I like to stay technical". When I have a technical role (which is always), that's music to my ears.
It depends what you want to do but as a manager I'd like to say a few things I found making the move:
1) It's obviously very different. It's primarily about organisation and co-ordination - you need to understand all the moving parts of a project, know what's important, what might need your attention and what can be left alone. You might want to ask yourself whether after 3 years experience you feel you're equipped to do that - some people have a feel for it and are, others need more first hand experience of projects. More importantly you want to think if you're going to be happy doing that.
2) There is a temptation to think when you're a programmer that the reason things aren't going well are that the manager is doing his job badly and you're going to do better. This may be the case but in my experience that's often not the case. Organisational cultures and how projects are run tends to be driven from the top of the organisation down and you may find that the things ultimately causing the problems are far higher up the chain. Where things are bad for programmers they're often bad for managers (or at least middle managers) too. Moving into management because you think you can fix the world is probably misguided.
3) Following on from that, you'll probably have a lot less power / authority than you think. It's best to think of managing at this middle level as working with programmers but doing a different job rather than them working for you. Generally, as when you're a programmer, you're a middle man turning the wishes of those above you into reality. Yes you might get a say / some influence but probably not anywhere near as much as you'd like. People will tell you to do stuff, you'll do it.
4) Learn to delegate. This is key. When you're given things your first instinct will be the one you have now - to do it yourself. That approach is going to kill you. You need to learn to give other people work.
5) If being friends with the people in your team is important, you might want to think twice. That's not to say you can't be friends with someone who works for you, just that there is always the potential for problems. If your friend starts coming in late are you willing to pull them up on it and risk the friendship?
6) It is hard to go back. Some roles keep you hands-on to an extent but once you're not coding at least 20 hours a week, you've got a year, maybe two at most, before your skills have significantly atrophied at which point moving back will be a problem.
7) With regard to skills decay, you also need to understand this is happening when you're making decisions on the project. You may be the best programmer in your team but if you spend 0 hours a week programming and the graduate entry level guy spends 45 hours, how long before he knows more than you do?
1) It's obviously very different. It's primarily about organisation and co-ordination - you need to understand all the moving parts of a project, know what's important, what might need your attention and what can be left alone. You might want to ask yourself whether after 3 years experience you feel you're equipped to do that - some people have a feel for it and are, others need more first hand experience of projects. More importantly you want to think if you're going to be happy doing that.
2) There is a temptation to think when you're a programmer that the reason things aren't going well are that the manager is doing his job badly and you're going to do better. This may be the case but in my experience that's often not the case. Organisational cultures and how projects are run tends to be driven from the top of the organisation down and you may find that the things ultimately causing the problems are far higher up the chain. Where things are bad for programmers they're often bad for managers (or at least middle managers) too. Moving into management because you think you can fix the world is probably misguided.
3) Following on from that, you'll probably have a lot less power / authority than you think. It's best to think of managing at this middle level as working with programmers but doing a different job rather than them working for you. Generally, as when you're a programmer, you're a middle man turning the wishes of those above you into reality. Yes you might get a say / some influence but probably not anywhere near as much as you'd like. People will tell you to do stuff, you'll do it.
4) Learn to delegate. This is key. When you're given things your first instinct will be the one you have now - to do it yourself. That approach is going to kill you. You need to learn to give other people work.
5) If being friends with the people in your team is important, you might want to think twice. That's not to say you can't be friends with someone who works for you, just that there is always the potential for problems. If your friend starts coming in late are you willing to pull them up on it and risk the friendship?
6) It is hard to go back. Some roles keep you hands-on to an extent but once you're not coding at least 20 hours a week, you've got a year, maybe two at most, before your skills have significantly atrophied at which point moving back will be a problem.
7) With regard to skills decay, you also need to understand this is happening when you're making decisions on the project. You may be the best programmer in your team but if you spend 0 hours a week programming and the graduate entry level guy spends 45 hours, how long before he knows more than you do?
Completely correct on all points. When I was a programmer, I would sit and stew about the decisions management made. I was deluded into thinking "I would do this different". Moving into management and realizing that it is a totally different role of planning, organization and coordination - all of which isn't really in your control.
After having been a manager for a few years now, I realize my tech skills have degraded. So I do side projects programming things I want to do, the way I want to do it to keep my skills up to date.
The other thing I think I'm realizing is that being a manager is sort of generic role. Most career paths forward at this point look rather boring and mundane. Even if it is a new project - some sort of skunkworks effort - using some new tech and solving really cool problems - managing that isn't much different than managing a team maintaining a 10 year old system. Maybe morale is easier to manage.
Think about what your next position would be after taking a management role - your options become limited. Other companies may see you as "manager" and not as "developer" regardless of skills, perhaps thinking subconsciously that "if I hire this guy, he is going to want my job".
After having been a manager for a few years now, I realize my tech skills have degraded. So I do side projects programming things I want to do, the way I want to do it to keep my skills up to date.
The other thing I think I'm realizing is that being a manager is sort of generic role. Most career paths forward at this point look rather boring and mundane. Even if it is a new project - some sort of skunkworks effort - using some new tech and solving really cool problems - managing that isn't much different than managing a team maintaining a 10 year old system. Maybe morale is easier to manage.
Think about what your next position would be after taking a management role - your options become limited. Other companies may see you as "manager" and not as "developer" regardless of skills, perhaps thinking subconsciously that "if I hire this guy, he is going to want my job".
Yep, development manager / development project manager is actually an odd half way house. It's still basically a delivery role, working closely with developers and the product, but it's the last time that's really true. Beyond that when you start managing managers, things start becoming somewhat more abstract and that's where things really change.
This contains already most of my realizations about management as well: it's a completely different job and your role to team and code will change as well. What I want to add is that you don't need to become a manager to make money. Most middle management doesn't make that much more money than the engineer. Building capital is more about what you do with your paycheck than the size of it.
I had roughly 6 years of experience before I made the transition. I had spent a considerable part of those 6 years thinking about all the things I'd do if I were the manager of my team. Whenever I interviewed for an IC role, I made my intentions clear that I wanted to get into management long-term. I was offered a management role 5 months into a job and I took it. All those years of thinking about management enabled me to transition nearly smoothly.
Looking back, the 6 years I spent coding were extremely valuable. The only way I'd have become a manager after 2-3 years was if I had had a good mentor. My advice would be to spend the next 3-5 years building a lot of things and observing your leaders closely. Read about what great managers do and don't do and play out scenarios in your head.
Looking back, the 6 years I spent coding were extremely valuable. The only way I'd have become a manager after 2-3 years was if I had had a good mentor. My advice would be to spend the next 3-5 years building a lot of things and observing your leaders closely. Read about what great managers do and don't do and play out scenarios in your head.
I am actually in the same spot as you are - 2,5 years into programming and there is this opportunity to switch to another role. All the good managers I ever met or had the pleasure of working with were form a technical background - but they were working as the programmer for over 6-8 years each. It does stand for something.
It really boils down into one point: how happy would you be doing whatever you choose to do - there is nothing worse than a manager that hates his job or a programmer that doesn't feel the "drive" and passion to work.
Personally, I do not feel equipped to switch into management just yet - I am not confident enough I would make the best decisions, and I am leaning towards staying in my role a while longer, just to be totally sure I acquired all the necessary skills.
It really boils down into one point: how happy would you be doing whatever you choose to do - there is nothing worse than a manager that hates his job or a programmer that doesn't feel the "drive" and passion to work.
Personally, I do not feel equipped to switch into management just yet - I am not confident enough I would make the best decisions, and I am leaning towards staying in my role a while longer, just to be totally sure I acquired all the necessary skills.
I guess it all boils down to your long term goals. Think about where you want to be in the next 2-3 years. Does this current switch to manager role makes sense then. Think.
Im doing a bit of management part time coz my team is small. I manage multiple products and i code on one product one week and the other product the next week.. sometimes it depends on the priority levels. We might have a release due in some product where extra hands are required. Then i go do that. So!
Will you love it? If you want to go work for apple or start your company or something, it always helps to have a bit of management in you. So instead of a full switch to management, ask your company if you can work on code 50% of the time.
Im doing a bit of management part time coz my team is small. I manage multiple products and i code on one product one week and the other product the next week.. sometimes it depends on the priority levels. We might have a release due in some product where extra hands are required. Then i go do that. So!
Will you love it? If you want to go work for apple or start your company or something, it always helps to have a bit of management in you. So instead of a full switch to management, ask your company if you can work on code 50% of the time.
IMO, 2-3 years is too soon. You might be pigeon-holed as a manager for future jobs. I guess you can always craft a resume to emphasize your hands-on technical experience though.
Maybe management is what you want? If so go for it. But your tone suggests you have reservations about this, so I'd suggest you ask to remain engineer and then after 5-10 years doing that, re-evaluate your desire for management.
Also, I'd be inherently skeptical of a place that moves you to management after 2 years of experience. That means they generally have non-technical managers. I think managers should be the senior engineers who also have people skills and like managing.
Maybe management is what you want? If so go for it. But your tone suggests you have reservations about this, so I'd suggest you ask to remain engineer and then after 5-10 years doing that, re-evaluate your desire for management.
Also, I'd be inherently skeptical of a place that moves you to management after 2 years of experience. That means they generally have non-technical managers. I think managers should be the senior engineers who also have people skills and like managing.
[deleted]
If your career is set on going down the managerial path then of course this would be a good opportunity. If your heart is in tech, however, I'd stay low level. My own personal anecdote is that I thought I was having a blast going down the leadership path for about five years, until I realized that I actually wanted to stay technical.
At the point I made this connection, I had lost several years of progress, skills had depleted, and technologies had moved on a lot. I'm still catching up! Consider that a cautionary tale. :-)
Just my 2¢.
At the point I made this connection, I had lost several years of progress, skills had depleted, and technologies had moved on a lot. I'm still catching up! Consider that a cautionary tale. :-)
Just my 2¢.
Please read this article that talks about a software engineer changing into a managerial role:
http://michaelochurch.wordpress.com/2014/07/13/how-the-other...
also read the hackernews discussion:
https://news.ycombinator.com/item?id=8033051
http://michaelochurch.wordpress.com/2014/07/13/how-the-other...
also read the hackernews discussion:
https://news.ycombinator.com/item?id=8033051
I think if you are good technically, you should aspire to grow on technical front rather than aspiring or actually moving to managerial role. There are technical managers but in the long run the management part of the role tends to eat into the innovative,experimenting technical side of your personality. If you think you can balance it well then no harm in becoming a technical manager.
In my experience existing in the middle ground of being a manager of 3-5 resources and being expected to produce your own work with no managerial experience (only 6 years dev experience), added on that unrealistic client expectations has been the greatest challenge I have faced so far. To whomever finds themselves in a similar position I wish you the best of luck.
I took a position as a team manager when I was offered, and I absolutely do not regret it, but it made me realize that what I really wanted to do was to be a developer.
Try to find out what you really want to do, and be aware of that it is not straightforward to go back to a position as a developer in the same company after you've become a manager.
Try to find out what you really want to do, and be aware of that it is not straightforward to go back to a position as a developer in the same company after you've become a manager.
I wouldn't do it. Just let me have fun with my code editor :)
NEVER!
It Depends !
Ok, to be more specific:
Do you prefer wrangling bits and bytes or people?
Do you like your current company? Is there an appealing career track for you?
Do you like being challenged technically? Or would you just prefer to earn a comfortable salary?
My observation is that once you get settled into the management track it is hard to go back to development. Even if you do side projects, that doesn't really put you back on the tech track.
Ok, to be more specific:
Do you prefer wrangling bits and bytes or people?
Do you like your current company? Is there an appealing career track for you?
Do you like being challenged technically? Or would you just prefer to earn a comfortable salary?
My observation is that once you get settled into the management track it is hard to go back to development. Even if you do side projects, that doesn't really put you back on the tech track.
I like to work that is challenged technically, salary is second preference for me.
I like my company as i come in very starting members of company, so its tough for me to leave this company.
i am doing management but somewhere i still want to write code and live that life.
From my experience every developer I know who ended up early as a manager, where not really happy with that. Most of them had the impression of being taken apart of technical challenges, and wasting their time in endless meetings.
To some extent I think this type of experience is almost a rite of passage as developers become increasingly senior. I've had experiences along these lines as have most of my more seasoned colleagues. Management sounds OK from a distance, but when devs realize the kind of petty idiocy that will now dictate their daily life, it's normal to start running back to the compiler.
This may not be true in companies where engineers make up the upper echelons, but it invariably seems to occur in other types of companies. Management is a fundamental game change, and it's not about programming, and it's not about organization or efficiency. It's not about how good a manager may or may not be at getting things done. It's about psychology, the psychology of the people higher or lateral in the structure more than the psychology of a manager's direct downline (though both require cultivation).
The number one rule of management, and employment in general if you want to rise through the ranks, is ABC: Always Be Campaigning. If this doesn't sound good to you, you don't want to go into management, and you probably don't want to be a normal employee for very long either, because if you aren't doing it, you're going to pay sooner or later.
Everyone tries to tell themselves that their employer is different for reasons X, Y, and Z, but it's very unlikely to be true, no matter how nice you think your company is. I've even experienced the ramifications of not adopting ABC just in the last few weeks at another company that I swore was different this time and is lead by an old-school computer engineer who has been working since the 80s, and I'm not even trying to do any management-type stuff there, as I'm still reeling from last time I tried my hand at that.
It's hard to come out of these experiences without a massively pessimistic view of everyone else. Any time I try to allow myself to become optimistic and think, "Nah, these guys aren't like that", and no matter how much evidence I think I have, it all comes back to people being people and heavily favoring typical pre-programmed people responses, even if those responses may not be well-considered or well-informed. Biology is hard to override.
It seems if you want a different employment experience, you must compromise such that you are always campaigning.
This may not be true in companies where engineers make up the upper echelons, but it invariably seems to occur in other types of companies. Management is a fundamental game change, and it's not about programming, and it's not about organization or efficiency. It's not about how good a manager may or may not be at getting things done. It's about psychology, the psychology of the people higher or lateral in the structure more than the psychology of a manager's direct downline (though both require cultivation).
The number one rule of management, and employment in general if you want to rise through the ranks, is ABC: Always Be Campaigning. If this doesn't sound good to you, you don't want to go into management, and you probably don't want to be a normal employee for very long either, because if you aren't doing it, you're going to pay sooner or later.
Everyone tries to tell themselves that their employer is different for reasons X, Y, and Z, but it's very unlikely to be true, no matter how nice you think your company is. I've even experienced the ramifications of not adopting ABC just in the last few weeks at another company that I swore was different this time and is lead by an old-school computer engineer who has been working since the 80s, and I'm not even trying to do any management-type stuff there, as I'm still reeling from last time I tried my hand at that.
It's hard to come out of these experiences without a massively pessimistic view of everyone else. Any time I try to allow myself to become optimistic and think, "Nah, these guys aren't like that", and no matter how much evidence I think I have, it all comes back to people being people and heavily favoring typical pre-programmed people responses, even if those responses may not be well-considered or well-informed. Biology is hard to override.
It seems if you want a different employment experience, you must compromise such that you are always campaigning.
Thanks for this post. Can you drill into a little bit what you mean by "campaigning" though? Do you just mean constantly lobbying people in your organization to gather support for process changes, new programs, initiatives etc. that you want to sponsor?
No, the problem is believing that it's about important things like programs, processes, and initiatives. The reality is most people can't and don't want to understand that type of stuff. That doesn't just apply to MBAs, it applies even to most of the people in your department. You'll become their enemy if you go in there and start advocating all but the most minor and gradual changes (even this is dangerous). Consultants are paid to operate outside of the political structure, not employees. If you want to recommend changes and get ignored, do it as a consultant because you'll be better paid and have less stress in doing so, since you'd be ignored as an employee too but you'd also be collecting personal political enmity.
If you want to be an employee, you have to play politics. You have to be campaigning for yourself. As an employee, you are your product, your brand, and you're supplying it to the customer, your employer. For the same reasons that front-line customer service representatives for retailers and phone companies have to go all day biting their tongues, you also must do so as a front-line representative of your personal brand. It doesn't matter what you think. It doesn't matter what is or isn't better or worse. Nobody wants to hear it and nobody cares. Some people may say they're hiring you for your opinion on things like that -- those people are lying, don't believe them. They just want you to coo gently to them and give them whatever they want, or a close enough approximation thereof that they can't really tell the difference.
You have to always be the nice, self-sacrificing guy who doesn't make any waves but is just so grateful for anything and everything and always go the triple-extra mile to help out. The guy who is always taking his co-workers to lunch because he appreciates them that much. The one with the "charisma", the "flair", and the "charm". In short, the sycophant, just barely non-obviously. That is how influence is aggregated.
As an employee, your productive output is secondary to successfully running a personal campaign. You do all the schmoozing, make all the power plays and all the disingenuous convenience connections you would if you were running for a real political office, basically the whole shebang except the posters. As long as you kinda-sorta look like you're doing some actual work somewhere under the covers, it doesn't matter if you actually are or not. What matters is that you become that guy. If you are employed, your real job is selling yourself to your colleagues (mostly superiors, the further up the chain you can get known and get positive attention the better). Devote 75% of your energy to this task and 25% or less of your energy into whatever you were actually hired to do and you'll go far.
This is geared toward employment in general, but it's 50x more important if you're in a management or leadership position, because at that point you don't really have a real job to divert any energy toward anymore anyway.
There are some companies where this is so expected that your continued employment is jeopardized if you don't do it (like my previous employer), and other companies where you'll just be passed up for advancements and go unnoticed if you don't do it (like my present employer). There's not really a third type of company excepting very small startups, which is usually not the kind of place someone looking to be employed would wind up.
If you want to be an employee, you have to play politics. You have to be campaigning for yourself. As an employee, you are your product, your brand, and you're supplying it to the customer, your employer. For the same reasons that front-line customer service representatives for retailers and phone companies have to go all day biting their tongues, you also must do so as a front-line representative of your personal brand. It doesn't matter what you think. It doesn't matter what is or isn't better or worse. Nobody wants to hear it and nobody cares. Some people may say they're hiring you for your opinion on things like that -- those people are lying, don't believe them. They just want you to coo gently to them and give them whatever they want, or a close enough approximation thereof that they can't really tell the difference.
You have to always be the nice, self-sacrificing guy who doesn't make any waves but is just so grateful for anything and everything and always go the triple-extra mile to help out. The guy who is always taking his co-workers to lunch because he appreciates them that much. The one with the "charisma", the "flair", and the "charm". In short, the sycophant, just barely non-obviously. That is how influence is aggregated.
As an employee, your productive output is secondary to successfully running a personal campaign. You do all the schmoozing, make all the power plays and all the disingenuous convenience connections you would if you were running for a real political office, basically the whole shebang except the posters. As long as you kinda-sorta look like you're doing some actual work somewhere under the covers, it doesn't matter if you actually are or not. What matters is that you become that guy. If you are employed, your real job is selling yourself to your colleagues (mostly superiors, the further up the chain you can get known and get positive attention the better). Devote 75% of your energy to this task and 25% or less of your energy into whatever you were actually hired to do and you'll go far.
This is geared toward employment in general, but it's 50x more important if you're in a management or leadership position, because at that point you don't really have a real job to divert any energy toward anymore anyway.
There are some companies where this is so expected that your continued employment is jeopardized if you don't do it (like my previous employer), and other companies where you'll just be passed up for advancements and go unnoticed if you don't do it (like my present employer). There's not really a third type of company excepting very small startups, which is usually not the kind of place someone looking to be employed would wind up.
Yes, I have been promised a promotion, and seem to be doing half of the management style stuff for it already. (Though to be fair I have 11 years experience).
Meetings, meetings, interruptions, absolutely no time for coding anything but simple one or two line changes. I am thinking of asking if I can have my old job back, and forget the promotion.
Meetings, meetings, interruptions, absolutely no time for coding anything but simple one or two line changes. I am thinking of asking if I can have my old job back, and forget the promotion.
you comment seems to abide by my feelings.
I combine stuff at my job. Development and Management is split 50/50 a.t.m.
This of course might change to more management if that part of the jobs demands more time.
Nothing wrong with becoming a manager if that's your thing. But I love the fact that I can still do some research (/poc development).
As we say in Dutch: A Developer in Heart and Kidneys ;-)
edit:
Additionally, I think it might actually help in becoming a good manager if you are a good developer, still being able to 'relate' (i.e. not looking down from your ivory management tower).
This of course might change to more management if that part of the jobs demands more time.
Nothing wrong with becoming a manager if that's your thing. But I love the fact that I can still do some research (/poc development).
As we say in Dutch: A Developer in Heart and Kidneys ;-)
edit:
Additionally, I think it might actually help in becoming a good manager if you are a good developer, still being able to 'relate' (i.e. not looking down from your ivory management tower).
Every manager of programmers I've known who was not themselves a competent programmer caused more harm than good. Take that for what you will.
I was sitting nodding me head with that, but I did have a manager who was a trained engineer. He was good. Knew enough to know what to ask you, but didn't assume that he knew enough to implement something - so left the fine details to the developers.
Now I have a team leader and group leader on top of that, who are in my opinion junior to intermediate level programmers who have gone for the management option early. They are annoying because they think they know how to solve a problem. Their requests come in the form of half though out solutions. "We need a new table in the database with these fields" as opposed to "I want to track this information and see it here". I have to translate these to higher level requirements, then work out the implementation details myself, as often their "solution" has flaws - we actually need two related table, or an additional field in an existing table - not the new table they have suggested.
Now I have a team leader and group leader on top of that, who are in my opinion junior to intermediate level programmers who have gone for the management option early. They are annoying because they think they know how to solve a problem. Their requests come in the form of half though out solutions. "We need a new table in the database with these fields" as opposed to "I want to track this information and see it here". I have to translate these to higher level requirements, then work out the implementation details myself, as often their "solution" has flaws - we actually need two related table, or an additional field in an existing table - not the new table they have suggested.
Your second example is exactly what I had in mind. It reminds me of the final group listed in this quote from General Kurt Von Hammerstein-Equord:
"I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief."
"I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief."
Beats having a manager that has completely no engineering background what so ever. We have those... they are very dangerous.
The horror ...
Example:
Explaining why testing is necessary. Corollary: Explaining why despite having delivered the application once without testing once, it does not mean testing is useless.
Explaining that our testing is not useless because the client found a bug.
Explaining that it is normal that we get some specification wrong and need to change them after further discussion with the client. No we do not need to fire the BA.
Explaining why, despite coding our apps "by the spec" we still need to schedule some integration testing.
Explaining that public shaming of a developer that committed a bug is counterproductive.
Explaining that the priority on task to LOW allow us to know what task will not be done if running out of budget. Also explaining that setting all the task as HIGH is not a workaround for lack of budget.
Explaining that budget consumption is not a proper indicator of progress. Also 9 women cannot have a baby in 1 month.
Sometimes the client is wrong, it is ok to discuss with the client.
It is ok to be wrong. Yes developer are wrong all the time and that does not make them bad developers.
You cannot estimate with 100% certainty.
Analogies and high level description are not substitute for in depth knowledge.
Example:
Explaining why testing is necessary. Corollary: Explaining why despite having delivered the application once without testing once, it does not mean testing is useless.
Explaining that our testing is not useless because the client found a bug.
Explaining that it is normal that we get some specification wrong and need to change them after further discussion with the client. No we do not need to fire the BA.
Explaining why, despite coding our apps "by the spec" we still need to schedule some integration testing.
Explaining that public shaming of a developer that committed a bug is counterproductive.
Explaining that the priority on task to LOW allow us to know what task will not be done if running out of budget. Also explaining that setting all the task as HIGH is not a workaround for lack of budget.
Explaining that budget consumption is not a proper indicator of progress. Also 9 women cannot have a baby in 1 month.
Sometimes the client is wrong, it is ok to discuss with the client.
It is ok to be wrong. Yes developer are wrong all the time and that does not make them bad developers.
You cannot estimate with 100% certainty.
Analogies and high level description are not substitute for in depth knowledge.
Lots of interesting Management material to learn about. To be a manager it's good know a little about a large number of things. Learn about the theory of constraints, lean, product management, finance, psychology, visual management etc
Lots of cool things to learn, don't think your leaving interesting knowledge behind.
Being a manager is about getting the right resources, the right people to do things at the right time.
Lots of cool things to learn, don't think your leaving interesting knowledge behind.
Being a manager is about getting the right resources, the right people to do things at the right time.
If you're starting to do technical management after only 2 or 3 years working as a coder, I would say that's a bad move. Project management, people management - all fine, but it's extremely unlikely you have the depth of experience required to be providing technical direction for any kind of a large project
And with only 2 years of programming its unlikely that you will have developed enough soft people skills.
I'd argue that these skills are only tangentially related. Despite what others experiences are with MBA types, one of my best managers ever was a very smart recent MBA grad with no programming experience.
He cared deeply for the team, set up growth paths for everyone that wanted them, acted as a crap umbrella when shit hit the fan, praised publicly and provided very constructive criticism in private.
He cared deeply for the team, set up growth paths for everyone that wanted them, acted as a crap umbrella when shit hit the fan, praised publicly and provided very constructive criticism in private.
was this a proper MBA ie 35 or so with a decade or more of work experience before doing their MBA.
A lot of people seem to do BS/BA->MBA with no work experience prior to the MBA as away of dodging immigration hassles
A lot of people seem to do BS/BA->MBA with no work experience prior to the MBA as away of dodging immigration hassles
Straight out of school. Hour was at least a year younger than I was.
Is it because someone has identified you as having leadership potential or because no one else wants to be the manager?
If the former, thank them for the assessment and leave to start your own company, even a tiny one. You will learn more about management and less about impedance matching the (dys)functions of existing organizations.
If the latter, leave to work elsewhere in a technical role, preferably under a good leader.
If the former, thank them for the assessment and leave to start your own company, even a tiny one. You will learn more about management and less about impedance matching the (dys)functions of existing organizations.
If the latter, leave to work elsewhere in a technical role, preferably under a good leader.
I've never been a manager, so I might well be completely wrong about this.
Anyway, I think that, even as a manager, you have the option of being involved in the design aspect of things, even though that heavily depends on the kind of developer you are. If you're anything like me, you love designing new features and writing specs that are as detailed as needed. That's something I've been doing quite frequently, to the point where, for the project I've been assigned to, I do most of the design of new features besides helping turning them into working code. I sit down and think through the problem at hand, jotting down ideas in plain text files and commit them to a dedicated folder in our project's source code repo, iterating over them as I think of more efficient/elegant/fast/simple ways to implement the feature and taking into account inputs from the other guys in the team. Again, I've never been a manager, but I think one could retain at least part of this role, provided she can cut through all the bullshit that working for a company entails (meetings where you decide nothing, chiefly).
OTOH, if management is not your thing it's not your thing, I guess. Then again, why not give it a try? Give it some time and see how that works out for you. If you like it, great. If you don't, you can always quit and the best that can happen is that your resume will look more interesting.
If I had to hire someone, I would give bonus points to someone who knows about managing and communicating with people, not only machines.
Anyway, I think that, even as a manager, you have the option of being involved in the design aspect of things, even though that heavily depends on the kind of developer you are. If you're anything like me, you love designing new features and writing specs that are as detailed as needed. That's something I've been doing quite frequently, to the point where, for the project I've been assigned to, I do most of the design of new features besides helping turning them into working code. I sit down and think through the problem at hand, jotting down ideas in plain text files and commit them to a dedicated folder in our project's source code repo, iterating over them as I think of more efficient/elegant/fast/simple ways to implement the feature and taking into account inputs from the other guys in the team. Again, I've never been a manager, but I think one could retain at least part of this role, provided she can cut through all the bullshit that working for a company entails (meetings where you decide nothing, chiefly).
OTOH, if management is not your thing it's not your thing, I guess. Then again, why not give it a try? Give it some time and see how that works out for you. If you like it, great. If you don't, you can always quit and the best that can happen is that your resume will look more interesting.
If I had to hire someone, I would give bonus points to someone who knows about managing and communicating with people, not only machines.
It really depends on your medium/long term career goals. If you want to become a manager it's better sooner than later. At least you'll have the time to learn the job properly.
The managers I liked the most so far were the least technical, but also the least opinated about how techs do their job, trusting our time estimates and other things that should be the developers/architects to decide.
I usually don't get these types of questions. I you like engineering you stay as engineer, if you don't you try to find something else. If you just want more money try to find another engineering role.
If it's good or bad it depends on what you enjoy doing, nothing more nothing less.
If it's good or bad it depends on what you enjoy doing, nothing more nothing less.