← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
CTO Series: Bridging Innovation and Strategy as CTO of CrateDB With Sergey Gerasimenko
00:44:52
CTO Series: Sergey’s Leadership Insights—Bridging Innovation and Strategy as CTO of CrateDB In this BONUS episode, we sit down with Sergey, the forward-thinking CTO of , to unpack his journey from Nokia to CrateDB and his leadership...
Loading summary
Transcript45 lines
- [00:04]
Vasco Duarte
Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th to 20th of 2025 in Tallinn Eston, we're going to have a transformative experience. We're putting together an event that it's all about real life Agile. It's not theory or buzzwords, it's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now we're bringing together the best stories in Agile. From product leaders to engineering wizards to business visionaries, this will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now we're in our super early bird phase. And that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three will dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person, real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now, right now that that's out of the way, onto the episode.
- [02:40]
Sergei Gerasimenko
Hello everybody.
- [02:41]
Vasco Duarte
Welcome to this very special CTO series episode. And joining us for this episode is a very old colleague from many years ago. We worked together at Nokia, Sergei Gerasimenko. Hey Sergey, welcome to the show.
- [02:56]
Sergei Gerasimenko
Hi Vasco. Thanks for having me.
- [02:58]
Vasco Duarte
Absolutely. So Sergey's career has taken him to be the innovative CTO at createdb, which is leading the charge in real time analytics and hybrid search. Previously he was a VP of engineering at MongoDB, shaping the edge device strategy and at Realm, before that the leading open source mobile, pardon me and embedded database that was acquired by MongoDB in 2019. With a career spanning groundbreaking roles also at Brainly and Nokia, Sergei co founded two companies and even holds a patent. His leadership continues to push the boundaries of tech innovation and today we're going to explore all of the lessons that he's collected over the years. So Sergei, let's take a minute, tell us a little bit more about yourself and share with us a pivotal moment that you think defined your approach to leadership and technology.
- [03:55]
Sergei Gerasimenko
Thanks Fox. Very kind words. Probably it's easier to start again. Going back to Nokia, that was by far probably the most defining chapter of my career. That shaped a lot. So probably for the listeners like we know we each other from what is it probably like 15 years ago back in the Nokia times when we've been building one of the open source phones they were about to release. And I think like the pivotal moment for me over there was actually the fact that I started to work with a very, very talented people manager, Satiris Macrigianis. Mosca probably also remembered this person as well. And one thing that I learned over there is that Satyis had a very interesting approach for running his team. He was responsible for the application divisions over there and what he was doing is that he was trying to combine several properties. So being a servant of his team, being a cheerleader, constantly trying to pump up the atmosphere and just make sure everybody's like chunking along together. But at the same time also being a chief strategist, the person was absolutely unique with trying to figure out what we actually should be doing next. And this was like this just as an example of how our team leadership can be done was probably very, very impactful for me for all these years at least, you know, when I was reflecting back on it and then for the technology itself, I think like, you know, Nokia story is also somehow pivotal over here. Like one thing that you can learn is that it doesn't really matter how great products you have. Lack of marketing and the lack of product adoption is something that fundamentally destroys no matter what great product you would have. And my Nokia story started way before also the Intel Migo days. It was also in the are in the research division and the Nokia Research center. And like there were just so many absolutely great, unique, incredible products like we built one of the first home automation systems that's like very, very close to what Apple is doing with the Hot Kim Hot right now. Sorry, but we built it in 2007, 2008, like almost like 10 years ago before they started. Like Nokia made one of the first Internet tablets. This 7710. No, Nokia made one of the first tablets. 770. It's like, you know, it went almost completely unnoticed up until iPads took the throne. And you know the same story with the, with the phone that we were building, the N900 and N9 that had absolutely revolutionary user interface if you think of it right. This whole swipe swipes gesture is something that actually powers the iPhone right now, like they tend and Android. Right. Like, you know, so the whole interface, completely buttonless was something that we already had implemented in 2010, 2011.
- [06:45]
Vasco Duarte
And one of the cool things about having worked back then, at least for me, and I remember you were there as well, so you probably saw the same was the fact that all around you there were, you know, extremely large amounts of super intelligent, super dedicated, super motivated team members. I remember when we worked together in the open source based phones that everywhere I looked there were people who wanted to make a difference, who believed in what they were doing and were really pushing the boundaries. But it does come back to this idea, and I think you mentioned it already, that it doesn't matter how good your product is. What matters is how it gets adopted in the market. Right. And when you think about, you know, the work that you're doing these days at CREATEDB and before at MongoDB and Realm, what have you learned about that aspect for your work as a cto, as a VP of Engineering? When it comes to making sure that it's not enough to have good technology and good products, we need to make sure that they actually have a market.
- [07:53]
Sergei Gerasimenko
Well, that's, that's a kind of tough one because typically the problem of the product market fit is something that is very, very well explored for the, for the B2C for the typical product companies out there, right. You need to identify the user, you need to run AP experiments, you need to figure out whether people actually would be able to pay for it or not. With technology, like with the pure technological components, things are a little bit more tricky in the end. And what, what has happened with Realm, for example, just as, just as an example back in the day, let's say 2017, 2018, the size of the marketing team that they had was actually almost equivalent to the size of the engineering team and the marketing team that they had actually they had a very interesting title. They were all called Product Engineers. So effectively it was a handful of very, very hands on engineers who were just ready to build demos, who were ready to talk on the conferences, who were ready to present at various meetups and just run with the story of just popularizing and adopting the product that they built. So that's a form of a dev rel of sorts. MongoDB also did a very, very similar work in more or less the same timeline. Also that's something that led towards the adoption of the performance model. And this is also to a degree what we are trying to do right now with the cratedb because createdb itself is not particularly well known database. But when you start looking into the capabilities, you'll see a lot of absolutely outstanding qualities.
- [09:31]
Vasco Duarte
So one of the things that from what you share here is I hear that it's very important to understand how the product gets adopted, who does the adoption and then also how to engage them. Right. Is that something you regularly think about and worry about as a cto?
- [09:51]
Sergei Gerasimenko
Yes, maybe I worry about it also sometimes way too much. I think you mentioned, right. Like I have a two startups experience and both of them were unfortunately something that we needed to shut down just again because we couldn't really scale that product market seat well enough. So this is just something that I think deeply affected me in the way how I think so when it comes again to technological products, there are usually two motions. There is a top down and there is a bottom up motion. So the top down is typically when you sell a database where you talk about the database, you need to go to somebody who you identify as a decision maker. Right? So like a CTO or VP of Engineering or CIO or something like that. And typically they're in a very, very different world from the actual developers. They are sometimes, only sometimes people who actually can advocate for the particular technological choice within the company. Usually they just need to get to know about something and they need to be comfortable with it. The actual people who really, really push technology inside of any organizations is the actual developers. And this is where the bottom up motion comes in. Right. So because in most of the cases it would be development people would come to the VP of engineering with the stories like hey, our search technology is just not really working particularly well, we have to replace it. And here are two options that we looked into. Can you help us getting a quotes and talking to the salespeople that they have or their so doing the Top down motion is usually very straightforward, right? This is this classical marketing approach of like let's write something on Twitter, let's write something on LinkedIn, let's write some white papers, let's go to some AWS summit like conference and present our solutions. So this is just builds our general awareness among them, let's call it senior decision makers. But then there is the actual developer adoption, right? Because it's not enough for the developer just to figure out that yet another database exists over there. There are like 2, 300 database products out there. The tricky part over there is the exactly the adoption. So from the moment that they hear about it to actually trying to use it for something meaningful. And this is very, very, very tricky thing where you have to advocate a lot on the quality that you bring in to the unique features that you bring to how you specifically actually going to make the life of a particular engineer easier than it was before. So those are to a very large degree actually pretty much direct products questions. Because what are we talking about is how developer experience changes by using the product that you have. And it's not enough that it just does what the other databases do, stores data to some degree. All the databases out there just glorified spreadsheets with a lot, a lot of stuff built on top of them to make sure that they can work and they scale. Right. But like how individual developer will experience the product. I think this is the most important thing that pretty much everybody in the technology industry should be worried about every day.
- [12:54]
Vasco Duarte
I'm pretty sure that when you think about developer experience, I'm pretty sure that you guys have already discussed a lot to do with the latest trend at the time of recording, which is of course AI as an assistant for developers. Are you playing around with it? Do you have something to share with us on that space?
- [13:12]
Sergei Gerasimenko
There is a lot actually. So first I think maybe a general comment. I personally believe that what we have with the AI right now is a lot of hype. Why? Very simple thing. Just because my life personally hasn't really been transformed by the AI at all. It has been transformed by the Internet completely. I'm working in their large international company sitting in Finland just through the means of Internet. And this is a transformative change with AI. The things a little bit are simpler over here. Yes, I can write a better email. Yes, I can make a very, very simple sample application. Yes, I can convert natural language query to our SQL statement, but it's still not transformative. I think the actual transformation will come in the next two or Three years, maybe a little bit longer from the developers, from the engineers who is going to be building those products that are leveraging our AI. Because again, right now all the companies that we hear about is OpenAI, the company that actually develops the model, Nvidia, who provides an infrastructure to run those models and to a degree amd, and that's about it. And this is also the niche in the industry. I think it's very, very important to be the, the solution provider that leverages some certain technological trends. And in our case we're exactly a database that enables their AI workflows. So we are naturally suited for machine learning, we're naturally suited for the machine learning operations. And this is also where the real time analytics comes in. Because in order for you to extract the value of the data that you have on your business, you need to have a very, very fast access to operational data that you have that you can seed into the AI model that you can figure out then whether you need to stock up more items if you're running a store, or whether something got broken in your logistical chains. So again, using AI per se, or here sometimes in Oracle, like if you're doing our time series workload and you want to have just predictability or the forecast, you can achieve it with many other solutions. But I think simplicity or the usability of the various UI models that we can bring in is something that will help people go building the applications that are really, really transformative. So again, what are we trying to do is to stay in the space. This is where gradedB is a natural features. Because we have the vector store functionality, we can power any kind of retrieval augmented workflows out there. We can have vector search, we can have hybrid search, but we're still in the business of building the middleware for people who are building applications that leverage this AI.
- [15:55]
Vasco Duarte
When we talk about AI, which is just one of the many technology trends that are out there for your business specifically and also in general, of course for your role as a cto, you need to figure out, okay, how do I balance this? Following the tech trends and understanding how they can benefit us and our customers versus broader business objectives, like whatever that might be, including specific partnerships or enabling entrants in some certain markets or whatever that is. So how do you make sure as the CTO at createdb, how do you make sure and what processes have you implemented to balance out the tech focus that you need to have with the broader business objectives? And of course at the same time remaining agile enough to adapt to change. Because as soon as you start working on something, it will change.
- [16:48]
Sergei Gerasimenko
Yeah, that's a great question. I think there are three answers. I'll try to stack them in order. So the first one is being the part of executive team of course helps a lot to try to figure out where the strategy goes. So this is where you're not just handed over a thing and saying now please execute the strategy X that we just came up with. So being able to actually shape it based on what you see on the market base and what you actually hear, where you think you should be developing a product is very, very helpful. But still, ultimately you end up with some sort of a document with an explanation of what the company strategy is. Right. Whether you contributed it or not. And this is where it kind of gets interesting, where the kind of theoretical plan needs to really get transformed into a reality. We tried multiple things over multiple components. We tried working with the okrs where you would break down the original the company narrative into set of strategic objectives, then try to cascade them to the specific departments, then cascade them to specific teams, to cascade them to specific individuals. So they're so great. But it always comes at a certain limitations. First of all is that you actually have to do a lot of work of trying to figure out those specific KPIs, right? Because it's not just an objective, you actually have to measure it. And sometimes you cannot really measure things. Sometimes the objective is really just get the thing done and release that. That's about it. And you can have an arbitrary adoption rate attached to it. But it's very, very artificial. And I think everyone involved in the process just notice that there is a lot of this artificiality, if it's an English word in general in it. So something that we eventually ended up working at Realm, at mongodb and to some degree at Crate as well. Is there a slightly different approach that would be perhaps would be a reef of an RFC process from the open source community. So how it works is that we do sit down and we do write a company mission and vision statement for a year ahead. But after that what needs to happen is that every single product line needs to write up an actual narrative that explains what specifically there thinking they would be doing. But it's not a roadmap, right? It's not just an explanation of the roadmap per se, it's just a high level thing. So if we just say that we want to invest into particular areas, like you know, we need to have an answer for the how, how particular database fits into the AI development workflow that would be the actual high level strategic objective. But then what needs to happen is that you start writing strategic narrative documents, which is a one or two pager that then starts listing potential initiatives that you actually can implement to it towards it. And then that becomes something called similar perhaps to a product backlog to a very, very, very high degree. And once you have this product backlog, then you actually can go to the teams. And when you go there, they don't see like, you know, here's five objectives, would you please do something with them? They actually see a story, a story that they can relate to, the story that they can read to that is written in a document. And then there is just a list of theoretical projects that they can pick up. And sometimes this is not exhaustive, right? Like, you know, sometimes team also can come up with quite a lot of information, like, you know, you're not always sitting the ivory tower and know everything that needs to happen. And then like when you do this quarterly planning, like we still have our guidance of doing things in the quarters, you go through the strategic narrative you try to pick up are those initiatives that they think actually aligning with the overall business objectives. And then you do it in a very collaborative fashion to make sure that when the team starts doing the planning, you also try to include all the, let's call it, decision makers from the company so they would be aware of the conversation that led them to choosing some of the initiatives against the others. And when you do, then, you know, effectively what you try to do is to defend the plan at least you know, for the two months in a row. Because yes, you're absolutely right, something will happen. There will be like, you know, yet another customer requirement that we haven't thought of or some drastic change. But I think the idea there is that once you lock in this quarterly plan, you try to communicate it and you really try to stick to it, unless you actually see substantial, let's call it a business risk thing popping up, right? Like, you know, so something that absolutely fundamentally changes what you thought about. If it's just a feature that you forgot to add, fine. You know, probably we can wait for the next three months and then include it into the next quarterly plan. So in this case, I think the balancing act over here is pretty much on the product managers, on the engineering managers, on the team as well, to be able to advocate for the necessity of sticking to the plan that has been chosen. And if in two weeks after doing the planning, you actually have doubts whether you plan things correctly, then it Just brings a question, how could be planning in the first place?
- [21:52]
Vasco Duarte
Probably like so on that vein, Sergei, in that narrative that you document and then distribute and kind of cascade through the discussions to the teams, do you have an explicit part of that? Not just vision and mission, of course, but also when you consider the initiatives and the trade offs you need to make when you choose one over the other, do you explicitly set out the assumptions that if proven not to be true, would invalidate the decisions made?
- [22:25]
Sergei Gerasimenko
Sometimes we. So it goes a little bit more depth over here. So let's just say that we would write the strategic document, we would come up with like 5, 6 high level business goals that we would want to focus on. Then we would have this like more specific tactical initiatives. And those business goals, by the way, they're not necessarily limited to just engineering. Like you know, the same framework just apply for the entire company the overall business goals of having, I don't know, employment satisfaction rate at X number. Right. So when you pick up those initiatives, you never say that we're just going to complete it in the next nine months just because majority of those initiatives are fairly large. And you're absolutely right. In many cases you actually have to validate whether what you're planning to do is feasible. So this is where you start breaking into a set of steps. And instead of saying we're going to be working on a very, very large database feature for the entire year, you say that we're going to break it down into set of incremental steps where we would be doing an assessment at the end of each step. And the first one would be we're building a general proof of concept implementation where we could try to validate whether the whole approach actually makes sense. Then you will get into our more of an initial implementation that you would be able to pass to a set of customers and call it preview, alpha or anything in between. And then there would be a more longer stretch where you would make sure that the feature that you're releasing actually has enough of quality, whether it has all the functionality that you need to have. And the keyword here is to have enough of those checkpoints and never assume that somebody will just work with the idea that you're just building the feature and it will be ready exactly in a year. Just because you said that makes sense, right?
- [24:13]
Vasco Duarte
It's useful to have it in a year. Let's put one year.
- [24:16]
Sergei Gerasimenko
Yeah. I mean this is the part where I think like you, you end up with a deadline driven development and with engineering, like especially with the with the database engineering, like, you know, something that's perhaps I'm most familiar with right now, it's, it's not something that you really want to end up with. We, like at MongoDB, for example, like back when we joined, like the company worked in the annual cycle where releases were done once in a year just because there was an annual conference. But even then when you try to push the release for the specific deadline, it was absolutely okay to just say, hey, this is still a preview feature and we're going to be hardening it over the next three or six months. So if you would want to use it, here it is. It's generally absolutely safe for the business to use, but we don't really declare it generally available.
- [25:06]
Vasco Duarte
Well, when we talk about deadline driven development, which is something that I have used myself a lot as an anti pattern, just to be clear on that, of course we are also kind of referring to this figure, this tool that we use in organizations called the roadmap. For you as a cto, the roadmap has many clear and present implications on how you do your work and then also how the teams that you work with can do their work. So how do you make sure that you are understanding the current struggles that you need to help the teams with, but also keeping your eye on the future and having kind of an understanding of where the future is leading us, how do you balance that through your roadmap process?
- [25:52]
Sergei Gerasimenko
So that's, I think another interesting question that will take quite a lot to explain. So there is another phase that most relays on product managers at large, but in some organizations it's a different function and this is a competitive intelligence. So effectively, before you actually start building things, it's not enough to just talk to the customers, to just figure out what the engineering team would need to do from the sense of, I don't know, technical depth reduction. You also really need to understand where the market is heading and what are the trends over there, what your competition is doing, what your potential partners are doing. And that's a very tricky act. Again, depends on the size of organization. Various people can do it. If the organization is small, I think it's just a handful of people having a well curated LinkedIn feed or Twitter feed or Devtool channel feed or Reddit feed or you name it. Because again, if you're on the data space, you can have quite a lot of signals of where the data warehousing companies are moving. All of this information is pretty much public. You can piece the things together to Figure out what's going to happen with the Data Lake architecture. But at the same time, maybe the huge advantage of the database world is that it's very, very, very slow moving industry in general. An adoption of a database happens at best in six months from the moment that you start talking to the customers. And in many cases, if you're talking especially about a replacement, it's a year long process, sometimes actually even longer. And this is just actually enough amount of time to catch up with everything. Right. So the choice, the technological choice is very, very rare. Just here's the latest React framework available. Let's rewrite our applications on this particular stack. Something that happens, for example, in the front end JavaScript world every year there is something new coming up and every year you would need to migrate from Vue to Angular or the other way around or get into React native or then start using React native components or maybe just ditch your front end together just because there is low code application available right now. That solves all the problems. Right. And it kind of goes in circles for almost 15 years right now. Again, the databases are much, much more rigid. And this is where you get a bit more of a leeway to not be able to be reactive. Where you would be able to actually see like, okay, this database invests into this particular data format. Should we immediately jump the bandwagon of supporting parquet files or should we actually wait a little bit? And sometimes like, you know, having this like, you know, six to 12 months gives enough of time to figure out whether something was actually are, you know, a good idea that you really need to follow.
- [28:45]
Vasco Duarte
Well, in fact, with that amount of time, you even have time to acquire a company before that becomes a huge issue in the, in the industry.
- [28:55]
Sergei Gerasimenko
Yeah, that, that, that's also true though. Again, you know, integration of a technological component necessary.
- [29:01]
Vasco Duarte
Yeah, it's not a given for sure.
- [29:06]
Sergei Gerasimenko
So yes, I think it's important to stay on top of the trends, but in a sense of just seeing where the market is heading and then try to like, whenever you actually write the strategic narrative, there's also a portion, a piece, a section that says this is where we think market is heading. So hence our bets are on this. So there is always a combination. Right. You never make the choices of the strategy just because you believe in it. You always need to base it it on some sort, you know, on some sort of predicaments that you see.
- [29:39]
Vasco Duarte
Absolutely.
- [29:40]
Sergei Gerasimenko
Hypothesis that you would want to validate.
- [29:43]
Vasco Duarte
So you say you talked several times already about this narrative, strategic narrative, and a Strategic document. Can you just outline high level how your annual strategic planning works specifically from the point of view of your role as a cto.
- [30:02]
Sergei Gerasimenko
So it will be a little bit tricky to explain because we're in the middle. Right. I would use a lot of vocabulary that we used at MongoDB but at the same time at. Great, we're just getting started of establishing a handful of processes over there. So what I will say will be something in between. So how it works for me specifically right now is that I need to sit down and write up the, the draft of the documents. Like very, very high level draft that would include the sections of where do we think our product actually has a competitive feature, competitive functionality, like you know, where it actually solves specific user needs. Then we could talk also about what we see competition is doing, like what's happening on the market, how it would affect it or you know, our positioning and then try to also outline what we have from the roadmap that. Not the roadmap from the list of potential projects that we can pick up in the next six months. Right. Like when I say roadmap, I don't mean the PowerPoint slide with this, you know, Q1, Q2, Q3, Q3 and some stars.
- [31:09]
Vasco Duarte
I remember that, yes.
- [31:10]
Sergei Gerasimenko
And the stars and the lines or the quarters. Right. I mean those are the roadmaps that we don't have. Instead what we have is the set of projects that we can pick up to prioritize. And typically, you know, the amount of projects that you already have is like two or three years worth of work ahead of you. Right. So they. The tricky part is always just picking up the things that would add tremendous amount of value in the short term. So in this case, this high level narrative is just more of our foundation. It's a high level brief that explains the market state, this current state of the product and where do we believe we actually need to invest. That's it. It's not necessary large, it's just a couple of pager, but it does have a lot of hyperlinks, asterisks and can send people into reading a lot of additional material just in order that was used to combine it.
- [32:06]
Vasco Duarte
So if I understand correctly, that document that you just said you draft, which I guess is more focused on the technology perspective to the strategic planning, it, it is as far as I understand, useful to trigger a conversation and a reflection with your peers. Right. It's not like a set of decisions, it's more like this is what we see, these are our options, these are Maybe the best options for the next year. Is that how you would describe it?
- [32:36]
Sergei Gerasimenko
Yeah, more or less on a high level.
- [32:39]
Vasco Duarte
And you did say, and I really like that you did say that, that a roadmap for you guys is not just one PowerPoint with some lines and some stars. Because I remember way back and when we both looked at many of those slides, of course you talked about having a list of potential initiatives. And I'm guessing that that would be more like, or very much like a strategic backlog. Is that kind of a good metaphor for it?
- [33:06]
Sergei Gerasimenko
Yes, that would be very, very, very much high level, like six months worth of a project. Right. So maybe also to take a step back, remember about the elements of any kind of good strategy. There is a seminal book called Good Strategy, Bad Strategy and highly recommend, and the author sums it up, that there are three key aspects there. The first one is the diagnosis, so explanation of where the things are. The second one is the guiding policy, like an explanation of what kind of criteria we will use in order to identify what we will do in order to address what we said in the diagnosis. And the third one is this coherent actions. So in our case, of course, those are this very, very specific projects that we would want to take. And again, on the, again on the, on the CTO level like, again, like, you know, it doesn't really matter the, the size of the company and what you operate with is this large investment areas that you would want to look into over the course of the next three to six months and try to pick them up and have a really, really good explanations why you're actually picking up like this, work over everything else that you have on the backlog, preferably again with the, you know, with the directory translatable business valor, but preferably in a way that, you know, if we do this, then we would be able to get, you know, 20% more of the markets just because we have a strong demand from the customers that are not that are in our prospects list, but haven't really adopted the solution.
- [34:41]
Vasco Duarte
So we're getting close to the end, Sergey, but I do want to ask you still two more questions. The first one is when you think about your career as a technology leader and cto, what's the biggest challenge you faced and how did you overcome it?
- [34:57]
Sergei Gerasimenko
I'd say that the biggest challenge actually, quite ironically, is the imposter syndrome and nothing else. And this is something that comes from the fact that the role of the CTO or the head of the technology in any kind of organization is very, very overloaded. Many people assume many things and you know, like all time ago I was also thinking that the CTO is the person who spends 75% time just coding things and then 25% being, you know, the nerdist nerd available out there. And that's actually not the reality. And this is something that also I learned by spending the five years at MongoDB. And we had two very, very distinct and different CTOs. One was the founding CTO and he was absolutely incredible from the perspective of pure technology leadership. He would be the person who would go and spend his weekend and he would come up with a half done product that a team of 15, 20 engineers could pick it up and build up an actual product that is sold to the customers. So he was absolutely incredible in this sense. But he lacked a lot in few other areas. And at some point of time he decided to leave the company and work in some other place. Just a lifestyle of choice. And we got a different person. And the different person was not a hands on engineer at all. He was in his late 50s, very, very far in the career. But he was absolutely incredible. Exactly as their, as the team leader, as a mascot, as our cheerleader, as the person who sets up the culture, as the person who figures out how to grow the process and scale their organization. And once I saw this difference, it was also very interesting to see that the role are largely also defined by the state where the organization is. And sometimes it also defies by the amount of business change that you have in the organization. There is a really, really famous paper that is called four roles of the cto. If I remember right by our.
- [37:04]
Vasco Duarte
By.
- [37:04]
Sergei Gerasimenko
An author that I actually don't remember. Like I need to look into my memory. Tom Beret. Now I got it. Tom Beret. The role of the cto and what Tom was actually talking there is that if you think of the business, business change and you think of the amount of the technology as a product that your organization is solving. Like, you know, think of this sort of, you know, two accesses, right? You can chart four high level roles of the cto which would be big thinker. So this is the person who tinkers with technology, tries to figure out where, where the company needs to go next, you know, prototype something with them drew knob boards, this kind of stuff. There is an infrastructure manager. So this is the person who is mostly looking after effective use of the infrastructure that the company has, whether the, whether the data center is actually operating at the full capacity. So those kind of roles are very, very frequently connected with the consulting companies, this externally faced technologist. And this is also another role that popularizes the role and the technology or among the public. And then the last one and the last one is called operations manager and visionary. And this is a role that actually combines a little bit of what you think you would need to be doing on the market and at the same time making sure that this vision can be translated into reality. And basically this is the role that they figured out is something that actually can add a lot of value in because I'm not comfortable with the other three aspects at all. Speaking on public or tweaking with their assembler on my free time at night or looking really, really, really far into resource utilization and like what are we doing with aws? But actually figuring out where we need to go and how to transform it in the way that the organization that builds it would be inherently happy and interested and motivated is something that personally interests me. And again what I figured out is that there are a handful of companies that actually need a person exactly like that.
- [39:06]
Vasco Duarte
Absolutely and beautifully described. We'll put the link to the article for sure so that people can go and easily check it out. And the last question for me, you've lot obviously you have thought a lot about the CTO role as a leader and a cto, what was the book that most influenced your approach to the role?
- [39:26]
Sergei Gerasimenko
There are three. I'll make actually a handful of recommendations but perhaps the book that affected me the most and not as a cto, but just as an engineering manager back in the day. There's very little difference, honestly speaking for the role is a book called Peopleware by a person called Tom DeMarco. And the book is written in 1987. 88. It's really, really old one but the book was written by two consultants who made a general claim that for the software systems the problem that are usually occurring there they're not just because of the badly implemented architecture or some horrible decision that has been made. Majority of the technological problems in any software systems they are actually caused by the people, by the relationships and how they actually build the system together. So this is why they called the book people were and they stressed a lot of importance on how the work is done, you know, the amount of interruptions that happening to the development process, all this, you know, meetings with the managers, this schmoozing with the coffee cup, like, you know, give me the status of the project. It stressed the concept of craftsmanship in the software development where you actually need to spend enough of time building things in A way that you actually proud of them, not just because there is a deadline and that you have to push it. Stress the importance of organizational support. So engineering organization is really, really feeling that the work that they're doing matters regardless again the type of the company. And then over time I read another book that was called Drive by Daniel Pink and it has very little to do with the technology, but it described how modern workforce treats motivation. When we shifted from the factory work where your motivation was, you know, you show up at the factory, you do something, you get your paycheck, you get the food, right, where we actually shifted more into this informational agent. What Daniel Ping summarizes is that there are three key factors that affect how we work and our general satisfaction with what we do. And those are autonomy, mastery and the sense of purpose. And in this case autonomy is that to a large degree you're actually able to choose what you work on and how you actually build it. There is mastery, which means that again, you have enough of time to actually build things to the state where you could be proud of them. And the sense of purpose is that no matter what kind of product you're building, you need to know that it actually adds up valor to someone. You're not building it just because somebody asks you, but you really truly understand the reasons the user needs the, the application area and then the third one are again not directly related to the technology. Would be Jim Collins good to great. Just a classical read on how to deal their good performance organization. And there is just one line that they want to say is that I might misrepresent it a little bit. I read the book a very, very long time ago, but I think Jim Collins said there that it doesn't really matter where the bus is heading. What matters is what kind of people you have on the bus. So the importance of the team, right, so it's what kind of products you build. Like reflecting at our Nokia operation, if we wouldn't be building the phones, it wouldn't really be mattering what we would be building. Just because the team was absolutely great, everybody were absolutely motivated and dedicated of building a product. And if we were pivoted to building smart television, like everybody, they probably.
- [42:55]
Vasco Duarte
Some of the competitors of Nokia did do that. They pivoted to developing smart televisions, smart dishwashers, washers and vacuum cleaners and so on Sergey, it's been an absolute pleasure and very insightful conversation. If people can get in touch with you and know more about what you're doing, where could they go?
- [43:18]
Sergei Gerasimenko
LinkedIn probably my LinkedIn profile is the most up to date and lively social media network that I'm maintaining right now so I can provide a link that people could follow and DM me if there's any questions that they could answer.
- [43:36]
Vasco Duarte
Absolutely and we'll put the link on the show notes. So do get in touch and why not ask a few follow up questions from Sergey Sergey, it's been an absolute pleasure. Thank you very much for your generosity with your time and your knowledge.
- [43:48]
Sergei Gerasimenko
Thank you Vasko. Thanks for having me.
- [43:54]
Vasco Duarte
Oh boy, I bet you are buzzing with ideas after listening to this episode. I know I was. Now there are so many ways we can help the leaders we work with, so I hope this episode helped you get some of those ideas going and getting inspired hopefully also to take action. That's what matters in the end. Don't forget that. Now if you want to check out the key lessons from this episode, check out the show notes@scrummastertoolbox.org but for now I'll say goodbye and see you in the next episode. We really hope you liked our show and if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is is carrying.