It’s not easy to find, recruit and hire senior engineers in the software space. And it’s an expensive undertaking if you’re successful; senior engineers command high salaries. A more efficient and inclusive method of building your senior levels is to invest in the process of transforming a junior engineer into an excellent mid, then senior engineer. It’s a competitive advantage for any company. Unfortunately, if your company hasn't hired juniors before, you'll need to make changes in order to create an environment where they can thrive.
This will be a three-part blog series on developing junior engineers for organizational leaders who shape the culture of your company such as CTOs, engineering VPs, and team leaders. It comes from Kim Schlesinger, Site Reliability Engineer at Fairwinds. Prior to being an SRE, Kim was an Instructor, Web Developer, and Curriculum Designer for the Full-Stack Immersive Program at Galvanize, a code school based in Denver, Colorado. She is active in the Colorado Chapter of Leadership for Educational Equity and is the co-founder of diversity, a company that is striving to make the tech industry more equitable.
In 1982, back when code was something spy agencies trafficked in, two academics named Terrence Deal and Allan Kennedy set out to define corporate culture. Their definition was decidedly simple. Culture was “the way things get done around here.” Before you can develop your junior engineers you need to take a hard look at “how things get done around here.” Develop a culture in which you will provide them with personalized resources and ongoing support to help them grow into your mid and senior-level engineers.
The first thing that should be true about your company is a guarantee of 20% time for learning. Your new engineers are going to be engaged in a lot of learning when they start, since almost everything might be new, especially if they just earned a degree in computer science. You want to bring them into an engineering team where learning new skills is valued and time is set aside for learning during the workday.
The junior engineer should not be the odd one out learning new things on the job. At Fairwinds it’s built into our planning process. Every week our team leads get together, review the work from the past week and add eight hours a week for people to engage in learning time. We call it “Fairwinds” time. All team leads and our VP of engineering are very clued into this, they talk about it every week, they measure it, they analyze it, they make sure that it's true.
The second thing that you want to be true of your engineering organization before you bring on a junior engineer is to create a culture of error. A culture of error means that making mistakes and learning from them is a valued part of your team. You expect error and praise risk-taking. This idea is from a book called Teach Like A Champion by Doug Lamov. Engineering has a lot of this discipline, and it can be seen in something like a “blameless post mortem.” It’s a great way of creating a culture of error. When you examine something that's gone wrong, instead of pointing fingers and making someone feel ashamed, you examine the problem, learn from it and move forward. Engineers should be willing to feel vulnerable by admitting when they don't know something and asking for help. And your junior engineer should see this in action from day one, so they don't feel stupid when they have to ask questions.
Finally, emphasize the importance of engineering teams and not individual engineers. Back to Fairwinds, about two years ago, the company was structured very differently than it is now. At that time, it was basically a staff augmentation firm. So a company would come to us with a problem and we would say “great, here's one engineer that's going to work with you and your company for 365 days a year.” In this model, you need very senior highly skilled engineers, and someone like me who is brand new cannot be hired in this model. So over the last two years, the company has done an incredible job of transitioning from that staff augmentation model, to a team structure where teams work with multiple clients all at once.
As a junior engineer, it’s helpful to see that no one is siloed in their knowledge. Teams work on clients, not individuals. Because we have to share a lot of contexts, it forces a lot of communication. This team structure is beneficial for a lot of reasons. One: our team can survive when people go on vacation. One employee doesn't have all of the contexts of one client. Two: When you're constantly sharing that context, it's easy to bring in a junior engineer and explaining things to them, providing that context over and over because it's already part of your team culture.
Next Up: Let’s look at Day One for your junior engineer.
