Time estimation, tech debt and architecture, management approach – these are the hidden meanings behind the stated pain point for many engineering org, “our team lacks capacity”. In this article, we’ll share our insights into how to project manage in software development. We share anecdotes from our experience and legendary examples in the software development industry.

Ari Ross, a seasoned Product Manager and Product Delivery Optimization Expert at PYGIO, discusses common pitfalls that prevent a project to be run effectively, such as: timeline management, tech debt/architecture, development approach.

Whenever I ask “What are your current pains?” to someone from the software product company, I hear “We don’t have enough engineers to build XYZ features”.

People in software product management tend to believe that the only thing that slows their product’s growth is their inability to hire as many software engineers as possible. And if they were able to hire 2x, 5x, or 10x more engineers, they would launch all those magical products/features in no time! (Most of their features took years to build). And they’d finally accomplish all the delayed projects that they felt were dragging on them and delaying growth. And of course, they’d also be able to start developing shiny new features/products.Let’s think slowly about it. To avoid our human bias which suggests we are lazy and want to take shortcuts, let’s unpack the best ways of work before starting a new product build.

Time Estimation

Let’s use a practical example to illustrate that exogenous factors usually land up doubling or tripling the amount of time estimated to complete a project.

The following is not a fictional story. This happened in the real world not so long ago.

Imagine a well-established, global SaaS product with hundreds of software engineers, professional managers, and millions of users around the globe. Their main offices are on both European and American continents. Let’s call it, “Ping”.

One morning, Ping’s Legal & Compliance Department received a surprise message from the EU regulator. It was a request to implement an obligatory collection field of residential address data from all the mobile app users (users had to specify this for some proof of address purposes). 

So, at the end of the day, the new Product Backlog Item looked like “Mobile App Users have to be able to add their residence address to their Profile”. 

And that feature had to be implemented as soon as possible (let’s say it was 1.5 months). Because that requirement was imposed by the EU information authorities, the Company was looking at the risk of millions of euros in fines in case they did not comply.

So, with all that said, how much time do you think it took to add that text field to the mobile app interface? It was 2 years. Yes, not 2 weeks, 2 months, or 2 quarters. Two. Freaking. Years.

Regardless of all the fines and lawsuits, it took Ping, the Global-Multinational-Intergalactic Company 2 years to add an API endpoint, add a mobile app field, connect all those things, and release it to Prod/Stores.

So, does team capacity really matter? Or maybe it’s something else?

The learning:

The underlying issue here is that the deadline was imposed and not self-determined. When these unnatural feature requests are put in the back-log, they get deprioritized.

Every team/department of Ping had their own backlog / list of tasks, hence their own priorities, hence additional delays caused by queues.

We don’t know why, but we see that product owners and heads of engineering prioritize work they want to do rather than work they should do. This is human pain avoidance, as studied by Daniel Kahneman and Amos Tzersky. Ultimately, in the case of Ping, this led to a 16x delay and millions of Euros lost.

The solution:

Project managers should enforce stricter, non-bias product hierarchy rules (effectively playing the Product Manager’s role) – this is the best way we’ve found to maintain a backlog, while prioritizing what the business actually needs to get done. 

Is this something your customers have asked to build?

Or 

Is this just something your CEO has asked for?

Tech Debt and Architecture

Have you been here before? … We have and here’s what we learnt.

Here’s another example we enjoy sharing – every time a Product Manager wants to make the smallest change in the application, it inflicts a crazy amount of stress: any minute engineers can say something like “We have to rewrite half of our app to make the change you’re asking for”. There are three main reasons for that: (1) poor solution architecture and other implementation-related issues (… caused by 2) technical debt (… caused by 3) Product Manager trying to shrink Time to Market.

Technical debt is a concept in software development that refers to the “cost” of choosing an easy solution now instead of using a better approach that would take longer. Imagine you have a quick fix for a problem, but you know it’s not the best solution in the long run (PMs will know this dilemma all too well). If you choose the quick fix, you accumulate technical debt. Just like financial debt, it needs to be “paid back” later, often at a higher cost, because it can lead to more complex issues down the road, like bugs or reduced productivity.

The argument for choosing the “easier route” is that Time to Market is the number one or two goals to optimize for in a start-up.

The learning:

The complaint, “We need more engineers”, never exists on its own and is seldom the root cause of the team’s pain. There is a belief that “the more engineers we add to the team, the faster they will build new features”. But we all know that “nine women can’t make a baby in a month”, right?

For example, if you have an architecture where each major client has a separate branch and instance of the codebase, this makes dev effort N times more onerous. 

The solution:

So, to better understand these delivery and system issues, we have to look at the product as a whole and find the best point to reach our Optimization Goal (the Optimization Goal targeted which results in Technical Debt, is speeding up Time to Market). We should understand when we should go slower, review Architecture Quality with painstaking detail, and when we can afford to be less accurate, scalable and secure.

But what does “Architecture Quality” usually mean? Quality often pertains to non-functional requirements, those of which every CS grad has learnt and hopes to practically deploy when work starts.

The trade-off must be made clear by the Product Manager (and CEO) – if we take this shortcut, what do we gain now, and can the future cost be tolerated if we take this path?

Are you able to deplete your stockpile of tech debt in the future? If the rate of new feature development is greater than your rate of tech debt depletion, at some point, this will become an insurmountable debt and potentially halt new feature development.

Management Approach

It’s important to ask yourself, “Should I keep investing in building/improving this feature?” at least once a month. Revise your decisions constantly, even if today you are 100% right, tomorrow the wind of change will come, and you’d better be ready. Here’s an example of a grand project, that turned out to be crazy expensive ($2.1 billion instead of planned $93.7 million).

In 2010, President Barack Obama signed the Affordable Care Act (ACA), known as Obamacare. This healthcare reform aimed to provide affordable health insurance to more Americans. The platform HealthCare.gov through which people could compare and buy their insurance was rolled out three years later…and promptly collapsed. The site was unusable and only 1% of people who tried to register could enroll. 

The learning:

Among many reasons why the project did not turn out an overnight success was poor project management and leadership. Centers for Medicare and Medicaid Services (CMS), the agency responsible for the project, turned out to be ill-equipped to do the job. CMS hired a huge team of contractors (55!), and started managing the team like a normal “build a standard chicken coop” project in a situation where they needed to do an “out of the box solution”. The project scope was not properly reviewed and understood, which led to poor assessment of the website’s technical objectives. 

The solution:I would illustrate this project management misstep with the help of the Cynefin Framework. Leaning in the graphic below, this Obamacare project was managed as “Clear” (sense-categorize-response), but not as Complex or Complicated, which require flexibility and the ability to sense the wind of change.

So what happened next, after the “Alarm, Alarm” from the White House, a high profile Silicon Valley troubleshooter stepped. Over the next six weeks, a small team of engineers made the website operational: fixed major system defects, increased system concurrency, and improved website page responsiveness. 

It’s important to understand the level of complexity and unknowns your software product is designed to solve. Are you operating in a “kind” environment, where the solution set is deterministic? Or are you operating and solving problems in an “unkind” environment, where the solution set to the problem you are solving is stochastic and random, and you need to approach the problem in a different way?

Summing up

When your software team/client tells you that she has a problem with capacity, you should not immediately believe her, you need to look deeper. Use the root cause methodology, the Five whys (5 whys). At PYGIO we provide first and foremost consulting: look under the hood of the client’s business (layers of problems are deeper than obvious). 

About the author:

Ari Ross, Product Manager and Product Delivery Optimization Expert at PYGIO

Innovative Product Manager with a track record of driving results. Passionate about crafting products that enhance people’s lives through a strong, evidence-based, customer-first approach. 

A natural cross-functional leader with over 10 years of experience in getting people together around building products across varied markets.

Holds internationally recognized certifications in Project Management, Process Optimization, and Building Scaled Software Products (PMI Project Management Professional®, Lean/Kaizen, Large-Scale Scrum (LeSS)).

Huge fan of Systems Thinking, Radical Candor, Data-driven Decision Making, and Extreme Ownership approaches.

Specializes in creating and engineering software products that integrate seamlessly into ecosystems.