2

Long story short, for one of the projects I am managing, I am managing an in house team of developers. I am a former developer now PM, and made the move because I disliked commercial programming.

In terms of performance as a PM, I have been getting a lot of praises from upper management, because I deliver software projects in a timely manner. My in house team however are backbiting about me, and I have found out from upper management, they are upset that I am not more hands on. To my face they can be patronising, and are acting as though they can do my job better than I can.

My day to day job consists of sprint planning, user stories, coaching, being involved in software architecture, reports, sprint retrospectives, user acceptance testing, managing resources/ stakeholder expectations etc etc When it comes to the day to day running of the projects, I believe in giving my team ownership, and supporting/guiding them where I can.

What is the best way to handle this situation, it is starting to get me pretty down. I feel like a bit of a punch bag now that I am in management.

bobo2000
  • 3,892
  • 1
  • 26
  • 45
  • I'd not consider it your role as a PM to be a developer also.

    within your sprint retrospectives does anyone step forward and comment on the fact that you're not "programming" or is it just hear-say ?

     – G.H Dec 18 '15 at 16:06
  • I had one of the members of the team approach me about this a few weeks back, I told him that it is not my role and ever since he has been bitching with other members of the dev team (and to my boss) criticising my skillset from a technical perspective. He feels that I shouldn't lead if I am not technically involved basically. – bobo2000 Dec 18 '15 at 16:13
  • Do you have Lead Developers in the Team?? the one who is "bitching" is he a Lead Developer? – G.H Dec 18 '15 at 16:17
  • He isn't. But yes, I have a lead developer in the team - he is a lot nicer than the one bitching, but I am not sure if he is being two-faced since my boss caught them bitching on skype about 'how the project run'. They both have this mentality that if I am not hands on, I should not lead the project because I dont know enough 'technically' to lead it. My job is much more client facing and about timekeeping, resolving impediments etc. Technically I am involved on a much more abstract level, helping them choose the right tech, code and architecture reviewing, – bobo2000 Dec 18 '15 at 16:23
  • Hi bobo2000 , since you already a PM , from my perspective should have any hands on into coding anymore , your new job should purely on management, correct me if i'm wrong – LArcenCiel Dec 26 '15 at 02:21

6 Answers6

8

My day to day job consists of sprint planning, user stories, coaching, being involved in software architecture, reports, sprint retrospectives, user acceptance testing, managing resources/ stakeholder expectations etc etc

Wait a second. Why are you doing software architecture? You are managing the project. Your technical people should decide on the architecture of the software they build.

If you aren't involved into the day-to-day technical work, you should refrain from making technical decisions for the people who are. Because they cannot be good decisions for the simple fact that you don't have a good base for those decisions.

I don't think your developers complain that you don't code. I think they complain because you are involved in decisions for which you should code. So don't be involved in those decisions. It's no longer your job, you are a project manager now.

Your people are probably right complaining. Stick to managing the project. That is your job. They aren't complaining about that so you seem to do a good job. If you need someone to make technical decisions, find someone. You said you have a lead developer, I would expect the lead developer to handle the technical parts.

nvoigt
  • 8,475
  • 19
  • 34
  • I am technical enough to make software architectural decisions - you know building an API, client - server architecture - outside of my managerial duties since I was a ex developer. I also coach developers. I just don't code. A good project manager should know what is involved in creating software, how can you manage something properly if you don't know whats involved in building it in an abstract level? – bobo2000 Dec 27 '15 at 04:41
  • What happens if I take the back seat, and the tech team makes the wrong decision causing the project to go over budget, delayed or even worse architecture that was not well thought out causing a rewrite later on because I blindly followed them? Who becomes accountable then to the stakeholder. How can I manage my risks as a PM if I have no input in the software lifecycle? Ridiculous, sorry. – bobo2000 Dec 27 '15 at 05:09
  • 1
    That are good questions that may be worth asking here. But as a PM, your job is project management, you need to let go of your former job. You cannot do both. You need to learn to trust your team. If you don't, they will remain unhappy. – nvoigt Dec 27 '15 at 06:52
  • Project management comprises of managing the project so that the project is delivered on time and in budget. If I am not involved in ANY decision making at all, how can I do this? I do not mind my team making tech decisions, and I do this already, providing that I am aware of what it is and the implications this may have on the delivery on the project on time, and in budget. There have been many times, where I have prevented delays by anticipating poorly thought out tech decisions by my team. – bobo2000 Dec 27 '15 at 18:22
  • If you have no technical awareness, it is also very difficult to estimate how long a technical task should take. This is problematic with stakeholders, since more often than not they will ask you, how long it will take to implement. IF you are not technical, your dev team can give you an unrealistic time frame affecting your ability to judge how long things will take. Another reason why my dev background helps me immensely. – bobo2000 Dec 27 '15 at 18:33
  • 3
    @bobo2000 All that technical stuff is not your job as a PM. Making technical decisions is not your job. Estimating time is not your job. Your job is managing this circus. Make sure time is estimated. Make sure technical decisions are made. That is your job as a project manager. If you are actually doing any of this yourself, then I would support your team: you should not do this without being in the trenches once in a while. Making decisions in an ivory tower does not mean they have to be bad, but chances are, they will be sooner or later. – nvoigt Dec 28 '15 at 15:45
  • I guide them, ultimately it is their decision I go with providing that it is realistic in x timeframe. They also set their own estimates providing that they are reasonable. I think this is important for every PM since the role is about delivering a project on time and within budget. – bobo2000 Jan 07 '16 at 13:48
6

I am a developer and after reading the discussions going on here I would like to answer from my perspective. One thing I have really appreciated about non-technical project managers is the fact they think their dev team is amazing because they pull off the feats they do. They also ask a whole range of questions to understand. In contrast when I have had managers-were-developers over me, they too often treat me like I'm inexperienced and can't be trusted with decisions - even technical ones (I've been coding over 20 years). I feel disrespected and often feel like the project manager thinks he could do a better job. I feel there is less personal care with such managers.

With that experience and possible prejudice out of the way, I would say that the best course of action for you is to meet 1 on 1 with the louder dev and in a relaxed way (shout him a coffee or beer?) ask some questions. It is often what we opinionated devs want - someone to check up on us "in a hands-on way" and see how we are doing and understand us more and how we can be helped through our work.

You could try questions like: What do you expect from a PM? What have you not liked about past project managers? (Without naming them). Then you will understand if he is just inexperienced or if he has a legitimate point that will help your team. But don't judge him on that. Take everything as food for thought and building a relationship with your team.

I'm not a project manager or any kind of expert on the matter, so please take this as one opinion only. I also tend to agree on some of the points raised that you should not try to steer the architecture for your team; that is the lead developer's job or architects if your company has them (I'm guessing they do not). Maybe you can stick to mentoring your lead developer one-on-one if you think he does not have the ability. You could still do code reviews or suggestions in direction for him, but I wouldn't do much else technical with the rest of the team; I'd make it about your lead dev's personal training.

Hope this helps, Ryan

Sarov
  • 14,768
  • 5
  • 33
  • 62
Ryan
  • 61
  • 1
  • 1
  • Do you mean "shoot him a coffee"? "Shouting a coffee" doesn't sound very relaxing ;) – Erik Dec 19 '18 at 18:51
3

I'll give the same answer I gave in the "Non-Technical PM" question. It applies equally here.

In your specific case, you need to educate senior management so you have their support. And then you need to give the team more visibility into what you do day to day. Make it clear that they would have to share this work if you were to do coding work.

3 down vote I've been very successful as a program manager and now agile coach, in Silicon Valley, for over fifteen years based on a completely non-technical background. I've faced this argument many times in the earlier stages of my program management career. My technical skills are at a basic advanced computer user and I've never coded.

When faced with these arguments I provide three reasons why I am well qualified. Two of those are fairly universal to any non-technical PM.

1- Perspective: As a non-technical person I am able to avoid falling down the rat hole. Because I don't have a technical background, I remain focused on the project itself and ensuring the project is a success. Whether we use one SQL query or another is not something I need to worry about. If we are getting enough work done to meet our schedule is something I need to worry about.

2- Force Multiplier: This one is best done through a short example.

"Say you have a team of five engineers and you want to improve productivity. If you hire a sixth engineer, in theory you will improve productivity by 20%. However, the law of diminishing returns and also the principles of team dynamics tell us that we'll probably only get 10% more productivity. If, however, you hire someone to focus solely on the program and helping the team and this person helps each member of the team get 5% more productive, than that one person has improved productivity by 25%. That's more than the best case of hiring one more engineer."

3- Broad Experience This one is more specific to me. In my career I've worked from computer games to enterprise virtualization to hard drives. I've also worked in support, QA, product management, business development, project/program management and agile coaching. The broad experience allows me to work well with almost any team.

Community
  • 1
Joel Bancroft-Connors
  • 12,543
  • 25
  • 55
  • I honestly do not understand how lacking experience on code side improve a person. ": As a non-technical person I am able to avoid falling down the rat hole. Because I don't have a technical background, I remain focused on the project itself " — since having technical background makes you forget how to see the big pictire and make you mentally challenged? Looks like self indulgence. Note to Topic Starter: that's how you get alienated from team for sure. (I am a pro coder with PhD in astrophysics and aims to become a solution architect). – onkami Dec 20 '15 at 18:29
  • @Askar- I'm unclear what your comment is intended to convey. Can you clarify? – Joel Bancroft-Connors Dec 21 '15 at 05:35
  • My comment is about: you offer some reasoning that basically builds up on declaring developers "incapable" of your thinking — due to technical background. " Because I don't have a technical background, I remain focused on the project " , " As a non-technical person I am able to avoid falling down the rat hole. " So — as opposite to you, the technical persons ARE NOT remain focused on project and falling to some "Rabbit Hole", they are less perfect than you are, or so it sounds. I hence do not believe it will work out well to present things in such light to the team, especially to Architects. – onkami Dec 21 '15 at 09:40
  • 1
    @Askar- Well I appreciate your point of view. And I will admit that the brief description written here is not a perfect communication. Verbally and in person there is a lot more to it than just saying "I can be more focused". That all being said, I've used this logic with engineering managers and leaders for the last fifteen years and been very successful in my job role. So I appreciate the argument does not work for you, it does work though. – Joel Bancroft-Connors Dec 21 '15 at 21:39
  • I am being alienated by the team by a disgruntled employee whose opinion is that I should do some hands on coding. Ironically, for those telling me that I should take a back seat, I did do that for a couple of weeks, and he felt I wasn't 'involved' enough. Having a technical background is such an asset, I don't think I can deliver really complex technical projects on time, if I had no idea what is involved and was not involved in the decision making process with regards to tech, architecture. That doesn't mean that I have to code :) I am strong advocate of coaching and guiding my team. – bobo2000 Dec 27 '15 at 05:17
1

It sounds like you are half in and half out of the techincal side of things. I would advise removing yourself from all technical descisions, discussions, architecture, 'trying to make things easy' etc

Concentrate on the timeline, budget and customer acceptance. Set challenges rather than specifiying solutions.

re the bitchy dev. They need to be told to act professionaly and try to make the workplace a nice place to be for everyone.

Ewan
  • 926
  • 4
  • 8
  • Yep, I was an ex developer, so I am a hybrid and to be honest it helps me immensely when dealing with stakeholders, risk management and managing my team, who from time to time I guide. Since I am able to anticipate technical pitfalls from prior experience as a developer. – bobo2000 Dec 27 '15 at 05:03
  • No it doesn't. it upsets your team and gives false assurance to your custimers. stop developing – Ewan Dec 27 '15 at 07:54
  • Not true. I have just delivered a project that is 6 months long in 3 months because I was involved in the technical decision making process on an abstract level. I helped my team avoid pitfalls from experience of building that type of app before. I don't see why this is such a bad thing, if you follow sports for example, a lot of the 'managers' are ex players who draw up plays without playing the game itself on the court. Similarly, I don't have to be a hands on developer to guide developers. I can guide them, which is what I am doing. – bobo2000 Dec 27 '15 at 18:26
  • The most clueless PMs I have met are the ones that have no understanding technically of what is involved resulting in poor quality software. – bobo2000 Dec 27 '15 at 18:29
  • You mean the developers delivered it quicker than you thought despite your low opinion of thier ability? Im starting to see where you might pick up some bad feeling – Ewan Dec 27 '15 at 18:47
  • I never said that they were not able, actually they were very able just one member of the team is arrogant. – bobo2000 Jan 07 '16 at 13:46
  • you implied it by saying that the project was delivered in half the type due to your technical input. You might be a genius programmer, but unless you are doing the programming you need to step back and let the programmers do it – Ewan Jan 07 '16 at 16:17
  • Well yeah, because I organised and delegated the work properly by playing to people's strengths as well as showing them industry short-cuts from doing this as a developer in a previous role successfully. I'm not blindly guiding them, before I took on this role I was doing a lot of the same grunt work in previous projects whereas they are doing it for the first time. – bobo2000 Jan 07 '16 at 16:55
  • You asked a question, looks lile you dont like the answers – Ewan Jan 08 '16 at 08:06
  • It's important to keep things in context. – bobo2000 Jan 08 '16 at 17:38
0

This not an easy situation to resolve amicably. It sounds like the team either don't realise that you have been given a new, non-development role, or don't understand the purpose of the role sufficiently. A PM should not be getting involved in development: that much you have stated. It sounds like the team want you to be a technical lead, which is a very different role from that of the PM. If you have a senior person on the team who could take on the role of technical lead or lead developer, you should consider making that role formal and directing the team members to him or her when they have technical queries. By doing so, you are demonstrating that you are outside the development team, and that your role is different from theirs. That then raises a new issue, which is that you could lose their support, which could prevent you and the team from achieving the project's goals.

I'm concerned about the comment that someone has been bitching with other members of the dev team and to your boss, without being told by your boss that your role is something other than a developer. The boss should be fully supportive of your role, and fully aware that it isn't a development job - so if the boss isn't backing you up, he or she is part of the problem. Try a heart-to-heart discussion with the boss, and check that you are both on the same page in terms of your role. If you are, you have support - so ask for it to be demonstrated. If not, then you need to align the expectations, otherwise you will never solve the problem as you will be "got at" from above and below.

One possible avenue to consider might be to ask the team what they see as the PM's role, as opposed to a technical lead's role, and offer them your view of the PM's role. Build on any commonality, and explain the purpose of any aspects of the role that they don't understand. Show them that these tasks need to be done, so if you are not doing them, then the responsibility will fall to the developers. That might just scare them, as in my experience, developers don't like to also be administrators, governance specialists, or progress reporters.

There are several other questions that cover broadly similar themes, so it might be useful to review these answers too:

How technical should a Project Manager be?

Splitting PM responsibility between technical lead and non-technical PM on an agile project?

Do technical leaders compete with project managers?

Role of a technical project manager?

Advice for a Non-Technical Newbie Scrum Master

How much technical experience is required to be a software project manager?

There are others, but these may help give you a flavour of how other people see the issue.

Good luck!

Community
  • 1
Iain9688
  • 6,858
  • 4
  • 23
  • 50
  • Thanks for this, they brought it up with the boss in a private meeting out of their own accord. My boss is very supportive since I have streamlined and structured his company and it is now running more more efficiently – bobo2000 Dec 18 '15 at 17:11
0

I am not in position to answer this definitely, but I think that you need right balance of power and loosen the difference.

  • Make sure you appreciate them and let them know that you take good things about them to higher-ups.
  • Make the right impression. Developers might recognize their job as core and your work on spring backlog as supplementary bureacracy. Because their job is the core indeed, though yours is also important. I think you should less capitalize the effort on your supplementary tasks and be more like another developer
  • Assume some task that you can do and make sure it is also a development.
  • Know your role's limits as per scrum guide. Do not demonstrate your authority just because. Reserve it for case when it can not be resolved in some inversigative manner.
  • Explain reasons behind your decisions.
  • Do not put common sense questions to vote and do not start debate these.
  • Know your limits. If you are not coding, you are missing out the details.
  • Do not make favourites.
  • Involve people in the decisions.
  • Explain that you are here for serving the project and that is your only purpose, not gaining power or playing with people's lives.

Even if you are not coding, dive into their code and play with software yourself and make it as you would be the only tester in the world between them and production release. Show great dedication and great knowledge of code.

Then I think you will be respected.

onkami
  • 101
  • 2
  • Aside from the coding, I do the others already. I am very heavily involved in QA - the last document I wrote was an overview of what was accomplished in v1.0 in that software, meaning I had to go in and use the product. I am not coding, but I am technical enough to know what they are trying to achieve, and how they are trying to go about and do it (and whether this is a good way of achieving it). This is also not the only project I am managing, I am managing 7 at one time in parallel. – bobo2000 Dec 20 '15 at 14:38
  • @bobo2000 I believe the key is not to alienate from the team. If you keep distance, then you basically asking for some tension. There must be something that you did that made their life easier, and just report that to them in scrum or something. – onkami Dec 20 '15 at 18:32