As soon as I learned that the Linux Foundation was setting up a speed networking & mentoring session at Open Source Summit North America in Los Angeles, I signed up as a career mentor.
Over the last few years, my day job has brought me to LinuxCon, Open Source Leadership Summit, Open Source Summit and many other gatherings and allowed me to interact first-hand with participants from across the globe and I thought that this could be one more way to contribute to the event beyond speaking, etc.
This is my report back to the community on my experience as a career mentor this year.
I had the opportunity to talk to four groups of people that included high school and college students and folks in different stages of their career across industries such as airspace, government, communications, etc. The Linux Foundation team had sent us a set of questions that were top of mind for the mentees (they ran a survey ahead of time), among them:
- How can I keep up with the latest technologies?
- I would rather plan my career instead of simply working to keep a job. How do I go about mapping out my plan?
- What sources of information do people in the industry read to learn about cloud business trends?
- What is your biggest regret in your career?
- How do you make a difference and gain respect even as a new employee?
- How do I get involved in Open Source documentation contributions?
- How can people without formal Linux work experience get hired for the first time?
- What qualities are sought after for open source technologies in industry?
Despite the fact that I was a career mentor, questions on open source community constantly came up and while I was happy to take those as well (the categories were career, technical and community and I have a decent background across all three) I think it was indicative that community involvement is becoming central to career development, at least in a set of roles in a set of industries and with a particular demographic. Such questions included:
- How do you successfully do Internal Open Source within a large software development organization?
- How can startups leverage open source projects?
- What could a salesperson do to earn clout in the open source community?
Instead of trying to type out what I answered to those questions here, I'd rather focus on the themes I saw from the mentees through their questions and discussion.
We knew this question was coming through the survey, but it was a theme across all groups. How can one establish rapport in the community through non-code contributions? I have to say that this resonated with me as I worked with Julia Liuson in her keynote which also talked about "open beyond the code". I think when it came to first-time contributions, embracing newbies and non-code contributions, my feedback always revolved around intent.
My position is that newcomers' experiences are defined by issues of form and substance. Most newcomers, like myself, worry mostly about the issues of form: am I going to do an IRC faux-pas, will they laugh at my rich-text e-mails, will I mess this bug report, etc. What has served me well here is to listen in. I join IRC channels, Telegram groups and mailing lists and lurk to figure out the "form".
The issues of substance are the ones that scare me the most, thinking systemically. We have our (more than) fair share of negative experiences rooted in issues of substance. Codes of conduct are a partial answer, but as we're living today, so are governance and many other things. And for newcomers, I think that intent goes a long way. In general, the community does not know why a newcomer is contributing to begin with and I think newcomers can make that clearer: I'm an expert in foo and I intend to work on this piece of code over the next period of time and would love your input and to collaborate. I'm a newcomer, give me some easy bug reports for me to get familiarizes with bar. I'm a technical writer, I will work on a separate branch on reimplementing some documentation to make it more accessible for non-English speakers, etc.
With intent, non-code contributions become more impactful than they look like when they first meet the eye. It's easier to get community support and establish rapport, and there are tons of great examples (many at Open Source Summit North America itself) of non-code contributions from design, documentation, speaking (making complicated things simple to understand to increase traction for a project), etc., that are both valued and necessary in modern open source projects.
A few of the mentees saw themselves as driving the open source vision inside their organizations, and were really focused on making sure they were effectively influencing others to do more. We talked about how the OSPOs, for example, are being called more and more to bring an informed viewpoint when it comes to strategic issues in the open source space, whether that's partnerships, viability of business models and technology trends.
I shared how I interact with my OSPO (I'm an open source strategist but not with the OSPO at Microsoft) and how we add value to each other. One example I gave the mentees was the work I do with open source market intelligence in the cloud and how that is a great way of not just bringing an informed viewpoint, but actually keeping up.
Unsurprisingly, there was plenty of appetite on strategies to keep up with changes in our industry. There are entire open source driven categories today, such as containers, where the landscape changes monthly. My perspective is that this is a fundamentally unfair problem, because of the natural day job/aspiration friction.
However, I also pointed out that we all got to be there in LA for Open Source Summit means that sometimes we put ourselves in a position where our day job supports the aspiration, and that those opportunities should never be given for granted and don't occur very often throughout a career. So there's an element of hustle there but at the same time focus and time management.
I try and put myself in the firehose splash zone, and start with a broad perspective of what's happening out there. One way I do that is by curating news from the open cloud in this RSS feed. And I have a set of core skills that I want to acquire over the next 18 months, and so set my attention bar so I can spend high-quality time acquiring those while also retaining my general perspective.
There's no easy answer - most of the mentees agreed they needed to adjust their expectations on how much they were going to learn by when as they progress in their careers. But they also agreed with the old adage: never stop learning.
When it comes to career, much of my experience is that of a contrarian. The main flaw I see in that is that valued coaches and mentors think that I don't value their input. I do, it's just that I see the flaws in them as well. Great examples of common (and valued) knowledge are:
- Less is more (normally in relation to writing, which as you can see is a losing battle with me)
- Throw fewer pebbles, make bigger ripples
- Where do you see yourself in 5 years
- No one wants a jack of all trades
I was surprised to see most of the groups bring the question of how to plan their careers to embrace the value they add as generalists. And that included a high school student who isn't even sure where do they see themselves in 5 minutes, let alone years.
To me, planning in early career stages is more a matter of what would you like to be doing, with whom and where. Unsurprisingly, this is what will help most people navigate opportunities nowadays, whether it's in the monthly Hacker News "Who's hiring" threads, or in places like AlphaGamma.
I had an amazing time with the mentees and learned a ton from their questions and reactions. Big kudos to Sarah Conway and the rest of the Linux Foundation and Open Source Summit North America team for making such a meaningful event happen this year, and of course for having me as a mentor. Looking forward to the ongoing discussion!
One thing to add - in at least two groups we discussed the role SRE has in transforming how sysadmins deliver value and are perceived. This is particularly true in organizations that are embracing with open source because in those organizations, non-tech decision makers are likely to be more exposed to the track record of disruption driven by Linux across many industries. Will update with more on this when I have access to a Markdown editor (I'm on vacation)