I find it hard to adjust to the top down decision making from management where I work. One example: I have raised my interest in moving to a different team a handful times, but management sometimes forget to come back to me, or I just receive a short "no". I feel I don't have much influence, but in the end of the day I am writing the code so I wish I felt more ownership to the processes.

To narrow what is going on to the essencial: My managers mainly focus on how they can keep pace with processes they have initialized, and care less for the human factor.

To illustrate what arguments leads me to that conclusion. 1) We are understaffed on both my current team and the one I wish to transfer to. 2) Management have initialized a large project that soon will split my current team into two teams. In my view, they take a big risk taking on a big project on our team when they are informed I am interested in changing team.

What is the best way to influence in a work environment like this, where concerns for the process are more important than the concerns of the individual? How can I make the managers care more about my perspective, hopefully without end up being perceived as a negative or difficult employee?

  • 1
    This is broad because you're hitting multiple issues - retention issues, requesting a team move, having ownership of your own work product, cooperating with highly technical managers who are former high level independant contributors - any one of these areas is rich with great questions, but there's no clear concept in this post on exactly what you want to change about your environment. I'd suggest editing to pull this into a single goal. – bethlakshmi Jul 22 '13 at 16:33
  • @bethlakshmi Thanks for your constructive feedback. I have updated my question, I hope this is better. – arg1 to rokca1 Jul 22 '13 at 18:50
  • "they take a big risk taking on a big project on our team when they are informed I am interested in changing team." They know you wish to change teams, but you've been denied. You're not changing teams. I don't really understand where you're coming from with this question. Your managers are your managers. It's not uncommon for them to have much more control/power than you. – acolyte Jul 23 '13 at 13:36

Influencing others is sometimes a difficult skill to learn. It is possible, as Wesley Long believes, that there is no such opportunity in your organization. It is also possible that there is such an opportunity.

In order to convince people of something, you need to understand their motivations. The first thing I recommend you do is to understand the culture of the group that is making the policies. Do they act on feeling? On evidence? On experience for things previously having gone wrong? An attempt to become ISO5001 certified so they can better compete in your particular market?

Once you know to what they are reacting, you can re-evaluate your position. There may be a very good reason for the policies that are being created, to which you are not yet privy. You can also look at the issue that they are trying to address and see if there's a alternate solution, or if you can demonstrate that it's a non-issue. Or, perhaps, you can demonstrate that the cure is worse than the problem.

  • Our middle management react based on what they know and gut feeling. If in doubt, stick with the plan. Better to decide something than nothing. They know the organization well and what is needed, but treat developers like external consultants with no influence. I know my managers well. I sometimes go to the head of the department, he is coming from outside so he has different view on things. But I think going past middle management over and over again is not a solution. – arg1 to rokca1 Jul 22 '13 at 6:24
  • OK. For the policies about which you disagree, why were each instituted? Just because a plan was needed? Or were they created to solve/prevent particular issues? – atk Jul 22 '13 at 12:08
  • The issues management are focused on is how they can keep pace with processes they have initialized. That is the only reason I can think of why they won't let me change to the other team. To illustrate what arguments leads me to the conclusion. 1) We are understaffed on both teams. 2) Management have initialized a large project that soon will split my current team instead of bringing in consultants. I believe that processes are the controlling factor. – arg1 to rokca1 Jul 22 '13 at 17:43
  • Have you tried asking any of them the reason for the policies? – atk Jul 22 '13 at 18:55
  • Your question actually helped med gather my thoughts more, and I have updated my original question. I am bringing up my concern or wishes with management if I am not satisfied with the answers in the first round, yes. It varies how good answers I get even after second round. Sometimes I understand there are good reasons for a decision, but other times I just don't get any wiser. – arg1 to rokca1 Jul 22 '13 at 20:52

"... but in the end of the day I am writing the code so I need some ownership to the processes."

No, you don't need it to do your work. You may want it, but the process given to you is what you have to work within.

"Ownership of Process" is a strange concept. Are you using it euphemistically to mean "Authority over the process?" I believe you mean either you want influence on processes, or at least some latitude within them for your own work. In a traditional engineering world, a change in process would require doing a cost/benefit analysis and a risk mitigation analysis (at the very least), then proposing it for review by management. Software development "borrows" a lot from engineering, but it doesn't bring all of it. It sounds to me like middle management is trying to bring some process control aboard, too. If you need the "fast and loose" feel you had before, you may be in trouble.

It seems this organization is designed to specifically prevent you from having influence. Without a major management restructuring (which you have no ability to initiate), things will not change.

If you mean "ownership" of the code, as I originally thought you meant, then that's never going to happen. Your code is work product, and it belongs to your employer as soon as you type it.

If you need "ownership" for your own personal sense of job satisfaction, then you definitely want to find a different organization. Keep in mind, though, that anything you write as an employee or as a contractor under a "work for hire" agreement is not now and never was yours, no matter what you "feel."

  • I have been thinking about going to a smaller shop because maybe my views would be more appreciated there. – arg1 to rokca1 Jul 20 '13 at 18:36
  • 2
    @arg1torokca1 - You should probably pursue that. It would probably make you much happier in the long run. Life is too short to work where you're not happy. – Wesley Long Jul 20 '13 at 18:39
  • 1
    @arg1torokca1 - if they're more interested in process than outcomes other people in your shop are probably eyeing the exits. Go fish, and see if anything bites. – Meredith Poor Jul 20 '13 at 22:51
  • 1
    Hi Wesley, by ownership, the asker is referring to ownership of the process not the product. I suggest you edit your answer so it addresses how the op might influence the work environment so that employees are empowered to make more of their own decisions. Note that on answers that suggest a person quit their job, we require those answers include facts, references, or experiences that happened to you personally as per the back it up rule. – jmort253 Jul 21 '13 at 18:20
  • 1
    Hi Wesley, I guess what confuses me is how in that paragraph you mention that code you write is not yours. That makes me think you're referring to ownership not process. If these aren't clear to me they likely aren't clear to others as well. Hope these suggestions are helpful! :) – jmort253 Jul 22 '13 at 3:25

Not the answer you're looking for? Browse other questions tagged .