--- title: Best resources to upskill your technical team teaser: Tried and tested techniques to keep your Ruby on Rails or React Native team up to date. tags: teams,culture,code review,pair programming,playbook,ruby on rails,people management author: Joël Quenneville published_on: 2019-12-23 --- 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 videos 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]). [upcase]: https://thoughtbot.com/upcase [conference recordings]: https://www.youtube.com/playlist?list=PL8tzorAO7s0g57gv25kLcHLTIyIBdEVyX [Pragmatic Studio]: https://pragmaticstudio.com/ ## 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]. [Continuous improvement]: https://thoughtbot.com/playbook/our-company/values#continuous-improvement [playbook]: https://thoughtbot.com/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 thoughtbot is ad-hoc. ![Two developers pairing](https://images.thoughtbot.com/jq-upskill/LNU27k3DSKK9sFc0CzDG__MG_0449.jpg) ## 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 juniors' 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 psychological 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]. [providing suggestions and feedback]: https://thoughtbot.com/blog/don-t-review-prs-like-a-space-wizard [investment time]: https://thoughtbot.com/blog/how-to-introduce-investment-day-at-your-company [pair programming]: https://thoughtbot.com/blog/pairing-is-caring [code review]: https://www.youtube.com/watch?v=PJjmw9TRB7s [thoughtbot's code review guidelines]: https://github.com/thoughtbot/guides/tree/master/code-review [every new function you learn]: https://thoughtbot.com/blog/turning-experience-into-growth ## 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. ## Work with us Bringing in an **outside team of experts** to your company can boost your team's learning and accelerate product development. Here at thoughtbot, we offer a dedicated levelling-up service. An agile team of thoughtbot product experts bring their expertise and passion to augment and upskill your team for as long you you need. Sounds just like what your team needs? Find out more about [how thoughtbot's team augmentation can boost your business]. [improves communication skills]: https://thoughtbot.com/blog/feedback-training-and-resources [how thoughtbot's team augmentation can boost your business]: https://thoughtbot.com/services/team-augmentation