Turning Classic Mistakes Into Key Technical Learnings

Setting a technical direction—and sticking to it—is an important factor in delivering a consistent ecosystem to meet the complexity inherent in clinical trials. As I shared in a recent post, running three software products—eConsent, IRT, and eCOA—on a single platform at a sophisticated level of customization requires a well-established foundation. And for Suvoda, that foundation is our guiding North Star architecture: the technical direction we established, stick to, and champion throughout our organization. 

It may sound like a straightforward solution, but it took a bit of learning to establish the importance of this critical step. In my past roles as leading architect at premier companies in wide-ranging industries such as the gaming, streaming, technology, and financial services industries, I uncovered (and learned through) some classic mistakes. As I delve into examples of what not to do, keep in mind that it was through evaluating and understanding the anti-patterns—that is, the opposite of successful solutions—that I arrived at what works well for us today. 
  

Classic mistake 1: The big rewrite 

I was lucky enough to be involved in a complete disaster of a project back in 2002 at a venerable financial institution. This is a company that built Cobol-based systems and C++ systems to manage the derivative trades running through London-based exchanges. A consultancy came in with the idea to rewrite all of those systems into one very generic system in which the core financial products would be modeled as a series of cash flows.  

This company had a legacy team—the one that had been in place—and a next generation team and began putting more value on the next-gen side. But the systems they called legacy were delivering immense value and upheld a tremendous amount of business cases, as they had for 30 years. Now the company was hoping to re-write everything in parallel development, which meant that it was very hard—even if it was executed perfectly—to catch the moving train of the legacy systems as they moved forward. And unfortunately, the “big rewrite” completely failed.  

Now an argument could be made that every now and again, you do have to rewrite a system completely. But when I rewrite now, I try to scope it down to the smallest thing I can rewrite as possible to keep it in a bounded context and recognize the value in existing systems. It’s a massive anti-pattern to devalue the teams that built the systems that got you to this point and to try reengineer them without the full reflection and an appreciation of the great difficulty involved. 

Classic mistake 2: Not delivering incremental gains 

It’s important to deliver incremental gains along the way so that the organization doesn’t lose sight of its technical direction. A key component of setting and upholding a lasting technical direction is alignment—that is, getting buy-in from everyone involved with the technological development. Without seeing incremental gains, a stakeholder in the company could lose sight of its worth and decide to cancel the project.  

Classic mistake 3: The big vision that can’t be achieved 

Another classic mistake to avoid is the big vision that cannot be achieved. If the project does not seem realistically achievable—for example, if it requires too much effort, or takes a leap of logic to believe it can actually be accomplished—the loss of alignment and buy-in with those working on the project can lead to apathy. But when people believe the desired outcome is possible, that it will work, and that the needed effort is manageable, they will often work super hard to make it happen. It’s like a tipping point. So, the vision must be appropriate for what the company can achieve.  

Classic mistake 4: Not solving the right problem  

Avoiding the real issues at hand can feel satisfying at the time, but that approach just delays the inevitable. I’ve seen it happen when there’s a large monolith with a lot of old business logic in it, people stay away from the monolith problem and focus on smaller issues. That happens even when there’s an underlying understanding that fixing the small challenges won’t have a significant result. Instead, you’ve got to attack the heart of the problem, even if it’s hard, and work to that established North Star goal and an incremental path forward. 

Classic mistake 5: The hype trap  

In the technology space, we’ve seen new trends surface every so often that seem to become the “hype” thing to do without unpacking the benefit or product value. So when I go into companies, I listen to the excitement around the latest trend and ask questions. The answer to “Why do you want to do this?” is sometimes, “I heard it’s better.” And that is not necessarily true. Instead, you have to look at the business benefit and make sure there is a valid business reason to buy into the hype. In the end new technologies, techniques, and ideas are really just extra tools in the toolbox we have for engineering, and it’s important to select the right tools for the job. 

Classic mistake 6: Not managing upwards  

It’s also important to remember to keep key stakeholders informed about what is happening with the project and make sure they remain aligned with the overall goal. This is similar to communicating incremental gains, but it’s especially important to help ensure that the people who accomplished the task and took the risks also earn the rewards.  

For example, I was once on a project that was super difficult—a complete rewrite of my company’s signature product. The team worked super hard and got it done (with bumps along the way), but because we were not managing upwards, another group overrepresented their involvement to upper management. That’s a classic anti-pattern because the people who took ownership of the project were not involved with the risks of the technological process and did not get the learnings from it—which creates engineering inefficiencies going forward. It is important for the team who experienced the process to move forward with what they’ve learned and to see the success of putting those learnings into practice. This is why it is important to keep a “line to the top.”  

Ensuring balance: The engineering triumvirate  

It is important for a company to have checks and balances in place to avoid the pitfalls of these classic mistakes and to better turn challenges into key technical learnings. At Suvoda, we have an engineering triumvirate in which three pillars of our company uphold our core alignment at the top level. For us, that is: 

• Product 

• Engineering 
• Architecture 
  

The product discipline and direction are preeminent here—engineering and architecture can inform and give feedback on the direction, but at the end of the day the product we are building and the prioritized list of features must be the prime focus. Then we have our Vice President of Engineering, who keeps our teams accountable, and our Chief Product Officer and the team helping with the architecture. With our engineering triumvirate in place, we can better uphold balance, ensure alignment, and avoid significant mistakes.  

I believe every company has the core knowledge and expertise to create a successful technical direction that is achievable. It’s just a matter of finding alignment.  

Through upholding our technical direction, finding our center of gravity by focusing on what we do well, delivering incrementally against our goals, and learning from classic mistakes like those I’ve outlined here, we maintain a nimble environment that delivers for our customers. And that’s an exciting foundation for where we’ll go as a company in the future.