Learning More with Less

We were paying thousands of dollars annually for a couple dozen licenses for an online training platform. During a routine expense audit, my colleague who managed all those engineers with licenses wanted my opinion on if it was a good value. Just like a gym, an online learning platform is a great deal... if you use it. Here's what we learned when we canceled our membership.

Instead of immediately signing up for a different platform, I knew we had to change our habits first and not expect a new vendor to change them for us. Before we closed our account, I logged into our admin dashboard and saw how some engineers would log in and watch a few videos in a few days then leave it alone for months, while other engineers never finished activating their accounts. In my experience, reading even one free article from a reliable source per week is better than watching a video tutorial every few months. It would have been a lot easier to throw some budgeted dollars at the problem and move on, but I wanted to do something more mindful and intentional.

A New Program

If you want to improve your organization’s engineer development program, start a conversation with the engineering managers. In my case, I was already working closely with one who wanted to collaborate on a professional development program. So we worked together to come up with a plan. She shared what she could from one-on-one meetings with the engineers who would benefit, and I shared my observations from the day-to-day work I supervised.

Since the program was for the engineers, we wanted a development program to fit their interests and needs. We came up with a general idea: each engineer would spend one hour every week learning individually and another hour every week learning with their team in a group. With some high level goals in mind, we were ready to work with the teams’ leaders to set more specific goals with clear finish lines.

When it comes to setting goals, I personally like the S.M.A.R.T. acronym: specific, measurable, assignable, relevant, and time-based. For example, instead of “Get better at JavaScript,” draw a finish line: “Implement a unit testing framework by the end of this month” or “Ensure every engineer on the team writes at least one unit test by the end of this quarter.”

In addition to helping set goals, each team’s technical leaders should be ready to offer favorite approaches and resources for learning. Saving money really wasn't the primary goal, but most of the resources we used were completely free. Going back to that gym analogy, you don’t need a gym membership to get in shape; you do need to build a habit and stick with it.

Whatever the technical leads recommend, this is a wonderful opportunity for them to provide mentorship and demonstrate leadership, making their own work more meaningful and creating talking points for their next employee review. If you need a little inspiration, I’ve got another article listing different ideas for how teams can learn together.

Finally, coordinate with product owners and program managers to check out the year's calendar and understand upcoming objectives that the engineers could prime themselves for. This can be especially helpful if you’re feeling aimless. When the team needs to learn a new skill to meet a business objective that’s on the roadmap, this can be an opportunity for engineers to prepare ahead of time instead of having to start from scratch when it’s time to start building.

As far as the learning plans go, make sure you’re committing hard to learning, not getting so invested in a specific plan that the team feels like they can’t (literally) change their course. It takes time to learn how to learn, and the hardest part for me is knowing when to show more grit and when to say, “Okay, let’s try something different.” My personal advice would be stick with each general plan for at least a month before deciding to try something else. Make tweaks as needed, but unless it's clearly a total flop, give each plan at least four weeks so the team can learn to make those tweaks that make their program work for them.

Normalize It

Although each team had its own specific goals established by their lead, it was great to have that universal expectation for time commitment: two hours per engineer, per week. Before we could ask anyone to set aside that time, we had to clear the way for them. In other words, this program needed to be completely transparent and normalized. Not just “approved”, but we wanted the engineers to feel actively and visibly encouraged to learn. Professional development needs to be an open part of the culture, not something employees do covertly when they’ve got extra time on their hands.

Luckily, our department head already understood the value of professional development. Our message could come from above. When we raised our program’s visibility during regular cross-functional leadership meetings, everyone from analytics to the creative department saw what was happening and could plan accordingly. Most importantly, we weren’t just adding another thing to the engineers workload, we made it clear this was going to take time away from other projects. I think this was especially important so the more "project-managery" folks could adjust their delivery expectations appropriately.

After everyone aligned, our boss met with all our engineers and clearly expressed his support for the program. He wanted every engineer taking the time every single week to sharpen their skills. This made it crystal clear he had their backs, and we weren’t asking anyone to squeeze “learning time” in on their lunch breaks. It was up to each engineer to manage their own time so they wouldn’t have to.

When are you going to learn?

Engineers should be stoked at an opportunity to invest in themselves, especially if their input is being heard and they're getting a path to help meet their professional goals. So make it real: Ask each engineer to book regular repeating meetings for themselves to actually do it. This provides the same “permission” and encouragement to switch gears just like with other meetings. It also guards against the refrain of “I was too busy doing actual work” as a cover for a gap in time-management skills.

When the boss went on the record enthusiastically supporting this program, that made it clear how important it is. It should be a strange and rare case that an employee is unwilling to invest in themselves, but at the end of the day remember it isn’t your job to force people to do things they don’t want to do. All we can do is clear the barriers for them, they have to do the rest.

Ease Product Management Concerns

It’s worth acknowledging: This can look scary for the people relying on those engineers to deliver the work that keeps the lights on. We had constant looming deadlines and “big pushes,” so pulling engineers away from any of those projects added risk to delivering on time. So how can you ease some of these concerns? There must be better arguments than “Well, the product owners aren’t responsible for managing the engineers, so they’ll just have to deal with it. On a related note, here’s an animated ‘Deal With It’ dog-wearing-sunglasses GIF from 2010.”

This is where those S.M.A.R.T. goals come into play. This isn’t engineers diving down a rathole of Wikipedia articles about character encoding every afternoon, this is engineers following a plan to become professionally better. Two hours a week from every engineer may affect team metrics like velocity or throughput, but it shouldn’t affect the team’s overall predictability. If an engineer starts floundering, make sure their manager helps them get back on track. If it’s the team’s program itself that isn’t productive, make sure the team lead can help pivot and figure out what’s not working. Be sensitive to any “image problems” the program develops and address them early and head-on.

Less But Better

By thinking about what learning tools we wanted to use and how we wanted to use them, we became re-engaged with professional development. It wasn’t as simple as getting the boss’s payment credentials and renewing a paid membership, but it was a lot more valuable. If we’d renewed that expensive membership anyway and tried to make the same changes, I don’t think we would have been as effective. Without our usual training resources, we had to become more thoughtful about what we wanted our training to be.

I think one of our keys to success was keeping the groups small (less than 10) so the concept of going around in a circle and sharing was practical. In a sea of “all engineers” it’s easy to melt into the back row and become less involved with the presentation. Those kinds of presentations are valuable for raising visibility across a big organization and learning from people we wouldn’t normally hear, but I pay much closer attention in a meeting when I’m a key part of it or know that I’ll be called on and, more importantly, earnestly heard. That kind of involvement is way better and more useful than signing up for another year of that learning platform I always forget the password for.