Learning is both a personal and a career opportunity: a lifelong skill that helps us navigate challenges, work more effectively and become better developers. Commit’s Sarah Marion sat down with Bethany Foote, head of infrastructure engineering at Outschool, to talk about the challenges of building a learner’s mindset, both as an individual and within a company culture, as well as how new executives can become better learners. See the first post here and third post here.
On helping teams learn
Sarah: When we talk about creating opportunities for developers to learn, people’s minds almost always jump to learning a new language or building a new product. But many mid-stage startups also get to a point where they have a legacy codebase that they need to maintain alongside a newer, shinier one. I’m curious how you approach developers who are working on that less-loved codebase, and how you create opportunities for them to feel like they’re still growing and learning.
Bethany: If you have a legacy team and a new team, it’s important that the legacy team doesn’t get pigeonholed to the point where they don’t have an opportunity to learn the new technology. There’s always an understanding that eventually you’ll move away from legacy technology and thus away from their work. They’re not seeing a future there, and it’s hard to keep people engaged if they don’t see a future. Giving people the opportunity to help transition and learn as they go gives them the opportunity to acquire new knowledge.
At another company I worked for we had an old product and a new product. The old product was 35 years old and built with C++, and the new product was React. The codebases were nothing alike. I needed somebody to build some web services for me, so I asked one of the engineers on the legacy codebase to help, and picked a language that would be relatively easy for him to transition to: Java. He struggled with it initially, but then he had a really satisfying breakthrough.
A few months later we had a similar opportunity to build out a new API and integrate the legacy system with a third-party application. He and another engineer from the legacy team built that out, and it’s now a bridge for them to start working in other systems. So starting to transition the technology and provide opportunities in this way really works well.
Another thing I’d recommend: If you’re going to have two separate teams, it benefits the team working on the new stuff to actually go and do a couple sprints on the legacy team. Learn the history, learn the struggles, learn why stuff was built that way in the first place, because there’s a lot of domain knowledge and history that they may not be aware of that’s really important to bring into the new product. Doing this also promotes understanding and relationships between the two teams.
Similarly, where possible, have the legacy engineers visit the frontend engineers for a couple sprints to learn new skills, so when the transition happens they’re pre-trained and can transition into the new work environment.
Sarah: Speaking of pigeonholing, a pitfall I sometimes see with new managers is that they’ll identify where their employees shine and give them lots of space to do it, and suddenly those employees become pigeonholed in one particular area rather than broadening out of it. I’m curious about your experience as a manager and how you recognize when your team’s growth is plateauing because you’re rewarding the things they’re really good at.
Bethany: If you have a single person who’s a subject matter expert, that can be very risky, especially in small organizations. You want to have at least two. People might cringe at this analogy, but if that person got hit by a bus, what would you do? Do you have a backup? For your own team’s sanity, have at least two people who can do any one thing.
The other thing to realize is that most people get bored after a while. Once you’ve mastered your subject, you usually start looking for something new. That can be a great opportunity for someone to grow by training somebody else. When that experienced person gives their knowledge away, now they can do something else, and you’ve potentially increased the capacity of your team.
The other thing is to take time and make room for people. Don’t just go, “They’re super fast, they’re the best at it, so they should do this because we need to get it done quickly.” Don’t schedule everything for the last minute so that single, super-skilled person has to take responsibility for everything. Build time into your schedule so they can train other people.
The last thing is to realize that when people are pigeonholed, they can become frustrated. If they don’t feel they can progress within your organization, they will leave. If you don’t want that to happen, you have to make an effort to give them new opportunities.
# # #
Bethany Foote is the head of Infrastructure Engineering at Outschool. Her extensive experience in tech includes cloud SAAS products, enterprise applications, mission-critical space systems, and more.
Sarah Marion leads Startup Partnerships at Commit. She’s spent her career collaborating with early stage founders as they solve valuable problems.