Mentoring Engineers Through An Engineering Fellowship Program

For two years, I’ve managed the Infrastructure Engineering (“Infra”) team at DigitalOcean. We’re responsible for managing all servers and machines up to the application layer. This includes hardware spec, firmware, component validation, base OS, configuration management, and hardware management (hardware management database).

In addition to my core responsibilities managing the Infra team, I wanted to foster an environment where mentorship was possible and worked with colleagues to create the Infrastructure Engineering Fellowship Program. It’s an immersive program where DigitalOcean employees from other teams “join” the Infra team for two weeks. Employees with fundamental Linux knowledge and some configuration management experience are eligible to participate.

“Fellows”—as they are known—are invited to a private Slack channel with fellowship alum. They work through JIRA tickets assigned to the team (all while pairing with Infra team engineers), attend team stand-ups, and finally, pick a project to work on for the two week duration. Additionally, fellows meet with me at the start and end of each week to discuss what they worked on and to answer questions they have. To date, we’ve had nine people complete the fellowship and we continue to open the fellowship up to other engineers at DO.

How the Fellowship Started

This program started as a cross-team training experience between my team and the Tier-2 Cloud Operations team (the 24/7 team responsible for uptime on our servers and services), since both of our teams interacted with each other on a daily basis. After a few successful trials with the Cloud Operations team, we realized that there were several other teams that were interested in learning what we do and wanted to take advantage of the fellowship program. We have now had people from five different teams sign up and participate in the program.

My team gets so much more out of the fellowship than we put in. First, we build comradery between the wider organization and my team. Individuals we only worked with through JIRA and Slack now have a personal relationship with the team and are more eager to engage and work with us. My team gains a better perspective of what other teams go through and work on a daily basis which helps us build better tools and workflows to support them. Finally, it is a great way to recruit. Engineers that have been hired for my team came through the fellowship program.

Growing people internally is one of the greatest things I have done with my career. I have had three people join my team from inside the company and have been very successful in their new roles. In a perfect world, we would pair every senior engineer on the team with one engineer still early in their career. In my experience, when looking at the “Tuckman’s stages of group development” you will have the best performing team when you have mentors and mentees going through the four stages together as a team:

Tuckman’s stages of group development. Photo credit: Tutorials Point

Managing the Fellowship Program

One of the things that we keep top of mind is sustainability. Although two weeks isn’t very long, properly mentoring someone takes a lot of time, and we want to make sure no one feels overwhelmed by the experience. We currently take on just one fellow at a time, and we cater the program to each participant. For example, if a fellow is more interested in hardware than big data, they might pair with our integration team who is charged with managing hardware and firmware, rather than our DevOps-focused team.

There are a few benefits of managing the fellowship this way. One, we can iterate quickly since the program lasts just two weeks. And two, we can focus our energies on mentoring just one person at a time to limit straining the team’s bandwidth. Based on feedback from past fellows, we’ve changed how we handle our 1:1s with engineers and code pairing sessions. We now conduct 1:1s with specific goals in mind. Each fellow is asked to give feedback at the very end of the program to help us guide future fellows.

That said, the same benefits are in some ways ongoing challenges. Working with each fellow individually takes up my time, but it also affects the engineers on my team. They need to take time out of their busy schedules to pair with the fellow by breaking their usual workflow and compelling them to walk through projects step by step. This means something that may take them an hour ends up taking most of a day.

That said, we’re able to make this work because we work on a number of tasks and projects at any given time. If a team is working on one long-term project, the time it takes to explain the project to someone won’t actually yield any benefit in a two-week long program. The fellowship program (and programs like it) really need to be catered to the participant and the team that they are embedding with.

What Makes It Worthwhile

As I pointed out earlier, pairing engineers with more senior engineers leads to better performing teams. Furthermore, there is an even stronger connection when you pair engineers that have proprietary or historical knowledge from inside the company. I am a firm believer that if strong minded, eager-to-learn engineers exist within the company, you shouldn’t hire from outside the company. Creating infrastructure that supports mentorship leads to strong engineers, strong teams, and a strong company.

I love seeing people continue to have conversations and work on projects with my team after the fellowship is over. It is simply amazing to see, and I give all the credit to the engineers on my team. Every one of them is eager to pass on knowledge that they have, and they’ve embraced the fellowship and its goals. The fellowship wouldn’t have been successful if my team didn’t share the same beliefs around mentorship and its cross-team benefits that I have.

Future of the Fellowship

When I started my career in IT, I had an amazing mentor (shout out to Rob Lahnemann) who really took me under his wing and taught me everything he could about programming, Linux, and networking. My manager at the time (shout out to Eric Austin) set this up and put me in a place to succeed as a mentee. This experience really influenced what I believe it means to be a good manager. Pairing engineers eager to learn with senior engineers is huge key factor in any successful team. In the current engineering community, it is not uncommon to find engineers who are not influenced to share their knowledge or are not given the time to be a mentor. But in my opinion, growing as an engineer means being a mentor.

In the future, I would love to see the program more of a revolving door of people doing more work with the Infrastructure Engineering team and doing the fellowship program multiple times (hopefully sometimes for longer than two weeks). I also would love to influence programs like this more often inside DigitalOcean and outside DigitalOcean. One of my biggest goals and drivers in writing this is to influence similar programs in the industry as a whole. My career and pace of growth was directly influenced by a strong mentor, so my passion here for influencing more mentor/mentee relations in the industry is high.

Tom Spiegelman is an Infrastructure Engineering Manager at DigitalOcean. He has an awesome dog, a great team, and is married to the amazing Chantal Spiegelman. He is passionate about all things tech, specifically infrastructure. You can find him on LinkedIn or on Twitter.