Human Relationships and Digital Transformation

Welcome to another episode of Innovation Tales! Today, we delve into the often-overlooked human element of digital transformation with Sergey Gladkikh, a technology consultant with over 15 years of experience. We’ll explore how trust and relationships can make or break even the most technically sound projects. 

Have you ever witnessed a project on track suddenly fall apart? Or one teetering on failure miraculously turn into a success? Prepare to be amazed by two real-life stories that showcase the power of perception in shaping outcomes. In the second half, Sergey shares practical advice on building successful teams and the importance of strategic “reality checks.” From Accenture and PwC to Knowledge Expert, Sergey’s journey encompasses renowned companies and a passion for mentoring teams through agile methodologies. Buckle up for a conversation that goes beyond technology and into the heart of human dynamics driving innovation.

—

Listen to the podcast here

The Impact Of Human Relationships On Digital Transformation Initiatives With Sergey Gladkikh

Introduction

Our guest is Sergey Gladkikh, and we’ll be discussing the impact that human relationships and especially trust can have on digital transformation initiatives. Were you ever involved in a project that was technically on track but got canceled anyway? What about a project that was almost a failure but turned into a huge success? I’ll stick around and know two powerful stories that demonstrate that perception can be everything.

In the second part of the interview, Sergey shares practical advice on how to set up a team for success rather than leaving the human element to chance. He makes a terrific point about reality checks that you won’t want to miss. Sergey has been a technology consultant for many years helping his enterprise clients streamline their operations and foster innovation using low code and business process management platforms. He’s widely recognized for his thought leadership in digital strategy and for his dedication, to mentoring teams embracing agile methodologies. He has held positions with famous companies like Accenture and PWC and is now at Knowledge Expert, a Capgemini company. Without further ado, here’s my conversation with Sergey Gladkikh.

Sergey, welcome.

Thank you.

I’m glad to have you on the show. You’re quite the master of digital transformations. You’re an expert in technologies like Low-Code, Business Process Management and DevOps, but you’ve also been vocal about agile methods and other organizational questions. Can you give us an idea of what led you to take an interest in such a broad area of topics?

First of all, thank you. I’m quite happy to be here. Coming back to your question, I think that it started right away when I started my career. My first formal job while I was still at the uni, was a pure software developer job. Already at that time, I felt disappointed by the relatively narrow scope of my responsibilities in that job. [00:02:18] for a few months, I don’t remember exactly, and after that, I joined my first consulting company.

Since then, almost my entire career I spent in consulting. I felt, more motivated, and more excited to work in a role that still revolved around technology. It also had a lot of other parts, including the part where, you interact with people, with the client and the business and that has always been interesting for me. I’ve always tried to develop my skills in that area as well as the technical excellence. 

From the conversation you and I had to prepare for the interview, I understood that you find the technological side of digital transformation projects sometimes to be overrated. Would you mind giving us an idea of why you believe that people have the most impact on success?

I would not use the word overrated. I have a feeling that in terms of the area of focus when a project is planned and organized, a lot of attention is given to the choice of first technology if we talk about digital transformation projects, choice of the platform and tools. Second, usually, the choice of methodology plays a big part then when it comes down to the people who are going to do it, the teams, the individuals, it’s usually, “Now we need to find experts in this technology and this methodology, match them all together and hope that it all works out.” 

I feel like that is not the most optimal way to do it. Sometimes you are lucky. Sometimes after this process, you end up with a group of people, teams, technical teams, QA teams and businesses. They end up working quite well together and you get a successful project, but sometimes not, and in my experience, whatever it’s worth. I’m not sure how statistically representative it is, but that’s what I can go with. I see a strong correlation between the fact that in those projects where I have seen good relationships and cohesion between teams and individuals. Those projects tend to be more successful. 

Digital Transformation: When there is good relationship and cohesion between teams and individuals, projects tend to be more successful, while projects with tension and incompatibilities between the approaches of different people tend to struggle.

1) The projects where there was tension in compatibility between the approach of different involved stakeholders, things like that. Those are the ones that tend to struggle. While the choice of technology, in my view, I worked. I focused on one technology specifically, but I’ve been exposed to many others during my career and I haven’t seen a big difference. 

 It’s like being lucky by design, by making sure that the people gel well together and they’re motivated rather than leaving it to essentially the chance.

It is what very often happens because as I said, attention is given to other areas. The same with methodology. While the methodology is helpful in setting, it’s a shared playbook. If a methodology is followed by everyone involved, it makes things easier because we all play by the same rules. What exactly is that set of rules may not be important as long as it’s understood and followed by everyone involved, I was involved in waterfall projects, agile projects, safe and everything in between. Usually, it’s somewhere in between in real life. I didn’t see any correlation between the success rate or the choice of methodology used. 

Echoes Of Innovation

In this segment, we use storytelling to bring authentic insights to our audience, but I always advise using discretion with names and specifics to protect people’s privacy and confidentiality agreements. Feel free to use generalizations or change names whenever necessary. With that in mind, can you think of a past project that would be good to illustrate what you were talking about? The fact that you can design a group of people or help them operate and be successful, maybe a project where it wasn’t, let’s say, great to start with because like you said, the focus was on methodology or technology, but eventually maybe there was transition to more performance phase of the project. In any case, if you have an example in mind, start by setting the context. What’s the background? What are we trying to achieve? 

I would like to share two different examples. One of them is the opposite of what you suggested. It started out and went on quite well for a long time and then faced some unexpected issues. Let me not spoil it right away. To set the context, we are talking about a client company, the financial sector, a very big company, that is important to the understanding of the story. It’s a big enterprise, a big international company I was not part of that company. I was part of a consulting company, a big international consulting company working together with that client on a digital transformation project. When I came into the pictures, I had already developed a relationship between the two and between specific teams working in a certain area of the business, developing local applications for that area of the business. 

Technology is not the root cause of the issue. It’s the lack of  trust and understanding between the teams.

It was a bumpy ride. It had been a bumpy ride by the time I joined, which without it already in this natural process some things did not work and some people drifted away. I was lucky to come into the picture at a time when things have stabilized, where through a natural process, the number of teams and stakeholders learn to work together quite well. It was a great experience for me. In terms of my personal and professional development played a be a role in having a successful project both in terms of what we did from the technology perspective, it was quite outstanding. Sometimes in the interviews, they ask you what are you proud of.

If I talk about the technology aspect, I usually, talk about that project. We did something quite unusual with the technology platform that we had. The more important and maybe personally more satisfying part was again that I was part of a team that worked well together and everyone was happy with the progress we were making. That one dawned for quite some time until we started to realize it, and that realization came not just to me but also to others in this team. We thought while we formed a small group of well-connected individuals and teams, we were in isolation from a big context and specifically the business sponsors of this entire endeavor.

In the end, it was quite an unpleasant surprise to many of us when they decided to stop the financing of the project. It was already life by the time it wasn’t production and new features were constantly added at some point the business came back to us and said, we see no point in continuing this. I had there an example. Here we have good relationships and good connections, and everything is working fine, but we missed the vital link. There were other stakeholders who also play a very important role, a critical role that we did not invest time and effort to build the connection with, to ensure that we were on the same page in terms of the progress we were making. 

We felt we made tremendous progress, but they didn’t apparently, and in the end, the project was killed after two and a half years. That was also a lesson for me that when you measure the success of something by formal criteria, is it working? Yes, it’s working in production, millions of cases, literally lots of KPIs shown how effective it is. That’s not what matters. What matters is do the people who are the sponsors and stakeholders who initiated all of this, how do they perceive the success and this perception, I’m not even questioning whether it was rational and objective or not. That’s beside the point. The point is that perception is what matters most in this situation.

Perception is what matters most.

Perception is the reality when they can stop the project.

That is one example, which for me was also one of the situations that reinforced already at that time I had a feeling that the personal side plays a huge role in the success of any project. After that, that reinforced my belief.

It certainly sounds in this example you couldn’t have explained the decision to stop through technology or methods.

No, because if you look at any of those formal criteria, the reason was going well.

You said you had a second one.

Indeed, this is the opposite story, a story where things were going badly at the beginning, despite the fact that the team involved on the implementation side included a bunch of talented professional people who were talented, not just from the perspective of technology, but they were experienced senior consulting leaders who also had a great track record of building a successful relationship with clients. 

There were clients who were, especially as I found out later, quite flexible, receptive, and ready to listen and make compromises. On the surface, it would seem like it was a good setup to succeed. It was also using the state of the local platform. It was using the safe methodology, which is also supposed to be one of the best things you can do these days, yet at the time when I joined the project, which is in fact a context in which hedge joint was already firefighting, there was an understanding both from the consulting side, client-side and things are not working out.

I was called into that project as a firefighter to see if I could somehow help improve the situation originally the focus was on the technology. Everyone told me, “We are having issues with our quality, the quality of the code. The test results constantly discover a lot of bags. You should do a technical audit of the application with your experience. Maybe you can help us out.” Very quickly, I discovered that while there were some problems with the technology side, that was not the root cause of the issue.

There was a lack of trust and understanding between the implementation team and the business team. Complete lack of trust, which made it impossible to make any progress. It took many months and a lot of rotation in the team. We managed to make it right. When we understand that the problem is building trust in relationships with key stakeholders on the client side we need to focus on that, we need to have open and honest conversations to understand what’s going on from their perspective. It was difficult for the team for sure. 

If I look at the regular developers in the team, they felt very stressed because on the one hand, they were working hard and doing their best, and on the other hand, they were constantly facing dissatisfaction and open frustration from the client. There was pressure to do more, to do better, but they didn’t seem to achieve anything, trying harder to do the same.

Not seeing any value in any extra effort they make.

It was a very frustrating experience and that created tension even within the team, between the developers and the PO or the Product Owner, the QA side and the development side. There were tensions everywhere because these things tend to spiral out of control when you get in this way. Vicious cycle of okay, things don’t go well. Unfortunately, we as humans tend to blame others. It’s a very natural tendency. Since everyone felt like, “I’m doing my best here, things are not working out,” probably that’s because everyone else is not doing well. That is the fuel for tearing a team apart and that’s what was happening there.

It sounds like this is a happy story or a story with a happy ending. Was there a clear moment where things pivoted or was there a longer phase of realization?

It was definitely a longer phase if things were not fixed in a day. Luckily for us, we had time while there was pressure in terms of the timeline and budget. They were already discussing shutting down the project, not even trying to get to a go live, shutting this down, and the losses from the client side. We managed to start migrating things in time to prevent that. Over time, one of the key things that helped was creating the perception of the client that these consultants are here only to make money because that was the perception and the time that, “They’re just here to make more money. They don’t care about anything else. They’re making money.”

That was literally the perception. While some of the people from our side were trying to break that if it did not work because the thing is naturally when things are not going well, there is a tendency to try to cover up. Some of the people on the consulting side fell for the trapper, whereas they were constantly trying to portray things in a more positive light, not even hiding things, but trying to put a positive spin, an optimistic spin on it, which seemed like the right way to do.

The client is constantly negative, but look at how much we have achieved. The client perceived that as, “They’re trying to oversell themselves all the time. They don’t want to acknowledge problems and instead over cells and words they do.” What I try to do is look at his frontal perspective of the client, join them in that nightmare, go with them and say, “Yes, it’s terrible. This is a disaster. Let’s try to save it still.”|

From their perspective, then what’s changed?

Over time, they came to realize that maybe they did not perceive things quite objectively at the beginning. At the moment, it was important that they gained a sense that they have more control, that finally they are presented with a situation as is with all the problems laid bare with no overselling or trying to paint things in a better way like, “This is an honest picture.” Because of a lack of trust, they naturally wanted to have a lot of control or what we do and how we do things.

My view was, “Let’s do it your way. Fair enough. Because we’ve been trying to do it our way, apparently it’s not working now, let’s do it your way.” Even though I knew that some of the things they suggested, like tracking time spent on each Jira task by the hour so that all developers should log exactly how much time spent they spent on every single task, it would be counterproductive. They needed that at the moment to change their perception, to build trust because, at some point, they thought that, “The developers and maybe not working honestly or doing something else on the side,” or whatever. There’s a basic trust issue there. Change is like that. Change is where we have to give in, even if we are like, “That’s not a rational thing to do,” but that can help us to improve this relationship point.

It sounds like from their perspective, they observed the change and people cared more. They saw people who would see from their perspective and try to provide a bit more transparency.

They realize that people are working hard and people are already doing their best, then there was a question of formal things like organizing back around QA and documenting acceptance criteria in the stories to make sure that the expectations are very clearly defined because when you already have a very good relationship between your business and developers, you don’t need those formalities. You can have your developer talk to the business people and go and develop things on the fly.

When you don’t have that, when you have a complete lack of trust and understanding, this is where formalities help, having super detailed, well-documented acceptance criteria and test scenarios and based on that helps to show, “This is what you ask. This is exactly what we need. This is exactly how it works. We have all of this here clearly documented.” It helps to start breaching that gap. Over time, after months and months, first, we abandoned the time login, then we stopped detailing on every sub-task exactly what we do, and then even breaking things down into sub-tasks and then eventually also not being formal about testing and everything, not putting screenshots on every ticket of what has been done. 

Once you overcome those problems, you can go back to a normal way of working and suddenly you do all the same things that you were doing a year ago, but now they were because you have the goodwill and the trust. That’s turned into very successful stories that turned into a successful live. The client was very happy with it and wanted to work with us more on another project. It was the opposite of the previous story in some ways where it started quite badly, but we managed to make it work. The main effort to fix it was about personal things, relationships, understanding, and ultimately trust. 

Thank you very much. Those are two very powerful stories that truly illustrate the point that you were making. 

—

Blueprints Of Innovation

In this segment, we are going to look at tools and methods. It is designed to be a shorter segment, but before we proceed, if you find Sergey’s stories valuable, please like and subscribe to help us share the episode with more people. Sergey, I want to use this as an opportunity to challenge you a little bit, if you don’t mind because at the beginning you made three categories. You talked about the technology, the methods, and the relationship between the people. Aren’t there sometimes links between those things where for example, the method helps people to trust each other more? I’m thinking, for example, you mentioned the scaled agile framework before safe, it has a fair number of articles about building trust between an organization and its external suppliers. What do you think is that tool or method that is worth mentioning for yourself? Do you find it relevant in your work?

Indeed, from the perspective, if I had to choose a methodology and in an abstract situation, all artists are equal. Safe is a great methodology, especially for an enterprise context, which is the one I happen to work with most of my time. It has the right priorities and focus, which aligns with my point that it puts a lot of focus on building trust and relationships between the key stakeholders, having the right level of visibility and things like that. Just the right level of control. However, the challenge here is that, let me put it this way, it can be problematic if methodology becomes the goal rather than means to an end. Even in that example that I mentioned. One of the things that were perceived by the client as being the problem where they are, “This is not working. We don’t like your methodology,” and then the consultant goes, “No, this is the best methodology. We will keep using it.”

It can be problematic if methodology becomes the goal rather than the means to an end.

I believe this is not the right way to approach it. We should always look at things in the context of where we are and what is the current situation, especially with the relationship with the client, with the key stakeholder. We should not sacrifice that in favor of staying pure with our methodological approach. It’s an instrument. It’s not something that should be put ahead of everything else.

What I understand is that it’s dangerous to be talking about methods in such contexts because it can be the source of more distrust and more arguments, but the whole point is to let people collaborate more and provide them with more transparency and reassurance. Before we move on to the third and final segment, staying with the scaled agile framework or any other method that promotes trust, what would be the 2 or 3 mechanisms that you would try to ensure are there every single time? 

Maybe I will answer a different question. When you ask the things that comes to my mind first is having reality checks. Whatever methodology you use, it’s essential to have reality checks the more often the better. What do I mean by that? A production goal line is a very good reality check, but then many other things can be a reality check. QA and UAT or User Acceptance Test are forms of reality check. In that sense, why that is one of the things that make waterfall methodology not good because by design it postpones reality checks. I have a feeling that this lack of reality checks can lead to problems in multiple ways. If you have a negative scenario like the one I described, where you already have a lack of trust, you may end up in a situation where some work which is objectively quite good is not perceived as such because that was no objective way to qualify that. 

 

 On the other hand, which probably happens more often, is that you can have something that’s bad that nobody’s aware of, because nobody had any reality checks then after a very long time, everyone might be in for a very unpleasant surprise. When you already have problems with trust, having those reality checks in any form can help to rebuild trust because, in the end, you need to establish criteria of objective realities that will be agreed and undisputed by everyone involved. That may be test results, that may be time tracking in during tasks, or something clear and objective that will be undisputed and agreed on by all parties.

Innovator’s Playbook

The third and final segment focuses on practical advice and let’s unpack what we were describing earlier about trust and collaboration between people. Let’s look at it from the point of view of a leader beginning their digital transformation. What advice would you give them at that point?

It’s difficult to give generic advice. I will try to make it a little bit more specific. I will talk from the perspective that is closest to me, which is someone working in the consulting space who is responsible not just for working with the client, building the relationship with the client, but also bringing together people to form teams that will deliver the services to the client. I will probably start with that. Building the right team is a huge factor for success. While it is essential to have the people who have the right skills and knowledge for the job you are hiring them for, it should also be tremendously important and emphasized that the people work together well. They really form a team, not a collection of individuals. 

They are on the same page as you in terms of, “What we’re trying to achieve? How do we work? How do we go to the client?” This very often happens naturally if you are the person who let’s say, does the hire and does the interviews, you will subjectively tend to select colleagues who think like you act like you in some ways, it’s a natural bias. If you work in a bigger organization, there’s a very high chance that you will be working with people who you didn’t hire, interview or select. Not just, “These are the people available on the bench today. Here you go, that’s your team.” That can be a huge challenge. Sometimes we need to be strong. If you see it doesn’t work and are not the right people, or at least if you bring them together, they don’t form the right team. 

 It’s not a good idea to go in there and hope things will work out because if it’s not very smooth then they are under stress on the client engagement. It’ll only get worse. I’ve seen that happen as well. I’ve seen both successful exams where a team of people who are amazing working together, overcoming challenges, but I also stayed in the house since it completely degraded and fell apart. If you put a team that’s already mad then you put them in a stressful situation. I feel like that part, which I think a lot of leaders naturally realize, but I feel that we don’t talk enough about that. We don’t make that a point of our discussion as an objective thing that must be taken care of.  If you are in a big consulting company and you have to staff a project, everyone will talk about the formal criteria, years of experience, do they have the right certifications, and things like that. Everyone talks about that. That’s important, but that alone is not going to get you a successful project.

It goes back to what you were saying at the beginning where don’t leave these things to luck. Design for them. In a previous episode, I was talking about outsourcing innovation. I was making the point that outsourcing innovation is not necessarily the same as outsourcing the maintenance of your systems or a more operational business-as-usual type of activity. I feel like sometimes organizations will outsource and as you mentioned, will never get to choose the people that they’re going to work with. Let’s go into specific advice. What advice could we give a leader starting on their digital transformation journey who is going to be outsourcing, what is the right way to outsource from your perspective? 

Let me try to switch perspectives here. I put myself in the shoes of an actual potential client who wants to develop their business and transform the current tools, use the most advanced modern solutions for whatever the business is doing they want to use consulting naturally, a lot of companies do this, it’s very often not a smart choice to try to build an expertise in-house. Sometimes it’s not practical or not feasible at all. You have to outsource how do you approach that? This is a huge challenge because most likely you are already under constraints. You have your procurement departments. You have maybe some average daily rate constraints that you have to follow.

In that situation, you will tend to look at the financial part. You will look at the company who have all the formal things and many people certified in this technology and many congregating years of experience. One of the most important things you will look at is, “Can we afford them?” That’s the harsh reality. With all of that, you need to keep in mind that if you are a person who’s responsible, who’s starting a new project, and you probably still want to succeed both for your personal psychological well-being, but also from the perspective of your career, a very pragmatic consideration, you want that project to succeed.

That means probably you need to find the system you are in, you need to bend those constraints and all those formal criteria that the environment and everyone around you expect to follow, instead trying to figure out who you are dealing with. As much as possible, try in advance if you are already selecting your outsourcing partner, your supplier to see behind all these formal numbers and criteria, the people you will be working with, both the leaders, but also try to get an opportunity to see more needle management in the average consultant that you will be working with. 

Try to see from that perspective, “Are these the people I want to work with? Are these the people who can make a successful project for me and who will work together with me rather than for me?” That’s a key thing. It’s very difficult. You will find challenges along the way. You will find a situation where they offer you, “You can do a formal interview of your potential team members,” but that’s not going to cut it. That formal interview will not give you a feeling of who the people are and how they work. Talking about methodologies, there are tools and techniques that rather some innovation sprints, some discovery workshops, some situations where you can get together with those people in a not very formal environment, but a more working environment, spend some time together with them trying to achieve something to see them in action and do that before you commit to long to cooperation with those people. I feel like that’s the only way to get this feeling, “Is this going to work?”

That fosters trust and collaboration.

It’s something that he said, but I said it in passing and it’s something I would say is important to focus on is that cultivating the spirit of collaboration rather than service. Making sure that both you and your outsourcing partner see this as a partnership rather than a situation where they are offering you a service. You work together with them to achieve shared success rather than they work for you because you pay them money that is something where I’m going to make a reference here, which maybe you will want to cut in the final version because it’s very specific and it’s specific to my mathematical background. 

It’s important to focus on cultivating the spirit of collaboration rather than service.

The thing is, there are mathematical models that attempt to simulate pretty much everything including social constructs and this specific situation where you have a chain of leadership, several iterations in the chain where you have your top-level management, then they have someone working for them. It may be subordinates or outsourcing partners. There are two different approaches here, but one that I want to talk about is, let’s say we have this abstract situation where on every level, the goal of your next level alone is to satisfy you in a sense that they don’t care about your objectives, they care about what you told them to do, and they formally want to do exactly what you told them they don’t care about any context or whatever, “This is our job. Our boss or client gave us this job and we want to achieve that.” 

The model that described this shows that if you have two levels in this equation, it works fine. If you have three levels, it starts to get a bit different, and difficult, but if you have four levels, it’s never going to work as the model diverges. It’s impossible to make that work. If you have four levels, you are in a situation where whatever happens at the bottom level will never achieve whatever’s the top level.

It is statistically very unlikely.

Unlikely to a point where practically, it’s impossible. It’s an abstract situation. In reality, you never have this fully black and white. It’s always somewhere in between. This example illustrates that it’s in your interest to pull this as far as possible from the approach where “We work for you, this is what you told us to do, and we want to do exactly that, go away from that to a point where we work together. This is our shared objective, which we all understand we are fully transparent on what that objective is and how we are trying to achieve that.” As a leader or a client, you need to constantly make an effort to keep thin, keep that mindset active, and keep reminding not just with words but with your own actions and attitude that, “This is how we work.”

Digital Transformation: Be fully transparent about what the objective is and how you are trying to achieve that. As a leader, you need to constantly make an effort to keep that mindset active.

It sounds like the advice you were given about promoting, selecting the right people who work together well, and then promoting understanding of what is the vision, why do we do this so that people at different levels understand each other? It sounds like this advice would be good advice even for an organization that doesn’t outsource its innovation. Would there be anything specific in those situations that you would advise them if they’re not as reliant on external partners, but if they’re working mostly with their own people, and employees, what insights complimentary to what you already said? What other advice would you give them?

In the context of your own people and organization where you have much more control over, the people that work in your teams. I always find it one of the most critical points is the balance between retention and new talent. On one hand, you want stable teams with people that you have successfully interviewed and make sure that these are the right people, they work well together, and everything is amazing, then as an employer, you want that super performance team to stay there and do what they do well indefinitely, but it’s never going to happen.

People will outgrowth their roles. People will develop new interests and new ambitions. They will leave because they get a much better competitor offer, which you cannot match. There are many things. You cannot freeze your status score. Your team will always be dynamic. In that situation, the suggestion I would give, which is again not original at all, keep people that you can with high confidence, retain for a very long term, build a team around them, and make them the end course of your team.

Make sure that in this dynamic environment where people keep coming and going and things change, there are some points of stability that you as a leader can rely on to keep things going as a whole over a long period of time. As a company in the modern world, almost no matter what it does, it’s your people who make it successful, whatever you have. For a consulting business, it’s more tools than anything else because you don’t have anything except people. If you are in the industry and you also have your plans for natural resources or whatever, but if you are in a technology business, you only have people, nothing else. You need to take care of them. You need to recognize that they are your most valuable asset.

Take care of the humans. As we are close to wrapping up, are there any final messages that you would leave our audience with?

To continue the trend of this discussion, I will say that right now, we are at a time where a lot of attention and discussions revolve around technological breakthroughs. There is the big topic of AI that excites and disturbs a lot of people, including business leaders, but also consultants, and developers, programs. A lot of questions were asked about what the future is going to look like with this breakthrough. I don’t know, nobody does, but I feel like the key things are not going to change. Human civilization is pretty old already. In a few thousand years it will look like a civilization period. 

Trying to see things from the other party’s perspective can be the key to fixing issues.

Over those times, there were a few technological revolutions and things. There were quite difficult times. Some of those transition periods were rather bumpy. In the end, I think the core things about how people coexist, how they work together, and how they cooperate, things didn’t change. I don’t think they will change. What I said about it, is the value of people and human relationships, any company, any project, I don’t think this is going anywhere. I think that AI will change that.

Thank you very much for being on the show.

Thank you for inviting me. It was very interesting.

It was a pleasure. Thank you.

—

Episode Wrap-Up

I hope you enjoyed this episode and the stories that Sergey shared with us. They illustrate the impact that human relationships, trust and perception can have on digital transformations regardless of their technical aspects. Sergey gave practical advice to leaders setting out on new journeys. He advised against relying solely on skillsets and qualifications when assembling a new team and recommended running innovation sprints and other forms of intense collaboration early on in order to ensure that the human element is not left to chance. We have more exciting topics and guest appearances lined up. Stay tuned for more tales of innovation that inspire, challenge, and transform. Until next time, peace. 

Important links

• Sergey Gladkikh – LinkedIn

About Sergey Gladkikh

A digital transformation maestro, Sergey Gladkikh is at the forefront of integrating agile and DevOps into business landscapes. His expertise shines in utilizing low-code and BPM platforms to streamline operations and foster innovation. Beyond his engineering prowess, Sergey is recognized for his impactful leadership in digital strategy and his dedication to mentoring teams towards embracing agile methodologies.

—

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc. Please visit https://www.scaledagileframework.com to learn more.

Pega® is a trademark of Pegasystems Inc. Please visit https://www.pega.com to learn more.