"C" is for Challenging: Stepping into the CTO role

‍

Matt Warcholiński

So in general to talk about your transition, because this is really interesting transition from startup through the corporation, various roles that you had here from the analytics and leadership thing and how you build the lead teams. Yeah. And at the end ask some questions about a book, podcast or something. How do you develop yourself during those or maybe in the past during those roles? What helped you comment? And we put it on Spotify, on Apple podcast and on YouTube, that kind of stuff. Okay, so that's pretty much it.

Andrei Ciobotar

Okay, sounds good.

Matt Warcholiński

Yeah man so we know each other for quite a while and it's great to see. Amazing transition that you did through the startup. Your startup was acquired by Relayr, the company in which you are at the moment. And you went from head of analytics to CEO. Head of Analytics, CTO of Engineering and CEO. So this is really interesting career within a really short period. Man. First thing that I wanted to ask, how different it is to work today as a CTO versus like doing the same thing in a startup.

Andrei Ciobotar

Yeah, it's interesting. I mean, if I were to reflect on being a CTO during the NeoKami times in the startup, it was completely different in the sense that half a hat that I was wearing was basically more of a lead architect kind of guy, specifically working on low-level design together with the engineers. And then the other half of the hat that I was wearing was basically actually working on the culture of the company, growing the engineering team and managing engineers. And if I look at my CTO role today, I have very little people management. I only have three direct reports and I don't have the privilege or pleasure, however way you want to look at it, of spending so much time shaping culture. All that much. I can shape software engineering culture in the company, but it's very far away from the development teams doing the work in the trenches, so to say. And that's challenging. I feel like I'm at least three or four layers away from where the action is happening. So that makes decision making a little more difficult and it makes the work a lot more abstract. I think, ironically, when I joined Relayr as a Head of Analytics, it was a lot more similar to my CTO role.

Andrei Ciobotar

Prior to that, had a team in Munich, was working on low level stuff, but just kind of on a thin slice focusing on analytics. Right now, it's like, extremely broad and extremely far away from the actual development efforts. So I rely on people that are orders of magnitude smarter than I will ever be to kind of feed information back up and help me do my job at the end of the day.

Matt Warcholiński

Cool, thanks. That's super interesting you mentioned this, but currently you have three people with whom you work. Could you, like, describe the structure in who they are, what they do?

Andrei Ciobotar

Yeah, to backtrack for a second. One of the main things that I had wanted to focus on when I took on the VP Engineering role in Relayer was to create this split in the career trajectory for people. Specifically. Before that, we used to have basically managers that were both technical leads and also people managers. And that was a bit of a challenging situation because you had really good technical talent that had very little inclination to manage people. So they were kind of set up to fail and or not doing the thing that they were enjoying. And you had extremely good people managers that were suddenly also having to make technical decisions again, something that they were not necessarily comfortable with. So what we did was we split these two career paths, starting with the senior level, and you can go on a managerial track, managing a small team, managing a team of managers all the way to VP Engineering or even CTO. And the other track is basically what you would see as a staff engineer, principal engineer, senior principal engineer. So really expert roles that kind of go deep in specific areas of work.

Andrei Ciobotar

And part of this expert group now constitutes what we call the Technical Leadership Group in Relayr. These are the folks that think about architectural design principles. They think about technical landscape. They think about, all right, which tool do we adopt, when and how do we reconcile the strategic roadmap on the technology level of the organization with the actual product development backlogs and so on. Part of that technical leadership group is essentially a subset is called the CTO office. Those people basically report to me that's effectively, you can think of it as a small governance group, and they work together with the technical leadership kind of like cascading into the rest of the organization in general. I have, I suppose, principle and above report to me. So that would correspond to a directory level on the managed side.

Matt Warcholiński

Okay. That's an interesting structure. Cool. That they divided in like the guys who are focused on tech and the guys who are focused on people. I think that's a good way to go.

Andrei Ciobotar

I think it goes though without saying that when we hire people, managers, we do hire people that have a background in software. So naturally people managers need to understand software development is easy and they also need to be able to appreciate the challenges that the teams are going through and how to support them. So we are still focusing on people that have some sort of developer background, team lead background, some like that.

Matt Warcholiński

Okay. And corporate language is German or English.

Andrei Ciobotar

I would say it's 99% English.

Matt Warcholiński

Oh, okay. That's interesting.

Andrei Ciobotar

I mean, we're an international company. We have an office in Berlin, we have an office in Munich, we have an office in Katowice in Poland, we have an office in Chicago, and then we have a whole bunch of remote people in Europe, but also in Poland. So I can imagine there's a lot of kind of cultural challenges as well. But we also have to use English as a main language.

Matt Warcholiński

Good. It's not so obvious because I was working for BMW, the language was German only and I had the experience like most of the companies, even the IT companies back then, like a few years ago, they were still in German despite official language. Let's say text language is usually right. That's cool. And then as a CTO, how do you build a team around you? You have like a three people and before you were like a VP of engineering. And I know that building leadership team around you, it's really, really difficult. So do you check what kind of type of personality this person is? Like some assessment test or you just feel it after a few years, let's say, of experience?

Andrei Ciobotar

Yeah. I wish I could claim there's like a rigorous process there, but it's more like the latter, like a feeling perspective. Obviously people are promoted in the organization based on the impact that they're making, based on the values that they exhibit. So most of the work is already done for me because there's a lot of technical leaders that grow in the rank. What I'm particularly looking for personally is our individuals that are entrepreneurial and individuals that I suppose have initiative and push things through. And I think these are the two main components. Obviously technical expertise is super important, but that's also something that we all develop continuously. I think this very well. The technical expertise is such a kind of a fluid term. Every six months you probably realize that some of what you know is becoming outdated and then there's always something new to think about. So I place more value here on soft skills, entrepreneurial thinking, and the sense of getting things done. Okay.

Matt Warcholiński

And how about the roles. Let's start maybe with the VP of Engineering, because before you said you had around 150 people reporting, let's say reporting to you. And could you describe what was your responsibility there, maybe? What kind of metrics have you followed?

Andrei Ciobotar

Yeah, I think the answer doesn't change today. We're probably getting better at it, but the answer is largely the same. So in general, what I found and again, I don't think this is my own wisdom, I think the industry also agrees it's very challenging to compare team performance. You can start measuring velocity and all sorts of KPIs with regards to team performance, but if you compare those KPIs with some sort of golden standard in the industry, you will most likely not be fair towards the team. I think it boils down to measuring things, having a baseline, and then having a culture of continuous improvement against that baseline. And I think you will find, even in redirect, we have quite a few teams today. Each of them has a different velocity. Each of them has a different understanding of what a T shirt size or number of story points correspond to what. So it's very difficult to have an apples versus orange, an apples versus apples comparison. But what is important is continuous improvement. Always looking at, you know, how can I become 1% better on my next try? And I think that's what drives performance.

Andrei Ciobotar

Industry standards can give you a bit of a direction and give you a sense of how you can benchmark yourself. But I don't think it's fair to look at those in isolation. Typically what we're looking at today is a mixture of I suppose you could consider them Jira metrics. So how good are we at estimating our own work, closing the work that we commit to? How well do we document the work that needs doing? Which has an effect on how it's scoped, has an effect on how much work you have to do afterwards when you realize things are a little bit more complicated than you thought. And the other pieces we also look at, and this is kind of a newer development, we also look at GitHub. So we're interested in metrics around cycle time. We're interested in understanding are we spending a little bit too much time reviewing? Do we have too many cooks? Do we have too many people or too few people doing reviews? Kind of understanding where the bottlenecks are and how we can kind of open up the process a little bit. I would say, though, that the latter piece on GitHub is more immature, process wise, and it's something that we're actively working on.

Andrei Ciobotar

Ideally, we get to the point where everything that is in juror matches what is on GitHub, and then you have one source of truth, which I would argue is GitHub. But right now we don't have that luxury.

Matt Warcholiński

Okay. And how this is different to your current role. What is the difference as a CTO and VP of Engineering?

Andrei Ciobotar

How my role as a CTO is different to the VP engineering? I would say that reflecting and again been it's a while, so maybe my estimations are a little bit off. But when I think about my time breakdown as VP Engineering, I was probably spending 20% of my time on technical strategy and the other 80% of my time in meetings with managers, meeting meetings with managers of managers, doing skip levels and trying to, I suppose understand the intricacies of team performance. But that didn't leave a lot of time for the actual discussions and thinking around well, how should we execute against our technical strategy and what is our technical strategy at the end of the day? So, if I look at my role today, I would say it's 80% technical strategy and the rest of the 20% basically interacting with various stakeholders either on the C level or as part of engineering management. So I'm really spending the vast majority of my time on technical strategy,I would say. 

Matt Warcholiński

Okay, do you have any metrics or OKRs, would you report to other like C level guys?

Andrei Ciobotar

Yeah, we have not in the classical sense. So there is OKRs that for instance the CTO office team has around how good are we in articulating the strategies? And we have every couple of quarters we take a pulse of the organization, we see how people can do people understand the strategy, are people executing against the strategy and that's what drives a set of OKRs. The other piece is we are in the midst of, I suppose rather large platform revamp and we have metrics around what is the adoption of the new services? Are we phasing out at the pace that we are expecting to phase out services? So more focused on the execution today. But I would say they're really situational in the sense that this year we have this focus so that drives a couple of metrics, next year we'll have a different focus. So that will drive an entirely new different set of metrics. I think CTO roles in general are very difficult to measure. It's the kind of thing of it's probably a classic analogy, but if someone has a CTO, misses something like a key development in technology such as Docker or moving to the cloud or the internet adapted them right, then it's pretty fair to say that that person probably wasn't paying attention or doing his or her job.

Andrei Ciobotar

But that's the kind of event you see every once a decade or every five years. So it's very difficult to judge a CTO by if you're keeping up with the technological development out there. You only really know that you've missed a train when you're still in the train station. So that makes it a little bit challenging.

Matt Warcholiński

That's interesting because if you're talking about the strategy and following the trends, I'm always thinking about it. This is just to simplify it, you need to read a lot of books. You need to read a lot like look around the Internet and follow the conference and so on. So educate yourself a lot to kind of like to build this strategy. So it's like constant learning. It's part of the job, right?

Andrei Ciobotar

Yeah, I think there's the learning bit and there's a lot of material conferences, kind of papers on all sorts of topics and up and coming trends in software and the like. But what is also I think critical is being able to kind of sift through the noise and recognize hype from reality as well. And obviously there's a couple of technologies that are not proven. So it's difficult for me to call them hype. Obviously too early to call them hype, but at the same time, maybe an anecdote. I can tell you an example around blockchain. I mean, blockchain was also buzz a few years ago. Even last year, before the entire meltdown in the space happened, everyone was raving about web, three new paradigms, everything's going to shift to token based economies and decentralized organizations and all sorts of stuff. And for the longest time, the organization was doing the Blockchain hype. The organization was challenged like, well, do you have blockchain? Are you going to release a token? Are you going to do like a token based economy for this thing or that other thing? We even had like a few years ago, a group of engineers making a Relayrt, issuing a Relayr token way back then.

Andrei Ciobotar

And I'm comfortable with saying, well, we didn't do anything really with that and it may very well be hype, but had we basically doubled down and followed the hype around Blockchain, we would have probably been really wasting our time. There are obviously legitimate use cases, but I think it's important to not only look at what's out there, but also really apply a critical eye. Is it relevant? Is it going anywhere? Is it really delivering value for my customers? Or is it a margin either, but something that we feel good about talking because we feel good about talking about because it's really cutting the edge. So that's kind of how it goes, at least in my perspective, in my experience. The other piece is, well, engineers as well bring a lot of stuff. It's kind of a network effect in some sense. Engineers are also snooping around. They're looking at what's out there. They're also going to their own conferences and they're bringing information back. And it's also a question of synthesizing everything that is being brought into the organization.

Matt Warcholiński

Okay. And you are talking about stuff like blockchain, like web 3.0 and that kind of stuff. And I'm really interested, like, do you see any trends? Do you see any stuff that you are passionate about that could be the next thing? Now there's a lot of talking about the low code, no code solutions, right? So like, some stuff like that.

Andrei Ciobotar

Yeah, there's a lot of forces at play. I think if I were to look in the space that Relayr finds itself in, I think there's a huge potential, and it's probably being accelerated today by stuff like the notework of it and all that stuff. There's a huge potential in what the industry calls, I suppose, cyber physical systems, being able to kind of marry this world of physical things with virtual environments where people can work collaboratively. And I would say IoT obviously is a barrier of entry. You need to be able to take the pulse of the assets. You need to connect to them. But I think the real interesting bits happened a little bit further up the stack where you can actually interact with assets remotely. You can actually interact potentially with other colleagues on the shop, on the remote shop floor. And this is where you see like, really incipient developments. I mean, I can point to the omniverse from Nvidia. I know they also have like, a pilot with BMW in Munich. There is movement naturally. It's too early to say, well, this is a game changer for the productivity of people, or this is a game changer for the factory floor, or will we finally have factors where we can turn the lights off and no one has to go there?

Andrei Ciobotar

We're way off from that. But I think it's really an interesting development that I personally keep on my radar. There's obviously also, I think if you look at the hyperscalers in general, if you look at the likes of Microsoft or Amazon and the like, they are also slowly but surely moving up the stack as well. And that leaves a lot of room for essentially focusing more on data driven services and less on, well, how do I get this telemetry from the shop floor to my cloud? It kind of frees up. It eases the cognitive load for engineers to think about more interesting, more advanced use cases.

Matt Warcholiński

Yeah, okay. Do you code from time to time or emails 99%?

Andrei Ciobotar

Privately only. I think the last time I was actively doing coding was during my time as analytics director, maybe three years ago or so. So I was still working on our spark jobs, primarily Java and a little bit of Python as well. After that, I haven't really had the luxury, I call it a luxury still, period, to actually get my hands dirty. I would like to, but there's just not enough time.

Matt Warcholiński

Yeah, I get it. What do you like to read? Like any magazines or any websites to be on track to see the title.

Andrei Ciobotar

There's a lot of material out there and it's difficult for me to be super exhaustive. I think much like every other engineer, I keep up with hacker news that also turns more into political commentary rather than hacker news. These days I like to read the architecture books. I think something that people don't necessarily think about enough is what are the forces driving software engineering today? And if you look at the barrier of entry towards becoming a software engineer, it's becoming a lot easier for people to pick up coding if they're interested in inclined to do so, of course. So that means you have a nontrivial number of people that come from an entirely different field and into software development at the same time. You have offerings, products that are growing in complexity. I don't want to suppose discount everyone has a phone these days and by virtue of having a phone, you have a whole lot of apps that drive expectations for you as a user. It would have been easy 20 years ago to say, well, one of our users is a technician on a shop floor and of course he doesn't have like super high expectations, but now everyone has high expectations.

Andrei Ciobotar

These are the responsiveness, these are the quality of the experience, these are the depth of the insights that you're getting simply because it's super, super common. So in general, the complexity of software is going up. What is not evolving at a reasonably high pace from my perspective, is the tools on architecture. I would say that they're not proportional to the speed on the software delivery side. I would say that it continues to be a challenging topic. Topics around how do I create a software product that can change over time without too much friction? I think change is really the main coordinate when it comes to software engineering. So long ramble. But that's why I really am quite passionate about reading architecture books I think too that come to mind from a more recent memory and I don't want to do a disservice to the others that kind of fell off in my recent memory drawer. One is Evolutionary Architectures. It's one that I would recommend. The other one is the Software Architect Elevator. The latter is quite interesting because it also goes into what it means to be able to have a common vocabulary. When you are on the shop floor talking to engineers and you need to speak their language, you need to be able to connect with them, use the same terminology and appreciate the work that they're doing.

Andrei Ciobotar

Jump onto the elevator, go a few floors up, speak to an engineering director about what is happening on the shop floor, but again with the appropriate vocabulary and then jump back on the elevator and go up in the executive suit where you basically have to talk on a completely different abstraction level about what's happening on the shop floor. And I think this is a super important skill for any kind of aspiring architect CTO, and even for an engineer, I think anecdotally the most successful engineers tend to be the ones that can speak the language of engineers when they're with engineers, but go a little bit higher and make things understandable for people in management. As an example, I think those are the two that I would recommend.

Matt Warcholiński

Okay, cool. And two last questions that I have. One is kind of like you have answered this already, but is there any book, podcast or a thing that helped you a lot or change you a lot during the last couple of years? So one part is you already mentioned those two book about the architecture, but I'm thinking maybe about something from the soft skills part, like something what helped you transition.

Andrei Ciobotar

I think there's a lot an interesting podcast that I follow is called Moonshots and it's effectively looking at what are the habits, principles, pillars that entrepreneurs out there basically tend to follow or tend to subscribe to. Again, there's no kind of recipe one size fits all approach. It really depends on the industry, it depends on the background, depends on the team, depends on so many things. But I would say Moonshot is something that kind of deconstructs some of the more famous, but also less famous people out there. And they try to understand what are the driving forces for these people. Obviously nice to reflect on, but I think soft skills mostly come from within. It's not something you learn on a podcast.

Matt Warcholiński

That's right. I didn't understand exactly the structure around you. So you're CEO and you have like three guys next to you. So you have probably in the same place, the VP of Engineering, right?

Andrei Ciobotar

Yeah.

Matt Warcholiński

And the two other guys.

Andrei Ciobotar

I have three principal engineers reporting to me. From a structure perspective, you can think about the CTO focusing on the how and on reconciling technical strategy with business strategy. And you can think of the SVP Engineering as being basically the line manager for the entire engineering population. And it's kind of a yin and yang situation. Obviously cannot succeed without buyin and support from the SAP Engineering and the way it goes, we transitioned to a matrix organization. So in principle, technical leadership, even if it doesn't report to me, has a dollar line of reporting to the CTO. And we're spending not sure if it's enough time. But we are starting to spend more time reflecting on what's the breakdown of work. How much of the work that people are doing is basically feature roadmap. How much of the work is working on technical strategy. Adopting stuff from the strategic roadmap. And how much of it is technical depth as an example. And trying to kind of find some rules of engagement there so as to minimize friction because it's always an ongoing discussion. Do I work on this feature or do I adopt this new technology because the tech roadmap says so.

Andrei Ciobotar

How do I split my time? But that's kind of the crossplay.

Matt Warcholiński

Okay, got it.

Andrei Ciobotar

If you consider the split that I was describing earlier between people managers and technical leaders, you would think that the CTO is on one end and the SVP Engineering is on the other end.

Matt Warcholiński

Okay, got it. Last thing. This is really interesting for me personally. How do you compare the stress, like startup level and now at this level, is it like similar but different environment or is it less stressful? Like how do you feel? How do you feel?

Andrei Ciobotar

That's a difficult question. I think it's different stress because you're stressing about different things and you know this very well, right? In start up mode, you stress about runway a lot more. You stress about every expense. You stress about am I going to make this pitch next week so that I can have basically enough runway for another six months? Am I doing enough? Am I looking enough at product market fit? Am I nimble enough? I think it's a different kind of stress in a startup. You pivot so many times, you just kind of try things out. You throw stuff at the wall and see what sticks. So it is a flavor of stress that I don't see here. The stress is more. How do all of these levels of the organization effectively work together? How do we make sure that we're executing on the right things? That the communication was crisp enough, that things didn't go lost in translation. And you can imagine there's many moving pieces. There is if you look at it as a graph problem, I suppose you have so many peoples and so many kind of arrows of communication and so many bottlenecks of communication and that's driving stress.

Andrei Ciobotar

I would argue that with perfect communication, perfect transparency, stress would go down. But that's just the nature of being in a larger organization. So still stressful, but different flavors of stress. Not that one is better than the other.

Matt Warcholiński

Hey man, great talk to be honest with. Really cool answer, really interesting. Thank you. Yeah, I really enjoyed personally because usually we're just starting the format and we are just doing MVP with my co founder. So at the moment it was the best one.

Andrei Ciobotar

Thank you. 

‍