Staying Afloat During Rapid Growth and Transformation

Problem

We had a new team of five people, and in the nature of a fast-growing startup, you must work on everything and react to all types of requests. We were running in that mode for a while and began to get bogged down. In turn, we were constantly patching additional things, even as the team size increased.

Actions taken

First, we identified the areas of responsibility and the various challenges that we had on the technology side. We did the same for processes and products that were causing all kinds of issues. This came by way of an inclusive team brainstorm session so that everyone could participate and bring ideas to the table. 

Additionally, we prioritized and added a bit more weight to certain things in order to have a more clear focus that allowed for quick wins. 

As a final step, we created some space for one to two people to build something long term. This space was meant to act as a shield from the day to day chaos of failing systems and having to refactor parts of the code. As if theoretically given the next 12-18 months to start from scratch, those particular people were put into a different room and given the challenge of addressing our top three to five critical priorities. 

Lessons learned

• It is challenging to try to fix 50 things at once, but you can establish quick wins by identifying at least three of those things and show progress on them. 
• Before coming up with different solution proposals, two of our senior engineers separately focused on critical priorities for a few months by talking to other companies and industry experts. They ended up building a rules engine which was very dynamic and in real-time. It allowed a larger audience of people to easily create those new changes without too much effort towards coding and deployment. It initially took about six months for the first version of that test and maybe 12 months more to actually flash it out to the current state. Once we had that, all of the older legacy codes could migrate to the new system. 
• You can’t spend too much time thinking and tinkering without taking action. It is important to find a balance and not spend too much energy on RID and research. As the company changes over time, your work may become irrelevant as a result of that. Instead, break the bigger picture/system down into smaller pieces or phases that can get delivered; even if it is a hacky prototype. The immediate feedback you will receive from other people will be extremely helpful. 
• It’s easy to spend a lot of time on build versus buy, especially if you are talking to a bunch of external companies. Bias to action is important here, but you have to produce some smaller things, ideally every one to two weeks. It doesn’t necessarily have to be code that gets shipped every week, but a deliberate dump or write up forces people to have that bias to action.