Implicit delegation of responsibility

Question

Context: I am an employee in a semi-small company, where most people have multiple responsibilities and tasks concurrently. Most of the time, there is no explicit/formal definition of projects responsibility. There is a hierarchy with about 5 managers managing about 5 employees each. Work contracts usually last for ~5 years, so there is a relatively high turnout rate, including for managers (this is because of the company's field, not because of the company ambiance).

Issue: Since project responsibility is rarely assigned explicitly, it has become customary for managers and team members alike to assign it implicitly to anyone who either:

• propose an idea to approach the issue, even partially,
• or is assigned a smaller task related to the project (eg, an intern or team member is asked if he/she can complete a small task related to a project, and from there the project responsibility is assumed to be on his/her shoulders).

I feel this attitude is counter-productive, as it prevents team members to voice ideas or invest in projects or tasks even partially, as doing so would usually result in them getting responsible for yet another project.

Question: Is this kind of implicit delegation of project responsibility common and normal? If not, how to avoid being the target of this method without being rude or unprofessional?

/EDIT: Thank you all very much for your answers, even though I cannot apply most advices because of other issues at my company, this made me realize the complexity of the issues I am dealing with, with our corporate culture being one of the culprit. I divided the accepted answer reward and the bounty to two answers as I could not accept both.

Answer 1

Is this kind of implicit delegation of project responsibility common and normal? If not, how to avoid being the target of this method without being rude or unprofessional?

In my experience implicit delegation of responsibilities is prone to fail. Doesn't matter if it is a big or small company, if there is no clear delegation and project leads the development and design process becomes way slower and cumbersome.

I am also currently working on a small company/startup, and I have experienced those "mixed responsibilities" present also in your company. In the case of such companies, it is even more important to have clear roles and tasks delegated, so proper follow-up can be given to them.

So, regardless it is "normal" or not, it is a situation that should not be that way, and thus there are some things I can point out here:

• The next time you see this happening, speak out and ask for confirmation of the delegation. No need to be rude as you said, I would go with something like this:

  Sure thing boss. So, you want me to take full responsibility on this project from now on? I'll gladly do so. What should I do with [other tasks you have] in that case?

  This way you are (1) making it explicit if you are, or not, in charge of such project and (2) professionally asking what to do with the other tasks you already have so you can manage them properly and don't end up in a compromising situation.

• After making it clear who is now in charge, I suggest you make a paper trail of it, so everything is documented and you have evidence to backup any actions you make. After clarifying who is in charge and what is to be done with your other tasks, send an email explaining so:

  Hello everyone. As discussed with Boss, I will be in charge of this task, and will attempt to do [...]. Also, I will be putting on hold my other tasks as to fully commit to this task, and will resume then as soon as possible.

  This way there will be no doubts who is in charge of what, and no one will argue about why your other tasks are not progressing.

• Try to make all this on a regular basis. Not only you will be CYA, but hopefully this good practice will catch on your other coworkers and managers, possibly aiding your whole company with a better communication flow and clear responsibilities. Of course, this may take time, but as long as you do it this should mean no problem to you.

Answer 2

I think you need to raise this issue with management almost exactly as you have done here, but with more specific examples of implicit responsibility transfer. You should propose that each project has a specific owner and that there should be a system of record for identifying the owner of each project. Explain that this is needed for clarity and that this lack of clarity makes the workers reluctant to volunteer for small tasks.

As to whether it is common or normal, I will say that it's a pattern I've seen before. Although in those cases it was more a matter of different sections of code within a software product. The team got into this situation of "the last one who touched it owns it" naturally as the project aged, and the original implementors moved on leaving large sections of software "unowned".

Answer 3

"I would like to specifically address the problem of implicit delegation, as I think it lowers the productivity of the whole team including mine since we become wary of contributing any idea or solution.".

I guess if you hide in the back and never raise your hand or voice, you can hope to be forgotten, but that helps nothing and as you said encourages more of the same (increasing the problem).

Instead you can speak up.

Say you'll be happy to do "X" and "Y", but not "Z"; but only if you can unload "A", "B", and "C" into the job jar. If you can't unload "A", "B", and "C" then maybe you could do "Z" but only if you can unload "A" and "B" ...

It doesn't have to be a good idea to let you out of "A", "B", and "C", the management only has to either agree or understand the need to not have too much on your plate or speak when your mouth is full.

It sounds like there's too many "managers" and not enough employees, are they all partial owners? They need to manage better, like delegate explicitly and fairly, retain staff ($$$), and hire more employees to distribute the load.

Three less managers and four more employees would seem better, but obviously that's neither a change you are going to make or want to suggest.

Perhaps some Scheduling or Time Management software would help, try to assess load and 'time to delivery' - attempt to divide it evenly, and give a particularly difficult project to the talented managers (unless they are owners whom contribute money and little else).

Alternatively you could wedge yourself between the owners and the employees, you be the one whom delegates better and whom assesses progress and where work needs to be reapportioned.

Sometimes it's easy to see there's a problem, sometimes not.

Sometimes it's easy to speak up about a problem, sometimes not.

Sometimes it's easy to fix a problem, sometimes not.

If you can't do any of those three, preferably the first and third, nothing will change.

Answer 4

As usual with workplace related question, yours is actually a mix of questions and context.

If I were to break down your question, it would boil down to this:

1: Is it normal for small companies to assign workload arbitrarily and without proper tracking?

2: What can I do to avoid picking up tasks I don't like for whatever reason?

Having worked in similar environments as an executor, not a leader, I can summarize my answer to the question of "Is this normal?" to be "It depends."

Usually, if it "works", as in it produces desired results within a reasonable time frame, then don't try to fix it.

"Fixing" it might imply more work than it's worth and could bring you at odds with the "powers that be" in the company. If it doesn't or for some reason you are concerned with other parameters of the execution of the task that are not tracked, the solution I found was to add those extra parameters of concern to the Definition of Done. So for example if I'm concerned that a certain task must have unit tests, must properly merge and the resulting code must build into a working artifact, then add these requirements to the Acceptance Criteria of the story (or requirement) that generated the task.

A Continuous Integration framework could help you in formalizing these requirements in sets of automated checks you run on each commit for new tasks.

In regards to your second question: what can I do to avoid being tasked with arbitrary stuff I care very little about?

The solution I found was to always be busy with something.

In corporate speak, "be proactive".

What that meant for me is scouring the backlog daily for old or new defects, unfinished tasks or (god forbid) technical debt items that I could work on. Since I was a tester, there's never a shortage of testing tasks for me to perform (fixing tests, infrastructure, test environments, improving older tests, turning bugs into automated checks for regression purposes etc.)

No self-respecting manager would ask you to drop whatever you are doing if that thing adds value to her project and is more important than whatever bs task is next on the backlog.

Having a groomed backlog (where stories and defects are ordered by importance and impact) helps a lot with this.

So in conclusion:

Is it normal?

Not really, but if it's their way of writing software and it works for them, don't challenge it, unless you are ready to prove your point.

What can I do to avoid being the target of bs tasks?

Get busy of your own accord on important things.