‘Building efficient dev teams through human-centered approach’ with Denis Čahuk, Technical Leadership Coach

Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we have a very special and unique guest with us. Although being a part of the startup ecosystem for more than 15 plus years, Denis brings a different set of expertise into this entire ecosystem. He has evolved his abilities and now helps mentors, engineering leaders to develop this growth mindset. He has a very unique approach, which he calls as a human-centered approach that he brings into the ecosystem and helps build efficient dev teams.

I think we are all fascinated by this concept and would like to hear from the man himself. Hey Denis, welcome to the show. Thank you for your time today. 

Denis: Hey, Mohan. Hello to our listeners, to our viewers. 

 Kshitij Mohan: Oh, yes. 

Denis: Thank you. Thank you for inviting me. 

Kshitij Mohan: Perfect. I think, firstly, Dennis, we are all fascinated by the concept that you are trying to bring in, and we love, by the way, your detailed insights that you share in crafting tech teams, so that’s really helpful.

And secondly, we have seen that happen. We just love this style of yours, the beads that come in, and I think a few words, we would all love to understand the significance of this and how it adds to your persona.

Denis: Well, I’ve always been a recovering left brainer. You know, I’ve always been very analytical and there came a time in my life where I can no longer solve problems by analyzing them. So I had to experience something outside of my comfort zone and on my way of personal growth and personal development. I sought out yoga and yogic and  Ayahuasca retreat, here in Italy, Europe. And that was possibly one of the hardest and, and not just hardest in the sense that it was hard.

There was something challenging, but prior to going it seemed that I am signing up for something that is impossible. That’s gonna be impossible, that’s gonna be for whatever reason, challenging and very difficult. And I just had a lot of irrational fear from it. And I carry it as a reminder that I did it.

That even though I thought it would be impossible, very challenging, that it’s way outside of my capabilities. I’m still here and I’ve grown a lot from that experience. 

 Kshitij Mohan: Oh. So I think great story Denis. It’s a reminder of you did it and I think. That’s how I think you might have added this aspect into your entire approach of building the teams as well.

Denis: Absolutely. 

Kshitij Mohan: Perfect, Dennis. I think, to get started with this entire theory and the concept that you bring in, right? I think the first foundational thing that always comes in is psychological safety, right? How do you ensure that you are able to impart or set this psychological safety within teams that fosters productivity and transparency?

I think that’s the most challenging part that most of the teams face today. How do you do that? Or what processes do you think you follow around that?

Denis: It is one of my core, let’s say the aspects of why I’m not just calling myself a trainer or like an agile coach. I don’t like labeling myself an agile coach.

The coaching that I bring is life coaching. But it’s specifically targeted to a tech audience.  And I like to separate that out because I’m not here to coach you on how to use Jira, What one story point means. I don’t particularly care about that nuance of, let’s say, methodology or just tooling.

What I care about the people who use this and one of the aspects of my coaching, the life coaching aspect is that whenever I’m working with a team, I’m also working behind the scenes one-on-one, privately with the team lead. I might instruct them okay, I have a feeling if I ask them, they’ll remain silent.

That’s your feeling as well. And that’s usually the first signal, the deadly silence. That’s usually the first signal that the team doesn’t feel safe to speak up. So it’s very hard to ask a team, Hey, is there anything that we could improve? And they’re silent.

They don’t say no, it’s just silence, right? So it’s not true or false. It’s true, false, and null right? And, you want the process to come to a Yes. And then follow up with, okay,  where should we start?  Usually, leaders get stuck in getting null back and they don’t know what to do with No.

So, one of the first things we do is even check if that’s a problem. Usually, it is, but it’s not on the surface. So usually I get to know a team before we even get anywhere close to it. But I can sense that there’s emotionally, psychologically, some boundaries, right?

So maybe they’re stressed out, just maybe they don’t have the cognitive load to even be thinking about showing up for the training calls. Maybe there’s just something super urgent going on in a company. And one of the things we do is because I’m working on the team from both sides, with the leader, and with the team. Right. We are working on the team from the outside and from the inside at the same time. And one of the things that I might ask,  once we know that psychological safety is something that we wanna work on, I might ask the leader privately, Hey, can you like model a behavior of saying you don’t know?

Or could you model a behavior? Could you do me a favor? Could you just, you know, whenever you encounter something that you don’t know about, just speak up and say, Hey, I don’t understand this. Could you explain it to me, Right? So that the leader models the behavior by example, immediately in front of the team because it’s possible that they, that if the team doesn’t feel psychologically safe, that then patterns start emerging.

And then the leader also doesn’t feel psychologically safe, to be vulnerable with the team, right? ’cause they, they might be playing off of each other to no fault of their own. Maybe it was left there by somebody who hired the original team and then they left and then that culture stuck and then everybody just got replaced one by one.

And then nobody knows really why that feeling is there. And nobody really set it up, but nobody’s really working or understanding of, is this a problem? Is it okay? Like, is this normal? And then the teams usually get accustomed to just thinking this is okay by default. And I come in to say, Hey, well, do you want it to be this way?

It’s like, no. But I don’t see what we could do to improve. Right? And that’s then the first step. Okay,  what if we could improve on it? Wouldn’t it be better if we could do this and this and this instead? 

Kshitij Mohan: And based on your experience,  you have found a breakthrough with the leaders easier or breakthrough, the dev teams easier.

So, because I feel that has to be somehow top to bottom driven, right? 

Denis: It’s complicated. You know, like when I’m talking to the leader, he’s also not on top right. I’m not talking to the most technically savvy founder, right? I’m talking to the leader of the team, so even they are not on top.

So they might be experiencing this also as a downstream problem with their leader. So I can’t really go to the source all the time. Sometimes it’s, I’d rather bring in another, Another coach who does executive level coaching or like founder level or board level coaching, depending on the type of the company.

And I just focus on the team and I essentially give a commitment to the team of improving the team without really, ’cause I can just get lost going down a rabbit hole,  traversing the entire vertical of the company. And,  the further away I get from the team, the harder, you know, it just gets at some point, it just gets organizationally.

So, such a large network of communication issues that change just becomes exponentially harder and harder to impact back down to the team. 

Kshitij Mohan: Another perfect use case of human emotions are simple, yet complicated. So I think we totally get where you’re coming from. 

Denis: But I don’t wanna dodge your question.

You know what’s usually the simplest is speaking up about it. I will speak up,  it’s like, Hey, I realized that you and I decided that this was a problem and, you didn’t speak up.  Like  just now, would it be okay if we talked about and then  I sort of model that to sort of weasel it out, but then if I know that if I leave the room, they won’t continue that behavior, right?

Because the safety isn’t permanent. I might bring it in temporarily so that we can discuss it, but it won’t establish itself permanently. Usually what we do is I would then go talk to one of the team members one-on-one to even see whether they want to improve on it. Right? Because you can always solve it from a different direction.

We can solve it from the direction of, if you’re working in a team where you don’t have that, you can sort of model that behavior bottom up. Not to the CTO level. But at least with you and your immediate peers and with your leader because as far as we as human, as employees are concerned that is your immediate impact radius.  Your leader, your manager, your supervisor, your team lead, your tech lead, your engineering manager. They are the one human being other than yourself, who has the biggest impact on your career at this company. 

Kshitij Mohan: Exactly

Denis: Right. So at least with them, That’s fully in your control, like how you respond to them and what kind of behavior you model yourself that we can solve on an individual level.

But usually, I’m not hired to then coach each engineer individually as well. We sometimes do that outside, of the company program then if they also hire me individually. I even just now had a, a few months back, had a case where I was coaching an engineer. For a very long time, one-on-one and then the team I was working with, they were hiring and I suggested, you know, they’re like, I have someone here I know they’re really good, they’re vetted. And I happen to know that they’re a cultural fit because I’m a fit with them and we are a fit. So I think if you just met in a meeting, you could, you could decide on whether to hire or not within 45 minutes.

Right. And then they ended up hiring that person, you know? So even that, you know, connecting the dots, playing, sometimes I’m playing matchmaker.  And then we continue it from that route because then it’s also easier because if I had worked with them, the employer also knows what to expect because I might have trained them in exactly the same ways that I’m training the team on.

So they have, not only do they know the curriculum, they didn’t even miss out on anything. And they have a head start because we’ve been doing it for a lot longer. 

 Kshitij Mohan: Perfect, perfect. Interesting. Dennis. So, coming to the point of two spectrums, right? So one is where this entire behavioral part comes in, whereas the other aspect is where every team, every company today is in the kiosk of releasing things fast, right? 

So in turning into somewhat feature factories, I think that’s a term that’s going on today, right? Yeah. So how do you suggest to balance this out, how CTOs and the leaders could actually stay away from this trap? 

Denis: I think staying away from the trap is not a good strategy. I think you should be able to go into the trap, realize that you’re trapped, and then safely get out.

Right. Because if you wanna avoid it and then accidentally step in, you still need to know how to get out of the trip. Right. So I think if you’re talking about it strategically, you would need to know it is like a first aid kit. Like we are not only doing prevention, but we are also gonna teach you what to do if it does happen. And because you know how much energy you need to invest to do, I don’t know, to revise someone or to give them first aid. When you understand how complicated and dangerous that is then you’ll do everything in your power to avoid that being necessary. Right. But it requires both components.

Right. So if I use this sort of first aid parallel to the feature factory, all you need to know a feature factory is a cost center. A feature factory is a subunit, a department, or even just a team or maybe just part of the team that is organized in such a manner that it is optimized for process.

It is not optimized for outcome. Because it is being perceived as a cost center. So if it has a high cost, we want as much output as much as possible from that unit, from that team, from that sub-department, squad, whatever it is drive whereas a profit center is pushing business KPIs.

And so they know that the salaries are fixed and the other fixed, you know, the other cost of goods and services provided is server costs, license fees, and anything else that might be necessary for data movement or security or just ongoing development as a sort of stable, but unpredictable cost, let’s say.

It is important to emphasize that first, you need to know what a profit center looks like and what a cost center looks like.  And then you need to be really honest with yourself, which one you are. If you are a cost center and you don’t want to be, that’s important.

Like you want to, you, there has to be some motivation for you to want to become a profit center. Then we can talk about what you asked me, how do we make a profit center out a cost center? 

Kshitij Mohan: What’s important aspect is realization that you are a call center and not the profit center.

Denis: Yeah, yeah.

Kshitij Mohan: No, definitely. And, in your experience, so generally how do you ensure or what process you follow that where people actually believe in this. Hey, we are not at all measuring the impact. We are just kind of running behind releasing it. How, how do you do that? 

Denis: It depends.

I think we can’t look at it specifically from the outside, you know? And say, Hey, oh, profit center, cost center bad, and you just go around the company and cost center bad, you know, and just point the finger and just like, you’re a cost center and you’re a cost center.

Everybody’s a cost center. No, it’s really important to not look at things as revenue streams, but as value streams. You know, hotels, luxurious hotels really understand this, that, you know if they hire a driver to pick you up from the airport, that person is part of a value stream. They provide value.

They might not immediately provide revenue, you might not even exchange money with them other than giving them a tip. Right. So they’re not an immediate revenue center, but they are part of a value stream of a bigger profit center. So it’s important that when we’re talking about a profit center, it’s usually not a unit. It is a network of collaborative strands of value streams that are sort of branching out from a core revenue stream, and it’s important that, the profit center who is sort of embodying that revenue stream, owns that revenue stream. So if this is a engineering team that builds a product, they own the business KPIs for the product being profitable.

So if you have a product department and the engineering department, These two teams or units of organization are divorced, right? So it’s like I have a task and on weekends you take care of the task. And on weekdays I take care of the task then that, that’s a divorced value stream, right?

So if the product team owns the value stream, the revenue stream and the engineering team just provides a value stream where they just minimize the cost of the engineering team  because the cost engineering team is also being used for other product revenue streams, and then that’s defacto a cost center that cannot become a profit center. Right. 

Kshitij Mohan: Definitely 

Denis: It is the, it is the product team that needs to absorb the engineering team into itself. Right. You can’t make that engineering team in isolation and just say, Hey, you know, create new networks where you no longer when, when you’re working with this product owner, you’re always a cost center just because of the nature of the relationship. So the only way to get out of that is to fire the product owner, you know, in the context of I will no longer service your tasks. Not fire as in leave from the company, but fire as in, okay, I’m now setting up a vertical. I’m vertically assimilating this engineering team into the company by giving it a dedicated product stream or value stream that they own. Right. And usually, this happens on the wrong end. Usually, this first happens on like DevOps or DevSecOps. You know, when they, they become the owners of security and certificates and how much we’re paying AWS and then they own that and then they actually become a profit center because they might actually optimize, hey, if we, instead of, you know, having three sales ops people who are also engineers, we can just promote them to actually be just full-time engineers and do it to the cloud and do this and do that. Then they become a profit center in that space. But in the context of the company, if they don’t control the entire KPI of providing value to the users.  And then understanding how the value is then being captured as revenue, and then measuring that and optimizing that. 

You need a small team for that. Yeah. And then a small team that’s part of a big organization. That team, even though it’s really flat, needs to be very high up. You can’t have seven managers above them because that is exactly what will diminish the capability of becoming a process. 

Kshitij Mohan: You contextually need to get into the details and then find out how exactly the system works. You know that definitely works. And just going one level deep. So by talking about this, efficiency, understanding the impact of, let’s say, what we were talking about, right? So there is this interesting approach of doing releases with event modeling, right? So then try to understand, uh, all the events and then design and define our information systems.

I think that’s something we would also love to know more about, right? So you have been doing that and you know, where the challenges come in, what the effectiveness looks like, and then that’s something. I think we and the users would all love to understand this piece. 

Denis: So how much do you know about event modeling? I can talk about this ad-lib for hours, but it would be we practical to know how do you see event model? What do you think it’s? 

Kshitij Mohan: Yeah. So I think the simplest way would be for us, as well as just to keep us context in the conversation, would be that,  firstly, how simplistically do you see when modeling, and then obviously second how do we design and implement it, which comes with the second.

The first part, what I see, is as a very simple understanding, the events that happen. And planning so that they happen and fall in the right piece. That’s what very simplistically, I would say event modeling is, but yeah, what your thoughts would be.

Denis: That was what I thought event modeling is, so that was my sort of version 1.0 understanding of what event modeling is until I met the person who discovered event modeling Adam Dymitruk.

I was set up three hour podcast episode with them ’cause we just went deep on event modeling and then I realized that event modeling is a sort of upgrade over typical agile processes. Right. So it’s not so much about designing a spec for events, event schemas as much as it is managing a project that has data flow.

Right. So event modeling is more the idea of rather than if, let’s say Kanban is the flow of tasks through a team’s pipeline then event modeling is the flow of data through the lifetime of creating a software project. 

Kshitij Mohan: Got it. 

Denis: So like if I have a data point that needs to go from point A to point B,  how does that data flow in version one?

How does that, and then when I release version two, how does the flow change? And when I release version three, how does that flow change? Okay. We have a new feature now. Does one of the flows split? Is it a new entry point? You know, are all features just essentially. Are we a feature factory? And you can tell from the event model because it feature factories have a very specific structure of a event model. You can spot that a feature factory is a feature factory, which is by the, the topology of the, of the event model because every stream is being completely isolated. There’s very little overlap. And you can essentially build seven features in parallel, independent of everybody else’s, data flow, except for maybe Feature flags and identity management, authentication, security. Yeah, the common modules. Right. So if you see that like it’s completely separate like this data flow is completely separate UI and that data flow is a completely separate UI. And this one has, and this one has, this one has. And then we just piggyback on synchronizing this, these two data points at the very end there because it’s user related as a feature factory. If we can decide to just not build six of those seven features, focus on one, determine if it has market value, if it has market demand at first, and then if it’s actually valuable to us, if we can then, if it’s valuable to the users, and then if it’s valuable to us, if we can capture revenue based on the value that it provides to the user.

Right? And then you can flip it from an event model, just a typical agile.  And what it helps with really is the slice, to do vertical slices across planning, because you’ve probably seen this before, where if there’s a typical like let’s say Scrum -esque Scrum inspired story and you put it in Jira you have this idea of, well, what does this look like when it’s finished?  But the tasks and the specs are talking about how to create it. But there’s nothing, there’s no communication. Very rarely you might, the good teams have goals and acceptance criteria. The great teams don’t even use stories. Right. So it’s not an upgrade you use something completely different. It’s this idea that if you’re planning your tasks with user stories, well, the story doesn’t say how it’ll evolve. If you’re doing continuous delivery, it doesn’t specifically specify how it’ll end up on production.

It just says what it looks like when it’s done and how, what are the technical details to complete it. But what we should really care about is if I add this feature, what data flow that’s already there, is it piggybacking on, does it interrupt the data flow? Does it augment the data flow? Does something that was previously atomic now become a saga? If this crash is conducting crash independently, you don’t see that flow because you, in a typical story system, you might just be adding things, but you are not actually adding them so that the old code is…

Kshitij Mohan: Together to reach that one common outcome.

Denis: Exactly. Right. So,  it’s as if your source code repository was also event sourced. Scrum creates that illusion that if I add seven features then I add the eighth one. I won’t touch the source code of the other seven, and I’ll just append right to the source files.

That’s not the case. Usually you go back and you start touching stuff. That’s what usually. But like badly managed non-modular, like big ball of mud monoliths are every feature you add, you need to keep touching something from the other features that are already in the system. It’s not an append-only source code repository.

Kshitij Mohan: Definitely.

Denis: And that’s what the event modeling tries to sort of highlight. It’s like, hey, if you’re building this feature and you need to touch a line of code in these nine other things, this is probably not the best way to go about it. But usually, this is not visualized. Right. And it’s only visualized partially, very temporarily in one engineer’s head, and only when it’s too late to course correct. When they’re already working on it and they’re stuck on something that would be the correct time to course correct in order. 

Kshitij Mohan: But it’s to realize that you would have to have the context of the entire system. And I think that’s where biggest challenge comes.

Denis: And the engineer has that when they’re writing the full end-to-end or integration test. So at least one person at some point will have that, but it’s usually too late in the project. Event modeling brings that further forward, but there’s a trade-off. The trade-off is you can’t really use it well with other project management methodologies. Like the event model has to be the main management methodology. Because the thing is that I really recommend beginner teams to start adopting is, well, now you see what it looks like, and an event model doesn’t just have events on the diagram. It has a historic flow of data. When the user logs in, here’s the user’s credentials, and then here is how the user’s credentials flow to the system. They appear temporarily here, they get transformed, their own account. Then that other piece here, that becomes a session and then this session at some point dies, and then they have to go back and do that thing again in a different kind of flow, and then that’s visualized. And this can also be the case for a bank account or an order or you know, it might go into the system and then we determine that, hey, actually we didn’t fulfill this order, but we forgot that we didn’t fulfill this order and now it’s been two months. Now it’s inappropriate to fulfill the order. So actually we need to go through a different flow but this is hard to express if you don’t think about your features as a data stream. Usually, features are a stream of development focus of, okay, where should we put engineering focus this month? Rather than, how are we adapting the data flow?  And what I recommend teams do the, you see the entire diagram, the events are not, the only thing on the diagram, what’s in the diagram is the dependencies between the event streams, the consequences of the event streams, the side effects of the event streams, and for each UI element you can see on the subcutaneous level. So it’s that invisible stuff just beneath the UI, non-technical stakeholders usually call that long darkness of backend stuff that you guys do that we can’t see. 

Kshitij Mohan: The black box.

Denis: It’s exactly expressed on the diagram. It’s like it becomes visible. Here it’s under the surface. This is the backend stuff, and you can see it because what we’re building is the flow of the data.

We’re enriching the flow of the data.  And what we you can do with event modeling is because you have them left to right sliced on a timeline, following the age of the data stream, you can decide not to start the project from the left side. Usually what teams do they start the project from the left side of the timeline of the data. So if you have a new greenfield project, you know, day one for data points are user registration and login. And then that’s where they would start the project following the age of their data. Whereas that’s usually the most commoditized part of the system that not the engineers should really be wasting time on. But then with the event model, we can say, well this is how it’s gonna end up. That young data age stuff where we are registering people, we’re not gonna waste time on that. Let’s start on the right side. Let’s start on the right side where I have a UI element that shows something really important to the user. You know, if I’m building Instagram, that might be the users feed. And when they come up they need to see a new feed every time. Let’s start with that. And on the subcutaneous level, let’s just fake that. Let’s just serve them random images until we connect the dots on the data pipeline behind the scenes. And let’s make that version one and let’s deploy it. And you can explain that to somebody who is non-technical by just visualizing the event model. But saying here’s the UI updates when this, what I call a projection, which could be and if you saw. Now that Twitter X whatever, twitter’s code was, the algorithm was published on GitHub. And you can see that, they have this sort of same similar system where they’re creating they’re not computing your feed as you log in. They just have it ready as a projection. So if I told you this is what the projection, this is the schema of the projection, looks like if I create a fake UI with a fake instance of that schema, I can create a prototype, no problem. I can create that prototype, possibly even using low code or no code solutions temporarily while the backend team is solving that really complex issue that where the, you know, the seven streams of data meet and then they, something complex happen.

You might actually have something to show and then the project manager can say, well, you know what?  For every UI element that we need to update, I want us to at least fake a lot of non-important stuff while you guys are working, like cracking the nut on this really big important thing. I still want us to see progress so that I can, you know, run tests or give it to the users or I wanna know how far away we are from the point where the users notice that we are faking data and that the next valuable step is giving them the real data.

Because if you’re saying no to all that,  if you’re building software products, especially as a startup but you’re not even considering that option where version one is a feature Complete,  fully blown enterprise-level version of the product. You are a year, 18 months behind the market.

Kshitij Mohan: Yeah. Definitely. I think this kind of helps into detailing, breaking it down, visualizing the right way. 

Denis: The breaking down is still, you know, it’s still here.  The model doesn’t break down the problem. You still need to ask a lot of questions, so you still need another process.

Event storming, you can still do naturally. And then just instead of leaving it on a board, that then becomes maybe an architecture diagram.  You continue storming and you just continue it into the event modeling flow. It’s like, okay, well we are in event storming, but rather than just talking about events, well show me what UI disappears on and then what do we, what do we call the data set that the UI is using?

And okay,  who can possibly cause this data set to refresh?  Okay. How can the user cause this data set to refresh? How often does that happen? Does it really need to refresh every time the user does this? And then that’s how you have these kinds of conversations on a completely non-technical jargonistic level.

And then you can decide to, you know, There are two, like Miro is great for this ’cause you can just zoom out, create a frame for it, and you can zoom in. And then when the non-technical stakeholders leave the room, the engineers can just zoom into one of them and then add the, the JSON Fields and the schemas.

And then I’m gonna have an entity direction diagram in here. And then when they come back into the room, you can zoom back out and it disappears. 

Kshitij Mohan: Perfect. Perfect. Dennis, I think this really helps. Super insightful on how visualization can definitely help and that leads to I think, one last aspect that we would love to talk about is these, the soft skills that you bring in this entire game, right?

And one of the important aspects that helps you grow and progress over time as well. So, quick thoughts on what do you think are the right set of things a leader, a manager should be focusing on, on the software scale aspect?

Denis: I like to think that engineers are very intelligent people that everybody really understands that this is really important. So the question isn’t so much, you know, what should they be working on? And should they be working on their soft skills?  I think the really tough question is figuring out instead of what, right?

Right. Because people might be thinking, oh yeah, I’ll learn soft skills if that’s replacing some of my boring meetings or if it’s replacing some of my annoying one-on-ones with my manager. I will learn soft skills if it gives me a little promotion. If the, instead of what is really benign, And sort of passive and on the side.

But I think if you really wanna take your tech career seriously and if you wanna take your, as a leader, as an engineering manager, as a tech leader, uh, or even just a product manager, if you wanna help your team hold themselves accountable, then if they’re behind on soft skills or if they think that that’s the biggest step forward and usually it is.

Then the soft skill training has to happen at the expense of technical specialization, and that’s the tough decision. It’s like, no, don’t learn the new framework. Leave zig and rust alone. Don’t do that new greenfield project. It’s like whatever technology we’re using, it’s good enough like to just use boring commodity software.

And better yourself as a human being. You know, rather than following, trying to follow the trend and getting really anxious about, oh, the AWS has a new certification 

Kshitij Mohan: Yeah, everyone worried about the new tech being released every other day 

Denis: And, oh my God, and ChatGPT and, now it’s no longer considered private and secure.

So now I need to learn link chain and what’s length chain and. What is it like? Like what I need to catch up on seven years of linear algebra and calculus. It’s like, no. It’s like those tools can wait, but soft skills can’t. Soft skills are your highest predictor of movement in any kind of organization.

Soft skills can help you land positions in FAANG companies, even if you’re technically not really competent. Like it is that impactful. Like, okay,  the FAANG companies might be a little bit stretching it ’cause they, you know, if they have nine rounds of interviews with you, they might call you out on something that you actually don’t know.

But you might learn it on the interview.  If you know how to prepare, you might, because a lot of engineers just going into interview and they get asked a question and they just freeze. They try to think themselves. Whereas with somebody who is not engineering savvy or didn’t spend a thousand hours on leet code, it’s a huge waste of time if they’re have very good soft skills.

You know, they might call out on the interview, Hey, like this is really awkward, but I don’t really know how to solve this. So I think that’s it for the interview, but could you gimme some pointers on what I should look up or where I could learn more about this and they might actually give them immediately material to look up and learn.

It’s like, do you mind if somebody who is sort of well versed in soft skills might ask, okay, well actually would you consider it cheating or would you mind if I just looked it up now and see where we can get to and like 20 minutes, right? Because that might be a much more. Warm and charismatic and likable approach to just having the interview.

If nothing else, it calms down the interviewer and you should get them on your side and that can go over a very long way. But now I’m talking about this from sort of a freshman sort of intern level for a team that’s has been through all this and there are professionally  decoupling has already happened.

You know, the team is now part of this team. The team has this manager, it has this tech stack. So there aren’t as many reversible, malleable decisions anymore. That team also has a lot of cultural depth. So the real question is not should they train soft skills. The question is obviously yes should they train soft skills?

But even if I, even if a team member like really goes up and wide on soft skills, is there anything on the team that prevents them from applying it? That is what I would focus on as a leader. It’s like, is there anything in our culture that prevents somebody who is well-spoken, who is very friendly, who is very open and helps everybody?

Is there anything in our culture that prevents them from embodying that? Like would they be attacked for doing that?  Would they be mistreated or ridiculed or, you know, I come from the Balkans where we have this sort of, proud view of, you know, if you don’t know something, you should have a plan.

If you don’t know how to make a plan, you’re probably incompetent, right? So you should hide. You should rather than talking about your problems, about your incompetence, you should just read up on it and prepare for the next meeting.  It’s sort of Spartan approach to a more competitive kind of collaboration.

Whereas, you know, the, one of the hardest things that I do with like C-level coaching or just,  senior management is I’ll just keep asking them questions until somebody says, I don’t know. And often times people can just, just spend hours running in circles and they will not say, I don’t know.

Right. And then I might even call them out as a coach and I say, look, I’m already asking you these questions because  I wanna come to the point and I’ll say it out loud to them to their face. I just wanna get to the point where the answer to the question I’m asking is, you don’t know.

I’m just waiting  where we have to go so that people will talk about that. And usually, it’s talking about engineering with somebody from product. Hey, Mr. Product, how long do you think your engineering team needs to build this? And then they will say, I don’t know like they know.

And then once they say that, I might ask them, okay, well what do you think, the revenue estimate is once they finish this feature and implement it? Like you’re head of product, you should not revenue estimate. It’s like, what do you mean?  They might have never done that before. They might have only done it in one way. It’s like, figure out what the next product cycle is and then just try to motivate the engineering team so they deliver it. But it gets in the way if that prevents the other arrow from pointing out upwards, which is okay, well we need to have an estimate for how much revenue it’ll provide. cause if you don’t have that, we don’t know what the upper bound of how much cost we can, we can endure building it. 

Kshitij Mohan: Yeah. So I think in this example, you touched everything that we talked about, right? From the psychological safety to visualizing the entire impact, and I think coming to the soft skills.

So I think this really sums up our discussion, Dennis.  This has been really interesting to hear a totally different perspective on building and leading efficient dev teams. So thank you so much for your time today, Denis, lovely having this conversation with you.

Thank you so much.

Denis: Thanks for inviting me. I really enjoyed it. Great questions.