2

I have a technical background in software development and spent some time as a lead for a small team. Last year, I officially became a project manager in a much larger team whose work I am much less familiar with, and have less time to learn the technical details.

Sometimes when I am looking for information, a developer might tell me that the information I am looking for is in some folder buried inside the application or in a git repository, as if expecting me to go look for it there. I technically could spend the time and effort doing so, but that is no longer my responsibility and would take time away from my real responsibilities.

How do I tell them, politely but authoritatively and without sounding like "that's not my job," that I need them to provide me that information in an already-digested form?

  • 2
    So it's definitely their job to do your research for you? (it may well be, or it might take away from their real responsibilites). Also, bured in git? Is it the case that if you want to know about about Foo-ing and they point you to a comment in Foo.c that's too much for you? Really? – Nathan Cooper May 13 '16 at 17:30
  • Why are you assuming that my request could be answered by reading a single comment and no further context or domain knowledge? – Pedro May 13 '16 at 18:06
  • @Pedro Nathan might be assuming that because your question lacks some foundational context. I address this (rather exhaustively) in my answer below. Hope it helps! – Todd A. Jacobs May 14 '16 at 0:40
  • @NathanCooper The rudeness was simply uncalled for. I would have been happy to clarify if you had just asked without assuming the worst. – Pedro May 22 '16 at 11:12
3

TL;DR

You've framed your question as an interpersonal issue, with the presumption that it has to do with your delegated authority within your organizational framework. This is an assumption, which we'll talk about shortly.

Even if we accept the premise that this is an issue of your authority, it is not necessarily a personal or interpersonal issue. Since a project manager's scope of responsibility is to apply controls to a project, any failure to control for known issues within a project may affect the success of the project. It is therefore better to frame the issue in a project context rather than an interpersonal one.

Furthermore, project managers are often responsible for a project's process, and for managing communications within the project and among its processes. Those are generally areas that receive less attention than budget and schedule—and certainly less than politics and issues of positional authority.

With all of this in mind, I recommend that you inspect your project's processes and communications. If you find gaps or failures in either, you can then work with the project team to adapt them as needed.

Documenting Assumptions is Valuable

This question, as currently posted, is plagued with assumptions. It contains assumptions on your part, as well as forcing the reader to make assumptions about the roles, authority, and context of your situation. In the interests of answering the question as originally posted, I will therefore document some foundational assumptions to enable an answer. The assumptions are:

  1. You are making ad-hoc requests of developers which are not part of their currently assigned tasks.
  2. You have the authority to assign ad-hoc tasks within your project.
  3. The developers have a responsibility (however delegated) to respond to your requests.
  4. You are making your requests in socially, politcally, and organizationally appropriate ways.
  5. Your developers are giving you what they believe are contextually-appropriate answers, rather than saying RTFM or "up yours!"

If any of these assumptions are false, then the answer will be left as-is for future visitors, but you may need to revise your question to more accurately reflect your given circumstances.

How to Solve for Process and Communications Failures

Since we're assuming, a priori, that you genuinely need the information handed to you by the developers and that everyone is asking and answering in what they think are appropriate ways, then we are left with the presumption that there is a process or communications failure at work here. Let's look at both possibilities.

Process Failures

You are under time pressure to deliver something (e.g. a report or other project artifact) and therefore need something from the developers. However, unless this task was assigned in the standard way for your project, you are creating time pressure and schedule risk for the developers (and therefore the project) by asking them to:

  1. Task-switch.

    Task-switching can have a huge negative impact on cognitive flow in knowledge work. It isn't merely the time it takes to switch gears; this also involves cognitive disruption, and creates cognitive load as the knowledge worker shifts context to another task. As a one-off, this isn't a project-killer, but team capacity generally drops as task-switching and cognitive load increase.

  2. Shift capacity.

    Your requests essentially require that developers shift a portion of their available capacity from whatever they was working on, or whatever milestones were set for them at this stage of the project, towards something else. This has a direct cost to the project, as projects generally have finite capacity. This may also have knock-on effects if any dependent tasks are affected by a team member's reduced capacity.

    It doesn't take much reduction in team capacity to affect a schedule. As many organizations fall prey to the 100% utilization fallacy, it doesn't take much variance in individual or team capacity to throw a project out of tolerance. Even if your project schedule provides some slack, you need to consider how much impact these requests cumulatively have on the available slack, or whether the reduced capacity simply creates more pressure to meet deadlines despite insufficient slack.

  3. Perform invisible work.

    Since this request isn't part of the project schedule, and presumably isn't tracked as a project deliverable, you are asking the developer to switch from a visible task that he is held accountable for to an "invisible" task that won't be immediately visible to the stakeholders or his line manager. As these types of requests can add up quickly, you may be creating more "off the books" work than you think.

There is never an easy answer for process failures, as they are (by definition) systemic in nature. However, you may be able to inspect-and-adapt your process in one or more of the following ways:

  1. Bundle up requests to reduce task-switching overhead.
  2. Ensure documentation, reporting, and research tasks are accounted for within the project schedule. Slack is fine, but having explicit tasks on the project schedule for things you can plan for (like reports or documentation) is even better.
  3. Ensure you have sufficient slack in your capacity planning and your scheduling to account for unplanned/unscheduled tasks. Remember too that you need to add slack for the time it takes to get back on track when flow is broken, and not just budget for the tasks themselves.
  4. Ensure all requests are tracked by the project. CodeGnome's Law says: "No invisible work, ever!"

There may be other ways to fix the process, too. Discuss it with the developers, and see what you can work out!

Communications Failures

This is actually a much more complicated issue with many more variables than a potential process failure. However, we can roll most of it up into two key areas: context and transparency.

  1. Context

    You have a context regarding what you need, what the project needs, and what everyone's roles are. This may not be a shared context.

    In addition, the developers have a context as well. You may or may not understand the developers' context, or have a full understanding of what their perceptions and motivations are within your mutual context.

    You probably ought to discuss those things together.

  2. Transparency

    At a process level, you may lack visibility into what the developers are doing and what pressures they are under. The reverse is almost certainly true: developers rarely have insight into what project managers are doing, or the impact that anything has on the project outside their assigned responsibilities.

    From a communications standpoint, what's missing is transparency. You and the development team may need to communicate more effectively about pressures on the project as a whole, and about how those pressures affect the team. It may also help to have more transparency about the organization, including the chain of command and lines of delegated authority.

    The only way to improve transparency from a communications standpoint is to talk about things explicitly, rather than relying on shared context or assumed frames of reference. Perhaps you feel that you shouldn't have to haul certain things out in the open and talk about them, but unless you do they will remain opaque problems for all parties involved.

    So, talk about things. Together!

There are certainly other types of communications failures. Perhaps you will uncover some of them as you dig further. In the end, though, the solution will almost always start with talking more openly, and ensuring that issues are discussed in an explicitly-shared context.

3

Maybe you need to adjust the way you ask for information.

When you have no longer the time to do the fact-finding yourself, you have to delegate it. But you need to make sure you communicate this change clearly. Obviously people still think you can just grab data from the repository. Next time, make clear what you need:

Hey Bob, can you please prepare a short report about how the baring for our three main foos work concerning the new widget and send it to me by tomorrow morning? Thank you.

Oh and don't call people "resources". If you called me a "resource" I'd sent you a reply asking you to please go through my line manager for tasks. Be nice and you will meet nice people.

  • Agree, if you ask a 'quick' question you get a quick answer. Ask for somone to spend a day writing you a doc – Ewan May 15 '16 at 8:42
0

If you are the project manager and those resources report to you, then delegate the task and outline your expectations of what you need, how you want it, and when you want it, and if you're ignored, take action.

  • 3
    In what environments do developers report to project managers?? Project Managers manage projects, not people. At least in every place I've ever worked. – RubberDuck May 13 '16 at 18:52
  • Every project on which I have ever worked. If a PM does not have control over resources, including the human kind, then what exactly does managing a project mean? – David Espina May 13 '16 at 21:30
  • 1
    people are not resources... They're people. – RubberDuck May 13 '16 at 22:02
  • Human resources. Get used to it. – David Espina May 14 '16 at 0:03
  • Get used to what? I'm the one living in the present instead of the 90s. – RubberDuck May 14 '16 at 0:10
0

As a project manager you can delegate the job to your trusted team members. Please change your command and control approach to this problem. Show your servant leadership quality to your team members and support them in their day to day activities. It does not mean that you have to do their job. Explain the importance of the information you are looking for and gain the involvement of your team members

-1

If you're the one who needs the information, and the developers are already busy doing development, why is it their job to find the information for you? By saying "I think it's in this repo" they might be thinking that they're being helpful by pointing you in the right direction.

  • While your statement may be true, but it doesn't really answer the question the OP asked. Even if you think the OP asked the wrong question, you ought to suggest something more actionable as an answer. – Todd A. Jacobs May 14 '16 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.