How I became the PM bottleneck as a founder: And how I unblocked it.

Until 2014, I was the only project manager (PM) for the company I co-founded 9 years ago. While my co-founder, Ben Cheng, became the technical and product bottleneck, I became the project management bottleneck when our team grew to 20+ developers and 10+ projects.

Where did the problem begin?

The problem began with what Ben Cheng, Rick Mak, and I were most proud when we started: our “>code quality. Ben used to check every line of code. Rick and me became the only two people who could merge pull requests after we hired our early team members. Since we were the most senior developers, it made sense for us to do quality assurance as well. I’ve never worked in another company, but Ben later told me that many companies think of PMs as just account managers. PMs in other companies may not have any technical knowledge or offer advice to their clients in product development, but I expected any PM to join me to do all of the below:

  • Meet with clients (and report to them, and set their expectations)
  • Provide consultation on how a product should work
  • Provide technical advice and explain how things work technically
  • Handle project’s admin work
  • Plan future features and changes
  • Manage developer schedules
  • Offer guidance to developers when thinking about the whole product

Ben, Rick, and I began our startup with our own product, Pandaform. Even though the product made money and still does, we also started to take on client projects on the side. Back then, it was Ben doing sales and me doing the project management. All of us founders had to deal with clients, but as our company grew, we began to specialize. Ben went to events and did sales. Rick became our CTO, and I managed the projects.

I was growing with my company, but I didn’t consider my own limits and how to prepare for it.

At my peak, I managed 10 concurrent projects for over 20 developers, but it was unsustainable. At the time, it was easier for me to get better at my job than finding another PM, but we were just delaying the issue. We delayed it right up until our product quality began to suffer.

How our first solution failed in the long-term.

Photo by Nicolas Cool on Unsplash

A few years ago, we started looking for a second PM, but it was a long process and by then we were desperate. There weren’t many PMs who met our technical and client-facing requirements. The second PM to join the company had experience, so he delivered results. Because things seemed okay, I never questioned how his work process was different from mine. But when he left to do his own startup, we were back to square one. Finding him only solved our immediate problem, but we didn’t take the opportunity to standardize our PM process.

Without a standardized process, we only discovered problems too late when a product was about to be shipped.

Us founders and early team members developed many of our best practices in project management through iteration. But the problem became when the company grew beyond 10 people and we had junior developers with less experience, we didn’t have documentation to help them onboard to our standard fast enough. As a result, our company also couldn’t take on more jobs even though there was a demand because I couldn’t handle them all. Basically, I was stopping my company from growing.

Realizing our PM expectations were unrealistic.

Photo by Christian Joudrey on Unsplash

As a small tech company in Hong Kong, we are challenged to find candidates who fit all the requirements. We cannot compete with corporate firms that can pay more, and probably require less skill. So instead, we have begun investing in a team of PMs. Some were hired directly as a PM, while others were shifted from other departments (such as QA) into a PM position.

We created a PM learning ladder.

Photo by Fernando Reyes on Unsplash

After the painful lesson we faced with our second PM leaving, I started creating a PM training process. We currently have 5 PMs managing 16 active projects and 10 follow-up projects. All of our PMs are expected to have some understanding of the following: UX Design, technical knowledge, product design, analytics, project management, client communication, internal communication.

Skills required are:

  • UX Design: foresee potential UX problems, learn about the latest technologies independently (i.e. how ARKit in iOS11 should work in terms of UI and UX)
  • Technical Knowledge: Able to give ballpark / estimation for clients. Basic coding knowledge. Understand 3rd party system integration details. Able to read API docs (i.e. payment gateway, 3rd party services API, authentication)
  • Product Design: Can spot bad user stories design.
  • Analytics: Run the hypothesis -> Experiments -> Data cycle consistently and correctly
  • Project Management: Manage multiple (2–5) projects with high-quality control of schedules, people, and resources; predict and track dependency issues
  • Client Communication: professional communication with clients; manage client expectations
  • Internal Communication: Connect relevant team members, follow-up with tasks, take feedback, and find resources

As our project managers become more experienced, their understanding and ability to analyze and advise increases for the previously mentioned skills.

Support PM

  • new to the role, and will be coached on all tasks
  • will join meetings, but will not be expected to run them
  • Example: will join client meetings, and follow-up e-mails to clients must first be checked by a Senior PM

Associate PM

  • Takes ownership of projects, with heavy supervision
  • Will run standup meetings with supervising PM attending; plan weekly deliverables and take ownership of daily tasks
  • Example tasks: prepare notes for client meetings, manage project’s Waffle board and Basecamp project portal

PM

  • Takes ownership of tasks, with some supervision
  • This is for a PM with enough experience, (e.g. track record of good communication with client, sensible decisions in project management). Does not need supervision unless requested.
  • If major decisions / technical explanations are needed, the PM should request supervising PM and developers to join such client meetings together to ensure the quality of communication.

Senior PM

  • The senior PM is expected to take fewer projects that involve direct control and take up an overseeing role at Oursky to make sure different projects are up to standard.
  • Helps resolve escalated problems from other project managers, and then coordinate different resources to resolve the problems.
development PM
Oursky’s Waffle project management for Skygear.io

What I would do if I were to start over

My biggest advice to other project managers with growing teams is to find your next PM before you hit 70% capacity.

The PM helps guarantees the quality of client projects. If you are near your limit, you will not be able to spot problems in the product until late in development, which means too much effort is wasted redoing things. You will also not have capacity to think about high-level things such as how to train up your PM team and it will take longer for you to guarantee that they have the standard you want.

I am just as busy now as I was when I was managing 10 projects on my own. But because my PM team can cover most of the day-to-day things such as “daily focus” areas, client reports, and accepting new features, I can now take a step back and analyze our company’s performance at various stages such as our project estimations for clients and optimizing our development cycle. When I have time, I will share my learnings on those too!


Building an app? Our free developer tools and open source backend will make your job easier.

Leave a Reply