I first considered starting a software agency 8 years ago. It would become Telos Labs. At the time, I was a strategy consultant at a giant pharmaceutical company. It was bringing an innovative cancer therapy to market. We needed a validated software platform to track a patient's cells. And it became my job to make sure it was available before FDA approval.
What I learned from that experience set me on a path to creating a unique engineering culture. Powered by purpose, instead of paralyzed by boundaries. Below I share more about the specific project and the challenges we encountered.
Commercializing an immune cell therapy for cancer
I joined the effort to launch this immune cell therapy (for leukemia and lymphoma) as a strategy consultant for the commercial team. Among other responsibilities, I helped develop the commercial model, create sales forecasts, and work out the logistics of getting a patient’s cells back from extraction sites. But when the software delivery seemed at risk, the commercial head asked me to lead this project. I was a software engineer who had already developed several digital products. Additionally, I had a good sense of what the commercial team needed.
The software delivery showed signs of crisis early on. The system had been created by the manufacturing and clinical functions for its use in clinical trials. I learned it had a history of missing deadlines and needing budget increases, as well as multiple vendor firings. The prognosis was so dire that our first IT project manager on the commercialization project quit after a few months, citing that the project could not succeed and he did not want to be associated with it.
But what about this business domain made it so challenging? Fundamentally, this product required an operating model focused on personalized medicine rather than the standard chemical-based model pharmaceutical corporations were founded on. The underlying mismatch of a standard pharmaceutical orientation and what was needed for an individualized therapy was at the root of most of the challenges we were to face.
The product’s supply chain started with the patient’s own immune cells which were extracted at a treatment center, packed and shipped in stainless steel containers at below freezing temperatures, modified at the company’s manufacturing site using a viral vector, and then delivered back to a treatment center for infusion. Hence, we needed to track a patient’s cells, orchestrating their chain of identity and chain of custody. It could be catastrophic if the wrong cells were infused into a patient. The criticality of tracking and identifying the cells correctly meant that we were required by the FDA to validate the system. Validation adds a significant quality assurance overhead into each release cycle, as I was soon to learn. And we faced these challenges in a strict corporate environment which had been designed for a much simpler supply chain that started from chemical substances and certainly not the patient’s cells, and was not usually comfortable with flexible or enterprising approaches given the high degree of regulations and safety concerns.
Early on, the team understood that the process this corporation enforced to create software made it very likely that the software would be late, even by years of the FDA approval date for the US. Yet most of the team members felt they could not affect change. They saw themselves against a vast and unmovable wall of the corporation's processes and structures which enforced a snail’s pace. I realized that this was a misunderstanding. While it was true the processes were heavy and overbuilt, everywhere you looked you could find unnecessary waste to reduce or opportunities to lighten the load in a way that would help us achieve our goal. For example, the system included much functionality that was poorly conceived or unnecessary. Many elements could be stripped out altogether or handled manually. In many cases, stripping out these elements made the system better as users had no use for them in the commercial process. By viewing the situation from a multifunctional and integrated perspective, a vast array of creative solutions revealed themselves.
Later I concluded that the overbearing processes had produced a bureaucratic mindset that led to team paralysis. Technology professionals saw a vast sea of unachievable requirements and despaired. They were rendered ineffective by the walls of their specialist mindset, walls of concrete and steel that this corporation invested significant effort to build up. What we needed was an injection of context from the business, as well as a sense of purpose that our work would save lives.
Grounding ourselves on purpose, and the mentality that we could take actions to correct course was enough to start moving the gears. Over the next 18 months we turned the situation around. The process was punctuated by emergency meetings, sudden brainstorming sessions and workshops to descope one more time, or reconceptualize the flow to avoid a newly discovered hurdle. But in the end we did succeed with our launch. Working with the cross-functional team to troubleshoot a very difficult situation to provide access to lifesaving therapy was one of the highlights of my career. Credit goes to many heroes who shall remain unnamed out of respect for their privacy.
The project held many additional technical and organizational challenges. It required integrating Salesforce and SAP. It was subject to massively long 8 week test cycles, due to the vendor's reluctance to automate testing. It required computer system validation, given the risk the system presented to a patient’s health. And through it all, we were subject to lack of responsiveness from the actual technology vendor – who reported into the IT function and viewed us as a captive client.
I’ve come to conclude that there are three exacerbating situations that made our work particularly difficult, and would highly recommend you ensure this is not happening in your place of work.
- It is not a good idea to split who selects a vendor from who receives services.
- Only work with people who put the company first, not their function.
- Prevent excessive functional separation. Instead strive to create a high-context environment where there is joint understanding, brainstorming and problem solving.
Learnings I applied to found Telos
I set out to create a working environment free of the bureaucratic burdens or conflicts of interest I had seen first-hand. I poured my conviction, enthusiasm in building web products, and genuine enjoyment of software engineering in addition to my skills in strategy consulting into founding Telos Labs.
Here are four elements that have filled the past years with productivity and enjoyment.
Focus on purpose and impact first and business goals or personal advancement second. I have seen how vendors come to fleece their clients. This can also happen when a specific function aims to maximize its own autonomy and power and introduces information gaps which end up hurting the company. (This can easily happen when inexperienced technologists lean into a predilection for premature optimization or over-engineering.) Therefore, it is important to suspend the hard cold logic of the market inside a company’s place of work, and to also reign in one's own preferences if they don’t contribute to the goal at hand. Solidarity and the love of doing great work (defined as producing value for the customer) have to come first. I learned from my client on this project that patients come first. In our context, we put our clients interests first and adopt their focus on their users or customers so that we can be the best partner possible.
Work strategically and with the holistic product in mind. In the sanitized corporate world, company’s often overspecialize people and segregate roles to such a degree that work becomes more difficult to accomplish. People are cordoned off into their functional silos and specialist roles and told not to cross the lines. The result is that it takes many more people, many more meetings and consultants to accomplish anything. Instead, I've found great success day-to-day in liberating team members from the shackles of specialization and letting the team shape and ideate openly in cross-functional environments. By encouraging developers, designers and product leads to problem-solve jointly, we conceive, shape and deliver an excellent product more easily and quickly.
Value code and technical people. In the experience I shared above, corporate IT viewed code and programmers with deep suspicion and almost contempt. The winning type of professional was the communicative manager, who could follow guidelines and show up with slide decks and spreadsheets. People who had no interest in software engineering were elevated to orchestrate the whole operation across the corporation, and they unsurprisingly put all their eggs into low code environments conveniently sold to them by the Salesforce enterprise sales cadre. Except technical people aren't the enemy, nor are they a different kind of person to be kept out of sight. And code is not some arcane gibberish that ruins a well-functioning business environment. Rather, it is a human artifact that translates human intelligence into machine operations. Things go better when we all get more technically savvy, and when we value code as a direct way to produce great technology. In particular, at Telos, we love Ruby on Rails (the one person framework), because it provides the right level of abstractions for technical teams to produce business results fast and with great quality.
Treat team members as people and not resources. While we tried to treat our team with appreciation and dignity and I felt wonderful appreciation from my client, the nature of the corporate culture is to call everyone a resource. I believe referring to people as resources internalizes a factory mindset that hinders forming and performing as a truly outstanding team. The impersonality of the factory is geared at uniformity, not at excellence. It takes humanity to unleash creativity, initiative and human energy. Otherwise we smother each other in dispiriting bureaucracy. At Telos we treat each other as people and try to keep the bureaucracy-speak at bay. When you treat people as people, paradoxically, you uncover their otherwise suppressed resourcefulness as initiative tends to bubble up from previously placid personalities.
The image above shows a whimsical group of paladins warmed by the heat of a Ruby gem created using Midjourney. It is a throwback to the ideal of honor (loosely inspired by the novels of Brandon Sanderson), so important to effective trust for a team and for work in professional services. I am privileged to have had a part in creating such a working environment at Telos.
Note: I’ve tried to maintain confidentiality and be fair to the facts on the ground. Don’t hesitate to reach out with any comments. I care about getting the story right. I welcome your outreach and will consider making changes.
