4 Factors That Shape a Technical Direction That Lasts

Author: Andrew McVeigh, Chief Architect

Snapshot:  

• Alignment with Product Direction: Suvoda closely aligned its technical direction and product strategy, ensuring technical choices supported the company's long-term vision, particularly maintaining and enhancing customizability. 

• Establishing a "North Star": Suvoda defined an ambitious long-term goal and developed a conservative approach to achieve it, enabling the technology platform to manage highly customized systems effectively. 

• Transparent Communication: Continuous, transparent communication about the technical direction was crucial, allowing for feedback, fostering buy-in, and ensuring everyone understood the path forward. 

• Encouraging Feedback: Suvoda prioritized gathering authentic feedback through Request for Comments (RFCs), ensuring all voices were heard and fostering a culture where critiques were welcomed and addressed constructively. 

In the often-complex clinical trial space, effective trial management technologies are critical to ensuring an efficient process from start to finish. Suvoda runs three products—eConsent, IRT, and eCOA—on a unified SaaS platform, with the goal of seamlessly managing mission-critical, time-sensitive patient interactions throughout the clinical trial. We support immensely intricate and often varied study requirements. And in doing so, we offer a sophisticated level of customization for clinical trial software.  

So, how did Suvoda create a technological foundation for our continued growth and success? And how can we learn from our past to set a successful strategy for the future?  

It begins with setting a clear technical direction. I came to Suvoda with a PhD in Software Engineering and a background leading architecture at companies like Riot Games, Hulu, Amazon, and LiveRamp. In a recent keynote address, I shared my insights on setting a technical direction and sticking with it—and outlined why the following four steps have been so pivotal to Suvoda’s success. 

1. We got clarity on the product direction

It was vital to make sure our proposed technical direction was in alignment with the product direction. To do this, I worked closely with Suvoda’s Chief Product Officer to make sure we had complete alignment. This is important, because it is dangerous to make technical choices and move in a technical direction that’s not helping the product. We asked questions like: 

• Where does the company see itself in five years? 

• What is the vision?  

• What do the CEO and sales teams care about?  

• What do our customers need? 

• What does the CPO want to achieve?  
  
  

It’s often the case that a company gets to an inflection point that drives its evolution. At Suvoda, we discovered that to move the company forward, we needed to retain that sophisticated level of customizability, especially for our IRT product. We also needed to increase the efficiency of customization. Those learnings helped set our product direction.  

Next—and this may be the most important point—we set what I call a “North Star” architecture, a focal point for Suvoda as we moved forward. As a company, we determined where we wanted to go and identified our ambitious goal. And then we developed a conservative strategy to get there.  
 
An effective technical direction can be built incrementally without sacrificing the speed of delivery, and a “conservative” path can mean different things depending on the company. It can mean “let’s move very quickly and try not to break the technology too much,” or it can mean that we must move slowly and cautiously because we work in a complex environment and cannot afford to break the technology at all. At Suvoda, we focus on incrementally improving and bringing the current system into the North Start architecture. It’s often possible to do this quite efficiently. But both elements need to be defined in concert: the North Star, and the safest way to reach that ambitious goal.  

The core of our North Star architecture is a powerful way to manage a set of highly customized systems as a multi-tenant SaaS platform. This supported us in creating a platform that efficiently deals with large variability, addressing the tension between promoting our standard system and offering lots of customizations. Because we work with very complex clinical trials, our North Star needed to match the company’s ambition. And I’m incredibly proud that we just received notice of a patent allowance from the US Patent Office for the North Star architecture. 

It's often very easy to come up with an ambitious North Star architecture, but it can be very hard to make it work in practice. I’ve often customized the North Star for easier implementation, even if it means making the architecture a bit less ambitious. I see that approach as a success, not a compromise.  

The third thing we did, and continue to do, is communicate transparently. Everyone needs to know where we’re going and why we’re going there, and they also need to be able to give us feedback if they don’t like it. Then we can process feedback in a way that gets buy-in from everyone.  

I aim to over-communicate, highlighting the benefit of the North Star architecture and listing its characteristics all the time. I make sure people understand why we’re going in this direction, what the pros and cons are, and what they can expect along the way. I do not want to set up a North Star architecture incrementally and then have people complain about it behind the scenes in a way where they’re never heard. I want people to know their perspective matters, and it is important to take their feedback and process it in a way that turns critics into allies. 

It is important to listen to authentic feedback and get others to champion your technical direction. We want Suvoda’s team to be champions of the technical direction, and we want that optimism to permeate through the company. 

To do this, we published every architectural decision as Request for Comments (RFCs). These are basically shared documents that allow people to comment, but the key thing is that there is one document owner. It’s designed to become a coherent stream of thought, where the RFC owner’s job is to listen to feedback and take that into account. That RFC then becomes that vehicle where people can put forth their ideas, and at Suvoda those ideas and comments roll up conceptually to me so that I’m looking at the coherence of the architecture across everyone. 

I learned this technique from working at scale in investment banking, and we did the same thing at LiveRamp, Hulu and Riot. When I review the conversation in the RFC, we then assess and pivot based on feedback. We work hard to create psychological safety around giving negative feedback, because the last thing I want is for anyone (whether a junior or senior contributor in the company) to share constructive comments or complaints about the architecture and get shut down. We like to aim to understand, and we like for people to feed heard. And that has worked out pretty well. 

Following our North Star 

By going through this process, we found our center of gravity by focusing on what our teams do well. And we found that because we have a sophisticated and powerful IRT system at the core of our platform, we can deliver quickly and iterate on that technology.  

But every company reaches an inflection point when it’s time to grow, expand or move to the next level. That’s where Suvoda was at the time, and that is where our incremental North Star approach became pivotal to our technological success:  

• We got clear on our product direction 

• We overly communicated the direction and its value 

• We never missed a chance to critique or explain our own designs 

• We worked hard to create psychological safety around negative feedback 
• We focused on what our teams do well  
  

A good technical direction allows value increments to build in a conservative way without sacrificing speed of delivery. With this formula, every company can apply the core knowledge and expertise to create a successful, achievable technical direction. 

This is the first in a two-part series. Stay with us as we continue the conversation and uncover how to turn classic mistakes into key technical learnings.  

CASE STUDY

Author

Andrew McVeigh
Chief Architect
Suvoda