Open Source Engineering Manager: The Path to Success

Open source contributors come from all walks of life and take different paths in open source. There is, however, one very special breed of contributors: the full-time open source engineers. As brilliant as all open source engineers, they have the privilege to be paid for devoting all their talent to open source. That’s sweet, isn’t it? 😉

That very special breed of engineers requires a special breed of managers, open-minded in their own way: the open source engineering managers.

Yes, that is a true role. And yes, there are real people doing it. You are reading the words of one of them right now.

After more than a decade working with and leading the engineering team at a financial institution, maintaining the in-house legacy software systems, I felt like it was time for a change. I acted upon that nudge. I changed companies, industries and the software development methodology all at once and ended up as an open source engineering manager at a cloud computing technology company (that’s VMware, FYI!).

That’s a lot of change that one needs to adjust to pretty quickly. I needed to understand the concepts of open source, the compliance, the communities, the governance, the people, the technologies, the overall spirit. I started reading articles, watching conference talks, asking questions and listening to open source gurus. I was rushing through the Fear and Learn zones toward the Growth zone, completely losing sight of my Comfort zone.

But here I am today, three years later, already armed with knowledge and experience of my own, confident that I’m becoming a better open source engineering manager each day and willing to share my learnings with all of you out there who work with open source engineers. I hope these tidbits prepare you for some pull-your-hair-out manager topics or simply bring a smile to your face and remind you how lucky you are. 🙂

Here we go …

Strategy

There are so many game-changing and world-transforming things happening in open source and so many bright people to collaborate with and learn from. The temptation to be part of every huge and exciting innovation project looms large. Projects with the largest reach are inspiring, energizing and rewarding to work on for open source engineers!

But here comes the sad part (aka “the reality”): Open source engineers can’t be in 10 places at once. Time is often a limiting factor in the task completion equation.

If you want your team to truly succeed and make a meaningful impact, consider helping them focus. That means engineers have to choose between projects, because they simply can’t work on them all. The more aligned that choice is with the company strategy, the better.

Strategic alignment, however, might require a change in investments. Sometimes, just the open source project(s) folks are contributing, but other times the entire problem space is involved. Some engineers will embrace the opportunity to explore a new domain, eager to experience different technology and community challenges. That’s the easy part for managers!

Other engineers have a hard time letting go of old projects. That attachment can be a pain in the neck. Managers can either plant the passion seed to nurture a new appreciation for emerging projects or rustle up support that will keep the project on the OKRs board.

There is a third possible outcome. Managers should accept the fact that some folks are really into what they do and will always find their way to keep doing it. I truly envy those folks. Celebrate with them, find new talented additions to the team and make sure those engineers don’t get over-attached to projects and communities and are prepared to leave an open source relationship gracefully whenever needed.

Prioritizing

There is a prioritization anomaly you might run across. When you discuss priorities with open source engineers, everything seems important and urgent. That would make everything P0, right? But in their everyday execution, many tasks can usually wait. Thus the overall priority drops down to Px (out of X).

At first, that hurry-up behavior might strike you as contradictory. But if you think about it, you’ll see how logical this actually is. If it’s true that everything is P0, then it would also be true that everything is Px, wouldn’t it?

Don’t forget that prioritization is the process of deciding the relative importance or urgency of things. Have priorities, try to stick to them and review them regularly.

Planning

Simplify your understanding of a project plan and a roadmap and don’t get overexcited when you are presented with one. Usually it’s clear what direction engineers want to go but the road is often winding with lots of unknowns and not much (if any) visibility after the turn.

A plan is a non-exhaustive and not-yet-ordered list of things we might want or might need to do in the indefinite future.

There’s not much clarity here but don’t let perfection get in the way of innovation. Think short-term and run planning exercises often.

Deadlines

Do yourself a favor and bury the D-word deep inside your vocabulary. Open source engineers don’t like deadlines much, unless they have a conference talk accepted and they are presenting their work to the world. The stories are true of presenters fiddling with slides and demos even when mic’d up for the presentation. “Just one more thing …”

Instead of concrete deadlines, find other ways to maintain the healthy sense of urgency to keep projects moving. Most of the time, deadline setting is wishful thinking and sometimes there will be external factors that will get in the way of completing stuff on time or completing it at all.

Be patient. Even your excellent project management skills and execution discipline would bend under the weight of so many stakeholders running their own agendas. Regularly review and update the target dates (a target quarter or even half is far easier to digest for open source engineers and managers), reflecting any known external risk to completion. Know that it’s passion that drives engineers, but it’s the open source community where they work that often sets their so-called “deadlines.”

Performance and career growth

If performance feels a bit outside your control, let the open source project maintainers’ take care of that. As soon as the community is happy with the contributions, assume the engineers are doing well and so are you. Just wait for the next community shoutout. Trust me, it’ll get you no matter where the kudo came from and how.

Is this good-enough evidence that engineers are meeting expectations and could be promoted to the next level? That’s a different story that you’ll need to figure out yourself.

You have a number of options you can apply in various combinations. This is far from an exhaustive list, but here are a few ways to gauge performance:

• Trust engineers when they say they are ready to move to the next level
• Seek wider peer and community feedback
• Spend time reviewing GitHub commits and issue discussions
• Attend community meetings

Reviewing code and endless discussions on GitHub and attending community meetings might add a bit to your everyday managerial responsibilities and put your work-life balance to the test, especially if you are in an inconvenient time zone. Well, I don’t want to be the bearer of bad news here but you need to prioritize … just like you expect the engineers and everyone else to do!

Remote work

Due to the distributed nature of open source communities, open source engineers usually work from home. Folks on the team might be spread all over the world with hardly overlapping working hours. What keeps the healthy work-life balance in that setup are the excellent collaboration skills of the team and the strong sense of inclusiveness that unlocks the power of diversity.

Finale

Working with open source engineers comes with many challenges for the people manager to figure out, but it also presents inspiring opportunities to support those talented engineers’ growth, see them succeed at the things they are passionate about and contribute to innovations that change the world.

A big THANK YOU to each one of the wonderful open source engineers I have the privilege to work with: Anna Jung, Diana Atanasova, Enyinna Ochulor, Ivana Atanasova, John Hawley, Joshua Lock, Kairo de Araujo, Lubomir I. Ivanov, Martin Vrachev, Radoslav Dimitrov, Rose Judge, Teodora Sechkova, Tim Pepper and Tzvetomir Stoyanov.

Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.