For the last few months, we have been a company in transition. We transitioned from a very small team (6–8 people) to a slightly bigger team (12-15 people). For a team of 6–8, there was always enough for everyone to do and there was no formal way of allocating work. All of us were either fighting fires or experimenting something new to do. All these years, unlike a regular company, achieving a sales target was never a serious consideration. Our motivation had always been to build a better product, and eventually hope people will start paying for it. Build, and they will come.

Being target oriented keeps everyone on the same path and driven towards the one goal, but in our team, everyone had the freedom to select their goals. As we expanded the team, it was hard to explain this to the new recruits. When someone joins a company, they expect that they will be assigned some work. The product we are building has many features, many pending fixes, many process that need automation, and we just assumed that people will eventually find something that interests them and start contributing.

In this transition process, we also lost one of our core engineers, when we had a major version migration in pipeline, on a brand new, untested cloud platform that we had built and it was also the time of our annual conference. The ideal recipe for a perfect storm. All this meant meant that we were not able to give enough time and feedback to the newer team members. Unfortunately they started getting lost and their performance started dropping.

Being a moderately successful open source project, our annual conference is where we get to meet our entire community of users and developers. We are at the stage when the first set of community contributors is just beginning to be formed. This is a really exciting phase for all of us. The community looks up to us for leadership to drive the process of community building. We realized that it was imperative for us to harvest the energy generated from the conference. The way we interact with the community is through GitHub Issues and Pull Requests, our forum and chat. There are users of all levels who need help from the community. Students want to learn what an ERP is, small business owners what to understand how to use ERPNext and if the product is for them in the first place, service providers need to understand how to customize the product and developers want to build on the product.

At some point, it struck me that the challenges of building a community whether within or outside the organization are not so different. Specially if you are an open source company. You have to train people, give them the right resources to start improving the product, connect them to the community and build systems to accept their contributions.

Worried at dropping team productivity and morale, we decided to start using GitHub Issues to assign work and track performance of all the team members. For the first month, that worked surprisingly well. Knocking off a bunch of every week was fun and at least you knew what was expected out of you. The downside was that someone had to take up the job of allocating issues.

But this was still not ideal. I personally felt that I was most motivated to work when I was working on issues of my choice. Someone assigning issues felt like a step backwards. We needed to figure out a way for team members to choose their own work, based on what they found interesting, and were curious to learn about. The most meaningful work happens when you build something that solves a problem for you. Currently most of our work is driven by issues posted by our paid users, issues we have ourselves while using ERPNext to run our company, and issues we have while building ERPNext itself (hence Frappe Framework). On top of this we run other projects like our deployment platform (Bench), cloud management platform (Central) a community portal and our own websites.

We realized it was for new recruits to get familiar with all these platforms and start finding their own issues. We needed to get the team to get familiar with all these assets. Ask them to explore these and find what is it that interests them the most, challenges them, builds their curiosity and aligns with their long terms goals in terms of the skills they want to build. For this, they must understand how each of these assets are used, and the way to learn that would be to use it themselves. Even if they managed to do that, there would still be a big missing piece. That is, most of our customers don’t use most of these systems. They use accounting, inventory management, buying and selling, HR and payroll. The challenge is how do we make our team deeply understand the challenges of running a company. Maybe there is an answer to that too.

While I was browsing a few open source projects, I found that a lot of them sold merchandise related to their product. So the natural thought was, why not run a web shop to that sold ERPNext merchandise and a few nice technology products that we love, and build a small company to run that? I realized that was the exact idea my friend Sukh Dugal had when he started his T-shirt company, and it completely validated my idea. Along with this, we are also in the process of establishing the ERPNext Foundation, so that gives us one more use case for which we will need to build software. With all these use cases in front of us, I think we can finally build software for our own use, that is used by our users too. These will give enough first-hand access to our developers to start identifying problems and start building solutions that they will be able to use themselves. Its seems like a round about way to run a software company, but it will make our work a lot more meaningful!