開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《Rainbow-Fart-MBG》
今日推薦英文原文:《Team Contributors — Because There』s No 「I」 in Team》

今日推薦開源項目:《Rainbow-Fart-MBG》傳送門:項目鏈接
推薦理由:馬老師早已血洗鬼畜區,現在甚至上了 github 的 Trending 項目,看來是有備而來啊~
今日推薦英文原文:《Team Contributors — Because There』s No 「I」 in Team》作者:Nick Gibbon
原文鏈接:https://medium.com/better-programming/team-contributors-because-theres-no-i-in-team-31afd0a6ec81
推薦理由:即使是 MVP 也難以一打五。

Team Contributors — Because There』s No 「I」 in Team

Team Contributor is a better label than Individual Contributor for members of your team

I didn』t come up with this notion, but I think it』s the correct way of looking at things and worth elaborating on a little. I can attribute it to John Cutler via LinkedIn:
(John Cutler — Team Contributor — LinkedIn)

Individual Contributors

Individual Contributor is the term that is widely used to refer to a member of an organisation who is not on the management track. And so it follows that they will have more time throughout their career to dedicate to their craft and specialising in whatever domain they work in. Design, engineering, and product people come to mind for me, but the definition is really broad. I will be using engineering as a reference point throughout this article because it』s what I understand most.

The fact that Individual Contributors are a thing is great. It indicates that there is acceptance that these types of people are really valuable and that they should also have a realistic path to leadership roles in an organisation. Awesome.

The term isn』t bad — it can just be improved. By emphasising the individual, this term differentiates these contributors based on what they don』t do instead of what they do do! Team Contributor puts a more positive spin on this, as it tells everyone what they are doing and doesn』t define them as just being not-a-manager.

In reality, all Senior TCs will have various degrees of 「management」 responsibility, but it will be as a consequence of trying to achieve something — not their primary function. Considering exactly what this should look like is an interesting exercise, but we won』t go through that right now.

Teams

Technology ICs work in teams. In my career, I have always been part of a team working towards some goals in some form or another. That』s about nine teams so far because that』s just how it works.

I fear that the Individual Contributor moniker may provide the impression that vagabond engineers roam around inside organisations doing what they want. Or they work nomadically on a different project each day depending on which manager manages to flag them down. I』m sure some of you will have an experience like this, but it』s obviously not a good thing.

There』s consulting, personal projects, the gig economy, contributions to open source, and other internal projects where you aren』t part of the core team, but 99% of paid engineering work is completely team-based. And so it should be!

It』s become more and more evident that sustainable success comes from relatively small, product-oriented, long-lived, cross-functional teams with clear areas of focus, domains of responsibility, and communication channels who create, operate, and iterate.

I also feel that the IC term may further the stereotype of IT being a closed-off discipline when it is in fact hyper-collaborative. It takes different types of people with different skills to make a software product successful. There are so many different stakeholders and interests that you need to balance and reckon with. At every level, there is consensus-building and compromise, and it is all driven through inter-/intra-communication and collaboration techniques.

You need to work out what to do, how to do it, when to do it, and coordinate this across everyone involved. Taking complex things and breaking them down so they can be worked on and brought together precisely to integrate and achieve the desired outcome. Yes, there are periods where you need deep thought and minimal interruptions, but a lot of the work really is people work.

Teamwork is very much baked into a technologist』s career progression. One of the key identifiers of a Senior Engineer is the ability to help make other Senior Engineers. Of course, technical skills and domain knowledge are a major component, but so are mentoring and helping people out. If you read through day-in-the-life articles by staff and Principal Engineers, they — without fail — focus on teamwork as a theme:

What a Senior Staff Software Engineer Actually Does
What does Staff level mean at GitLab?

In fact — inside an organisation at least — if one person (no matter how great they are) is working on something for too long on their own, it is an anti-pattern. Person dependency is always a risk, so it』s really important to make sure your team understands what you are doing and to regularly demonstrate and knowledge-share within your team and more widely for other stakeholders.

Conclusion

I have explained why I think Team Contributor is a better term because of what it emphasises and conveys and what it doesn』t. But I also think it looks and sounds better too. Individual is a longer word with a high syllable-to-letter ratio. Team Contributor/TC feels nicer and snappier than Individual Contributor/IC. This may just be personal taste, but I don』t think it』s an insignificant thing. The sound of a word or a term is (probably) a pretty important factor in its adoption.

I intend to use the TC term as the opportunities arise in conversations and I encourage others to do the same. Hopefully, this can help nudge the industry』s vernacular in a better direction.


下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/