Add section on teamwork #255
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| # Teamwork | ||
|
|
||
| If done well, working in a team can be more fun, more productive, and more effective. | ||
| There are both benefits and downsides of working in teams, | ||
| and the key is to work together in such a way that the advantages outweigh the disadvantages. | ||
|
|
||
| You can learn more about teamwork in [The Turing Way](https://deploy-preview-2239--the-turing-way.netlify.app/collaboration/new-community/new-community-teamwork.html#cl-new-community-teamwork). | ||
| Also checkout the [Teamwork for Research Software Development lesson](https://nlesc.github.io/teamwork-for-research-software-development/index.html) that we developed. | ||
|
|
||
| ## How we do teams at the Netherlands eScience Center | ||
|  | ||
| *Schematic overview of how teams operate at the Netherlands eScience Center* | ||
|
|
||
| There is not one fixed way of how teams operate at the center. | ||
| Even the definition of what a team is is flexible. | ||
| On one side there are formally defined teams in which engineers mostly work within the team and focus on a few projects. | ||
| On the other extreme a pair of two engineers that occasianally review each other's code can also already be called a team. | ||
| Checkout this [whitepaper](https://collegeville.github.io/CW21/WorkshopResources/WhitePapers/structured-unstructured-teams.pdf) | ||
| about the range of teams we have at the center. | ||
|
|
||
| Here are a few guidelines on working in teams (the above figure could help visualizing) | ||
| * Working in a team is optional. | ||
| * Teams are self-organizing, there is no boss. | ||
|
There was a problem hiding this comment. The second statement seems to contradict the first ;) If a team wants to self-organize around a boss (team lead), that is fine as well, no? There was a problem hiding this comment. You are right. This refers to an outside boss that tells the team what to do I think. There was a problem hiding this comment. I rephrased it to 'there is no boss external to the team that tells the team what to do'. There was a problem hiding this comment. Hmm, I think this may be more complex. If we allow an internal boss, then how does that work? If a lead engineer on a project is in a team and also has to report to a team boss, effectively the team boss becomes the lead engineer on that project, right? Does a team boss thus mean: the team agrees that the "team boss" engineer is lead engineer of all the projects? There was a problem hiding this comment. Indeed, something like that @ridderl. In practice, one person then handles most of the planning and external communication and the rest can focus on technical aspects. I think that's not an uncommon way of working in software teams in industry, for instance. As long as all team members agree this is the best way to go. If people's preferences change, they can self-reorganize 🙂 |
||
| * We aim for diverse teams. In terms of technical skills and seniority, but also gender, ethnic, and cultural diversity. | ||
|
There was a problem hiding this comment. Do we? I mean, do teams make an active effort to have a good gender balance? There was a problem hiding this comment. To my knowledge we don't look at gender, ethnic, and cultural diversity at all (but maybe we do?). But I hope this addition can at least make people aware. We should look at it! And in team flow we have a reasonably diverse group of people (who am I to say as a heteronormative white young man..) and I am quite happy with that. There was a problem hiding this comment. Yes, I agree team diversity is definitely important, and raising awareness around it is a great step to actually making it so. I'm just thinking about how to word it best, because we should consider diversity, but do not have any mechanisms to enforce it. Suggestion: "Teams should consider diversity in terms of technical skills and seniority but also gender, ethnicity, and cultural diversity. A more diverse team is better equipped to consider different perspectives." There was a problem hiding this comment. I would shorten @c-martinez's suggestion to something like: "Teams should consider diversity in terms of technical skills, seniority and perspectives." I am all for diversity (of any kind: academic background, ideological, geographical, socio-economical, etc. etc. as well as the already mentioned gender, ethnic and cultural kinds, also age and sex btw, disabilities that are relevant to the digital world like dyslexia, color blindness and hearing disabilities, neurodiversity, etc etc etc) for that exact reason of diverse perspectives. I'm not so keen on focusing on politically charged intersectional aspects only, as they may alienate people as well. I do also think it's good to keep in mind that we cannot be too picky, since we only have about 50 engineers to form teams with (most of whom will already be "taken"), so most of the task of increasing diversity should be done at the hiring level. There was a problem hiding this comment. Again, I don't want to over engineer this :) But I appreciate your thoughts! I made it "Teams should consider diversity in terms of technical skills, seniority and perspectives (for example gender, age, ethnic group)". |
||
| * Teams are responsible for entire projects from start to finish. | ||
| * Teams are responsible for their own planning. | ||
| * Most engineers in the team are Lead Engineer on at least one project. | ||
egpbos marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * The team is in close contact with the relevant Programme Manager(s) and Tech Lead(s). | ||
|
There was a problem hiding this comment. This is sort of assuming that people have the new structure document under their pillow. I don't want to explain that. But if it helps I can add something like:
But even this is incomplete I think. Also the Tech Lead role in relation to the team is something that is intended in the new structure I think, but is currently not put in practice in all teams (at least as far as I know) There was a problem hiding this comment. Yeah, I agree it intuitively makes sense (except that I would say the Lead RSE is mostly in contact with the PM, but details). I was more wondering why it has to be in here, it's not really concrete and at the same time quite obvious, so doesn't add much imho. So indeed, "I don't want to explain that" would be my approach here :) There was a problem hiding this comment. OK, I just removed it. Maybe this is more something for the guide page on the new structure ;) There was a problem hiding this comment. Most of these are a direct outcome of all the restructuring discussions, and finally ended up as a DT decision to "make it so" ;-). I think it is good if the guide reflects that outcome. There was a problem hiding this comment. I'm not sure if the team should be in contact with the PM/TLs though. That's more a task for the Lead engineer of a project. There was a problem hiding this comment. I'm sure there must be an "official" document (documents?) with detailed information on the new structure. I guess pointing to those would solve the problem. (I just don't know where to find them ;-)) |
||
| * The team has a dedicated Section Head that serves as a coach, escalation point, and final authority in team composition. | ||
| * Usually the team members commit most of the time to projects within the team. | ||
| * Engineers that are not part of the team can act as 'consultant' for the team. A consultant can for example bring in some expertise that the team does not have. | ||
| It is useful to have someone in the team who has the role of team coach. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess linking to deploy preview is only a temporary solution, and we should link to the guide chapter once the corresponding PR gets merged. The risk is that we forget...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, see the description of the PR. If this PR is merged earlier than the Turing Way one (which is quite likely) I will make it my personal mission to not forget (and create an issue for it of course).