Companies are shifting away from hiring for specific programming skills and know-how in lieu of finding candidates who are adaptable and quick to learn on their feet. But once you find these individuals, it’s crucial that you maintain that learning environment, for the sake of the software engineer as well as the company.
Ron Lichty, consultant and co-author of Managing the Unmanageable, has decades of experience in this area. From leading Apple’s Finder and Applications group — the team developing the Macintosh’s user interface, which some say is what set Apple apart from their competition — to building the first investor tools at Charles Schwab, he’s seen just how much learning opportunities can motivate and empower software engineers.
Furthermore, he’s seen these learning opportunities not only make for a stronger team but a more robust product. In Managing the Unmanageable, Lichty and co-author Mickey W. Mantle explore Frederick Herzberg’s seminal work from the 1950s, which identified what people are motivated (and demotivated) by. Lichty and Mantle took this one step further and applied it to software engineers. Learning is second in the list for satisfaction and as they point out, is not only essential for keeping your software engineers happy, but for making your product successful.
There are two primary reasons why this principle is important:
1) To maintain client or customer advantage, we need our programming teams to find the best solutions.
2) To maintain stability (and with stable code, the ability to go fast), we need to identify and hone in on best practices.
Enabling your software engineering team to find the best solution possible while maintaining the stability of your product is key to a successful business. This can be facilitated a few different ways:
Inspire Exploration.
Let your engineering team know that their feedback is valued and that all opinions are welcome. Empowering them to bring different options to the table encourages a thirst for knowledge as well as an awareness of advances in their specific field of technology. This exploration should be balanced with making sure you don’t reinvent the wheel. Lichty explains:
“It’s really important not to solve problems that have already been solved. The Internet is a crucial tool for looking for and seeing if a solution already exists. One reason why programming is hard is that it’s hard to estimate whether we should be doing something new or simply reusing what’s already out there. If there’s a stable and reliable solution that already exists, our mission should be to find that solution, rather than create our own.”
Allow for Mistakes.
Blameless postmortems are an important part of DevOps and Agile cultures. This means you view mistakes and errors with a perspective of learning instead of liability. As John Allspaw, Founder of Adaptive Capacity Labs, says,
“Having a Just Culture means that you’re making effort to balance safety and accountability. It means that by investigating mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process of individuals proximate to the failure, an organization can come out safer than it would normally be if it had simply punished the actors involved as a remediation.”
Hire for Empathy.
Make sure that the problem you’re solving for addresses the root of the issue, not just the superficial complaint. By building a team of software engineers who are excited about solving problems for customers, you’ll not only be taking care of bugs but building out features and solutions that will facilitate further success for your customers.
The next question is, how do you, as a manager, foster this type of effective learning environment? Stay tuned for more advice from Ron Lichty and the team at PlusPlus, coming soon.
—
Originally published at plusplus.co on October 10, 2018.
Top comments (2)
I would so wish that the real world would function like this :( but we can only strive to do better.
I'm currently in the candidate role, in more EU countries, and I can tell you that it is only a fairy tale. It applies to huge corporations like Google. All the other companies requires X years in Y specific technology, even if you could deliver better than a candidate that has that experience, you will not pass the screening process.
Clearly is not essential, most of the tech teams I saw and know do not have such an environment. They provide access to learning resources, but there are only a few companies that have a learning culture.
Yeah ... beside redundant internal tools like building, shipping and analytics, that many companies are building (dunno why), I even saw entire products that can be replaced by OSS versions. It is a shock for a dev working at one of this examples, for years, to find out that here is an OSS alternative out there. They just didn't searched.
I dunno what exactly do you mean by stability, in a market or from a technical stand? If you strive for high SLAs and 0 bugs you will have to sacrifice delivering and feature adding speed, which in most cases, 99% of the business people will say no. Sounds good on paper, but impossible to achieve.
Thanks for taking the time to reply, Adrian! I completely agree that this doesn't apply to every company, but there are definitely a lot that are moving in this direction, both in the enterprise space as well as startups. I'm of course noticing it more in the San Francisco Bay Area, so that's a good portion of my sample set, but hopefully others in various locations will begin following the same trend.
Sometimes things that are actually essential for success don't exist... but if you look to the companies that are truly successful, not just riding a wave of popular tech tooling, they have indeed created a culture of learning. It might look different from place to place, but it exists!
re: stability, I mean availability of the product for customers -- uptime, etc. -- as well as continuing to solve problems for customers. I completely agree that there needs to be a balance between delivering features & fixing legacy code or problem areas. Some companies won't understand, but that's the value of metrics that show how much of a difference those fixes can make :)