How to Manage Engineering Projects at a Startup

This blog post, initially intended as an internal guideline for our startup’s wiki, has been refined and expanded for a wider audience. It aims to encapsulate our philosophy and practical approach toward project management in the dynamic environment of startups.

Before diving into the details, let me address two extremes we want to avoid.

1. The traditional waterfall model, characterized by its linear and sequential approach — from gathering comprehensive requirements to exhaustive design and coding — often falls short in dynamic environments. Its inflexibility becomes a significant hindrance when changes arise, leading to potential chaos.
2. At the other extreme lies the ‘Cowboy Coding’ approach, which eschews planning and design under the guise of agility. While it may offer a quick start, this method typically falters in addressing complex problems effectively and maintaining quality standards.

Where do we stand? Over the years, we’ve leaned heavily into the agile side, albeit with a strong aversion to ossified scum. By ‘ossified scrum,’ I’m referring to a form of the scrum methodology that has become overly rigid and bureaucratic, losing the flexibility and adaptiveness that are core to agile principles.

However, this article is more of a narrative than an absolute recipe. You cannot manage a project solely by following a written procedure. Software is messy; human relations are even messier. These two intersect in project management, requiring improvisation when things don’t go according to plan.

Responsibilities

This one could be quite controversial. We centralize a lot of responsibility and decision-making power in the hands of technical leaders. Typically, such a person is responsible for prototype and design, planning and controlling the project’s track, task assignment, and some level of implementation. This approach allows for fast decision-making since one person holds the entire project in their head. However, it’s challenging; it requires someone good with both technical and managerial aspects. It might not sit well with those who believe good decisions come from groups. This leader’s role is to synthesize everything from the group into an actionable plan.

Project Stages Overview

Our project management process involves several stages: initiation, design and planning, execution and controlling, and closing. These stages peak and fade but run concurrently, not sequentially like in the waterfall model. Changes and unknowns requiring updates are common but manageable.

Initiation

First, no 20-page project requirements document (PRDs). I recall reviewing a ten-page testing plan that was mostly filler. Our guiding principle is “no fillers.” We aim for lightweight documentation and meetings, focusing only on essential details. Regular communication, albeit concise, is crucial for alignment and clarity.

Design & Planning

We usually figure out the ‘T-shirt size’ of the project quite fast. Detailed estimates often fail. For smaller, less risky projects, the planning phase might be straightforward. For more complex projects, we engage in prototyping, exploring multiple approaches, and discussing their pros and cons. Architecture involves exploring and comparing options, not just drawing boxes. We invest substantial time in figuring out a good option before building.

How Much Architecture Is Enough?

I like the idea that if the architecture is done well, you can literally see the code that will implement it. However, we don’t do this. We do enough architecture for each level, providing a framework that guides development without dictating every detail. If we’re talking about several components, we explain how they interact, what the interfaces are, and so on. Then, we leave the next level of architecture to be resolved later when people start working on it.

Why this idiosyncrasy? Not pushing down all architectural decisions gives more freedom for junior people to exercise their mental muscles. Also, this approach is more agile. Creating extremely prescriptive architecture upfront may be problematic because new requirements or unknowns won’t fit well and will require substantial rework.

Execution & Controlling

Execution and control go hand in hand.

It’s an unglamorous but crucial job to assign tickets, ensure that team members work on the most critical items, break down large tasks into smaller ones, and check whether anyone is stuck or facing bottlenecks.

Here are several guidelines we follow:

• Work on the most critical items first.
• Integrate as early as possible, even to the extent of following a “thin line through” pattern.
• Test critical aspects of the project as early as possible.
• Keep a vigilant eye on whether things are staying on track.
• Break down large items into smaller ones, even if they are already in progress.

This phase is usually the messiest part of the project, often being the heaviest phase where most things can go sideways.

A significant amount of energy is devoted to handling the myriad exceptions that arise, ensuring information is directed to the right places, and making decisions about new developments.

Being hands-on and able to dive in and surgically assist in specific areas is extremely valuable.

In my view, a good software architect is invaluable, akin to gold. And a skilled project driver, one who actively propels the project forward, is even more precious, comparable to platinum. The project needs to be actively driven forward most of the time. Allowing it to progress naturally often results in significantly more effort and time being required, as suggested by Parkinson’s Law.

Closing 

As a project wraps up, there’s usually a flurry of activity. Your default answer should become “No.” No new requirements, no improvements to architecture, and no bells and whistles. It should be a drive toward getting it over the finish line. Prioritize aggressively toward the end, leaving little wiggle room.

Standard Problems

We often face standard problems like running behind. I use a green/yellow/red zone categorization for this. Our first approach is to reduce the scope and push out all the bells and whistles of the project. Communicate and solve actively if you’re in the yellow zone; make tough decisions in the red zone. Sometimes, the project doesn’t fit, and you can’t cut the scope anymore. In such cases, it’s important to communicate this as early as possible.

Sometimes, things look trivial but are inherently complex. Our standard approach is to build something small first and ensure we don’t paint ourselves into a corner. Evaluate other options if we’ve chosen a suboptimal one.

Don’t Squeeze QA Out

If the project is running late, quality assurance often gets extruded, which is a bad idea. QA should be involved early, and the project should allocate a sane amount of time to QA activities. I’m a proponent of automated testing, but many things I’ve worked on require substantial manual testing.

Summary

This ended up being more text than I hoped for, touching only the most critical aspects. We can summarize our approach as doing just enough to move forward without tripping over ourselves. 

• One person should drive the project from beginning to end, focusing on choosing a better option rather than speeding forward with a problematic one. 
• Ensure everyone is in the loop, and routinely check if the project is on track. 
• Cut scope and re-evaluate options first, moving target dates only as a last resort. 

I do realize that it ends up being a collection of different pieces of advice with a very lightweight structure around it. And I think this is exactly what we are targeting. We want to get projects out fast and with high quality. As a result, we try to cut a lot of stuff out of the process to keep it lightweight and flexible. However, it requires people operating in this environment to be extremely good.