Knowing a project may fail should not deter you from pursuing it. Yes, it may fail, but it’s not a personal failure. There are so many opportunities for software engineers, I wouldn’t worry too much about that. I would worry more about missing a big opportunity.
Beier:One of our engineers joined a startup as a CTO, and had to attend board meetings. He asked me what his responsibilities were. Do you have any memorable experiences when you had to go beyond your skill set as a software engineer?
Alexis:Fundraising certainly gets you in a room with people who are very different from software engineers. Acquisition conversations as well. Once you start getting customers and you’re in a technology leadership position, you’ll inevitably be facing those customers. And unless you work at a company whose customers are software developers, you’ll be engaging with people with a different background than yours—different vocabulary, priorities, income and outlook.
Board meetings are interesting because they involve next-level conversations about a business’ constraints and opportunities. So you need to be at a different level of thinking to participate in those conversations.
There is a step function between thinking about a piece of software and its complexity, and thinking about a business as a machine to grow revenue and have an impact on the world. It has all kinds of inputs, constraints and opportunities too, but you’re trying to create a machine that will generate profit in the future, while making the world a better place. You’re investing in it in various ways and you’re monitoring its performance to see where it’s tracking and how it can grow. A lot of systems thinking and engineering concepts are actually quite applicable to business.
Beier: You started your career as a technical person—writing code, building products—how did you find the transition from engineer to technical leader?
Alexis:The way I approach it is to ask myself a question at every step of my career: what is the right thing for me to do to optimize my impact, given the people around me. Given the constraints, opportunities and what needs to happen. That way I know what I can do, I know what the challenges are, and I can forecast my impact.
If the right thing to do is to take a week and rewrite an Ionic app with React Native, even though I’d never built an app in React Native, I would do that. If it’s understanding what the product needs and then translating it into technical requirements—if I conclude that’s the best use of my time, I would do that.
I’m not coding now, not because I find it uninteresting or not impactful, but given the amazing team I’m working with, there’s someone else nearby who is much more effective at solving those problems. So you need to think about optimizing not only your personal impact, but the impact on the organization by putting the right people in the right places.
Beier:Let’s talk a bit about technology. One of the challenges technical founders face today is that there’s so much choice. What’s your philosophy of choosing the right technology to build a product?
Alexis:I take a layered approach. You want your fundamental, foundational technologies to be really well understood by the people who are going to be working on them. There’s a correlation between familiarity and robustness, because in order to understand something it takes quite a bit of time. If people deeply understand Postgres or relational databases, there’s probably a measure of reliability in them. When we started Dialogue, Amazon Web Services was already a foundational technology. The foundational services were already there. So we decided we were going all in on AWS, that it would be our foundational layer.
As you move up and start looking at specific opportunities or specific subsystems, for specific challenges or features, you can become more aggressive, more exploratory with the technologies you choose. If it works, you have a subsystem that’s working well. If it doesn’t, you haven’t destroyed your entire system. So the risk is lower but the upside is still there.
That’s why I don’t shy away from trying new things. I try them in isolated environments, where they’re not foundational to what we do.
Beier:What are some of the major technical milestones that Dialogue has achieved that may not have received much attention?
Alexis:We were building for a mobile phone and wanted to support both iOS and Android out of the gate—we went with Ionic first. It was quite elegant and we got something working quickly. But tiny details, like the keyboard coming up and down, turned out to be almost impossible to solve. So we had to switch from Ionic to React Native.
We rebuilt apps for patients using React Native and apps for healthcare providers in React. But React Native on Android was not on par with iOS, so we had crashes and memory leaks that we simply couldn’t solve ourselves. So we had to rewrite the Android app in Java, and we left iOS on React Native. We ended up with a situation where we’re using React Native for a single platform. Now React Native has advanced—it’s robust enough to build Android applications. So we took the iOS app in React Native and we’re importing it and recompiling it for Android.
Another milestone was when our largest customer came in and said, mobile apps are great, but we need a web application as well. We had to essentially build a brand new application in time for launch by that customer. It was an amazing effort and we made it. That was a fantastic achievement by the team.
A third milestone happened during the height of the pandemic. A large insurance carrier came to Dialogue and said, I’m going to take your service and distribute it to all my customers, to make it free for them. They were launching in a couple of weeks. It required a speed that was unheard of. We had to do some very sophisticated software engineering, because this was a scale at which software engineering really matters: the transactions per second, the way the database is organized, where the caching is, where you copy the memory. We pulled that off and achieved a 10X scale of the system.
Beier:Knowing what you know today, would you go through the same path, from Ionic to React Native, then to Native, then back again to React Native? Do you think that’s the natural evolution of any software, a hard lesson learned? Would you just go straight to Native now?
Alexis:It’s a tricky question. You’re making decisions at a point in time, with technology and knowledge of that moment. The best way to consider the question is to ask if you made mistakes in the decision-making process. Maybe you didn’t access information available at the time that could have led you to make a different decision.
It’s hard to say, but I think the first approach of using Ionic was a bad idea. We shouldn’t have attempted that, because the delta between React Native and Ionic was not that big. We should not have touched Ionic, and gone straight to React Native. I think it was a mistake, and I sensed that but was not comfortable going with my intuition.
But this shift from Android React Native to Native and back—it sounds weird, but I would make the same decision with the information I had at the time.
Beier: That makes sense. It’s not about right or wrong decisions, it’s about being adaptable.
>“…for every decision you make in technology, you need to know that you may be wrong. The best minds in computer science are often wrong, so of course you can be wrong too. That needs to be a part of your decision-making thought process.”
Alexis: You’re absolutely right. Another takeaway is that for every decision you make in technology, you need to know that you may be wrong. The best minds in computer science are often wrong, so of course you can be wrong too. That needs to be a part of your decision-making thought process.
Beier:What’s your hiring philosophy for early-stage engineers—the first one to five engineers?
Alexis:I would not look for specific technology experience. You’re not going to be able to make all these technology decisions yourself, so you want people who are flexible, able to think creatively about solving different problems, and able to use a range of tools. Not necessarily a deep expert in one thing.
Beier: Hiring is relatively easier than firing someone. If you’ve found you hired the wrong person for a role, how do you deal with that?
Alexis:There are a couple of things to keep in mind. First of all, the person is not wrong—what’s wrong is the match between the person and the role. And the match is not only about how the person performs, it’s also about your expectations. Perhaps you were not clear, or didn’t do enough to understand what the person can or cannot do.
The other thing I keep in mind whenever I’ve had to let someone go is that, while it’s painful in the moment, the change is about creating a better fit between a person and their role. It wasn’t the right fit—it wasn’t a question of them being a bad person.
So when I have to let someone go, I say: This position does not match you, let’s get you in a different position. It’s the fit that doesn’t work, not you.
We hire Software Engineers to build their careers with promising early-stage startups. Join the waitlist today!