Collaborate: Do Twice the Work In Half the Time

Stop me if you’ve seen this movie before: an engineer is ready to ship a new feature and issues a pull request. He expects the work to quickly move through internal reviews, and is looking forward to getting it in the hands of customers. But during the PR review, the assigned reviewer identifies that the engineer implemented an entirely new framework where one already exists. The reviewer also notices the engineer used a design that seemed overly complex for the problem, which might present maintenance issues in the future. Simultaneous to the PR review, a product manager identifies that while the feature meets the requirements, it is difficult to use and needs some changes to make it ready for customers. The engineer returns to the his desk to start working on a feature he thought was completed, frustrated and unsure of why it is so hard to ship such a simple change.

In spite of many engineers choosing to view the above as an organizational failing, we all know what could have been done differently: rather than go heads down on the feature, the engineer could have sought to collaborate with his / her peers. The pull request issues could have been identified through a design review, and the usability issues through a UX review. Both reviews could have occurred before any investment in writing code, and may have taken no more than a couple hours of additional project time. In large companies, this minimum process would be enforced through a Software Development Lifecycle (SDLC) - but in smaller organizations, the collaboration is delegated to individual engineer. But instead of seeking collaboration, the engineer chose to make decisions on his own, and to communicate these decisions to his teammates through a pull request.

The lack of collaboration and information sharing is one of the single greatest contributors to engineering inefficiency in software development today. There are a number of common causes - e.g. lack of experience, personal insecurity, mistaken belief collaboration is inefficient, need for control, etc... - but all collectively contribute to lost time and effort.

Here are some of the benefits you get by being collaborative and open with your work:

Better decisions - By opening decisions up to feedback from a group, you will improve the quality of your work product.
Team buy in - By being open and collaborative, you also foster buy-in from your team on the key decisions you make in a project.
Eliminate knowledge silos - Your teammates will be able to better support the software you build when you freely share information and solicit feedback on key decisions.
Non-linear thinking - By engaging a diverse team in decisions, you will sometimes find new and unexpected solutions to problems you thought you fully understood.
Learning environment - By engaging the full team in key decisions / reviews, you enable engineers of all levels of experience to learn and advance their skills - including you.

So next time you start a new software project, take a moment to consider how you can engage the broader team in key decisions. Doing so will ensure you deliver the best possible work in the least amount of time, and do so with the least amount of frustration.