Webinar: 'Unlocking Engineering Productivity' with Paulo André & Denis Čahuk

In the first session of the ‘Unlocking Engineering Productivity’ webinar series, host Kovid Batra from Typo welcomes two prominent engineering leaders: Paulo André, CTO of Resquared, and Denis Čahuk, a technical coach and TDD/DDD expert.

They discuss the importance of engineering productivity and share insights about their journeys. Paulo emphasizes the significance of collaboration in software development and the pitfalls of focusing solely on individual productivity metrics. Denis highlights the value of consistent improvement and reliability over individual velocity. Both guests underline the importance of creating clarity and making work visible within teams to enhance productivity. Audience questions address topics such as balancing technical debt with innovation and integrating new tools without disrupting workflows. Overall, the session offers practical strategies for engineering leaders to build effective and cohesive teams.

Timestamps

  • 00:00 — Introduction
  • 00:52 — Meet the Experts: Paulo and Denis
  • 03:13 — Childhood Stories that Shaped Careers
  • 05:37 — Defining Engineering Productivity
  • 11:18 — Why Focus on Engineering Productivity Now?
  • 15:47 — When and How to Measure Productivity
  • 22:00 — Team vs. Individual Productivity
  • 35:35 — Real-World Examples and Insights
  • 37:17 — Addressing Common Engineering Challenges
  • 38:34 — The Importance of Team Reliability
  • 40:32 — Planning and Execution Strategies
  • 45:31 — Creating Clarity and Competence
  • 53:24 — Audience Q&A: Balancing Technical Debt and Innovation
  • 57:02 — Audience Q&A: Overlooked Metrics and Security
  • 01:02:49 — Audience Q&A: Integrating New Tools and Frameworks
  • 01:08:47 — Final Thoughts and Farewell

Links and Mentions

Transcript

Kovid Batra: All right. Time to get started. Uh, welcome everyone. Welcome to the first episode, first session of our new, all new webinar series, Unlocking Engineering Productivity. So after the success of our previous webinar The Hows and Whats of DORA, we are even more excited to bring you this webinar series which is totally designed to help the engineering leaders become better, learn more and build successful, impactful dev teams. And today with us, uh, we have two passionate engineering leaders. Uh, I have known them for a while now. They have been super helpful, all the time up for helping us out. So let me start with the introduction. Uh, Paulo, Paulo André, uh, CTO of Resquared, a YC-backed startup. He has been the, he has been ex-engineering leadership coach for Hotjar, and he has, he’s an author of the Hagakure newsletter. So welcome to, welcome to the unlocking, uh, engineering productivity webinar, Paulo.

Paulo André: Thanks for having me. It’s a real pleasure to be here.

Kovid Batra: Great. Uh, then we have Denis. Uh, he’s coming to this for the second time. And, uh, Denis is a tech leadership coach, TDD expert, and author of Crafting Tech Teams. And he’s also a guitar player, a professional gamer. Uh, hi, hi, Denis. Welcome, welcome to the episode.

Denis Čahuk: Hi, thanks for inviting me again. Always a pleasure. And Hey, Paulo, it’s our first time meeting on stage.

Paulo André: Good to meet you, Denis.

Kovid Batra: I think I missed mentioning one thing about Paulo. Like, uh, he is like a very, uh, he’s an avid book reader and a coffee lover, just like me. So on that note, Paulo, uh, which book you’re reading these days?

Paulo André: Oh, that’s a good question. Let, let me pull up my, because I’m always reading a bunch of them at the same time, sort of. So right now, I’m very interested, I wonder why in, you know, geopolitical topics. So I’m reading a lot about, you know, superpowers and how this has played out, uh, in history. I’m also reading a fiction book from an author called David Baldacci. It’s this series that I recommend everyone who likes to read thrillers and stuff like that. It’s called the 6:20 Man. So.

Kovid Batra: Great.

Paulo André: That’s what I’m reading right now.

Kovid Batra: So what’s going to be the next superpower then? Is it, is it, is it China, Russia coming in together or it’s the USA?

Paulo André: I’ll tell you offline. I’ll tell you offline.

Kovid Batra: All right. All right. Let’s get started then. Um, I think before actually we move on to the main section, uh, there is one ritual that we have to follow every time so that our audience gets to know you a little more. Uh, this is my favorite question. So I think I’ll, I’ll start with Paulo, you once again. Uh, you have to tell us something from your childhood or from teenage, uh, that defines you, who you are today. So over to you.

Paulo André: I mean, you already talked about the books. I think the reason why I became such a book lover was because there were a ton of books in my house, even though my parents were not readers. So I don’t know, it was more decorative. But I think more importantly for this conversation, I think the one thing about my childhood was when they gifted me a computer when I was six years old. We’re talking about 88, 89 of the type that you still connected to your big TV in the living room. So that changed my life because it came with an instruction manual that had code listings. Then you could type it in and you can see what happens on the screen and the rest is history. So I think that was definitely the most consequential thing that happened in my childhood when you consider how my life and career has played out.

Kovid Batra: Definitely. Cool. Um, Denis, I think the same question to you, man. Uh, what, what has been that childhood teenage memory that has been defining you today?

Denis Čahuk: Oh, you’re putting me on the spot here. I’ll have to come up with a new story every time I join a new webinar. Uh, no, no, I had a similar experience as Paulo. Um, I have an older brother and our household got our first computer when I was five-six years old, first commodore 64. So I learned how to code before I could read. Uh, I knew, I knew what keys to press so I could load Donald Duck into the, into the TV. Um, yeah, other than that when I, when I got a little bit, you know into the teenage years, I, um, World of Warcraft and playing games online became my passion project when I, when I received access to the internet. Um, so that’s, you know, I played World of Warcraft professionally, semi-professionally for quite a few years, like almost an entire decade, you know, and that, that was sort of parallel with my, with my sort of tech career, because we’re usually doing it in a very large organization, game-wise. Yeah. And that, that, that had a huge influence because it gave me an outlet for my competitiveness.

Kovid Batra: That’s interesting. All right, guys. Thanks. Thanks for sharing this with us. Uh, I think we’ll now move on to the main section and discuss something around which our audience would love to learn from you both. Uh, so let’s, let’s start with the first basic fundamental definition of what productivity, what dev productivity or engineering productivity looks like to you. So Paulo, would you like to take this first? Like, how do you define productivity?

Paulo André: So you start with a very small question, right? Um, you actually start with a million-dollar question. What is productivity? I’m happy to take a stab at it, but I think it’s one of those things that everyone has their own definition. For what it’s worth, when I think about productivity of engineering teams, I cannot decouple it from the purpose of an engineering team. And then ultimately, the way I see it is that an engineering team serves a business and serves the users of that business in case it’s a product company, obviously, um, but any, any kind of company kind of has that as the delivery of value, right? So with that in mind, is this team doing their part in the delivery of value, whatever value is for that business and for those users, right? And so having that sort of frame in mind, I also break it down in my mind, at least, in terms of like winning right now and increasing our capacity to win in the future. So a productive team is not just a team that delivers today, but it’s also a team that is getting better and better at delivering tomorrow, right? And so productivity would be, are we doing what it takes to deliver that value regardless of the output? Um, it is necessary to have output to have results and outcomes, but at the end of the day, how are we contributing to the outcomes rather than to the, um, the just purely to the outputs? And the reason why I bring this up has to do obviously with sometimes you see the obsession about things like story points and you know, all of that stuff that ultimately you can be working a lot, but achieving very little or nothing at all. So, yeah, I would never decouple, um, the delivery of value from how well an engineering team is doing.

Kovid Batra: Perfect. I think very well framed here and the perspective makes a lot of sense. Um, by the way, uh, audience, uh, while we are talking, discussing this EP, please feel free to shoot out all the questions that you have in the comments section. We’ll definitely be taking them at the end of the session. Uh, but it would be great if you could just throw in questions right now. Well, this was an advice from Denis, so I wouldn’t want to forget this. Okay. Uh, I think coming back, Denis, what’s your take on, uh, productivity, engineering productivity, dev productivity?

Denis Čahuk: Well, aPauloal said, that’s a million dollar question. I think, I think coming from a, from like a more analytical perspective, more data-driven perspective, I think we like to use the, the financial analogies, metaphors a lot for things like technical debt and, you know, good story points. It’s all about estimating something, you know, value of something or, or scale of something, scope of something. I think just using two metaphors is very useful for productivity. One is, you know, how risky is the team itself? And risk can come from many different places. It can be their methodologies, their personalities, the age of the company, the maturity of the company. The project can be risky. The timing on the market can be risky, right? So, but there is an inherent risk coming from the team itself. That’s, that’s what I mean. So how risky is it to work with this team in particular? Uh, and the other thing is to what degree does the team reason about, um, “I will produce this output for this outcome.” versus “I need to fill my schedule with activity because this input is demanded of me.” Right? So if I, if I use the four pillars that you probably know from business model canvases for activity, input, output, outcome, um, a productive team would not be measuring productivity per se. They will be more aligned with their business, aligned with their product and focusing on what, which of their outputs can provide what kind of outcomes for the business, right? So it’s not so much about measuring it or discussing it. It’s more about a, you know, are we shifting our mentality far enough into the things that matter, or are we chasing our own tail, essentially, um, protecting our calendars and making sure we didn’t over-promise or under-promise, etc.?

Kovid Batra: Got it. Makes sense.

Paulo André: Can I just add one, one last thing here, because Denis got my, my brain kinda going? Um, just to make the point that I think the industry spends a lot of time thinking about what is productivity and trying to define productivity. I think there is value in really getting clear about what productivity is not. And so I think what both Denis and I are definitely aligned on among other things is that it’s not output. That’s not what productivity is in isolation. So output is necessary, but it is not sufficient. And unfortunately, a lot of these conversations end up being purely about output because it’s easy to measure and because it’s easy to measure, that’s where we stop. And so we need to do the homework and measure what’s hard as well, so we can get to the real insight.

Kovid Batra: No, totally makes sense. I think I relate to this because when I talk to so many engineering leaders and almost all the time this, this comes into discussion, like how exactly they should be doing it. But what, what is becoming more interesting for me is that this million dollar question has suddenly started raising concerns, right? I mean, almost everywhere in like in business, uh, people are measuring productivity in some or the other way, right? But somehow engineering teams have suddenly come into the focus. So this, this perspective of bringing more focus now, why do you think it has come into the picture now?

Paulo André: Is that for me or Denis? Who should go first?

Kovid Batra: Anyone. Maybe Paulo, you can go ahead. No problem.

Paulo André: Okay. So, look. In, in my opinion, I think I was thinking a little bit about this. I think it’s a good question. And I think there’s at least three things, three main things that are kind of conspiring for this renewed focus or double down on engineering productivity specifically. I think on the one hand, it’s what I already mentioned, right? It’s easier to measure engineering than anything else. Um, at least in the product design and engineering world, of course, sales are very easy to measure. Did you close or not? And that sort of thing. But when it comes to product design and engineering, engineering, especially if you focus on outputs is so much easier to measure. And then someone gets a good sense of ROI from that, which may or may not be accurate. But I think that’s one of the things. The other thing is that when times get more lean or things get more difficult and funding kind of dries up, um, then, of course, you need to tighten the belt and where are you going to tighten the belt? And at the end of the day, I always say this to my teams, like, engineering is not more special in any way than any other team in a company. That being said, when it comes to a software company, the engineering team is where the rubber meets the road. In other words, you do absolutely need some degree of engineering team or engineering capacity to translate ideas and designs and so on into actual software. So it’s very easy to kind of just look at it as in, “Oh, engineers are absolutely critical. Everything else, maybe are nice to have.” Or something of that, to that effect, right? And then lastly, I think the so-called Elon Musk effect definitely is a thing. I mean, when someone with that prominence and with, you know, the soapbox that he has, comes in and says, you know, we’re going to focus on engineers and it’s about builders and even Mark Andreessen wrote an article like three years ago or so saying it’s time to build, all of that speaks like engineering, engineering, engineering. Um, and so when you put that all together and how influencible all of us are, but I think especially then founders and CEOs are kind of really attuned to their industry and to investors and so on, and I think there’s this, um, feedback loop where engineering is where it’s at right now, especially the age of AI and so on. So yeah, i’m not surprised that when you put this all together in this day and age, we have what we have in terms of engineering being like the holy grail and the focus.

Kovid Batra: Uh, Denis, you, you have something to add on this?

Denis Čahuk: I mean, when it comes to the timing, I don’t think anything comes to mind, you know, why now? What I can definitely say is that engineering of everything that’s going on is the biggest cost in a, in a large company. I mean, it’s not, not to say that it’s all about salaries or operational expenses, but it is also from a business’s perspective, engineering is, you know, if I put a price to the business being wrong on an experiment, the engineering side of things, the product engineering side of things defines most of that cost, right? So when it comes to experiments, the likelihood of it succeeding or not succeeding, or the how fast you gain feedback to be able to, you know, to, to think of experiment feedback as cashflow, you know, you want the big bet that you do once every three months, or do you want to do a bunch of small bets continuously several times per day? You know, all of that is decided and all of that happens in engineering and it also happens to be the biggest fiscal costs. So it makes sense that, hey, there’s an, you know, there’s a big thing that costs a lot, that is very complex and it’s defining the company. Yeah, of course, business owners would want to measure it. It will be irresponsible not to. It doesn’t mean that it, that productivity from a team’s or an engineer’s, an individual’s perspective is the most sensible thing to measure. But I, you know, I understand the people that would intuitively come to that conclusion.

Kovid Batra: Yeah. I think that makes a lot of sense. And what do you think, like, this should be done that, that is totally, uh, understandable, but when is the right time to start doing this and how one should start it? Because every time our engineering leader is held accountable for a team, whether big or small, there is a point where you have to decide your priorities and think about things that you are going to do, right? So how and when should an engineering leader or an engineering manager for a team should start taking up this journey?

Paulo André: I think Denis can go first on this one.

Denis Čahuk: Well, I would never, you know, I would never start measuring. So I coach teams professionally, you know, they, they reach out to me because something about my communication on LinkedIn or newsletter resonated with them regarding, you know, a very no-nonsense way of how to deal with customers, how to communicate, how to plan, how to not plan, how to, how to bring, you know, that excitement into engineering, that makes engineering very hyperproductive and fun. And then they come to me and ask, well, you know, “I want to measure all these things to see what I can do.” I think that context is always misleading. You know, we don’t just go in, you know, it’s not a speedometer like the, I think the very, very first intuition that people still have from the 90s, from the, from the, like the initial scrum and Kanban, um, modes of thought that, “Oh, I can just put up speedometer on the team and it will have a velocity and it, you know, it will just be a number.” Um, I think that is naive. That is not what measuring is. And that is not the right time ever to measure that. Like that I think is my say. Um, the right time to measure is when you say, “I am improving A or B. I am consciously trying to figure out continuously, consciously trying to figure out what will make my teams better.” So a leader might approach, “Okay. If I introduce this initiative, how can I tell if things are better?” And then you can say, “Well, I’ll eyeball it or I’ll survey the team.” And at a certain point, the eyeballing is too inaccurate or it requires too many disagreeing eyeballs, or, um, you run the risk of a survey fatiguing the team, so it’s just way too many surveys asking boring questions, and when you ask engineers to do repetitive, boring things, they will start giving you nonsense answers, right? So that would be the point where I think measuring makes sense, right? Where you basically take a little bit of subjective opinion out, with the exception of surveys, qualitative surveys, and you introduce a machine that says, “Hey, this is a process.” You know, it’s one computer talking to the other computer, you know, in the case of GitHub and similar, which seems to be the primary vector for measurement. Um, can I just extract some metrics of, you know, what are the characteristics of the machine? It doesn’t tell you how fast or how slow it’s going. Just what are the characteristics? Maybe I can get some insights too and decide whether this was a good idea or a bad idea, or if we’re missing something. But the decision to help your teams improve on some initiative and introducing the initiative comes first. And then you measure if you have no other alternative or if the alternatives are way too fuzzy.

Kovid Batra: Makes sense. Paulo, would you like to add something?

Paulo André: Yeah, I mean, I think my, my perspective on this is not very different from, from Denis. Uh, maybe it comes from a slightly different angle and I’ll explain what I mean. So, at the end of the day, if you want to create an outcome, right? And you want to change customer behavior, you want to create results for the business, you’re going to have to build something. And where I would not start is with the metrics, right? So you asked Kovid, like where, where do we start in this journey? I would say do not start with the metrics because in my mind, the metrics are a source of insight or answers to a set of questions. And so start with the questions, right? Start with the challenges that we, that you have to get to where you want to be, right? And so, coming back to what I was saying, if you want to create value, you’re going to have to build something, typically, most of the time, sometimes it creates value by removing something, but in general, you are building and iterating on your products. And, and so with that in mind, what is going back to first principles? What is the nature of software development? Well, it’s a collaborative effort. Nobody does everything end-to-end by themselves. And so with that in mind, there’s going to be handoffs. There’s going to be collaboration. There’s going to be all, all of that sort of flow, right? Where, where the work goes through a certain, you can see it as a pipeline. And so then when it comes to productivity, to me is, is, you know, from a lean software development perspective is how do we increase the flow? If you think of a Kanban board, how do you go, you know, in a smooth way, as smooth as possible from left to right, from something being ready for development to being shipped in production and creating value for the user and for the company? And so if you see it that way with that mental model, then it becomes like, where is the constraint? What is the bottleneck? And then how do we measure that? How do we get the answers is by measuring. And so when it comes to the DORA metrics that you guys obviously with Typo provide, um, you know, a good, good insight into, and, and other such things, generally cycle time, lead time really allows us to start understanding where’s this getting stuck. And that leads to then conversations around what can we do about that? And ultimately everybody can rally around the idea of how do we increase flow? And so that’s where I would start is what are we trying to do? What is getting in our way? And then let’s look at the data that we have available without going too crazy about that into like, what can we learn and where can we improve and where’s the biggest leverage?

Kovid Batra: Makes sense. I think one, one good point that you brought here is that software development is a collaborative effort, right? And every time when we go about doing that, there are people, there are teams, uh, there are processes, right? Uh, how, how would you define in a situation that whether you should go about measuring, uh, at an individual-level productivity, a developer-level productivity, and, uh, and then when, when we are talking about this collaborative effort, the engineering productivity? So how do you differentiate and how do you make sure that you are measuring things right? And sometimes the terminologies also bring in a lot of confusion. Uh, like, I would never perceive developer productivity to be something, uh, specific to developers. It ultimately boils down to the team. So I would want to hear both of you on this point, like how, how do you differentiate or what’s your perspective on that? When you talk to your team that, okay, this is what we are going to measure, uh, your teams are not taken aback by that, and there is a smooth transition of thought, goals when we are talking about improving the productivity. Uh, Paulo, maybe you could answer that.

Paulo André: I was trying to unmute myself. I was actually gonna.. Um, and then it feels free to kind of like interject at any point with your thinking as well. You know, if I follow up on what I was just saying that this is a team sport, then the unit of value is going to be the team. Are there individual productivity metrics? Yes. Are they insightful? Yes, they can be. But for what end? What can you actually infer from them? What can you learn from them? Personally, as an engineering leader, the way I look at individual productivity metrics is more like a smoke alarm. So, for example, if someone is not pushing code for long periods of time, that’s a question. Like, what’s going on? There might be some very good reasons for that, or maybe this person is struggling and so I’m glad that I saw that in the, in the metrics, right? And then we can have a conversation around it. Again, the individual is necessary, but it’s not sufficient to deliver value. And so I need to focus on the team-level productivity metrics, right? Um, so that’s, that’s kind of like how I disambiguate, if you will, this, these two, like the individual and the team, the team comes first. I look at the individual to understand to what degree is the individual or the individuals serving the team, because it comes back to also questions, obviously, of performance and, and performance reviews and compensation and promotions, like all of that stuff, right? Um, but do I look at the metrics to decide on that? Personally, I don’t. What I do look at is what can I see in the metrics in terms of what this person’s contribution to the team is and for the team to be able to be successful and productive.

Kovid Batra: Got it. Denis, uh, you have something to add here?

Denis Čahuk: It’s, it’s such an interesting topic that sort of has nuances from many different perspectives that my brain just wants to talk about all three at the same time. So I want to sort of approach every, like, do a quick dip into all three areas. First is the business side, right? So, uh, for example, let’s take a, let’s take the examples of baseball and soccer. Um, off, when off season comes for baseball. Baseball is more of an individual sport than soccer, you know, like the individual performance stands out way more than in soccer when everything’s moving all the time. Um, it’s, it’s very difficult to individuate performance in soccer, although you still can and people still do and it’s still very sexy. Um, when it’s off season, people want to decide, okay, which players do we keep? Which players do we trade? Which players do we replace? You know, this is completely normal, and you would want to do this, and you would want to have some kind of metrics, ideally, merit-based metrics of, yeah, this person performed better. Having this person on the team makes the team better. In baseball, this makes perfect sense. In soccer, not so much, but you still have to decide, well, how much do we pay each player? And you can probably tell if you’re following the scene that every soccer player is being, you know, their salary, their, their, um, their contracts are priced individually based on their value to the brand of the team, all the way to public relations, marketing, and yes, performance on, on the field. Even if they’re on the bench all the time, you know, they might have a positive effect on the team as a coach or as a mentor, as a captain. Um, so if you did bring that into that, that’s one aspect. So now bringing it back into software teams, that’s the business side of things. Yes, these decisions have to be made.

Then there’s the other side of things, which is how does the team work? You know, from my perspective, if output or outcomes can be traced back to one individual person, I think there’s something wrong. I think there’s a lot of sort of value left on the table if you can say, “Oh, this thing was done by this one person.” Generally, it’s a team effort and the more complex the problems get, the harder it is, you know, look, look, for example, NASA, um, the Apollo missions. Which one engineer, you know, made the rocket fly? You don’t have an answer to that because it was thousands of people collaborating together. You know, which one person made a movie? Yes, the director or the producer or the main actor, like they are, they stand out when it comes to branding. But there were tens of thousands of people involved, right? So like to, you know, at the end of the day, what matters is the box office. So I think that that’s what it really comes down to, uh, is that yes, generally there will be like a few stars and some smoke alarms, as Paulo mentioned, I really liked that analogy, right? So you’re sort of checking for, hey, is anybody below standard and does anybody sort of stand out? Usually in branding and communication, not in technical skill. Um, and then try to reason about the team as a whole.

And then there’s the third aspect, which is how productive does the individual feel? You know, how productive, if somebody says they’re a senior with seven years of experience, how productive they, do they feel? Do they get to do everything they wanted to in a day? You know, and then keep going up. Does the product owner feel productive or efficient? Or does the leader feel that they’re supporting their teams enough, right? So it also comes down to perception. We saw this recently with the usages and various surveys regarding AI usage and coding assistance, where developers say, “Yeah, it makes me feel amazing because I feel more productive.” But in reality, the outcomes that it produces didn’t change, or it was so insignificant that it was very difficult to measure.

So with those three sort of three angles to consider, I would say, you know, the way to approach measuring and particularly this individual versus team performance, is that it’s a moving target. You sort of need to have a plan for why you’re measuring and what you’re measuring and ideally, once you know that you’re measuring the right things when it comes to the business, it’ll be very difficult, um, to trace it back to an individual. If tracing it back to an individual is very easy, or if that’s an outcome that you’re pursuing, I would say there’s other issues or potential improvements afoot. And again, measuring those might show you that measuring them is a wrong, is a bad idea.

Paulo André: Can I just add one, one quick thing again? Like, this is something that took me a little while to understand for myself and to become intuitive, which is not intuitive at all. Um, but I think it’s an important pitfall to kind of highlight, which is if we incentivize individual behaviors, individual productivity, that can really backfire on the team. And again, I remind you that the team is the unit of value. And so if we incentivize throughput or output from individual developers, how does that hurt the team? It doesn’t sound very intuitive, but if you think about, for example, a very prolific developer that is constantly just taking on more tickets and creating more pull requests, and those pull requests are just piling up because there’s no capacity in the team to review them, the customer is not getting any value on the other side. That work in progress is just in lean terminology. It’s just waste at that point, right? But that developer can be regarded depending on how you look at it as a very productive developer, but is it? Or could it be that that developer could be testing something? Or could it be that that developer is helping doing code reviews and so on and so forth, right? So again, the team and individual productivity can lead to wildly different results. And sometimes you have teams that are very unproductive despite having very productive developers in them, but they are looking at the wrong, sort of, in my opinion, wrong definition of what productivity is and where it comes from, and what the unit of value is, like I said, it’s the team.

Kovid Batra: Yeah.

Denis Čahuk: Can I jump in quickly, Kovid?

Kovid Batra: Yeah.

Denis Čahuk: There’s something I’ve always said. Um, it’s very unintuitive, and I can give you a complete example from coaching, that it throws leaders off-guard every time I suggest it, and it ends up being a very positive outcome. I always ask them, you know, “What are you using to assign tickets? Are you assigning them?” And they say, “Yes, we use Jira.” Or something equivalent. And I tell them, And I ask them, “Well, have you considered not assigning the tickets?” Right? And, well, who should own it? And I say, “Well, it’s in the team’s backlog. The team owns it. Stop assigning an individual.” Right? And they’re like, and they’re usually taken aback. It’s like, “What do you mean? Like, it won’t get done if I don’t assign it.” No, it’s in the team’s backlog, of course it’ll get done. Right? And if not, if they can’t decide who will do it, then that’s a conversation they should have, and then keep it unassigned. Or, alternatively, use some kind of software that allows multiple people to be assigned. But you don’t need to, because the moment you start, you know, Jira, for example, had like a full activity log, so I comment on it, you comment on it, you review, I review, we merge, I merge, I ask a question. You have a full paper trail of everybody who was involved. Why would you need an owner, right? So this idea of an owner is, again, going back to lean activities and talking about handoffs, right? So I hand it off to you, you’re now the owner, and you’ll hand it off to somebody else. Well, and, but having many handoffs is an anti-pattern in itself, usually in most contexts. Actually the better idea would be, how can we have less people than we have? How can we have less handoffs then we have people? If there are seven people in the pipeline, there shouldn’t be seven handoffs, you know, how can we have just one deliverable, just one thing to assign and seven people working on it? That would be the best sort of positive outcome because then you don’t cap, you know, how much money you can put around a problem because that allows you to sort of scale your efforts in intensity, not just in parallelism. Um, and usually that parallelism comes at a very, very steep cost.

Paulo André: Yeah.

Denis Čahuk: Um, so incentivizing methods to make individual work activity untraceable can unintuitively have, and usually does, drastic and immediate positive, positive benefits for the team. Also, if the team is lacking in psychological safety, this will make it immediately sort of washed over them and they’ll have to have some like really rough conversations in the first week and then things drastically start improving. At least that’s my experience.

Paulo André: Yeah. And the handoff piece is a very interesting one. I’ll be very quick, uh, Kovid. When we think about the perspective of a piece of work, a work package, a ticket or whatever, it’s either being actively worked on or it’s waiting for someone to do something about it, right? And if we measure these things, what we, what we realize, and it’s the same thing if you go to the airport and we think about how often, how much time are we actually spending on something like checking in or boarding the plane versus waiting at some of the stages, the waiting time is typically way more than the active time. And so that waiting time is waste as well. That’s an opportunity. Those delays, we can think about how can we reduce those and the more handoffs we have in the process, the more opportunity for delay creeps in, right? So it’s, it’s a very different way of looking at things. But sometimes when I say estimates and so on, estimates is all about like active time. It’s how long it’s going to take, but we don’t realize that nothing is done individually, and because of the handoffs, you cannot possibly predict the waiting times. So the best that you can do is to reduce the handoffs, so you have less opportunity for those delays to creep in.

Kovid Batra: Totally. I think to summarize both of your points, I would have understood is that making those smoke alarms ready at individual level and at process level also ready so that you are able to understand those gaps if there is something falling apart. But at the end of the day, if you’re measuring productivity for a team, it has to be a collaborative team-level thing that you’re looking at and looking at value delivery. So I think it’s a very interesting thing. Uh, I think there’s a lot of learning for us when we are working at Typo that we need to think more on the angle of how we bring in those pointers, those metrics which work as those smoke alarms, rather than just looking at individual efficiency or productivity and defining that for somebody. Uh, I think that, that makes a lot of sense. All right. I think we are into a very interesting conversation and I would like to ask one of you to tell us something from your experience. So let’s start with you, Denis. Um, like you have been coaching a lot of teams, right? And, uh, there, there are instances where you deal with large-scale teams, small teams, startups, right? There are different combinations. Anything that you feel is an interesting experience to share here about how a team approached solving a particular problem or a bottleneck in their team that was slowing them down, basically like not having the right impact that they wanted to, and what did they do about it? And then how, how they arrived to the goal that they were looking at?

Denis Čahuk: Well, I can, I can list many. I’ll, I’ll focus on two. One is, generally the team knows what’s the problem. Generally, the team knows already, hey, yeah, we don’t have enough tests, or, ah, yeah, we keep missing deadlines, or our relationship with stakeholders is very bad, and they just communicate with us through, you know, strict roadmaps and strict deadlines and strict expectations. Um, that’s a problem to be solved. That’s not, you know, it doesn’t have to be that way. So if you know what the problem is, there’s no point measuring, because there’s no, there’s no further insight to be gained that, yeah, this is a problem, but hey, let’s get distracted with this insight. No, like, you know what the problem is, you can just decide what to do, and then if you need help along the way, maybe measurements would help. Or maybe measurements on an organizational level would help, not, not just engineering. Um, or you bring on a coach to sort of help you, you know, gain clarity. That’s one aspect. If you know what the problem is, you don’t need to measure. Usually people ask me, Denis, what should I measure? Should I introduce DORA metrics? And I usually tell them, Oh, what’s the main problem? What’s the problem this week? Oh yeah, a lot of PRs are waiting around and we’re not writing enough tests. Okay, that’s actionable. Like, that’s enough. Like, do you want more? Like, but do you need a bigger problem? Because then you just, you know, spend a lot of time looking for a problem that you wish was bigger than that so that you wouldn’t have to, right, because that’s just resistance that just either your ego or trying to play it safe or trying to put it into the next quarter when maybe there’s less stress and right, there isn’t. That’s one aspect.

The other aspect, you know, this idea of.. How did you phrase it? An approach that works that aren’t generally approaches that work. You know, I always say that everything we do is nowadays basically a proxy to eliminating handoffs, right? Getting the engineers very close to the customer and, um, you know, getting closer to continuous delivery. Continuous integration at the very minimum, but continuous delivery, right? So that when software is ready, it’s releasable on demand, and there isn’t like this long waiting that Paolo mentioned earlier, right? Like this is just a general form of waste. Um, but potentially something that both of these cases handle unintuitively that I like to bring in as a sort of more qualitative metric is, um, the reliability of the team. You know, we like to measure the reliability of systems and the whole Scrum movement introduced this idea of velocity, and I like to bring in this idea of, let’s say you want to be on time as a leader. Um, I’m interested in proving the theory that, hey, if you want to be on time, you probably need to be on time every week, and in order to be on time on the week, you probably need to be on time every day. So if you don’t know what an on-time day looks like, there’s no point planning roadmaps and saying that deadlines are a primary focus. Maybe the team should be planning in smaller batches, not with, not trying to chase higher accuracy in something very large. And what I usually use as a proxy metric is just to say, how risky is your word? Right, so how reliable is your promise? Uh, and we don’t measure how fast the team is moving. What I like to measure with them is say, okay, when do you think this will be done? They say Friday. Okay. If you’re right, Monday needs to look like this. Tuesday needs to look like this. Let me just try to reverse engineer it from that. It’s very basic. And then I’m trying to figure out how many days or hours or minutes into a plan they’re off-track. I don’t care about velocity. So no proxy metrics. I’m just interested if they create like a three month roadmap, how many hours into the three-month roadmap are they off-course? Because that’s what I’m interested in, because that’s actionable. Okay. You said three months from now, this is done. One month from now, there’ll be a milestone. But yesterday you said that today something would be done. It’s not done. Maybe we should work on that. Maybe we should really get down to a much smaller batch size and just try to make the communication structures around the team building stuff more reliable. That would de-stress a lot of people at the same time and sort of reduce anxiety. And maybe the problem is that you have a building-to-deploying nuance and maybe that’s also part of the problem. It usually is. And then there might be a planning-to-building nuance that also needs to be addressed. And then we basically come down to this idea of continuous delivery extreme programming, you know, let’s plan a little bit. Let’s Build a little bit. Let’s test it. Let’s test our assumptions. And behind the scenes once we do that for a few days, once we have evidence that we’re reliable, then let’s plan the next two weeks. Only when we have shown evidence of the team understands what a reliable work week for them looks like. If they’ve never experienced that and they’ve been chasing their own tail deadline after deadline, um, there’s not much you can do with such a team. And a lot of people just need a wake up call to see that, “Hey, you know what? I actually don’t know how to plan. You know, I don’t know how to estimate.” And that’s okay. As long as you have this intention of trying to improve or trying to look for alternatives, not to become better.

Kovid Batra: I think my next question would be, uh, like when you’re talking about, uh, this aspect in the teams, how do you exactly go about having that conversations or having that, that visibility on a day-to-day basis? Like most, most of the things that you mentioned were qualitative in nature, right, as, as you mentioned, right? So how, how do you exactly go about doing that? Like if someone wants to understand and deploy the same thought-process in a team, how should they actually do and measure it?

Denis Čahuk: Well, from a leader’s perspective, it’s very simple, you know, because I can just ask them, “Hey, is it done? Is it on anybody’s mind today?” Um, and they might tell me, “Yeah, it’s done, but not merged.” Or, “It’s waiting for review, but it’s done, but it’s kind of waiting for review.” And then that might be one possible answer. Um, it doesn’t need to be qualitative in the sense that I need a human for that. What, you know, what I’m looking for is precision. Like, is it, is it definitively done? Was there an increment? You know, did we test our assumptions? What, is there a releasable artifact? Is it possible to gain feedback on this?

Kovid Batra: Got it.

Denis Čahuk: Did you, did you talk to the team to establish if we deploy this as soon as possible, what question do we want to answer? Like what feedback, what kind of product feedback are we looking for? Or are we just blindly going through a list of features? Like, are we making improvements to our software or is somebody else who is not an engineer? Maybe that’s the problem, right? So it’s very difficult to pinpoint to like one generic thing. But a team that I worked with, the best proxy for these kinds of improvements from the leader was how ready they felt to be interrupted and get course correction. Right? Because the main thing with priorities in a team is that, you know, the main unintuitive thing is that you need to make bets and you need to reduce the cost of you being wrong, right? So the business is making bets on the market, on the product and working with this particular team with these particular individuals. The team is making bets with implementation details to a choice of technology, ratio between keeping the lights on, technical debt and new features, support and communication styles, you know, change of technology maybe. Um, so you need to just make sure that you’re playing with the market. The upside will take care of itself. You just need to make sure that you’re not making stupid mistakes that cost you a lot, either in opportunity or actual fiscal value. Um, but once you got that out of the way, you know, sky’s the limit. A lot of engineers think that we’re expensive. It’s large projects. We gotta get it right the first time. So they try to measure how often they got it right the first time, which is silly. And usually that’s where most measurements go. Are we getting it right the first time? We need to do this to get it right the first time, right? So failure is not an option. Whereas my mantra would be, no, you are going to fail. Just make sure it happens sooner rather than later and with as little intensity as possible so that we can act on it while there’s still time.

Kovid Batra: Got it. Makes sense. Makes sense. All right. Uh, Paulo, I think, uh, we are just running short on time, but I really want to ask this question to you as well, uh, just like Denis has shared something from his experience and that’s really interesting to know like how qualitatively you can measure or see things every time and solve for those. In your experience, um, you have, uh, recently joined this startup as, as a CTO, right? So maybe how does it feel like a new CTO and what things come to your mind when you would think of improving productivity in your teams and building a team which is impactful?

Paulo André: Yeah, I joined this company as a CTO six months ago. It’s been quite a journey and it’s, so it’s very fresh in my mind. And of course, every team is different and every starting point is different and so on, but ultimately, I think the pattern that i’ve always seen in my career is that some things are just not connected and the work is not visible and there’s lack of clarity about what’s value, uh, about what are the goals, what are the priorities, how do we make decisions, like all of that stuff, right? And so, every hour that I’ve been putting into this role with my team so far in these six months has been really either, either about creating clarity or about developing competence to the extent that I can. And so the development of competence is, is basically every opportunity is an opportunity to learn, both for myself and for anyone else in the team. And I can try to leverage my coaching skills, um, in making those learning conversations effective. And then the creation of clarity in my role, I happen to lead both product and engineering, so I cannot blame somebody else for lack of clarity on what the product should be or where it should go. It’s, it’s on me. And I’ve been working with some really good people in terms of what is our product strategy? What do we focus on and not focus on? Why this and not that? What are we trying to accomplish? What are those outcomes that we were talking about that we want to drive, right? So all of that is hard to answer. It’s deceptively difficult to answer. But at the end of the day, it’s what’s most important for that engineering productivity piece, because if you have an engineering team that is, you know, doing wasted work left and right, or things are not connected, and they’re just like, not clear about what they should be doing in the first place, that doesn’t sound like the ingredients for a productive team, right? And ultimately, the product side needs to answer to a large extent those, those difficult questions. So obviously, I could go into a lot of specific details about how we’re doing this and that. I don’t think we have at least today the time for that. Maybe we can do a deep dive later. But ultimately, it’s all about how do I create clarity for everyone and for myself in the first place so I can give it and then also developing the competence of the people that we do have. And that’s the increasing the capacity to win that I was talking about earlier. And if we make good progress on these two things, then we can give a lot of control and autonomy to people because they understand what we’re going for, and they have the skills to actually deliver on that, right? That’s, that’s the holy grail. And that’s motivation, right? That’s happiness. That’s a moment at work that is so elusive. But at the end of the day, I think that’s what we’re, we’re working towards.

Kovid Batra: Totally. I’ll still, uh, want to deep dive a little bit in any one of those, uh, instances, like if you have something to share from last six months where you actually, when prioritized this transparency for the team to be in, uh, how exactly you executed it, a small instance or a small maybe a meeting that you have had and..

Paulo André: Very simple example. Very simple example. Um, one of the things that I immediately noticed in the team is that a lot of the work that was happening was just not visible. It was not on a ticket. It was not on a notion document. It was nowhere, right? Because knowledge was in people’s minds, and so there was a lot of like, gaps of understanding and things that would just take a lot longer than they think they should. And so I already mentioned my bias towards lean software development. What does that mean? First and foremost, make the work visible because if you don’t make the work visible, you have no chance of optimizing the process and getting better at what you do. So I’ve been hammering this idea of making the work visible. I think my team is sick of me pointing to is there a ticket for it? Did you create a ticket for it? Where is the ticket? And so on. Because the way we work with Jira, that’s, that’s where the work becomes visible. And I think now we got to a point where this just became second nature, uh, for all of us. So that would be one example where it’s like very basic fundamental thing. Don’t need to measure anything. Don’t need complicated KPIs and whatnot. What we do need is to make the work visible so we can reason about it together. That’s it.

Kovid Batra: Makes sense. And anything which you found very unique about this team and you took a unique approach to solve it? Any, anything of that sort?

Paulo André: Unique? Oh, that’s a, that’s a really good question. I mean, everyone is different, but at the end of the day, we’re all human beings trying to work together towards something that is somehow meaningful. And so from that perspective, frankly, no real surprises. I think what I’m, if anything, I’m really grateful for the team to be so driven to do better, even if, you know, we lack the experience in many areas that we need to level up. Um, but as far as something being really unique, I think maybe a challenge our team has to really deal with tough technical challenges is around email deliverability, for example, that’s not necessarily unique. Of course, there’s other companies that need to debate themselves with the exact same problems. But in my career, that’s not a particular topic that I have to deal with a lot. And I’m seeing, like, just how complex and how tricky it is to get to get right. Um, and it’s an always evolving sort of landscape for those that are familiar with that type of stuff. So, yeah, not a good, not a good answer to your question. There’s nothing unique. It’s just that, yeah, what’s unique is the team. The team is unique. There’s no other team like this one, like these individuals doing this thing right here, right now in this company in 2024.

Kovid Batra: Great, man. I think your team is gonna love you for that. All right. I think there will be a lot more questions from the audience now. We’ll dedicate some time to that. We’ll take a minute’s break here and we’ll just gather all the questions that the audience has put in. Uh, though we are running a little out of time, is it okay for you guys to like extend for 5–10 minutes? Perfect. All right. Uh, so we’ll take a break for a minute and, uh, just gather the questions here.

All right. I think time to get started with the questions. Uh, I see a lot of them. Uh, let’s take them one by one on the screen and start answering those. Okay. So the first one is coming from, uh, Kshitij Mohan. That’s, uh, the CEO of Typo. Hi, Kshitij. Uh, everything is going good here. Uh, so this is for Denis. Uh, as someone working at the intersection of engineering and cloud technologies, how do you prioritize between technical debt and innovation?

Denis Čahuk: It’s a great question. Hey, Kshitij. Well, I think first of all, I need to know whether it’s actual debt or whether it’s just crap code. You know, like it’s crappy implementation is not an excuse for debt, right? So for you to have debt, there are three things needed to have happen. At some point in the past, you had two choices, A or B. And you made a choice without, with insufficient knowledge. And later on, you figured out that either something in the market changed or timing changed, or we gained more knowledge, and we realized that we, that now the other one is better, for whatever reason. I mean, it’s unnecessary that it was wrong at the time, but we now have more information that we need to go from A to B. Uh, originally we picked A. Now you also need to know how much it costs to go from A to B and how much you stand to gain or trade if you decide not to do that, right? So maybe going from A to B now cost you two months and ten thousand euros and doing it later next year, maybe it’s going to double the cost and add an extra week. That’s technical debt. Like the, the nature of that decision, that’s technical debt. If you, if you made the wrong decision in, in the past and you know it was the wrong decision and now you’re trying to explore whether you want to do something about it, that’s not technical debt. That’s just, you know, that’s you seeking for excuses to not do a rewrite. So it’s, first of all you need to identify is it debt. If it is debt, you know the cost, you know the trade-off, you know, you know, you can either put it on a timeline or you can measure some kind of business outcome with it. So that’s one side.

On the, on the innovation side, you need to decide what is innovation exactly? You know, is it like an investment? Is it a capital expense where I am building a laboratory and we’re going to innovate with new technologies? And then once we build them, we will find, um, sort of private market applications for them or B2B applications for them. Like, is it that kind of innovation? Or is innovation a umbrella term for new features, right? Cause, cause that’s operational. That’s much closer to operational expense, operational expense, right? So it’s just something you do continuously and you deliver continuously, and that innovation that you do can continuously feature development will also produce new debt. So once you’ve got these two things, these two sides figured out, then it’s a very simple decision. How much debt can you live with? How fast are you creating new debt compared to how fast you’re paying it off? And what can you do to get rid of all the non-debt, all the crap, essentially? That’s it, you know. Then you just make sure that you balance out those activities and that you consistently do them. It isn’t just, oh yeah. We do innovation for nine months and then we pay off debt. That usually doesn’t go very well.

Kovid Batra: I think this is coming from a very personal pain point. Now we’re really moving towards the AI wave and building things at Typo. That’s where Kshitij is coming from. Uh, totally. I think, thanks, thanks, Denis. I think we’ll move on to the next question now. Uh, that’s from, uh, Madhurima. Yeah. Hey Paulo, this one’s for you. Uh, which metric do you think is often overlooked in engineering teams but has significant impact on long-term success?

Paulo André: Yeah, that’s a great question. I’m going to, I’m going to give a bit of a cheeky answer and I’m going to say, disclaimer, this is not a metric that I track with, we track with, with my team, and it’s also not, I don’t know, a very scientific way or concrete way of measuring it. However, to the question, what is overlooked in engineering teams and has significant long-term impact, or success, on long-term success, that’s what I would call ‘mean time to clarity’. How quickly do we get clear on where we need to be and how do we get there? Right? And we don’t have all the answers upfront. We need to, as Denis mentioned earlier, experiment and iterate and learn and we’ll get smarter, hopefully, as we go along, as we learn. But how quickly we get to that clarity in every which way that we’re working. I think that’s, that’s the one that is most important because it has implications, right? Um, if we don’t look at that and if we don’t care about that, are we doing what it takes to create that clarity in the first place? And if that’s not the case, the waste is going to be abundant, right? So that’s the one I would say as an engineering leader, how do I get for myself all the clarity that I need to be able to pass it along to others and create that sense that we know where we’re going and what we don’t know, we have the means to learn and to keep getting smarter.

Kovid Batra: Cool. Great answer there. Uh, let’s move on to the next one. I think this one is again for Paulo. Yeah.

Paulo André: Okay, so you know what? Maybe this is going to be a bit, uh, I don’t know what to call it, but considering that I don’t think the most important things are gonna change in the next five years, um, AI notwithstanding, and what are the most important things? It’s still a bunch of people working together and depending on each other to achieve common goals. We may have less people with more artificial intelligence, but I don’t think we’re anywhere near the point where the artificial intelligence just does everything, including the thinking for itself. And so with that in mind, it’s still back to what I said earlier, um, in the session. It’s really about how is the work flowing from left to right? And I don’t know of a better, um, sort of set of metrics than the DORA metrics for this, particularly cycle time and deployment frequency and that sort of stuff that is more about the actual flow. Um, but like, you know, let’s not get into the DORA metrics. I’m sure the audience here already knows a lot about it, but that’s, that’s, I think, what, what is the most important, um, and will continue to be critical in the next five years, um, that’s, that’s basically it.

Kovid Batra: Cool. Moving on. All right. That’s again for, oh, this one, Denis. How do you ensure cloud solutions remain secure and scalable while addressing ever-changing customer demands?

Denis Čahuk: Well, there’s two parts to that question. You know, one is security, the other one is ever-changing customer demands. I think, you know, security will be a sort of an expression of the standard, or at least some degree of sensible defaults within the team. So the better question would be, what do engineers need to not have to consciously, to not have to constantly and consciously and deliberately think about security, right? So do they have support by, are they supported by a security expert? Do they have platform engineering teams that are supporting with security initiatives, right? So if there’s a product team that’s focusing on product, support them so that they also don’t have to become an expert in security, cause that’s where all the problems start, where you basically have a team of five and they need to wear 20 hats and they start triaging the hats and making trade-offs in security, you know. And usually, usually large teams that are overwhelmed, love doing privacy or security trade-offs because they don’t have skin in the game. The business has skin in the game, right? And then when you individuate incentive to such a degree that it becomes dysfunctional, um, security usually doesn’t bode well. Um, at least not till there’s some incident or maybe some security review or some inspection, et cetera.

So give the teams what they need. If they’re not a security expert, provide them support. Um, and the same thing with scalability. Scalability is also something that can benefit more from tighter collaboration, more so than security. Um, so just make sure that the team is able to express itself as a team through pair programming or having more immediate conversations rather than just, you know, asynchronous code review conversations or stand up conversations way at the end of the cycle. At the end of the cycle when the code is written and it’s going into merging or QA, it’s too late, the code is written, right? So you want the preempt. That solution is being created by the team being able to express itself as a team rather than just a group of individuals, being the individual goals.

Kovid Batra: Cool. I think, uh, we have a few more questions, but running way out of time now. Uh, maybe we can take one more last, last question and then we can wrap it up.

Paulo André: Sounds good. Okay, so this one is for me, right? How do I approach, uh, integrating new tools and frameworks into engineering workflows without disrupting productivity? That, that final piece is interesting. I think it also starts with how we frame this type of stuff. So there is a cost to making improvements. I don’t think we can have our cake and eat it, too, necessarily. And it’s just part of the job, and it’s part of what we do. And so, um, you know, for example, if you take the time to have a regular retrospective with your team, right, is that going to impact productivity? I mean, you could be coding for an extra hour every two weeks. It’s certainly going to have some impact. But then it also depends on what is the outcome of that retrospective, and how much does it impact the long-term, um, you know, capacity to win of the team. So with that in mind, what I would say is that the most important thing I find is that you don’t just, again, as an engineering leader, as an engineering manager, you just don’t, you don’t just download certain practices and tools and frameworks on the teams. You always start from what are we trying to solve here and why does it matter and get that shared understanding to the point where we’re all looking at the same problem roughly the same way. We can then disagree on solutions, but we agree that this is a problem worth solving right now, and we’re gonna go and do that. And so the tools and the frameworks are kind of like downstream from that. Okay, now what do we need to gain the inside? Oh, now what do we need to solve the problem? Then we can talk about those things. Okay? So as an example, one thing I’m working on now with my team, I mentioned this earlier, I believe is like, uh, a bit of a full-on product delivery, product discovery and delivery, um, process, right? That includes a product strategy, um, that shouldn’t change that much that often. And then there are a lot of tools and frameworks that we can use. Tools, we use three different types of projects in Jira, for example. And when it comes to frameworks, we’re starting to adopt something called opportunity solution trees, which is just a fancy way of saying what outcomes are we trying to generate, what opportunities do we see to, to get there and what are the solutions that can capitalize on these opportunities, right? That sort of thing. But it all starts with we need to gain clarity about where we’re gonna go as a business and as a product and everything kind of comes downstream from that, right? So I think if you take the time and this is where I’ll leave it. If you take the time and I think you should to start there and to do this groundwork and create this shared context and understanding with your teams, everything else downstream becomes so much easier because you can connect it to the problem that you’re solving. Otherwise, you’re just talking solutions for problems that most people will think they are inexistent or they just look completely different, right? And this takes work, this takes time, this takes energy, this takes attention, takes all of those things. But frankly, if you ask me, that’s the work of leadership. That’s the work of management.

Kovid Batra: Great. Well said, Paulo. I think Denis has a point to add here.

Denis Čahuk: Yeah, I had a conversation this week with one of the CEOs and founders of one of Ljubljana, Slovenia’s biggest agencies, because we were talking about this. And, and, and they asked me this question, they said, “Denis, you don’t have a catalog. Like, what do you do? Like, how do, how does working with you look like? Do we do a workshop or something?” And I said, and I asked, “Do you want to do a workshop? And, and I saw on their face, they said, “Well..” I told them, “Yes, exactly, exactly. That’s why I don’t have a catalog because, because, because the workshops are this, I will show you how a great team works, right? I will give you all of this fancy storytelling about how productive teams work, and then you’re like, “Great. Cool. But we’re not that and we can’t have that in our team.” So great, now I’d go away because I’m, because I’d feel demoralized, right? Like that’s not a good way of approaching working with that team. I, I always tell them, “Look, I don’t know what will help you. You probably also don’t know what will help you. We need to figure it out together. But generally, what’s more important than figuring out how to help you is to figure out how much are you willing to invest consistently in improvement? Because maybe I teach you something and you only have 10 minutes. That’s the wrong way about it, right? I need to ask you how much time do you have consistently every week 15 minutes? Okay, then when I need to teach you something that you can put in practice every 15 minutes Otherwise, I’m robbing you of your time. Otherwise, I’m wasting your time. If you have three hour retrospectives and we’re putting nothing into action, I’m wasting your time, right? So we need to personally figure out like what is consistent for you? What kind of improvement, how intense do you want it? How do you know if you’re making progress?”

Those two are the most important things, because I always come to these kinds of questions about new tools and frameworks because people love asking me about, “Hey, Denis. Can you do a TDD workshop?”, “Denis, can you do a domain-driven design workshop?”, “Denis, can you help us do event storming?” And I always say, “If what you need is that one workshop, it’s not going to solve any problems because I’m all about consistent improvement, about learning, about growing your team, about, you know, investing into the people, not about changing, you know, changing some label or some other label.” And I always come back to the mantra of what can you do consistently starting this week so that the product and the team is much better six months from now? That’s the big question. That’s, that should be the focus. Cause if you need to learn something, you know, go do a certification that takes you a year to perform correctly, and then you need to renew it every year. That’s nonsense. This week, what can we do this week? Start this week, apply this week, and then consistently grow and apply every single week for the next six months. That would be huge. Or you can go to a conference and send everybody on vacation and pretend the workshop was very productive. Thank you.

Kovid Batra: Perfect. I think that brings us to the end of this episode. Uh, I think the next episode that we’re going to have would be in the next year, which is not very far. So, before we depart, uh, I think I would like to wish the audience, uh, a very Happy New Year in advance, a Merry Christmas in advance. And to both of our panelists also, Paulo, Denis, thank you, thank you so much, uh, for taking out time. It was really great talking to you. I would love to have you both again here. talking more in depth about different topics and how to make teams better. But for today, that’s our time. Anything that you would like to, that you guys would want to add, please feel free. All right. Yeah, please go ahead.

Denis Čahuk: Thanks for inviting us.

Paulo André: Yeah, exactly. From my side, I was just going to say that thanks for having us. Thanks also to the audience that has put up with us and also asked very good questions, to be honest. Unfortunately, we couldn’t get to a few more that are still there that I think are very good ones. Um, but yeah, looking forward to coming back and deep diving into, into some of the topics that we talked about here.

Kovid Batra: Great. Definitely.

Denis Čahuk: And thank you for Kovid for inviting us and for introducing us to each other and to everybody backstage and at Typo for, they’re probably doing a lot of annoying groundwork at the background that makes all of this so much more enjoyable. Thank you.

Kovid Batra: All right, guys. Thank you. Thank you so much. Have a great evening ahead. Bye!

Made in Webflow