How to Accelerate Your Staff+ Career through Open Source Engagement

It takes many factors for engineers to progress their career to a Staff+ position. In this article, you’ll find how contributing to and engaging with open source can help you sharpen critical Staff+ skills like writing communication while helping increase your visibility and the odds of landing in such a position.

Important Skills for Staff+ Engineers

All Staff+ engineers that I know somehow created their unique path to get and stay there, so it’s not easy to provide a list of important skills for such a role without a big deal of caution. However, it’s natural for us to try to find common patterns, and Will Larson’s book Staff Engineer and Tanya Reilly’s The Staff Engineer’s Path did great jobs capturing precisely those common aspects of the Staff+ role.

In summary, it’s expected that a Staff+ engineer plays a leadership role in contributing to the organization’s technical direction. Communication—primarily written communication—is a critical factor for that. So you’ll likely start writing more documents, like designs, strategy, and vision, than writing code.

It’s also referenced in the books listed above that Staff+ is still part of the technical track, so strong technical skills and some level of project management are also considered a must. But this is not a regular Senior progression (sometimes also referenced as “Senior Senior”). In this role, the scope of work is blurry and ambiguous, requiring big-picture and strategic thinking, execution experience, and positive influence.

Another critical aspect of the technical direction contribution is being vigilant and helping manage quality, balancing priorities of business needs while preserving the longer-term technical health.

Last but not least, one of the biggest challenges to execute at the Staff+ level is that you, as an individual contributor, usually don’t have the authority that engineer managers do. So you’ll have to exercise leadership to influence the organization without authority.

This article will cover how aspiring or current Staff+ engineers can sharpen some critical Staff+ skills with open-source engagement. But first, let’s get a better understanding of what open-source engagement means.

The Typical Open-Source Engagement Path

With more than 15+ years dedicated to open source, I had the opportunity to see many community members in different open-source communities grow their engagement over the years.

A typical path starts with a new community member asking beginner questions from a user’s perspective. Over time this community member starts asking more complex questions about best practices or performance tuning. At this stage, this member has the potential to transition from user to expert.

Identify experts in the open-source community as those who help others, provide answers and guidance for new users, engage in discussions, and provide examples. The key here is to be present! Be an active community member on the communication channels (Mailing Lists, IRC, Slack, Discord, etc.) asking questions and trying to help others with your own experiences and knowledge.

Another effective way to engage is by providing valuable feedback. For example, trying new features in a sandbox environment and bringing practical, real-world applications back to the community.

At some point, experts may get interested in contributing, and at first, a contributor won’t necessarily contribute with code. You can begin promoting that technology by writing blogs and articles, basically putting all your experiences in writing.

At this stage, some become interested in learning more internal details, and those are the ones who will begin exploring the codebase, up to the point that they send their first contribution (usually something small). Once they get their first accepted code contribution, many community members will continue this rewarding cycle by becoming active contributors. This is the stage at which engineers, including Staff+, will enhance their careers by contributing. 

It’s also important to highlight that most contributors will stay with the community at this stage, as the following steps will require more commitments. Usually, this is where you may shift your career to become a professional open-source developer.

Once a frequent code contributor, it’s not uncommon to become more involved and even become a module or component maintainer. Usually, this is a pivotal moment for the community contributor, where they may have the opportunity to grow to a leadership role and become an open-source module/component lead. Depending on the project, stepping into these roles may bring a lot of visibility and career opportunities.

Developing Writing—the Foundational Skill

By engaging in open source and contributing to that community, you can practice several relevant Staff+ skills, but writing is the most fundamental and foundational skill. Everyone can benefit from developing writing skills, and even if you already are a good writer, you can constantly improve.

When we talk about engineers, and more specifically the aspiring or already Staff+ engineers, they’ll need to write and review many documents; sometimes, they’ll be writing more documents than code. In that role, they shape their company’s technology, their expected impact is on the organization level, and writing is fundamental for communicating.

As already mentioned, you can start contributing by writing articles and blog posts. One excellent practical example is Mauricio Salatino, also known as Salaboy, who started blogging about open-source technologies around 2008. Salatino kept practicing his writing by blogging for many years until he began contributing with code and landed a job to maintain a very popular open-source project that he used to blog about. Today Salatino is a staff engineer at VMWare working on the KNative project, and he keeps actively blogging.

There are more opportunities to improve your writing beyond content creation. Interactions in dev mailing lists are also very effective in discussing and reviewing improvements or general changes proposed by open-source contributors. We can make a parallel between the dev mailing list interaction and the Request For Comments (RFCs) process that Staff+ are usually part of.

You can also provide good quality Requests for Enhancements (RFEs) using a structure similar to a design document. Actually, all interactions in open source will depend on your ability to communicate well in writing—thus, the reason writing is considered a foundational skill.

We’re also living in an almost post-pandemic world that was forced to work remotely. It’s hard to make predictions, but it looks like remote working may be here to stay. If this is the case, learning to work async is fundamental.

Async work is a paradigm shift from traditional office work environments where you have real-time access to stakeholders and can unblock issues as they come up with ad-hoc meetings or stop by a colleague’s desk for a quick question. Working asynchronously, you have to learn to work on your own and rely on offline communication channels like e-mail.In the case of messaging systems, don’t expect to receive a reply right away.

And we are connecting the dots here with open source. Open source is async and remote, and the most effective way to communicate async is by writing.

Recently, some companies started to add essays as part of their interview loop for senior engineers and managers, so a well-written communication skill may also help you land your next job!

Working and Improving Other Important Skills

Of course, there are other skills beyond writing that you can improve by engaging and contributing to open-source communities that you can undoubtedly relate to the Staff+ role.

By engaging and contributing to open source, you’re exposed to engineers from different backgrounds and cultures; it’s not unusual that you’ll interact with people around the globe. This alone will bring you different perspectives and other ways of solving problems. In addition, your code will be reviewed, and you’ll have the opportunity to receive feedback on your code submissions from a more diverse population.

Depending on the open-source community, you may interact with big industry players, and you can learn from them how they, together as a community, manage technical quality and innovation.

Last but not least is how to influence an open-source project direction. This is an interesting aspect for active contributors; you won’t have power or authority over any other member. You’ll need to read the virtual room, understand the community direction and propose changes that align with it. Then, and only over time, will your input become more relevant, and you’ll be able to have more space to drive changes you may want to have. Leading without authority is very familiar to Staff+ engineers.

Increasing Your Visibility

It’s not completely clear what exact set of skills and achievements companies expect from a Staff+ engineer, mainly because this is a role that requires a mix of technical and leadership skills. There’s also the fact that there are some aspects that you don’t have control over, like the right opportunity that will give you the visibility needed for the Staff+ role.

One way to bridge the gap between the “luck” to land the right opportunity and be more in control of your career path is to maximize your chances and exposure. An excellent option is to contribute to an open-source project that your company uses, even better if it’s a critical piece of an important project for your company. Nowadays, most data center infrastructure is based on open-source software, from the operating system to application frameworks. So it might not be that hard to find an open-source community that you can contribute to and positively impact the business.

One of the best examples I have of the visibility you may get by engaging and contributing to open source is from Tom Bentley, a senior principal software engineer at Red Hat. Bentley started contributing to Apache Kafka around mid 2017, but only after years of hard work did he finally become a committer. Reaching such a position is a huge achievement recognizing Bentley’s sustained contribution to that community. And to celebrate such an achievement, his manager sent an email to an internal Red Hat mailing list to congratulate him. Several congratulatory emails followed in the thread from all over the company, but one, in particular, came directly from Red Hat CEO Paul Cormier! You may not get an email from a CEO, but a well-aligned contribution to a piece of open source important for the business will undoubtedly help visibility.

Another common requirement to reach the Staff+ level is to deliver a Staff+ project. Usually, this is a complex project from the technology point of view and the impact on the business. 

However, projects like that are not that common, and you may not necessarily be assigned to one of those. But with the proper engagement and contribution, you can create your Staff+ project, by becoming a relevant contributor to a particular piece of open-source software critical to your business.

An advantage of this approach is that your Staff+ project is visible beyond your current employer’s environment.

Another career impact of a consistent open-source engagement is your network expansion. Depending on the project, you may create global connections with engineers across the industry. Such a network may also open new future opportunities. 

Conclusion

Although still part of the technical track, the Staff+ role is usually associated with leadership, which requires good communication. By contributing and engaging with open-source communities, you can improve essential skills, like writing communication, while increasing your visibility and the odds of landing such a role. You’ll also have the opportunity to sharpen other skills like managing technical quality and the art of influence without authority. 

Another significant advantage of getting involved in open source is interacting with people worldwide with different backgrounds and cultures, and expanding your diversity exposure and networking.