It is no accident that people over millennia have been able to effectively unlink from the food chain, build massive structures and civilizations, visit the moon, and connect instantly over a wireless online network.
People are incredible problem solvers. When faced with a coconut, someone found a way to crack it open with a tool. Onlookers noticed and adopted the technique, making coconuts much more accessible and eventually opening the door to a future with macaroons aplenty. People solved a problem, and tools then enabled a repeatable and scalable solution.
If you can automate your tooling, then do you still need people? You don’t have to pay machines or listen to their concerns, and you can work them all hours of the day and night. Surely, factories in the future will be productivity-optimized, machine-driven ghost towns… right?
When Robots Take Over
The first attempt at a massive-scale factory designed with a fully-automated approach was Tesla’s Gigafactory. Three years in, the factory has nearly 5 million square feet of operational production space and construction is still ongoing. Despite Tesla’s aggressive production goals, it was anticipated that this factory would be engineered in such an automated way, that it was only a matter of time before cars would be flying off the line.
By early 2018, the results told a different story. Tesla CEO, Elon Musk, was sleeping in the Gigafactory at the time, spending all his hours trying to solve this engineering challenge. The robots were actually slowing down production. When machines would break down, all production grinded to a halt until the engineering team could reset them. Meticulous tasks that a human could easy handle proved inefficient for a machine to take over.
It was only when they stripped out some of their automation and brought in more workers that they were able to hit their quarterly projection. This led Musk to tweet on April 13th, “Yes, excessive automation at Tesla was a mistake. To be precise, my mistake. Humans are underrated.”
Humans are Underrated
Tesla isn’t the only automotive company getting behind this position. Doug Neely, Director of Advanced Monozukuri Research at Yazaki North America, explained the focus of his work recently at the Detroit auto show. Monozukuri is a Japanese term which translates as “the way to make things and the way to develop human beings”.
Speaking on the topic, Neely asserted, “The idea is that this [monozukuri] is knowledge work. To be able to apply tools and materials for functional purpose, and do it with skill. We need to invest in the people.” People are uniquely skilled at adapting, innovating, and competing. Companies that are automating as a method for reducing payroll are actively losing these critical competencies.
This same debate of people vs. automation is waging across software development. More teams are moving towards automated pipelines, automated testing, and automated analysis. While there are unequivocal upsides to implementing these technologies (like faster time to market or better test coverage), they shouldn’t be seen as a panacea for software quality.
In our 2018 State of Code Review survey, we asked respondents to select the best practice for improving software quality. For the third straight year, the answer was code review. There isn’t a substitute for a veteran developer reviewing a teammates code, finding bugs, and teaching best practices. There simply isn’t a tool that can replace it.
There are static analysis tools that can automate some aspects of code review, but they can’t answer contextual questions like:
- Does the code change match the requirements?
- Is the annotation clear so future team members can understand it?
- Is the team onboard with making this change?
- What resources could help the developer do this better?
Fostering a Collaborative, Learning Culture
When organizations and teams start adopting a people-centric viewpoint, they start acting differently. Tools start to be embraced as people-facilitators, not people-replacers. For example, using a static analysis tool can save developers time by identifying a certain set of issues with great efficiency. That time can then be reinvested by developers learning best practices from one another in peer code reviews.
Peer review tools like Collaborator take care of unconstructive work like showing differences between code and document files, sending notifications, and tracking review metrics like time spent on reviews, lines of code reviewed, and defects found and fixed. Without a tool handling these things, team members would be squinting, nagging, and taking notes to maintain an audit trail. In this case, tooling actually helps unlock more collaboration and knowledge sharing.
One of our customers shared with us how his team took this approach and ran with it. For 9 months, this one veteran developer signed up to handle all code reviews for the team. With each review, he would share helpful resources with the more junior developers so that the next time they had a similar task, they would already know the best way to approach it.
His team focused on investing in each other. They became mentors for each other. They were all learning, week after week, until they became the highest-performing team in the company.
The Questions to Keeping Asking
Creating a company culture that prioritizes investing in people requires a consistent effort. Cultures are made up of more than values. Those values have to be infused into your structures, processes, and tools for your culture to have strong foundations. When looking at your own team, it is critical to ask questions like “How are we actively teaching each other?” and “How are we recognizing each other’s successes?”.
You could have the best tools in the world and still not succeed as a business. It takes a collaborative, learning culture to start solving the problems you don’t even know exist.
If you want to dig deeper on this, check out our new ebook on the topic, "Building a Development Culture of Collaboration".