Open choldgraf opened 2 years ago
I asked around about this in the Turing Way slack, folks shared these resources and thoughts:
I did a little bit of research and put together the beginnings of a role like this in the link below:
https://docs.google.com/document/d/1voDLLolN-2szln_KzdpNBH6aaobE8ajcjWYfv4c0DNk/edit?usp=sharing
There's still a lot to flesh out, but I would love any thoughts or comments for whether this is a good starting point.
@sgibson91 introduced me to @Arielle-Bennett - a Programme Manager with the Turing Institute. She graciously shared a lot of expertise with me about how project / team / program management works at Turing. Here are a few notes:
After discussing with a few others on the team, I think that we could benefit from having one of the team members serve in this role in the interrim, until we can find resources / capacity to dedicate a person to this.
I spoke with @damianavila and he said that he would be willing to serve in this role at a 50% capacity (and dedicate the other 50% to engineering). So let's try to get this role scoped out, and then we can pilot it with Damian.
@damianavila we are both assigned on this one, though this issue is sort of in a "steady state" right now. I think that there is nothing specifically actionable on this other than you serving in the PM role, and making iterative improvements as we learn more.
How should we handle this issue? Is there a way we can signal that it is "in the background" and maybe define a check-in date for it?
I was thinking about this one, alongside the leads-related issues... both are in progress but "Waiting" (using one of the states we already use in the cycle/sprint board). In the first case (this one), it is waiting for a downstream issue (#398), in the second case (leads), it is (maybe) waiting for feedback from the counterpart. I think creating a "Waiting" state + adding a check-in point is the way to go here... Let's do that and see how it works!
Background and proposal
Currently, our engineering team follows a fairly flat structure. We have a flat team with @choldgraf serving as an unofficial team lead / coordinator / manager. We also have a number of semi-automated processes to let one another know what we're up to, such as GitHub issues that transfer Support Steward status, or Slack messages that ping the team with open PRs.
However, this is not a scalable model, and we should explore ways that we can formalize team coordination and management so that it doesn't happen through informal processes. One way we can do this is by defining a "role" for team management that we can then decide how we want to fill.
Proposal
Define a "team coordinator" role for our engineering team. We should define it similar to how we'd hire for a position - define its responsibilities, the experience and qualities needed to excel in it, and metrics for success. We can then decide whether this role feels like a 100% appointment or not, and decide how we'd like to fill these responsibilities either from our current team or via a new hire.
Implementation guide and constraints
Resources about team, project, and service management
We can likely pull from a number of resources out there about managing teams and groups like ours. I'll collect links as I find them below.
Related issues
Updates and ongoing work