Crowdsourcing: How We Scaled and Established Our Development Processes

Crowdsourcing: How We Scaled and Established Our Development Processes

I remember my early days as a software developer and how I used to hate the development process. I wished my manager would leave me alone with my code and only worry about the final deliverable. My outlook changed over time as I understood how a defined process could help in streamlining software development. However, I believe that a process applied without consideration for the work culture harms software engineering. Also, if the team does not see the value in following the process, they game around it. Software engineers are particularly notorious for cleverly working around a system. I can say that with confidence because I have done it many times in the past!

With that kind of mentality, it’s not surprising that we avoided any formal engineering processes at Druva for a long time. In fact, it worked quite well when we were still a small team. Because of the size, it was easy to keep everyone on the same page. We used to figure out the process on the fly and immediately communicate it to everyone. After replicating the same actions a couple times, it became the unofficial, non-documented process moving forward.

Things started to fall apart when the team size increased beyond a certain point. Looking back, there were multiple issues that should have raised some flags:

  • New members of the team did not know of the non-documented processes. They had to approach someone inside the system to understand it.
  • If a new member could not find an existing process, she would just invent a new one.
  • It became difficult to make sure that everyone was on the same page when relying solely on verbal communication.
  • As a result of the above two, different team members would expect things to happen in different ways and the ball would be dropped or efforts misaligned.
  • We had some team members who worked better with a process in place. I was surprised when an engineer asked me why the process did not enforce a code review. Until then, it was left up to individual developers to judge whether the changes they were making were substantial and required a code review.
  • As our team expanded globally (marketing in Sunnyvale, Engineering in Pune), it became more difficult to align efforts with informal communication.

Ultimately, it was clear that we needed some documented development processes in place, but as an engineer, I hated the idea of engaging an external consultant or hiring a person purely to identify and document processes. I believed that the engineering team would also have the same feeling. Besides, I thought that we had some pretty good processes already in place and that we should document and improve on them instead of coming up with something completely new.

With that in mind, we arranged for three brainstorming sessions to come up with the first cut of documented development process:

1) The first session focused on identifying existing processes and any pain points with them.

2) The second session focused on addressing the pain points and improving the processes.

3) The third session, a consolidated outcome of the first two sessions, was presented followed by any final comments.

The entire development team participated in all three sessions. This was necessary because our non-documented processes were stored in everyone’s minds. However, there were other important benefits of having everyone present in these sessions:

  • We got immediate visibility into any possible shortcomings from different perspectives
  • Everyone understood the reasons why certain processes were defined a certain way
  • There was immediate buy-in to the processes, which increased the chances of the team actually following them

Now we repeat this set of three three brainstorming sessions after every major release cycle. Defining development processes is not a one-time exercise. We have only taken a minimum viable approach to process definition and documented only the parts of the processes that are required right now. As we grow, there are more parts and details to add to these processes as well as issues and improvements for implementation.

Interested in being part of this process? Join our team!


Milind Borate

Milind has over 13 years experience in enterprise product development and delivery. Prior to co-founding Druva he worked at Veritas Software as Technical Director for SAN-FS and served on the board of the Veritas patent filter committee. Milind has filed over 15 patent applications (4 allotted) and co-authored "Undocumented Windows NT" in 1998.


Leave a reply

Your email address will not be published. Required fields are marked *