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.
"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."
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.
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.
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.
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?
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".
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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¢.
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).
http://michaelochurch.wordpress.com/2014/07/13/how-the-other...
also read the hackernews discussion:
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 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.
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.
If it's good or bad it depends on what you enjoy doing, nothing more nothing less.
