开源日报 每天推荐一个 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/