The First Three Phases of a Company

Problem

From what I’ve seen, as you start growing in the early stages of a company, where you have fewer headcounts in engineering to fill and you’re trying to survive as you find your product-market fit, you’re usually building a lot of stuff. Some of those things work, and they start scaling. At that point in time, your product has started to scale, but it may not yet be built to scale. This is the beginning of the first three stages that a small business goes through as it evolves.

In our case, we started facing a lot of platform, production, and security issues and were trying to keep above water in regard to these technology issues. It kept pulling us back and distracted us from delivering value to our customers. At that point in time, what we had to do was be able to divide our efforts to some capacity, focusing on bringing in senior-level engineers who will be qualified to build architecture as leaders, as well as fixing any issues with the technology architecture. This was the first stage of the company.

Actions taken

Something that helped point us in this direction was the project management function. In early stage start-ups, there is no project management function because you probably do not need one; it adds many extra unnecessary layers of communication. Once your team grows to about thirty or so, however, the need for it will become obvious.

Typically, these days, it’s called TPM, Technical Program Management. We started building that about three years ago. It brought in a lot of structure and predictability to the group. We were able to reorganize ourselves into squads.

That brought us to this second phase of running very efficiently. It became less about the timeline and more about the cycle time. How long does it take for a unit to get from idea to production and into the hands of users?

I did a lot of reading and effectively modeled our development life cycle as a closed system with work moving from left to right. Any leaks went back to the beginning of the cycle. That visual really helped us understand and to measure how we were doing work. We were now much more aware of our leakages and cycle times and our defect rates. That’s when you reach the third phase.

Sure, as we grow, there are other phases as well. But these three come with many valuable lessons.

Lessons learned

• As you scale an engineering organization, you need to kind of actively think about the structuring aspect of it in addition to meeting your deadlines and objectives. Because you have no real way of knowing whether you’re beginning to move slower or faster as a company, you need to be flexible with your timelines. You plan to deliver by August, and you do. But is it good enough?
• When the organization is first growing, what you need right now is not what you’re going to need in six months. You need to be consciously looking out for these changes at pace along with the growth of the organization. What is going on right now? What is the next level? How can I preemptively build the team to solve those problems ahead?
• It’s a bit of experience, a bit of reading, and a bit of talking to people. Learning by experience alone can often be very slow. Rely on the literature out there as well as your mentors and your peers.