6

In practical terms, how do you suggest that a technical lead (me) work with a non-technical PM who is responsible for multiple projects? How should dependencies between stories, and external dependencies, be identified, discussed, planned for, scheduled and resolved? What should the division of responsibility be between me and the non-technical PM?

A non-technical PM cannot identify certain dependencies because they have no idea that they exist. Hence my question.

We are not using Scrum of Scrums (indeed we are not using full Scrum), but we are using an issue tracking system (specifically, Jira).

Improve this question

3 Answers 3

Reset to default
7

Firstly, you could use different methods/frameworks to run projects. Scrum wouldn't necessarily be the solution here as your prime concern is around the line in responsibilities between these two, both different and both required, roles. As well as getting the right level of communication set up.

I have grasped something from the tone of your question that seems to highlight already a problem. In your question you say:

A non-technical PM cannot identify certain dependencies because they have no idea that they exist. Hence my question.

On this note I would strongly recommend you start removing the 'non-technical' attribute to the role. That's not the real problem. The role of the PM is not to work out the technical dependencies by himself/herself but to manage them with the support and expertise of the team involved. If you are the Technical Lead, that's what you are there for. You have the best detailed information about the technical aspects of the project and understand better the dependencies.

Coming back to the separation of duties you could refer to Project Management and Delivery frameworks like DSDM Atern. If you take a look at the DSDM Atern Roles and Responsibilities diagram below you can appreciate that the Project Manager (blue) and Technical Coordinator (green) roles work together towards delivering business value (working along side with Business Sponsor and Visionary).

enter image description here

Some of the responsibilities of the Project Manager in this model would be:

  • Communicating with senior management and the project governance authorities (Business Sponsor, project board, steering committee, etc.) with the frequency and formality that they deem necessary
  • High-level project planning and scheduling, but not detailed task planning
  • Monitoring progress against the baselined project plans
  • Managing risk and any issues as they arise, escalating to senior
    business or technical roles as required
  • Managing the overall configuration of the project Motivating the teams to meet their objectives
  • Managing business involvement within the Solution Development Teams
  • Resourcing Specialist Roles as required Handling problems escalated from the Solution Development Teams
  • Coaching the Solution Development Teams when handling difficult situations

While for the Technical Coordinator:

  • Agreeing and controlling the technical architecture
  • Determining the technical environments
  • Advising on and co-ordinating each team’s technical activities
  • Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate
  • Ensuring the non-functional requirements are achievable and subsequently met
  • Ensuring adherence to appropriate standards of technical best practice
  • Controlling the technical configuration of the solution
  • Managing technical aspects of the transition of the solution into live use
  • Resolving technical differences between technical team members

The combination of the two roles is really powerful and usually leads to project success.

Now, we need to address the communication problem.

I always say to people they need to stop waiting for things to happen and point the finger later if things didn't work out the way they expected. This behaviour helps nobody.

If the Project Manager in your team has not come forward to work with you on how regularly you guys should meet or the tools to report please feel more than empowered to start that conversation yourself.

You mentioned that you are already using Jira so maybe you two could sit together a couple of hours to determine the best way to use the functionality to capture technical dependencies - linking issues from different projects back to a "Dependencies" project list- report status, and advise whether there is a team already looking at the issue, etc...

I have personally used Jira with GreenHopper for similar reports and it has worked very well.

Improve this answer
3

I understand that the situation are:

  1. You are a technical lead (TL),
  2. You report to a PM that has no or almost no domain knowledge, technical knowledge.
  3. The PM does not understand you.

"A non-technical PM cannot identify certain dependencies because they have no idea that they exist.": He doesn't have to. I think it is your main responsibility to explain the issues so that he can understand.

If I were you, I will talk in the language that the PM can understand and agree with me.

Talk directly to the PM and define a clear RACI matrix will be good idea.

The main point for the RACI matrix here could be: 1. The Tech lead manages and reports technical issue, alert possible non-technical issue he can sense 2. The PM manage all the non-technical aspects of the project, such as: HR, requirements, risks, communications, budget...

You may google for

  • "technical lead" "project manager" RACI

to see how a TL and a PM are different.

Improve this answer
3

To be blatantly honest, if your project has a non-technical project manager who is not very strong on the business logic or functional aspects of the project and is also involved with other projects, his involvement in the project should be no larger than that of managerial tasks – which is a nicer way of saying – "Getting the crap out of your team’s way and letting you and the development team focus on actual work".

He could:

  1. Attend never ending business meetings and brief the development team and you about the relevant stuff in 5 minutes thus freeing the team (and you) to focus on doing real developmental work.
  2. Help maintain time-sheets and project plans and update these meticulous so that the rest of the team doesn't have to file TPS reports. :)
  3. Do all other non-technical documentation that no-one in the team is interested in doing.
  4. Catch up with you and the team informally and help the team get what they need to do their work (servers, licenses, hardware, pizzas, coffee etc.)
  5. Promote the team and the work that the team is doing to rest of the business. Positive vibes and perceptions about the project and team go a long way in making the project successful. Story-Tellers are just as important as Builders.

With managers who are non-technical or playing a non-technical role, the best ones know how to get out of team’s way, keep problems out of the way of the team, show empathy, create a positive vibe and perception about the project and the team, get the team what they need to get their work done (servers, licenses etc.) and allow the development teams do the real work with undivided focus.

As Steve Yegge describes in his legendary yet controversial post, any other attempt by non-technical managers to manage programmers can be dangerous.

If you didn't click on the link above this: http://steve-yegge.blogspot.in/2006/05/not-managing-software-developers.html is a must read.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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