The world of software is in constant motion and so is your team. New technologies come and go, whole platforms emerge, teammates leave and new ones join. As a manager, how can you help your team, both neophytes and veterans, get better at their craft?
Build a library
Books are old-school but still a great source of knowledge. Some classic books from our industry include:
- Design Patterns (by the “Gang of Four”),
- Refactoring (by Martin Fowler)
- Principles of Object Oriented Design in Ruby (by Sandi Metz)
- The Mythical Man-Month (by Fred Brooks).
It’s valuable to have some kind of library for your team, either physical or virtual.
Videos are another great source of knowledge. There are tons of free vidoes out there, from our own upcase, to conference recordings, to dedicated YouTube channels. There are also many great paid video courses out there too (I’ve really enjoyed courses by Pragmatic Studio).
Cultural changes
Not all learning has to come from external resources. Many of the best opportunities for self-improvement arise out of team interactions. As a manager, you want to create a culture that fosters this.
Continuous improvement is one of thoughtbot’s core values. We’ve documented a variety of practices we used to build a culture around this in our playbook
Learning is something that happens every day, with every bug you fix, with every new function you learn, with every new pattern you encounter. While this will happen even for those who are alone, it is accelerated in team settings because now individuals can learn from each other. This is one of the big advantages of working with a team. Everyone knows some things that other team members don’t.
To take advantage of this, you will need to create a team culture where it’s OK to ask questions and even to say “I don’t know”. This is part of the greater issue of psychological safety. Teams that are status-driven and afraid to show weakness are giving up a powerful improvement opportunity.
Learning while doing day-to-day tasks is a great first step, but many things require more focused learning. This can be ad-hoc such as reading an article about an algorithm you’re considering using on an existing project or building a small prototype application to test out a new framework.
You can also go a step further and set aside a certain amount of time in the schedule that is dedicated to learning. At thoughtbot, we dedicate one day a week as investment time. This self-directed time is used to learn, experiment, build, and share outcomes with the world. Often, this will be a further exploration of problems encountered earlier in the week while working on a client project.
As a manager, you expect your team to be constantly learning and keeping up to date. You need to communicate to them that learning on the job is not only acceptable, but expected. Setting aside some dedicated time to learn demonstrates that continual self-improvement is more than just a meaningless phrase in your company handbook.
Pair programming
Another way to take advantage of having a team is pair programming. This technique is great for sharing knowledge of a system across a team, helping level up a junior developer, or just to throw two brains at a problem. Invariably, both developers walk away from the experience with improved knowledge.
Pairing doesn’t have to be a big formal process. A lot of the pairing we do at throughtbot is ad-hoc.
Code review
Another valuable place where knowledge is shared is during code review. Unfortunately, at many organizations code review has become notorious as a toxic gate-keeping exercise. There are a few things that can be done to improve the experience. First, make sure to take a peer review approach. This means everyone gets a chance to both give and receive code reviews. It’s important that it’s not just senior team-members reviewing junior’s code.
Even if your team doesn’t have an explicitly hierarchical approach to code review, it’s easy for one to develop implicitly. Junior developers may not feel comfortable reviewing a senior team-member’s code (see earlier mention of pyschological safety). They may not feel qualified to review code at all. You need to encourage and support your junior developers to start giving reviews in addition to receiving them.
Secondly, ensure that final editorial control rests with the code’s author. Reviewers are providing suggestions and feedback but are not there to prevent a feature from going out.
If you’re looking for inspiration on improving your team’s approach to code review, take a look at thoughtbot’s code review guidelines.
External help
Not all learning has to happen internally within your team. External sources can be particularly impactful because they bring new ways of thinking about problems that you team hasn’t even considered.
Conferences are a developer favorite. Not only do you learn from the speakers, but also the conversations that happen with industry peers outside of the sessions. Teaching is one of the best forms of learning, and speaking at a conference can be a pivotal moment for a junior developer leveling up or a seasoned developer mastering a new technology. In addition to the technical skills, speaking improves communication skills which are always valuable in every job setting. Encourage your team to speak at meetups and conferences.
Bringing in an outside team of experts to your company can also be a big boost to your team’s learning. This is something we’ve done often enough at thoughtbot that we have a dedicated service for it. Sometimes it is focused on a particular teaching a particular technology or methodology such as test-driven development. Other times we’ve done engagements that were more general mentorship. One of our core values is constantly improving ourselves, our team, and those around us. Because of this, even engagements focused on feature work with clients always involve some informal mentorship and knowledge sharing using many of the techniques discussed in this article.
Your ideas
Do you have some some favorite practices or resources for helping teams level up their expertise? Tweet them to us at @thoughtbot!
