Coordinating Capabilities for Improved Processes and Practices

Problem

"On my last team I was working with a great engineer who didn't like nor understand a particular part of his job. In order to support a larger team we had to change certain practices. He was upset because due to a process change he had to spend a significant amount of time on scrum work. He was super organized, communicated brilliantly, and was super methodical but for him, this new part of his daily tasks seemed like child's play. I needed him to know that he was an amazing engineer but that we not only needed a way to train and deliver the skills he developed to an engineer fresh out of school who never worked in production code, but also a way to document so that other engineers could jump right in as well. How do you explain and motivate a man with over 15 years of engineering experience that process change is not only beneficial to newcomers but to veterans like himself too?"

Actions taken

"First explain that the new process changes enforce the team's capability to clearly communicate. Distributed teams, and especially time zone distributed teams, require the use of both synchronous and asynchronous technologies and practices. There's got to be a way for people to participate even if they're not there in person. Sometimes you won't get the opportunity to sit next to the individual who will help you with the next step, or solve a difficult problem, so documenting transcends space and time. You'll not only be helping newcomers, but also veterans who work elsewhere than yourself."

"Besides the little systematic productivity improvements for the team, there's also the potential for career advancement for individuals. There's a saying that goes, 'You only ever progress in your career by making yourself replaceable.' If you document and automate your job then someone else, too, can do it and take over your position. This shouldn't be viewed negatively, but allows you to move on and upward in your career trajectory. You can swap jobs and tasks at any time, giving you an opportunity to develop new skills and allowing you to work across multiple business units on a project."

"In addition, another way of highlighting positive aspects of our process change was to compare it to an open source project. If you have actively worked and contributed to one of these projects, or had an issue with one and tried to resolve it, then you understand that problems are not solved by five engineers sitting in a room chatting. There's a gigantic workforce distributed around the world and whole processes designed around that which might be overhead. These processes become foundations for great practices that go beyond shipping good code. How you get to code production is equally as important as the code you write, therefore, the soft skills and business skills you gain from processes and practices are necessary for you to become a great engineer."

Lessons learned

"I made it aware that we were trying to balance the full spectrum of capabilities and provide opportunities for everyone on the team. Learning from each other benefits all parties involved. If the great engineer documents and deals with the rubbish 25% of the time overhead, the new guy will get examples of all these things, not just code. You're reviewing code but you're also reviewing people's work practices and what makes them productive. It's an intra team dynamic that fuels itself."