When Successful Projects Fail

Tell me if you’ve heard this before.

It’s a couple weeks after your app release. Reception of your team’s work has been great. The app is more polished and rock solid than a diamond ring. You and your team are basking in the glory of a job well done, when all of a sudden you get an email. 

It’s your product manager (PM) telling you team that the client has cut funding to the project. The team will be split up to backfill other projects within the company. Everyone is shook. How could this happen? What went wrong? Things were going so well.

Okay, maybe you haven’t heard this before. Maybe you haven’t experienced it. But, I have.

I was the technical lead of an iOS project for a client that was situated in San Francisco. It was a dream scenario for me. The app we created was designed and coded well. It had beautiful animations while running at a rock solid 60 frames per second. Even the small details were great, like the haptic feedback on every button press and network callback. It was well architected and was 100% crash free on Crashlytics. The rating on the iOS App Store was a cool 4.8. And here’s the cherry on top: we released to the App Store three months ahead of schedule.

The client PM (let’s call him Person X) sets up a meeting with us to discuss next steps. I’m confident—no actually, I’m cocky that there will be some type of contract extension. He tells us that despite his best efforts, upper management at his company (let’s call them Company A) will be ceasing all funding for mobile development and will not continue working with us. The app we created will just sit dead on the iOS App Store without any maintenance. I’m thinking to myself: “We did everything right. What went wrong?” Turns out, I neglected a key detail.

That key detail

As software engineers, we are taught one basic mantra: “If you write good code and deliver on time, good things will happen.” Usually, in a good team that means coders coding, designers designing, and product managers managing. And sometimes you don’t get the ideal team, and in our situation we didn’t have a Connected product manager. So that meant there was no team member solely focused on relationship management.

It also did not help that Person X, our client PM who was managing the iOS project was effectively siloed off from the rest of the company. The iOS project was just one project that got lost in a sea of other projects from Company A.

So what was the key, important detail I missed?

I was not able to convince anyone in Company A who had significant influence that our project was special.

And as a result, our project got cut from the budget. I can recall the times I chatted with the VP of Product or Director of Engineering during my client visits. If only I cut through the small talk and actually invited them to be an integral part of the product we were building. Maybe, the project would still be alive.

Projects live and die at the whims of upper management and it is absolutely vital that you prove to them your project’s value.

Key Learnings

1. Find the key stakeholders and get them involved

Usually the person who greenlit your project is the person you want to get on your side as early as possible. In my case, it was Company A’s VP of Product. Invite that person for a coffee chat and show them the great work you’ve done. Ask them for advice on how to make your product better. Your goal is to get them invested and to be part of your process. After all, your success is their success. So when the time comes to discuss investing in the next phase of the project, you’ll have someone with power in your court.

2. They don’t care about the journey—only the end

I’m sorry to say it, but immaculate software architecture means nothing to upper management. What they care about is whether you’ve delivered on time and whether you’ve matched or exceeded the project’s specifications. There’s a good chance that the people in power don’t have a technical background. Focus on delivering first and once you have proven that you’re a reliable and trustworthy software engineer, start asking for things that matter to you: clean code, using modern coding language, etc. People are more generous when they perceive that things are going well.

3. Animations and polish go a long way

I can guarantee you that the VP you’re trying to impress is going to be exponentially more amazed at a button animation that you made in five minutes than a deep refactor that took five months. Human beings are extremely visual, so it’s the small details that are the difference between whether a project lives or dies.

Final Thoughts

I understand the stresses and strains that upper management work under, and have learned that there’s a reason that the outcome—not the process—is what they focus on. As software engineers, we have the privilege of working in a world of near absolutes: design patterns are good, dependency injection is good, spaghetti code is bad, nested if statements are bad. For us, the world of coding is pretty much black and white. 

You know what is difficult? People are difficult. Finite resources are difficult. That is the grey world that our VPs, PMs, and CEOs operate in. It’s not that they don’t care about how we do things, but it is in their and our best interest to be hands off and to wait for the final product. They are not going to go out of their way to be involved with every single project. If you truly care about your project you need to step into that grey world and instead of just building code, you need to build a relationship. And maybe then, your 4.8 star rating app might live to see another day.