Sachin Rekhi

One of the classic pieces of software engineering literature that has had a profound influence on me since first reading it at Penn Engineering is The Mythical Man-Month by Fred Books. Fred initially authored the book in 1975 based on his experiences at IBM managing the development of OS/360. His central thesis is that leveraging man-months, a hypothetical unit of work representing the work done by one person in a month, as an effective way to estimate software projects is a myth. Put more simply, adding manpower to a late software project in fact makes it even later. This is because adding additional people to a software project significantly increasing the communication overhead and more people need to communicate in order to ensure they are aligned and aware of what everyone else is doing on the project. This significantly reduces the incremental output from each added resource.

While this is a well-understood and generally accepted reality, I still see many software organizations using some form of man-months for their estimation and jumping to add additional resources to their team in order to try to speed up their projects. I wanted to share some of the lessons I've learned on how to improve software engineering team velocity without simply adding additional resources to the team, which has all the challenges that Fred describes.

Inspire the team and demand excellence
Software engineering is a creative discipline and individuals passion, motivation, and excitement has a huge influence on how productive they are. So it's incredibly important to inspire your team and ensure they are bought off and excited about the mission you are going after. If they truly believe they are working on a once-in-a-lifetime opportunity, you'll undoubtedly see far greater results. Whether it's making their existing hours more productive, or going the extra mile to hit a deadline, or volunteering to go above and beyond when required, it'll all add up to increased team success. Similarly, demanding excellence from the team and ensuring that you give everyone the opportunity to shine to their limit will encourage them to keep going when they know they're stretching themselves to learn and accomplish even more. Many of the other leadership lessons I mentioned in my previous post equally apply here.

Measure and reward high quality velocity
Often it's common for engineering teams to be motivated and rewarded by the elegance of their engineering solutions, which is a great way to ensure craftsmanship in their work. But I encourage you to also develop measures and rewards for high quality velocity. What I mean by this is not only should folks be rewarded for high quality work, but also rewarded for their speed of execution in bringing a solution to market. You can't improve what you don't measure, so it's important to find ways to measure team member velocity and reward the star performers. When folks have a clear rock star to model themselves off of, they'll often adapt some of the practices of these rock stars in an effort to achieve similar results. So it's important to reward and recognize what great velocity at high quality looks like to inspire others to also achieve it.

Favor ad hoc face-to-face communication instead of heavy documentation
All too often as teams get larger there is a push to more documentation to facilitate broader communication with many stakeholders, whether it's specifications, designs, test plans, error cases, and more. While documentation is important, I encourage teams to favor ad hoc face-to-face communication between product managers, designers, engineers, testers, and more to quickly resolve questions instead of always jumping to the more expensive documentation as the main communication medium. It significantly speeds up discussions and reduces the back-and-forth typically associated with understanding what's going on.

Focus on developing best-in-class tooling & infrastructure
In software engineering, the tools and infrastructure we use on a day-to-day basis become an incredible leverage point for developer productivity. Whether it's the code repository, build process, code review systems, production push systems, code coverage systems, test automation systems, performance analysis systems, or others, each developer spends significant time in each of these tools everyday. The more streamlined they are, the more productivity you'll get out of your entire engineering team. Similarly, the infrastructure systems around databases, messaging, caches, etc. that are robust and general enough to be reusable by the entire organization, the less reinventing the wheel each team will do for each and every app that your team builds. Often much of this infrastructure is available from both commercial and open source vendors, so feel free to leverage as much as you can to improve your tools and infrastructure to drive output gains for all.