Although this text seems related to software development projects, most lessons are also applicable to projects like planning a wedding, renovating a kitchen, and writing a book. I marked lessons with bold.
I’ve been managing several large, months‑to-years‑long, cross‑team projects. As these projects tend to go over schedule and budget, I learned to take a different approach: plan slow, act fast. The bigger the project, the more planning I do.
When we choose the Silicon Valley way and “move fast and break things,” we often discover flaws in our approach in the late stages and must rebuild the solution or create workarounds to address them. Moreover, teams’ estimates are substandard or often plain wrong, which exacerbates the situation by creating a false perception that we will…
Although this text seems related to software development projects, most lessons are also applicable to projects like planning a wedding, renovating a kitchen, and writing a book. I marked lessons with bold.
I’ve been managing several large, months‑to-years‑long, cross‑team projects. As these projects tend to go over schedule and budget, I learned to take a different approach: plan slow, act fast. The bigger the project, the more planning I do.
When we choose the Silicon Valley way and “move fast and break things,” we often discover flaws in our approach in the late stages and must rebuild the solution or create workarounds to address them. Moreover, teams’ estimates are substandard or often plain wrong, which exacerbates the situation by creating a false perception that we will finish early. Sometimes, all of these problems are together.
Moving fast and breaking things is probably one of the worst things that a large project team can do. Rushing to start the implementation of a project guarantees that the project will go over schedule and budget. When problems are complex, they require a careful and precise approach. Yet, we rarely take that approach to untangle the whole complexity.
In software projects, product managers and designers often take time to understand the problem and prototype a few solutions to test their ideas. It’s a great approach to invalidate various proposals and choose a good direction. Yet, this is rarely mirrored on the engineering side. Engineers are sometimes involved early on in the product and design decisions, but they rarely touch code until implementation begins. Once the project kicks off, they act quickly, but end up moving slowly and often exceeding the schedule and budget. So, what can we do better?
Once the team understands the complexity, they should identify the smallest repeatable module. Imagine building a skyscraper. Consider building the whole thing at once; the project looks highly complex. But if the plan was to build one story of it, it appears simpler. So, the plan for the skyscraper, as building the same story over and over, makes it simpler. Although finding that module is difficult, once the team finds and builds the first one, the next iterations become easier and more predictable.
Modularity also supports contingency planning. The reality is that something always goes wrong in a large project. I’ve never worked on a project where everything worked as expected. That’s why there must be a contingency plan and backup approaches. Modularity helps with this because human brains are better at thinking in smaller pieces rather than comprehending the whole complexity. When we plan slowly, we consider risks carefully and choose the ones to guard against.
When it comes to teams’ estimations, we need to change our approach. Instead of asking people to estimate the time, we need to examine any similar work that’s been done before. Humans are almost always wrong by a significant margin when it comes to predictions. Using previous data as a baseline and helping to anchor and adjust estimates is a more accurate way to build a timeline.
The whole idea might sound like going against the bias toward action I advocate for. I still believe that learning comes from action. However, the learning should move to the beginning of the process: planning. Learning from mistakes is cheaper in the early stages of a project compared to later stages. Examining and moving the solution of the most complex parts to earlier phases, prototyping in code, and building contingency plans keep the project on a realistic timeline and increase the chances of finish on time.
Good to Great
Good: This one is for software engineers—Joy & Curiosity Newsletter. I’ve been following for a while. It gets better every time. Better: I’ve been reading Lorin’s blog about resilience engineering for a long time. Great: Nothing this time. Great things are rare.
Recently, I thought/wrote about
I didn’t share any writing yet but I’m thinking about one thing that I’ll post an article soon:
We can’t disconnect from our friends anymore. We carry emotional and relationship baggage with us wherever we go, often due to the influence of social media. We used to let go of friends when we moved on to somewhere else and found new ones on the way. We didn’t know what old friends were doing. Now, everyone we meet comes with baggage. We are in their life constantly and can’t disconnect at all because unfollowing on social media is considered rude (even though we might not see the person again).
P.S. I wrote about how engineering managers lead big projects before.