Project Lead: role description

On Friday July 5th we gathered with current project leads to clarify the role and gather some feedback.
Participants: @dfelinto @filedescriptor @FoxGlove @Jeroen-Bakker @sergey @sybren @ThomasDinges

What is a project lead?

  • Who? A developer or product manager? Not necessarily

    • Anyone who has technical skills enough + organization skills
    • Also depends on size of the team
  • Responsible for coordination:

    • Make sure the scope remains clear and in line with what was agreed on
    • Assign tasks
    • Make sure team is aligned
    • Make decisions within the team on priorities
    • Responsible for process and methodology to work on project
    • Making sure that testing happens (regression, integration, users) > technically sound, original intent is met
  • Communication: leads and organizes meetings, workshops, blog posts, community chats (with the support of Development management)
    * Reporting to the Blender team and leadership
    * Escalating issues or questions outside of the project team, to leadership

  • Goal: make sure that stuff happens and that others know about it

  • Position:

    • Has a bird’s eye view: overview of goals, stakes, challenges
    • Has to be hands on: spend time on the project, not just a couple hours
  • When is a project lead involved on a project?

    • Ideally: as soon as possible
    • Can be from the start, idea and design > gets full ownership of the project
    • Can be once a design is made, to implement > risk of having to redo design

Comparing to module owner role:

  • Very similar but different point of view and goal
  • Module owners are usually at higher level view than project leads: longer term goals , more investigative
  • Project > temporary / Module > continuous
  • Is module work maintenance only, and anything else is a project?
    • Modules should give feedback on design of projects relating to their area
    • A project can happen to be done within a module, but it is still a project like others

Project work

  • Not depending on minimum length of the project or number of people on the team
    • Should have a clear deliverable
    • Can be done and led by 1 person
    • Should be feasible in a few months
    • Should have time planned for debug
      and have a period when project is given back to module, with some overlap to work on bug fixing in support

A project can be small: we should aim at keeping things as small as possible


Feedback and questions are welcome!
To discuss in next meeting: feedback and improvements for next project leads

12 Likes

Generally that project lead definition sounds reasonable to me.

Not really related to project lead topic, but since it’s mentioned here: Keeping projects small, and divided in small steps for bigger ones, is also indeed something we must aim at.
But then I think that it would be good to define how small can a project be (or in other words, what’s the difference between a task and a project). Does a project have to be done by a team? Or can there be (small!) projects lead and executed by a single dev (keeping aside things like design and code review)?

Those are valid questions, indeed.
Regarding how many people: currently, with the group here we consider that a project can be done by one person - this has to be an exception, well thought of. The Vulkan project done by Jeroen is an example.

Regarding how small, we could be more precise. For now, Sergey and I have considered that anything that lasts more than 3-4 weeks and adds visible value (for users or on the engineering level) is a project OR anything that lasts more than 3-4 weeks and is done in a team.
As in, a nice refactor that takes 5 weeks can be considered a task.

We can definitely discuss if a step is a project in itself or not, but I think that concrete cases will be more helpful. The goal being that:

  • projects are more structured and monitored > developers get more clarity and support
  • tasks should be kept small and ‘bite’ sized (one thing, that can’t be split)