…that failure stuck with me for a long time.
My first job out of college was with a fintech firm — FactSet. I was on a team that was working on application infrastructure, building reusable components for other development teams to build large-scale applications. Early on I was given a large, ambiguous project to work on — build a new generic platform for other developers to quickly build large-scale applications. The new platform would replace an existing, aging framework that our apps were using. It was an exciting opportunity to build something that would be extensible and leveraged by every major product that the company built.
I spent the first few weeks planning out various use cases and requirements, mostly by meeting with my manager and gathering feedback from users of the existing app framework. I then spent a month building mocks and POCs (proof of concepts) so that I could gain a more detailed understanding of user workflows and how to improve the UI/UX. Iterating for a few more months, I finally had an MVP (minimum viable product) built that was ready for primetime!
…or so I thought. After the initial teams started migrating to the platform, we quickly realized that in practice these apps were unable to use the new framework. The platform was both too generic and couldn’t accommodate each team’s specific needs, but also too rigid and unable to be customized in the right ways. After spending a few more months trying to make the platform work, I ended up having to put the project on hold in order to address other urgent projects that had been on hold. Ultimately, the new platform was frozen indefinitely and scrapped.
It was a brutal loss for me. I had poured months of effort into it, working long nights and weekends, developing presentations and detailed documentation on how to use it, and in the end it was thrown away. I was able to use those urgent projects, which were smaller in scope and well-defined, to build my confidence back up, but that failure stuck with me for a long time.
Make It So
One of the things that I noticed about the greatest engineers I worked with was their ability to take any business idea and turn it into reality, no matter what constraints they were working with. Our architects could take a proposed business strategy and throw together a plan with ease. They were able to then execute on that plan and deliver on a solution that made a huge impact on the organization. Even when failures occurred or the team ran into roadblocks, we were always somehow magically able to navigate around them and take a different path toward success.
I admired how they were able to do this time and time again, and started observing how they navigated through these projects — how they gathered information, how they devised their plans, how they iterated based on new information, and most importantly, what criteria they used to determine whether or not they were doing things the right way. After tracking these architects through a few projects, I synthesized my learnings and tried to come up with some best practices. I hoped that by following these best practices, I would avoid repeating my earlier project failure going forward.
Outcome-Driven Iterations
There were a few common themes among the successful projects:
- Detailed requirements were gathered and agreed upon by all of the stakeholders before starting development: All requirements were gathered, and then split into two buckets — what would be included in the MVP and what would be queued for a later release. Conversations were held with stakeholders to agree on these buckets before starting implementation.
- A project timeline with major milestones were developed and signed off by all major stakeholders: Once the requirements were agreed upon, the next step was to lay out the major milestones of what to expect and when. The sequencing of dependencies was also made clear at this point, so every team knew what they had to do in order to meet each milestone.
- Stakeholders were kept up-to-date regularly about the progress and any modifications to the requirements or milestones: There were regular updates communicated through both email and meetings. Any changes were discussed internally within the team and once everyone was in sync, those changes were shared with stakeholders as soon as possible.
Although these themes aren’t revolutionary, they were the elements that separated projects that were well-received by their stakeholders — product managers, executives, and board members — from those that weren’t. The engineers leading these successful projects held themselves to these best practices regardless of the circumstances.
Since making these observations, I’ve applied these practices to every major project I’ve been involved in. At FactSet, I used it to plan out the modernization of multiple legacy systems, and a huge infrastructural overhaul of our financial software platform. With my next role at Flatiron Health, I used the best practices to develop a Patient Assistance platform to enable patients to receive financial aid for chemo treatments sooner, to help plan and execute a multi-year regulatory project across the entire organization, and to build a roadmap for interoperability within their health record system. The tight communication with stakeholders was key in each and every project, allowing me to make appropriate technical decisions while ensuring that stakeholder expectations were fully managed and aligned.
“Yo. Got an idea to work on…”
The latest example I have of using this framework is a recent collaboration with legendary entrepreneur Nat Turner. He approached me with an intriguing business idea in May of 2020 to build a cloud-based auction platform that was highly-scalable. This software solution would evolve to be the primary platform for Goldin, driving their multi-million dollar auctions and providing the foundation for an extensible marketplace ecosystem. While Nat focused on the business-side, I worked with each major stakeholder — the executives, the internal Goldin teams, and many others — to apply the framework and plan out the high-level requirements and timeline for the platform within the first month. Over time we hired a highly talented development team to take this initial timeline and set of requirements and iterate on them to ensure that all of the stakeholders’ needs were addressed.
We ran into multiple obstacles along the way. However, the team continued to provide transparency as quickly as we could to our stakeholders, and made sure that we were making decisions together with them to align expectations. In the end, we didn’t end up delivering the platform that we had originally outlined at the beginning, but we ended up with what was deemed by all to be a huge success and the right foundation for us to build our future on. The platform (which was predominantly built by only 4-5 engineers!) provided everyone with an example of how to apply the framework above. The team can now feel that much more confident about taking any proposed requirement or idea and making it a reality.
It took me some time to regain my confidence after the major project failure early in my career, but thanks to the amazing engineering leaders I got to work with over the subsequent years I was able to develop these best practices and turn that failure into multiple successes. Hopefully they will help you to achieve even greater successes in your career!
Change the world,
Dan Van Tran
