Learning is an essential part of any career path, but especially that of a software engineer. As people responsible for continually building something new, they need to enjoy and be motivated by the challenge of always learning on their feet.
Through the years, Ron Lichty has worked at well-known companies such as Apple, Berkeley Systems, Fujitsu, Charles Schwab, and more. At each of these companies, he observed that learning is not only a motivational tool for software engineers, but it’s one of the top reasons why engineers choose to stay at companies.
Learning isn’t just about picking up new skills or even being trained on a particular piece of software; it’s also learning from mistakes and victories alike. It’s gathering as a team and recounting what happened so that you (collectively) can make changes that will help move the whole company, as well as the customer experience, forward.
So how do you, as a manager, go about building an environment that encourages this at your company?
Like most things, there’s a “dark side” to learning. In this case, the dark side of the force is the potential to get distracted by all of the shiny new technologies that can pop up.
As Lichty says, “You want to keep your team on the path of discovery while encouraging them to not step in the woods and get caught up in the poison oak.”
Lichty’s co-author, Mickey W. Mantle, puts it this way in their book Managing the Unmanageable:
“Ensure that your staff is not seduced by the allure of new ‘shiny things.’ …New technologies are the ‘dark side of the force’ for programmers, who will spend countless hours exploring unproved technologies rife with potential to introduce risk if embraced before broad acceptance, extensive field testing, and guaranteed support by those promoting the technologies.”
As a manager, it’s your responsibility to foster an environment that encourages learning in a focused and systematic way. Limiting your engineers too much might keep them from discovering an out-of-the-box, creative solution, but it’s important to keep their focus on finding the best solution for your customers.
Agile has been an undercurrent for several decades now, but this movement only seems to pick up steam, and for good reason. One thing to keep in mind, however, is that agile is much more than practices. By implementing the values and principles, you become a more agile team creating a more agile product, better able to serve your community of customers.
One way to do this is through holding regular retrospectives. Lichty explains:
“One of the aspects of every agile practice is breaking large projects down into short iterations or sprints. At the end of each sprint, we hold a retrospective. The point of doing them frequently is obviously not to set long-term objectives, but to solidify what we learned from the past two weeks that could inform a change.
“Then we can experiment over the next two or four weeks to see whether this change improves our quality, productivity, performance, or teamwork and collaboration. It might also improve our ability to bring the customer into the picture more.
“The end-goal might change every sprint, but these frequent check-ins allow us to focus on one specific experiment over the period, with the result that we’re making constant incremental improvements.”
A team that is successfully learning is not just learning about new open source projects, new programming languages, or even new solutions. They’re also learning and growing as a team; figuring out which processes work for them, which projects went well and which didn’t, and how they can either improve upon or change the effectiveness of their work in the future.
When presented with a new problem, it’s easy for a team to approach it from many different angles in an attempt to find a solution quickly. In reality, a more holistic solution is often found when the team is willing to work together, integrating multiple viewpoints from across the company.
Lichty makes this critical point about who should make up these teams:
“Agile is fundamentally about values and principles, which include valuing customers, bringing delight to customers, and solving hard problems collaboratively, as a team. The team reaches beyond the programmers — it’s the programmers, product owner, QA folks, and the Ops team. Ideally, this team includes the customer as well. Before the team pushes the solution to production, the product owner should bring key customers into the team’s environment to offer feedback and insight into what will delight them.
“This emphasis on teamwork is driven by customer empathy. Instead of finding a piece of code that will solve one problem, let’s dig into what’s going to truly delight our customers. It’s possible that one line of code will be part of the solution, but it’s equally possible that if we focus on the root of the problem, we’ll find a completely different issue at hand. At Apple, where user experience constitutes the crown jewels, I learned to hire not just for stellar C++ coding ability, but for customer empathy as well. Whether we’re looking at Apple’s at that time or how companies are operating these days, delighting customers is what keeps us in business.”
These basic principles are the building blocks of an effective team focused on providing value for their customers. By implementing these principles, you’ll not only build a stronger team but enable your engineers to take on more significant challenges in the future.
To understand why fostering this learning environment is so essential to maintaining a successful and long-lasting engineering team, read our previous interview with Ron Lichty.
Originally published at plusplus.co on October 24, 2018.