What Makes a Perfect CTO? - CTO Talks

Well, how are you Dmitriy? It's great to be here. A bit about myself: I'm from Ireland originally. I got my Master's in software development back in Belfast. After that, I worked in data science at Citigroup. And then, I moved to New York City. These past few years, I started off working as an engineer for a construction company, building a boutique program for them. And then, before my current gig, I was a team leader in an equity trading platform for a Wall Street investment bank. But now I am a CTO and co-founder at Zelta, a startup where our mission statement is to create cross-collaboration on the web. And so, obviously, over the past few years, things have shifted massively in terms of the work environment. Many things went remotely, and I and my two co-founders experienced many difficulties in getting work done and work completed with our teams. And we've seen that as an opportunity to start our own thing.

So, what's out there is to make those processes of work where you have people working remotely, make that as seamless as possible, and improve that workflow. And as I say, make our employees more efficient. How we're doing that is, as I said, cross-collaboration on the web. We've found that if someone has an issue, they may have to email someone or go to Slack. There's a lot of jumping around between applications.

Whereas if they onboard Zelta, we have a Slack integration, an email integration, we sit on your web. So, you could literally hit our icon, it'll pop out. You can write a note and say: hi Dimitry, have you seen this report? Have you seen this? Is this correct? You'll get a notification; you can go into the app or whatever tools you're using for your business and reply there, and the end is actually on the web in that flow of work. So that's the goal.

There's a lot there to digest. The biggest thing I found as a team lead in my previous job was that we had a lot going on, but minor issues could manifest into moderate and even big ones. For example, if I'm sitting beside you in the office and I have an issue, I have a small problem. I don't understand this particular piece of code or something; I could talk to you right beside me. You're literally feet away.

When everything's shifted to remote, you're maybe going to a director or someone in your team; you’re looking for something holding you up at that particular minute. And instead of having that ability to talk right away, you maybe send them a message, but then again, that perhaps gets buried at the bottom of their emails because they're probably busy. Maybe they don't see it for a while. So all of a sudden, a thing that maybe takes you five minutes, but you're scrolling the web and frantically looking for an answer. An item that would normally have taken you five minutes in an office is all of a sudden taking you half a day, and it's holding up your workflow. So that is the collaboration aspect, and that's where, again, with us you'll have the actual app sitting in your web browser, or we're going to develop again in the desktop app.

How do we tackle that? I have an issue here being on Salesforce. Is this the correct data? Is this the data we agreed on with the client? I can write it in on Salesforce itself. So my app, Zelta, will pop out; I can write it and pin the comment to the actual page on Salesforce. It'll send you a quick notification. You can then go into Zelta as well, and you'll see, oh, here's all my unread. And then, as I say on the web, you can literally click on the link and take it right to the page. You can see that, okay, that is the correct yet, let's proceed. It's a 30-second process.

Yeah, I guess moving away from the official product description, but I guess it's to remove the annoyances because, again, I found it being a team lead. And all I can do is go back to my own experiences, that I found incredibly annoying. Someone has an issue maybe they want to see something different on Jira or something. They have to go to Symphony or email or Slack, ping me there, and maybe I'm in the middle of something.

I'm like, okay, can I come back to that? But did Dmitriy write to me on Slack? Did he send me an email? Did he write a note on Jira? I don't know where that comment is, because we're working remotely now.

Whereas if I have all those comments in one place, I also have integrations with email, regular heartbeat updates, maybe every half an hour to say here, even a small issue Michael asked you about, you can literally go in Zelta, see all notifications across every app, and I know where that issue is. It was resolved two weeks ago by a coworker. Look at their documentation on it. And then that allows me to move forward in my flow of work.

No, I disagree. Again, you need to understand your audience and your target market. I think many small companies widely use Slack, and you can toggle Slack on and off. So in your example, Dimitry, we're actually the same. We have a 10,000 message limit per month. But if you toggle Slack on and you write a comment, say in Salesforce or in Jira, let's use Jira as an example from a technical point because I had many problems between tools that are under one Atlassian umbrella. But again, comments will be lost. So, let's use Jira.

If you have Slack enabled, you can then write a comment and say, here, I see this here thing on the Jira. Did you mean that? Or I know we encountered difficulty with that before. Do you mean something else? If you're an average Slack user, then you can reply. We'll show it in Zelta too. So again, it depends on who you tag as well on our app. You'll get a Slack message if it's solely for you. If it's to your team, then obviously everyone on the team will get Slack messages, and they can reply in Slack, and it'll be shown on Zelta.

So, why that helps is because if you're an average Slack user, you can see your comments on Slack as usual. But if you're not, you can go to Zelta and see. And that's just on Jira. So again, if you say: “Oh, well, we had this Сonfluence glossary page, here's a link to it in Zelta,” then it helps your team be more efficient because we have some issues with Jira, maybe the description or some ambiguity. Normally you can write comments in Jira, but then again, I know that I'm solely working on this Jira. Does everybody else understand this logic? If not, then you can have everything in Zelta. Here's a link to the Confluence description where all that documentation is. But the good thing is that you do not need to jump between five or six different apps to get the necessary information. Everything's going to be in Zelta based on the correspondence you have with your team.

I think we may disagree there. I understand there's a lot of stuff in the news about people moving back to the office. But again, as a software engineer, I'm sure everybody can agree that some recruiters reach out to you and say, this is a hundred percent remote. The companies may be located physically in some areas, but you have a chance of remote work.

I think, again, I don't know if anyone really knows what the new normal is going to be. And I'm probably moving into a different topic here. I think you, as a company, need to provide flexibility to hire the best talent. So if you're telling people, I need you in the office five days a week, well, it's going to be difficult to try and retain people who have maybe two or three kids, live two hours away, may enjoy that aspect - flexibility.

Yeah, but if we want to go further, you could say stuff as we survived before with a horse and cart, but then the car came along. So, technology advances things and changes things, and once things change for a certain way and people get used to that, it's very difficult to get them moved back into the way things were just because that's the way they were. I even feel that whenever I talk to my own parents, they wear a badge of honor that I traveled to work one hour and a half one way every day for 30 years.

And now, if you ask people to do that, they will react differently. I can literally go to my study and get all my efficient work done from the comfort of my own home. And it means I can pick up my kids from school. It means I can be there to cook the dinner if my wife potentially works at the office. There's a lot of flexibility, and being in the software field, where basically all of your work is done through your computer, then I think it's important to allow people to have that flexibility of working from home. But again, our mission with sales is to try and make that if someone is working from home, it's not any disadvantage at all. It's as seamless as possible. The work is still being done in efficient standard.

I guess that's a difficult question, and I would say, building and maintaining trust is a tough one. But again, that's another thing that we feel at Zelta, also falls under the collaboration. Collaboration certainly helps if people are doing their work and doing it to their best and their ability.

I think trust comes from empowerment, from maybe a management perspective. Giving people autonomy over what they're doing as so long as the task is done gives them a mission. And then if they complete that, you have trust that they're going to be working at that particular level, and they have trust in you for the ability to express themselves.

I think that's a problem everyone has, but I'm not sure what category you would place that in. In motivation, I would say it's a tough one as well, because it can peak and drop. When you work from home solely, you start working more hours. Because, as you say, you go to the couch and think: “Oh, I forgot to do that.” You go back, and then all of a sudden, two hours go by. In terms of keeping motivation for remote work, I would say that's a difficult challenge many companies face now.

But a way to tackle it would be empowering employees to have a good mission in what they're doing. I know Google and Facebook, and all did mandatory days off to unplug; we had weeks off. But again, I don't think anyone's found a solution to really motivate employees; a hundred percent of the time, they would be in the office. I guess one could argue that even in the office, maybe employees aren't motivated a hundred percent of the time. So, it seems to be a consistent problem across many industries.

That's a good example. But again, I think motivation comes from trust. For me personally, and I know everyone's not this, but if you're given an insight into what we're doing and why we're doing it and how we're providing value, and how that is achieving our goals on a sense of mission, a sense of belonging, a sense of empowerment, the sense of making a difference, they're going to be more motivated to do their work.

Instead, for example, if I micromanage and I tell you Dimitry, have it done this way exactly the way I did it. And if it's not that, it's wrong. You’re not going to be motivated. Because you're just going to feel all I'm doing here is just jumping into whatever Michael says.

So, I think, again, you can get a lot from empowering employees. You can get a lot from admitting you're wrong and taking their advice on board regardless of their level. Because, again, if they're empowered to work for you, they will be motivated to do so.

What makes the CTO successful is, I genuinely think, a guy or a girl who can wear multiple hats. You need to be able to be tech savvy. For example, an art teacher has to understand art, you need to be able to have high-level and low-level discussions with your technology team, understand why the product fits, where it fits, what's the product limitations, how that impacts sales and marketing.

You're also a bridge between facing clients and your internal engineering team. And again, as I say, you should be very tech-savvy. And it would be best if you created a culture where people want to be there. I think a great metric to measure a CTO would be employee retention. Because if you generate an environment that people want to be in part of, that's a long way to being a successful CTO. Because if you have talent and retain that, then that's half the battle.

I'm not saying solely on retention. That's obviously, one particular metric you could move into is the product, developing in line with the latest technologies. How is the product performed? Is it on time and within budget? Is the engineering team happy? Is project points being consistently higher or at a high gradient? There are many metrics, but what makes a successful one?

I would say, in that particular realm of the sector, I would probably put intelligence first. Creative intelligence comes second and emotional intelligence third. But I would put attitude above everything if we discuss perspective hires here. And I say that because talent is the best it's ever been in terms of the explosion in software engineers. So, when you're interviewing a candidate, you'll be able to see their previous projects, work experience or where they've worked before, and their interests. You'll be able to see, obviously, if they're college educated or they have done some crazy projects, as I said before. And you'll have an idea of their pedigree before they actually sit in that chair. So, if they have an attitude of get up and go and, really want to make it this, I think that trumps everything else because again, as me and my co-founders have found out, in this startup game, but everybody's smart. Literally all our competitors are intelligent people.

A lot then depends on the attitude you have, how deep you want to go or how far you want to go, or how much go you actually have. So, I would say if I'm interviewing anyone I know, obviously I need to make sure they're technically savvy. They need to reach maybe a certain technical bar between the code and interviews and stuff that. But if their attitude jumps off the page or in your discussions with them, you have a great feeling that someone like this is going to add much value to my team, then I think that trumps everything else.

I think the first, from my perspective, is a great communicator. Being a CTO, you're going to be managing teams, you're going to be managing different personalities, you're going to be interacting with clients, with other C-suite execs. You need to be a great communicator to all that wide array of people and personalities. So, as I say, you need to be a great communicator to your own engineering team but also to your external clients.

I think it's about building trust with people in short. And that is the mark of a great communicator. I think it may be difficult to measure, but if your clients are retained, and they're maybe repeat clients, if it's the first time, if you can create a bond in a short space of time, that's obviously being a great communicator externally.

I would say internally, being a great communicator is being approachable by anyone in your engineering team. Keeping tabs on people, is everything okay? Is there anything you need? Is there anything I can do for you? Things that goes a long way for people because maybe there is maybe one or two developers in your team that maybe you'll have some issues. It might be work, without work, and they probably need to discuss it with someone, and no one's reached out. So it's good to keep tabs there. I think the things like that go a very long way for your internal team.

But for your external team, and when you're making sales, it's stuff like the little things, the cues you can pick up on, understanding your audience, maybe inquiring about different things, showing an actual interest in them instead of just being completely frank, really helps build rapport and can help you and your business going forward.

And for me, as a CTO, number two, I would put, is empowering my team. Again, for this current role, we've used some outsourcing a few months ago. But I think a good example would be in my previous role as a team lead for an equity trading platform. Perhaps I would ask people what particular aspect or what particular way they would do certain things. And even if it weren’t the way I would do it, I would agree with that.

Obviously, it highly depends on what we're trying to do. But why don't we test it this way but for something that's maybe small, less worry or something? I would say yeah, let's go that way. And even if I didn't think that was maybe the optimal solution, because again, you can let someone do that, and if they come back and they get the solution, then that's great. If it works, perfect. If it doesn't, then you can sort of say, okay, that's a learning curve because, down the line, you're going to be well equipped to those particular bottlenecks.

Using that example, it was a three-point story we had. I thought we should do it this way. The junior developer was like insisting on another way. I was okay, let's go. If I told him there in the end that there was a bottleneck he was going to experience, he would probably never learn from that. Whereas he went down his own path, spent two days doing that, got a bit of a dead end, and then we had another talk about it, and he was saying, I didn't envisage those bottlenecks at all. And then I was like yeah, maybe that's just my experience. I've experienced that before. He's going to remember that for the rest of his life. So, that's a great trait to have as a CTO to empower others, to allow them to make decisions, and not just micromanage.

Yeah, it will. But again, I'm not saying that's happened every single time, but you need to allow your team the freedom to make mistakes. Because if we're not giving them that freedom, we're going to encounter bottlenecks because they're just following orders all the time. We're going to stifle creativity.

Yeah, but again, if you bring people in and tell them what you want them to do, you will have people that just listen to orders. Whereas if you bring people in, and yes, you're going to have failures, but also greater efficiency within your team because everybody probably has a different background. Everybody has different experiences, especially in technology. Everybody's done different projects and understands different ways of dealing with data.

I think that in order to keep those skills and allow them to grow, you need to allow people the freedom to attack solutions in their own way to an extent. I understand if it's a huge feature and we have a tight budget and a tight deadline, you can discuss it. I think you're going to go down that road, and you're going to encounter those particular bottlenecks. But again, in the early stages, it's great to keep and foster creativity.

I think the best thing for me is, I don't want to sound vague, but to be a great link between falls under communication as well but to be a great link between your development team and those internal to your company and those developing your product, and those that you're selling the product to. So, I think, again, communication's one aspect of that, but being able to build rapport with your clients and being approachable, being someone people to be around, is huge for CTO success.

Technical, I would say that's it.

That's why I'm doing the MBA as well. To be better at that.

Speak these languages.

I agree. 100%.

And again, going back to empowering, yes, it's something I think is very important. As I say, we need to foster creativity, and I believe this is the enemy. But saying, oh, we're doing it this way because that's the way it's always been done, is one of the worst things to say. Maybe, because, again, it stamps on new ideas.

But I agree with you that, obviously, there's a reality aspect, too, that we are a functioning business looking to make a profit, and we have tight deadlines on that. But, where possible, we should allow people to show their creativity.

My mission is changing. And it will continue to change, iterate, and move organically in a direction that I still need to figure out. But now, my mission is to build a product. We're a small startup that's just started. We have some paid pilots and some paid beta testing now. But again, it's to listen to our customers and listen to any feature enhancements there particularly might be. The biggest challenge is that we're building a product with enough features to add value to your business. But at the same time, we need to be flexible enough to add value but then try to be as receptive as possible to see what features will provide the most value.

And then, go double down on that particular aspect. So it's difficult to code something like that, I don't want to say vague, but it's generic enough to provide value across several features. But then, it's specific enough to be incredibly valuable for our beta and pilot testers. And then, once we get the feedback, we shift from active development to managing outsourcing teams and new hires.

Suddenly, you take a step back from coding all day to help others define tasks, letting people know what and why we're doing. And then you’re involved in the clients and our business's marketing and sales aspects.

So, the question is, am I active or passive in terms of development?

Right now, I'm very active, coding like 80- or 10-hour weeks. In the future, I would like to be still active. Again, looking at great examples of CTOs or CEOs, you would see Elon Musk, for example, in the actual Tesla factory sometimes. It's good to be active in the weeds of your company.

Not the real...

Yeah, and I think the actual fact that he was on the production floor in Fremont and California, helping out with different things, really resonates with your employees. So, it's good to do that. But again, obviously, it will be a balancing act between active and passive. Because you're going to have other issues in terms of C-Suite stuff, how's the product performing? Can we make any more feature enhancements?

There are many discussions about the business aspect and how that will play in sales and marketing. So again, I'm not sure I've answered your question to a good level, I think that now I'm very active, and I probably will move to more passive. If we were doing a hundred percent right now, I'd move to an 80-20 split in the future.

Four or five months.

Again, that could be a favor question, but I think there are three most significant challenges for startups in general. And maybe this is what people make the most value out of. Time is number one if they're looking to start their own business. Because, again, I think everybody's smart. All our competitors are smart people. If everybody is at infinite time, they'll figure it out. Money ties into that too. We've obviously got some angel investment. We're looking for venture investment, but again, we need to show that our product provides value to get the venture investment. So time and money, I'd say number two and one and two, and maybe the last would be the direction.

Again, we are trying to build something that's going to provide intense value for our customer, but at this point in time, we have great ideas, but we have numerous ideas and we need to get that customer feedback to allow us to drive our particular roadmap and what we're going to double down on. So I would say time, money, and interaction for startups is maybe the three biggest challenges.

One last thing I actually wanted to say about startups is… And I'll answer that question just in a minute or two, but one thing I wanted to say about startups was that I read a book recently about PayPal by Jimmy Sony, The Founders it's called. There are Elon Musk, Peter Tiel, Max Levchin, Reid Hoffman, all absolute celebrities now in terms of ventures or companies they created. And they were always paranoid that their main source of income, which was eBay, was going to implement new rules that killed them if you get me.

So, looking back, they had the best team perhaps ever assembled in terms of a startup, and they were constantly paranoid that they were going to die. So again, for any potential startup founder out there understand that time, money, interaction is going to be difficult, but there will be stresses. But stresses happen even to the best team ever. So, I just wanted to get that across.

And in terms of outsourcing or hiring, I think that's a difficult question, too, because it depends largely on the projects or what you're trying to accomplish. There are obviously benefits to both. If you outsource people, you can have them for a particular period and get a lot done because you have a lot of great resources. I think, though, if you hire people, you can really get them emotionally involved in all aspects of the software lifecycle. And they know what we're doing and why we're doing it.

I love reading Michael Lewis. That's the Big Short, Boomerang, The Blindside, stuff that. The book I've literally just finished was Loonshots by Safi Bahcall. I would definitely recommend it. It is about how ideas normally die two or three times before they change the world. It's a great book for just perseverance and stuff that.

Other books: Zero to One by Peter Thiel's, a great book. And Product-Led Growth, another great book gone. I've just finished that, and I'm going to start reading my Billion Dollar Loser about Adam Neumann. So again, I think reading is liberating. I would definitely recommend people to read as much as possible.

Thanks for having me to meet you.