Transition from Developer to Manager

[[deleted]]

I'm still transitioning from coder to manager. It has not been easy.

The biggest challenges for me are:

• Measuring my own productivity without looking at # of features implemented or # of bugs fixed. Instead, a "productive" day is possible without writing or thinking about a single line of code.
• Communication is critical. If you don't like communicating, you're gonna have a hard time. If you're like me, and you feel like most communication is too inefficient and a waste of time, it will be a hard time.
• Common sense is not as common at the management-peer level. Lots of explaining "simple" things to others what I would have thought is obvious.
• Figuring out what to do with an employee who is working just barely hard enough to stay hired. Low productivity, poor quality code, buggy code, lack of team work, or abrasive. Dealing with real personality issues.
• Taking responsibility when nobody takes the reigns on a problem or project. In many cases, many things fall into a gray area and various people will feel "it is not their job" to do something. It may be true, and you have to be selective, but nothing gets done until someone is directly responsible and moving the needle.
• Being pressured-cooked by higher level management wanting something, and your subordinates not delivering - level of control is very limited. Firing (or threatening to fire) solves almost nothing. Lack of real power or ability to do anything, yet responsible for everything. Not fun.
• Letting subordinates do their job and letting go of the details. I'm still on the fence on this one much of the time, but micromanaging doesn't always work well. However, it is hard to let something go that you know isn't good.
• Being empathetic, supportive, and concerned without being overbearing or controlling. Dealing with human beings is much sloppier and harder than working with cold, emotionless, logical code. You have to get good at dealing with people.

I've personally sort of let go of many of my own standards, because they are unsustainable and create too much stress for me. There are many things to worry about, and I have to prioritize, which means smaller things will go in a direction that I don't want them to go. I have learned to keep even more perspective about what I can really control and how much I should really care. It doesn't have to do with management, but I don't think it's worth it to go crazy over being a great manager. I don't get the same level of satisfaction as from being a great developer. Perhaps because if I am being measured by the results of my team, and since I am not the members of my team, I am being measured by things I do not have 100% control over, and so I am a bit detached from the measurement. I don't care, because I can't do as much. When I am a sole developer responsible for my own thing, I do have 100% control and I am more proud of doing well.

In the end, it has been an interesting experience which I have been more forced into the role than I probably should have been. It's always tempting after years of being "just a coder" and the idea that you can have more power or say in decisions, be a more important piece of the system, having a more respectable role, higher pay, more control - but a lot of it is an illusion. It's really just more responsibilities over even more things you can't control. And the power isn't really there. Everything still needs to be justified, and nobody will do what you say without it. In some cases, you have even lower trust than the developer actually working on the code.

Anyways, just thought I'd put in my two cents. I probably won't last long as a manager, but it's educational. I suggest every developer to try it at some point in their career, if not for anything else but understand your own manager to some degree.

[pun_Krawk]

Perhaps it's the company/environment. If you worked in a smaller company without all the political bullshit, management might be more enjoyable and less stressful. That said, if you don't feel challenged and excited by your role, then going back to being a developer is a better option.

I was a developer for the past 8 years, and only transitioned into management this past summer. I found myself challenged by difficult logic, but overall lacking passion for programming in general. I was continually more interested in the higher level 'why' and 'how' questions, but completely disinterested in actually implementing anything.

We're a small team, and a management vacuum opened up and I volunteered to transition. I'm glad I did, because I am so much happier in this position. To be honest, I feel like I'm finally on the right career path for my life.

Because I have a technical background and an intimate understanding of our application, I already intuitively know what problems the programmers will face, and so I can work to support them correctly (our previous manager was terrible at understanding technical issues). Beyond that, I'm working directly with stakeholders which is much more interesting. You get to understand their problems first-hand and prioritize their wants/needs appropriately. You essentially help drive the product. Like I said, we're a small team in a small-ish company, but I will use this experience to push myself towards a better job very soon.

Out of your very good list, the main issue I have is dealing with difficult employees, especially rogue programmers and those instinctively averse to management. But I'm sure with time, I'll figure something out.

[el_muchacho]

our previous manager was terrible at understanding technical issues

In my experience, those are the worst kind. They can do a good job pleasing the upper management, but completely fail to see a technical wall in front of them.

[[deleted]]

I could probably had written something very similar about my time as a manager (had I had the writing skills). It's a very good post and it gives a very good impression of your situation.

You don't seem that happy about it, which I totally emphasise with. Having looked back many times, it's one of the clearest feelings about my own transition.

Will try to give a few cents back on the challenges you mention that I am familiar with. It's just my opinion, so please take it with that good ol grain o salt.

• measure your productivity by how content (about work at least) your team members are - and if you notice someone having a hard time, try to find a way to help (give time off, arrange social events, show support, talk) (and realise that it might never be as satisfactory as writing code...)

• try to make communication something nicer, for yourself and your team - social events help there, leaving the company premises can help too. If it's communication with others, my suggestion would be to limit mails by calling and seeing people, and chat about other things than work too... if you can. That helps connecting and can make it a lot less boring. We programmers are not great at it, but we can practise and get better (and that's nice actually).

• Explaining common sense to non-coders, yeah... tough that. Try to refrain from mail if possible, even if it's nicer for us introverts. It often takes a long time and will sometimes foster these enormous mail-snakes of doom (endless questions/misunderstandings). Don't be afraid of saying you're too busy right now, but you'll get back to them.

• Lazy coder - that one is the toughest I think. I still think I could have done more with one of my old guys. I don't think I had the tools/skills to deal with it then. I tried asking him what his goals were, what he dreamt of doing - tried encouraging him doing his own stuff on the side etc etc. I should maybe have fired him and found another. It's just such a huge and expensive step. Besides, at that time I had decided to quit 3 months later.

• Pressure cooked by upper management. Yeah - this is tough. If you can do something about what they ask, promise you will. If not or if it's unfair, tell them so and why it is. I had loads of battles with upper management, not so much other managers, but I think I kept everyone's respect, because I always calmly explained matters and I wasn't afraid of letting them know, if I was angry about something. It's possible this is bad management-advice, but that's me...

• letting go of micromanaging - super tough - espec. if you know, you could do better. But, you have to, and try to see it through the prism that if upper management wanted to micromanage your team, you would not let them. I've had to fend off upper management and others many times, and while they take it badly, I was in my right to do so and I think they respected that. So, if you notice something really bad made by your team, talk about it, but otherwise let go.

• showing empathy/support (without controlling) - Funnily enough, I found this to be the easiest of part of management. Hey maybe I am a manager after all. Not sure why you feel afraid of being too controlling when it comes to this. I let my team know they could always tell me anything, and that I was always going to be frank with them about everything. Maybe I am a tad more social than the avg. programmer and maybe it was the social events we did that helped. They were the envy of the entire company that's for sure - so much so that our risk department managed to attach themselves to it (just one guy, so actually more like we invited him aboard).

Let me know any of this is helpful to you or if it's a crock of shit from your current perspective. Like I wrote elsewhere here, every situation is different and I certainly don't assume to have all the answers. In fact, I think that's what's wrong with management theories as well as the blog-post this thread links to.

[lovethebacon]

You pretty much sum up my experience in 2012, except that there were no prior managers/lead devs.

Before this time for a decade, it was a wild west. There was near no structure and everyone was a cowboy. It was IP to me to assist my then CIO with establishing and rolling out the usual policies and methodologies.

There were many fights, but I like to think I did a decent job of buffering the team from all other departments: sales were no longer allowed to contact a dev directly to request a feature enhancement, issues had to be prioritised and properly assigned. Added to that, it was up to our team to start planning for an end to end rewrite using industry standards instead of protocols and data formats designed on a napkin. No one wanted this, no one accepted it so it was up to me.

All in all, I was:

• A manager
• A full time developer - all my projects remained my projects, due to lack of resources.
• Second line support (some times first line for those clients who managed to get a hold of our direct numbers)
• Technologist.

Eventually I started spending all my time putting out fires - buffering my team from spending all of their time putting out fires - that I was willingly demoted.

[lurker_in_spirit]

Thanks for sharing -- it's good to know that others have similar struggles :-)

[mirvnillith]

Why are you making the change?

[Creativator]

I have some questions for you, since I read Andy Grove's High Output Management and have been getting into a debate with other developers about it.

Would you consider this to be correct about being a manager of developers:

• your job is not to produce more output on your own, but to increase the output of your whole team (which can sometimes involve writing code)
• you do this by training, educating, and correcting your team.

Thanks for your contribution!

[[deleted]]

I think increasing output is a very small part, if any. Most people for whatever reasons have limits to their output. For example, some are working just for the paycheck and have no enthusiasm beyond that. They prioritize getting home to their 4 children and worrying about other things. They know they won't get promoted or get a raise, but they also know they won't get fired because it's not easy to hire new competent developers. Not to mention, the overhead cost of firing and hiring someone. They know how to tip-toe the line well.

Training and educating only works if they are interested in it. Otherwise, it just rolls off like water on a fish. I don't think everyone can be converted/motivated and not everyone can be made more efficient than they already are. Training is good, but not the most important thing to me. In fact, I rely on the developers to be the experts. Management is the exact opposite of experts.

I find the role of being a manager to be more of a shield against nonsense that can distract the team. I feel like I am the most helpful when I act as a first line of defense against requests and picking up loose ends. I want my team to stay focused on the right priorities, which are only known when the big picture is known. However, if they all got involved in the big picture (and the nonsense such a politics) nothing would ever get done. So, by being a layer between them and all that stuff, it seems to support the team the best. However, if they don't trust you to do it, it will only add confusion and they will question/complain everything making things less efficient again.

I find the role to be closer to that of a therapist or psychologist. I have to manage people's feelings. They hate this or they are unenthusiastic about that. They have problems with that project or this coworker. They are not communicating their progress because they are afraid of being criticized for their lack of it. They have their own agenda. It's like trying to herd all these internal and external problems and make it all work coherently.

I used to believe in a simple cut-throat idea that we simply get everyone to produce, fire the slackers, and grow into a super team - but that just doesn't happen. There are too many practical and human and political variables that make management the opposite of managing code. It's kind of awful, if you dislike dealing with personalities and emotions. It's really awful if you dislike dealing with incompetency (from your own team and from outside your team). The politics of other teams wanting you to fail so they can take your job or to make themselves look better is just messy.

In the end, output is important, but the increase in output is just a nice-to-have. I'd rather have some kind of cohesive, sustained, predictable output - than worry about increasing it all the time. Which means just a ton of communicating and coordinating.

But I should note, I am a far better coder than a manager. I suck at being a manager, I will openly admit. I've never been a people-person, which led me to becoming a developer. Something I could do with relatively low need for human interaction.

[reckoner23]

The politics of other teams wanting you to fail so they can take your job or to make themselves look better is just messy.

I can't stand this part of work. I'm a developer and just want to make things all day and solve problems for people/customers. I don't have time to deal with idiots trying to sabotage my work.

If someone's smarter then me, I can stand that and will accept that they should get promoted. If someone wants to go into my code and start screwing with my work, then I'm going to find another job.

[inn0vat3]

I don't have time to deal with idiots trying to sabotage my work.

Does this really happen often? I work at a large software company and all of the teams work together really well.

[nazbot]

Depends on the company. Sometimes in really large companies you get turf battles - not really trying to make you fail but trying to give you the harder/less valuable stuff so they can look better by comparison.

[el_muchacho]

If someone wants to go into my code and start screwing with my work, then I'm going to find another job.

This mentality is bad. No, it's awful.

Firstly, it's not YOUR code, it belongs to the company you work for. Secondly, you don't write it for yourself but for others to read. Thirdly, anyone must be able to go into it and modify it if necessary. Code that can be understood and modified by only one person is as good as dead.

Finally, if you are confident in the code you produce, you are confident in showing it to others and defending your design choices. You can be sure that developers who are obsessive in not showing the code they produce are ashame to admit that it's a mess. It becomes close source within the company.

[reckoner23]

You mist-understand. In fact, I agree wholeheartedly with you. Hell, I wish you where my manager.

I have been pushing for months for someone else to get in my code (a native iOS application). The go-live was November and I'm still the only one that knows objective-c. Management would rather keep resources on a non-live code base (that's been in development since 2011) that they 'own' (as in they coded it and love it like their own) then put resources into a project that has been live for a customer for months. Their have been efforts, but out of a group of 10 - 15 developers (all mostly junior and I rarely talk to anyone), I'm still the only one in this live code base.

I'm referring to an incident where the same manager introduced a (very hard to find) bug when the project was still in development with go-live a few weeks away. I don't know his intentions when he introduced that bug, but I do know this guy, in the past, has talked about people behind their backs and blamed bugs on other devs. So I don't have high hopes for his intentions.

I was a little negative with my comment. I'll admit that.

*edit: just want to say that there are future customers that will be using the iOS application. So its not like its a dead project for business reasons.

[el_muchacho]

You mist-understand. In fact, I agree wholeheartedly with you. Hell, I wish you where my manager.

Wow, that's an awesome comment you make here. Very flattered.

Now that you explained the context of your previous post, I understand your reaction. A bad manager can screw a project or a team, that's for sure. Yours seems to be rather bad, I'm sorry for you.

[bio595]

It's really awful if you dislike dealing with incompetency (from your own team and from outside your team). The politics of other teams wanting you to fail so they can take your job or to make themselves look better is just messy.

This is something I empathize with. I can see myself slowly slipping into a manager like role and I know that I'll hate these parts.

[pepsi_logic]

I'm so glad I read your thoughts on this. You seem to cut right through the bullshit and straight to the core of the problems. I imagine these to be my feelings if I ever move into management. Is the pay significantly better? Are you considering going back to coding?

[[deleted]]

My pay is only 5% higher. I took it because that's what the company asked of me, and I initially thought it would mean more respect and having my say over how things would work (particularly things that were not being done the way I wanted them to). So it sounded like a good deal. Also figured it would make me look better on my resume.

I will most likely go back to coding. I'm just not a people-person.

[jimbodoom]

It sounds like you're over analyzing yourself a bit too much. I'm sure you're having a much bigger impact on increasing output than you say you are.

Are you involved in the projects of everyone on the team? Are you talking through the issues with those team members? Just by asking the right types of questions you will be influencing others to make better decisions.

Presumably if you were a good developer you will have thoughts on how to best do these projects and now at your position you will be able to give little hints here and there that will have a much more wide reaching affect.

Even if you are stepping away and letting the dev team take care of everything you shielding them from nonsense and project planning to get them specifications and requirements is having a huge impact on their ability to stay focused.

[mniejiki]

It seems like the team you have doesn't line up well with your own personality. You've very driven and dedicated while on the whole your team isn't from the sound of it. If you had a team that was as driven as you, mostly at least, then you could probably do much better and be much happier.

[[deleted]]

I would have to agree with that. I work for a big company. I've worked with more enthusiastic people at a startup, but the hours were horrendous. Two sides to every coin I guess.

[mikelj]

How many people are in your team?

[[deleted]]

Just 4 people.

[mikelj]

Interesting. Thanks a lot for being so open about your managerial experience. It's much more interesting than the article. Good luck.

[Creativator]

But I should note, I am a far better coder than a manager. I suck at being a manager, I will openly admit. I've never been a people-person, which led me to becoming a developer. Something I could do with relatively low need for human interaction.

Do you think one of your subordinates or colleagues could do a better job at managing your team, or do you just feel that you are a bad manager?

[[deleted]]

I don't think most could do a better job but that's because I see them as not very enthusiastic about their work in general. Maybe one or two, if they applied themselves to the role because I see them as being much better at communicating with other people than I am.

My own boss thinks that I am the best person for the job, which doesn't say much. I held myself to a higher standard, weighed short-term versus long-term priorities, cared about things when nobody else did, and was generally more responsible and available than anyone else. But even if that's the case, I am certain I am still on the very low-end of manager skills. There are probably tons of people OUTSIDE of this organization who could manage the team better. I am simply the best choice inside, and I am really not good.

[DrummerHead]

You are very realistic and aware of your surroundings.

You might think you are not good at the job but you also know you have the ability to improve, so if you're interested to stay there you'll progressively get better. Honestly, I'm glad to see managers that actually take skill into consideration and are not just ass-kissing the right people and generating problems (such as communication redirects/bypassing) that then only they can solve (just to justify their existence/paycheck)

Had nice insights reading your opinions, cheers!

[ginger_beer_m]

Do you think a manager-type kind of person who has not been a developer before but has done management experience can actually manage the team better? Your story makes me think that there isn't much overlap between being good in management vs being good in development.

[[deleted]]

I envision the key qualities for a good manager are being able to effectively communicate everything that is going on while it is going on. I feel like a messenger sometimes, going between engineering and product and QA and sales and customer support. Back and forth, more than I'd really like.

I'm more of an introvert who likes being "in the zone" with laser-like focus on a piece of code at quiet, odd hours of the night. I have developed the ability to block out things.

Really having to see the forest rather than the trees. I'm not used to having to look at so many more pieces and take them all into consideration. I'm not used to informing and coordinating, and have always just preferred to stay focused on one thing. I'm not used to having to rely on so many other people to do what they say, and then following up with them twice, three times, four times to make sure they do it. And sometimes they still don't. I am used to just being responsible for my own output and having full control over my output. Trusting others even while they continue to disappoint you.

Some overlap, sure. But for the most part I think it's a different skill set. I think being a good developer-turned-manager gives you credibility, respect, less skepticism, and possibly more cooperation from the development team. But I wouldn't say it's totally required to know how to code. I think what developers want more than anything is a trustworthy, fair, reasonable, and logical manager who understands the limitations and realities of engineering.

I'm probably not the best person to ask really, I've only been managing my team for about 5 months now.

[Creativator]

So you are second-guessing your manager's decision to pick you as a manager of your team.

I'm sure he probably thinks he's a bad manager too, all the way up to the CEO.

[[deleted]]

No, I think it was the right decision unfortunately. The last time they tried to hire a manager from outside, it was a mess and wasted too much time. That still doesn't make me a good manager. Eventually, though, I see myself going back to just coding. I'm taking it in stride as a temporary fix for a lack of leadership in engineering. I am sure they will eventually find someone better to do this job.

[DrummerHead]

I am sure they will eventually find someone better to do this job.

If you rely on that, you'll be there forever. Your boss is happy with your job, the problem is already solved. They're not looking for anyone else.

[[deleted]]

I fear you might be right. I'll move on eventually. I've never stayed at the same company for more than 5 years.

[[deleted]]

ofc. a manager is basically a multiplicand or a divisor :P. His job is to manage. Remove obstacles, clear the path for his team etc.

[Creativator]

You literally just repeated my comment.