CTO vs COO? What’s the difference?
We sponsor TechDebates.org because we believe strongly in the idea of sharing experiences and ideas. For centuries, people have used stories to pass on knowledge. I personally believe successful tech leaders have an obligation to pass their opinions and learning on to the next generation.
At the end of January, we held a TechDebate in London on modern software architecture presented from both COO and CTO perspectives. Gabriel Cismondi, COO of iGenius, brought his diverse IT career experience to the discussion and he shared some of his experiences across multiple tech leadership roles. Thankfully, after the TechDebate, I had the opportunity to circle back with Gabriel to chat further about the topic.
Could you explain a bit about how you landed in your COO current role?
I’ve worked in IT for about 12 years in various roles, including network and systems administration, IT systems head, and DevOps leadership, and now I’m the COO at iGenius, an artificial intelligence solutions firm. Throughout this diverse background, I’ve always been interested in figuring out how to make my job, my team or the company perform at increasingly higher levels.
Especially in the last few years, I have really developed an appreciation for the “people side” of business, alongside my passion for technology. When I was joining iGenius, I had a choice. We’re a startup, and there were a lot of open opportunities. In the end, I decided that I wanted to utilize my experience in software architecture, cloud computing, and DevOps while also leveraging my people skills to influence the emerging company culture.
So, that’s a bit of why I decided to accept the COO role. Because we’re a startup, I’m still very involved in technical issues, but my role is a little broader. I work a lot with the product team but also work on understanding clients and personnel needs to find balanced solutions within a rapidly growing company.
What are the differences in perspectives between the COO and CTO roles in most technology companies, and how do these viewpoints impact software architectural decisions?
CTOs are very technically driven. However, an effective COO must incorporate people considerations and technology. In my current COO position, I work very closely with our CTO. When making decisions, he typically considers issues like system performance, style of the code, system stability, and system security.
I am concerned about these technology issues as well, but I view our decisions from a somewhat different perspective. For example, I think about how the software is providing value to the user, making sure customers are getting what they want and need, ensuring that customers are pleased, and making sure our internal development team is happy and effective and has efficient processes in place. I incorporate more of the emotional side into decision-making in addition to technology and technical considerations.
Additionally, I think a lot about efficiency. A developer might develop something that seems to be perfect, but it ends up creating a lot of organizational pressure because it simply isn’t efficient. I will always be the one asking how efficient and how scalable a given approach is.
The reality is, in technology companies, the CTO and COO roles are often very similar. In some tech companies, the roles are almost one and the same.
However, these positions can vary by company and especially by industry. For example, if you work for a manufacturing company, you are likely to view the quality of the products you manufacture as central to your value proposition and perhaps think of technology merely as enabling tools. A COO in this manufacturing company might view technology very differently than I do in my current role. iGenius is a technology company, and technology matters everywhere in the company—without it, we wouldn’t exist. In our case, the COO and the CTO need to be very close; we just look at the work at hand slightly differently.
How do you navigate these differences in perspectives? Is compromise sometimes necessary?
It’s mostly about finding a tradeoff between short-term wins and long-term wins. On one hand, what happens in the short term from a technology performance perspective if we decide upon a suboptimal technology that makes the client happy? On the other hand, how will this suboptimal technology decision affect the project in the long run?
Startups tend to be very dynamic organizations. When I joined iGenius, there was sometimes a bit of debate between me and our CTO on the best decision for the company. But now, the two of us work very closely together, and we have designed a framework to evaluate most situations and come to the best conclusion together. Often our solutions aren’t perfect. Rather, we work to come to the best decision for the given situation in a specific moment in time. We also frequently ask ourselves how we can mitigate the future impact of making the wrong choices.
What are some of the things you are working on now?
We’re constantly transforming the way we work. Again, we are trying to determine the most efficient approach. We use agile methods, but agile has become a very big and overarching concept in recent years. You can be agile, but you don’t necessarily need to apply a specific agile methodology. So, we’re crafting our own construct, which means that we are constantly rethinking and reshaping our teams and evaluating the way we work. But the most important thing is that throughout all these adjustments, we keep people—both our own people and our clients—at the forefront. The first thing we think about is not the process itself, or the structure itself, but how people are going to feel working within the structure.
Was there anything else that came up at the TechDebate that you thought was particularly interesting?
I was again reminded that technology shouldn’t be about the perfect system. Your team and customers are interacting with the technology. It’s not just about the technology; I want people to feel happy about what they’re doing. In the end, I think happiness and job satisfaction create better end solutions, and if you want the best talent, you must keep them engaged and give them interesting problems to solve. I work hard on this issue because I want to build the best possible company culture so that we attract and retain the best possible talent.
