-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add section on teamwork #255
Conversation
best_practices/teamwork.md
Outdated
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super!
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🙂
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.
best_practices/teamwork.md
Outdated
* Teams are self-organizing, there is no boss. | ||
* We aim for diverse teams. In terms of technical skills and seniority, but also gender, ethnic, and cultural diversity. | ||
* Most engineers in the team are Lead Engineer on at least one project. | ||
* The team is in close contact with the relevant Programme Manager(s) and Tech Lead(s). |
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.
Why?
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.
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:
- 'Teams are in close contact with the relevant Programme Manager(s) as they are responsible for the projects executed by the team.'
- 'Teams are in close contact with the Tech Lead(s) so the technological quality of the team deliveries is ensured'
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ;-))
Thanks for your useful comments @egpbos! 🙏 Who else has an opinion about this? @c-martinez? @yifatdzigan (I have the feeling you presented a part of this at the section heidag, but I am not sure)? |
Indeed @svenvanderburg, I also recognized those lines from somewhere 😄 |
best_practices/teamwork.md
Outdated
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). |
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).
best_practices/teamwork.md
Outdated
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. | ||
* 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we? I mean, do teams make an active effort to have a good gender balance?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)".
Looks like a great start @svenvanderburg ! I guess section heads, programme managers & tech leads might have some input in light of the restructuring, like you and @egpbos already discuss in the comments. So apart from @yifatdzigan , maybe you can ask for representatives of the other groups to comment? |
Thank you for your comments @c-martinez 🙏 In my opinion I don't think the whole management layer should give their opinion on adding something to the guide. But it would be good to not let this depend on the availability of @yifatdzigan, I think also @ridderl, @jmaassen, and @nielsdrost also presented something at the heidag. If one of you could review if this matches the ideas about teams of 'the management layer' 😋 (and please if you think this is an improvement over what is currently in the guide give an 'approving review') |
|
||
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 outside of the team that tells the team what to do. |
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.
* Teams are self-organizing, there is no boss outside of the team that tells the team what to do. | |
* Teams are self-organizing, there is no boss inside or outside of the team that tells the team what to do. |
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.
Team have no boss inside the team as well ;-)
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.
@nielsdrost thanks for your suggestion. This already has an ongoing discussion here: #255 (comment) I think this sentence covers the consensus from that discussion. I hope you agree?
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 think Niels' formulation makes sense too in a formal sense, because everyone can just decide to leave a team and hence there is no boss. Maybe mentioning the boss at all complicates things unnecessarily for the Guide? Just "Teams are self-organizing." could also suffice. The complete formal definition could be relegated to some internal document. I'm fine with either choice, just my 2cts.
It seems like no one really feels the ownership to approve this pull request, @egpbos or @c-martinez maybe you could approve (and merge) this since you have reviewed it most thoroughly (or at least left the most comments that is of course not entirely the same). |
@svenvanderburg there does still seem to be some controversy. I'm fine with merging now and changing later when someone feels that's necessary, though. |
That was my suggestion to @svenvanderburg. You know what they say about great minds @egpbos (it seems to also apply in our case ;-) ) I've approved this issue, we can add a link later on if/when there is an "official" reference to the structure. |
Yeah! 😄 Thanks @egpbos and @c-martinez for your action 🙏 Indeed let's update this somewhere down the road! |
Below, describe what this Pull Request adds:
Still todo: