Toward a Better Model of Learning and Teaching — Part 3: Results & Lessons

In parts one and two of this series, we talked about the impetus for creating a Culture of Learning at Enova. We also covered some of the mindset changes that were necessary to get there. We’re only a short time into the experiment, but we’ve already seen some solid results, and I wanted to take a moment to reflect on them.

Focus Hard on Onboarding

At a competitive company, project pressure never goes away. In the past, when we’ve experimented with mixing project and learning work, deadlines have almost always edged out professional development. I don’t think this is something that we can easily change.

So, rather than trying to fight the tide, we’ve assigned new hires 100% to training until they reach a critical threshold of skills. Though we know that some other companies focus on pushing to production on the first day, we find that the differences in quality more than make up for the difference. This approach also allows the new hires additional time to shore up their weak areas.

Typically this period of time is around six weeks, which is actually somewhat stressful for new hires. They want to contribute immediately, and we’re explicitly not allowing that. Most new hires understand the need for the delay, but we’ve also worked to manage frustration as it arises. A few things that we’ve seen work:

1. Pairing with another experienced developer on production work in a limited capacity. The trainee is still not deadline driven.
2. Continuing work on (or bending training towards) an external side project or open source library the new hire has been working on.
3. Sitting in on code reviews and team planning activities for established teams.
4. Contributing back to the codebase we use to train new hires.

All of these strategies help give a sense of productivity to a developer who isn’t yet ready to take on production deadlines. Obviously we go with whatever each situation warrants. I believe in other industries this is simply known as “management”.

Don’t Try to Teach Everything

I’m an engineer, not a teacher. I spend a few days every week programming. So I’m relieved that others have done such a fantastic job of creating training materials. Rather than trying to build our own materials and tutorials (something we’ve done poorly in the past), we now leverage all the wisdom and effort of the internet instead.

The most productive use of time, I’ve found, is finding the best resources for various styles of learning and providing as much exposure to them as possible. When trainees go astray or struggle too much, we have plenty of resources to get them back on the path.

Contrariwise, there are still places where it helps to teach. Our stack — like everyone else’s — is short on documentation in some places. Resources on the internet are either too basic or too specialized, and it’s been useful to build resources from time to time to meet our needs. This should be the exception, though, not the rule.

Scale, Eventually

The first set of new hires to go through the program got a literal, manual spreadsheet of things that I wanted them to learn. That spreadsheet had come from prior new hires and an attempt to standardize some skills that they should know. Providing context and proof of skill were a huge pain with the spreadsheet, but it let me find deficiencies in what was provided and react quickly to feedback.

As I became more confident in the approach, I built LevelUp, an open source, available-to-all website to answer all the questions that had arisen with the spreadsheet. Assignments were spelled out and resources provided for learning each section. This has been incredibly useful now that new hires have reached critical mass, but it wouldn’t have been successful if I had tried it on day one.

To this day, we still manually review each training exercise as a Github pull request. Some have suggested moving towards a more automated model for this as well, but I have resisted so far. Scaling is dangerous for quality, and I don’t think we’re at a point where we understand how to automate more of the process without sacrificing quality.

Shared Purpose is Critical (and Awesome)

We’ve seen that the people and groups who most strongly believe in the Culture of Learning see the best results. What does that look like and how do we help propagate it?

Every new hire goes through the same training, but some really take to it like fish to water. They not only complete their own code, but also actively help code review and mentor others in their cohorts (and even people in other ones). The new hires have self-organized into small teams to make this more effective, which gives them a support system for when things get tough. They love these groups enough that they’ve started getting t-shirts made for their training cohorts.

Once new hires finish training, we ask them to join our Bucket Brigade, which engages newish employees to guide and mentor brand-new employees through the program. This gives them an opportunity to hone their skills further while giving back to the department.

Beyond the new hires, some of our existing engineers have really stepped up to pitch in. This is a fantastic result, as it wasn’t one that I was expecting. Having more senior folks around for guidance means better outcomes for everyone involved.

Since engagement with the Culture of Learning predicts such positive outcomes, we’re interested in seeding it as far and wide as possible. So, we try to “seed” positive role-models throughout the department, where they can have an effect on their local teams. By spreading influencers around, our reach is increased.

We Need to Keep Building Bridges

Explaining to your product manager why they can’t have more resources for over a month is… a hard sell. While everyone agrees that training is important, we have to keep cognizant of how our internal and external customers perceive us.

Thinking of it another way, trainees are taking time off of potentially very profitable projects to play with toy code. We need to demonstrate continually how that improves total outcomes for everyone involved.

Showing impact (as opposed to outcome) is always hard, and especially so for formalized training. We’ve been using a combination of surveys, code reviews, and informal feedback from team leaders to keep a bead on how training is impacting new hires. Thankfully our internal customers are quite reasonable people and have been receptive to that proof.

Broad Learning Increases Empathy

We are at this point a fairly large engineering department. The company as a whole has well surpassed a thousand employees, and so it’s basically impossible to know about everything else that is happening outside your department or even your own team. When that happens, we can forget that there are other groups with orthogonal needs to our own, and when that happens, we all lose.

What we’ve seen is that as engineers learn about our entire stack — from database to interface — they do a better job of keeping others in mind. They know how not to make a mess of other people’s work. This is key for folks whose work reaches across several disciplines.

We Hit a Nerve: People Want to Learn

Within a few weeks of starting the program, I started to get requests from existing engineers for help with training themselves or their teams. This ranges anywhere from getting exposure to new technologies to changing job roles entirely.

Leaders of each of our development teams have taken it upon themselves to help here. Several of the teams now hold daily or weekly professional improvement time. This works wonderfully as team members keep each other accountable for getting better at their jobs.

As the program moves forward and we get the bandwidth to spend more time on existing engineers, I’m excited to see what we can do with this group. You never really master programming, and people are excited to add new skills to their roster.

There Are Plenty of Things That Don’t Work

We’ve failed as many times as we’ve succeeded, and I think that’s fantastic. Learning about what doesn’t work is a great joy to me and says that we’re still trying ambitious things. Some of the stuff that hasn’t worked in the last few months:

• Workshops that we didn’t design well or plan sufficiently for.
• Running ongoing classes for existing hires when time sensitive projects show up (not much we could have done to save this).
• Training off of the spreadsheet mentioned above (god it really is boring and confusing).
• Putting new hires into teams right away but assigning part-time training (project pressure again, they never quite get trained).
• Expensive external trainers (their incentives don’t align with ours, and we have the expertise in-house already).

There Are A Few Things That Do Work

The successes have been fantastic. Just a sample:

• Aside from the aforementioned onboarding period, we’ve also run some successful workshops for new and existing engineers.
• We’ve ramped up our Tech Talks program into a weekly affair that attracts a hundred spectators and is scheduled months in advance.
• Materials are unbelievably cheap relative to developer productivity, so we provide as many as possible. We’ve created not one, but two libraries on the floor with carefully selected books. Memberships to common learning sites are available to everyone.
• As mentioned above, graduates are reviewing new trainees’ code. This benefits all parties equally and frees up some of my time for building new content.
• LevelUp is helping new employees, existing employees looking for training, and even employees from other departments.
• We’ve brought in some outside training to great success. Topic experts from the community have done a better job than professional trainers every time.
• Conferences inject new ideas into the department and refresh engineers’ minds. This is an easy win.

Overall, our successes benefit the department, and our failures tell us more about what to do going forward. In the next — and final — post, I’m going to talk more about where we’re headed.