B (4:46)

So describe for us quickly what is eos, what is its name and what is its origin?

C (4:52)

Yeah, so EOS stands for the entrepreneurial operating system. So think of it as a business operating system which is there to orchestrate and harmonize all moving parts of your business. Right. So that means how do you set your priorities? How do you run your meetings, what time do you connect? How do you connect? How do you track your numbers? And it was created by a guy called Gino Wickman in Detroit in the US and it was created, I think around 2013 or 12, around that time. And Gino was really frustrated running his own business and he tried to look for something which was relevant for small to medium sized businesses and he couldn't find anything. So that's when he started researching and started experimenting on his own company to create this system, which now we call EOs.

B (5:51)

So how would you look at EOS in the context of Agile? Where do you see the parallels and where do you see that they might differ?

C (6:02)

Yeah, so I get this question a lot when I work with tech companies who are already using Agile and I love Agile because I love systems in general. And it's better to use a system than use no system at all. But the challenge is, and this was my challenge as well, people get lazy and they want to pick only bits and pieces of the system. Right. And they don't really get the full value of that system because you're only doing things that you're comfortable doing and you're not doing the things that are uncomfortable but are beneficial for you. Because maybe you don't know how to do it right, or maybe you relax the parameters so much that you change them completely. So instead of it being EOS or Agile, it becomes sos, which is SIDS operating system, which is just an emergency call for help. And that's what I did. I kind of changed the system a bit, but I always come back to the origin of the system because it was designed to deal with the particular situation. So Agile. So I'm not an expert in Agile, but I know that both EOS and Agile are allergic to hero culture. I know that both EOS and Agile push for decisions as close to work as possible. So it's not woo woo, it's not in the air. It's about taking a decision, moving on. And the beautiful part about Agile and also EOS is that it has a cadence, it has a sprint, it has a rhythm. Right? And that's what we call, right. It's about having that connection where you're not micromanaging something and you come once a week or whatever the cadence is. It could be daily. I know there are daily standups in Agile. You come, you connect, you understand what the challenges are. You kind of have this plan and you go execute, you disconnect and you go do your own thing. Right? You're not standing on top of each other every hour, every minute looking for an update. It's about coming, connecting, downloading and just understanding, solving the problem, disconnecting and going and doing your thing. So I love the cadence and the sprints concepts that are there. Now. Agile says you inspect and adapt and EOS says that, okay, let's go solve the root causes. So very similar. And both rely on visibility and numbers and scorecards. What I feel is the real overlap is trust through structure.

B (8:38)

Can you expand on that a little bit more? What do you mean by trust through structure?

C (8:43)

Yeah, so what happens in EOS is that there is a way teams are structured for accountability. And we call this an accountability chart, which we essentially say, great, so you're in, let's say you're a team lead or you're a product manager. And I would say, okay, how does your team look like? What is required for you to be successful in delivering that product? How is your team structured for success? Right, so you might have developers working with you in your team, you might have designers, you might have QA you might have, you know, I don't know, maybe some project sponsor or project manager helping out as well. And obviously you have developers as well, so you have a team, and now that team reports to you because you own the outcome for delivering that product, right? So that's a structure, Right? And then if the team is not accountable, you will never trust them. You will always follow up, you'll always check in. You'll always want to know more about what's going on. So once a structure is created, we say that. And if you start trusting the people in the team, there is a structure around it. And trust is built only if that structure is in place. Because if there's no structure, then I'm not accountable to you.

B (9:57)

Okay, let's make it very practical, Sid. So I hear you. Structure helps to, I guess, solidify, clarify, crystallize accountability. So let's make that practical. Do you have a story to share of a team or a business that you helped to build that trust through structure and using that aspect of structure, bringing accountability?

C (10:20)

Absolutely. And I'll give you a great example. And this is the most common use case that I see also, especially in tech teams. So in my business, we had a team that was not reporting to this product manager because the developer was reporting to the developmentally, the guys who were responsible for development. So it's like a matrix sort of structure where we make a squad, right? It's a mission. Like, our mission is to deliver the product for our client. So we pick the best people and we put them in a structure. And, okay, it's like Navy Seals, right? If you want to go and complete a mission, you put a structure together, right? A squad. And that's what we did. And I said, for this project, you report to this guy, and you guys need to deliver the product, and you own the outcome for development, you own the outcome for QA, you own the outcome for UIux, and then the product manager owns the product to the customer. That's the structure that we created now for the time that they were together to deliver the product to the customer. That's the accountability that has been created. Now, I'll tell you how trust helps. Now, if there's no trust, right, that means that you will not challenge your teammates, you will not engage in any sort of conflict. You'll just be, yeah, whatever. Yeah, I'll do what you say, right? And so that's the first thing we had to do, is like, hey, we need to be vulnerable. We need to be open and honest with each other. So we can engage in healthy conflict, and I can challenge your assumptions and hypothesis in meetings. Right. And if I can engage in this healthy conflict, you know, there'll be debates and discussions, but a decision would be taken, and then there would be some commitment that. All right, we've heard everyone. But, you know, based on what I see and hear, the product manager would say, let's go in this direction, because I've heard everyone. I think this is the best way to go. Now. People feel heard, and now they can at least know that their value, you know, their points are valued and you know, they can put their point across without repercussions. And once the commitment is there and you've agreed that, yes, this is the way to go forward, then there is shared accountability as a team. And you're saying that, yes, I'm accountable for this, but I'm also holding you accountable for this. Right. So I'm going to hold you accountable, and you hold me accountable. And with accountability, you then start. Then you're able to deliver the results that are expected. This is like a trust ladder, or you can call it the Lencioni pyramid. Great book written by Patrick Lencioni. And this is where this comes from,

B (12:54)

the Five Dysfunctions of a Team, where he talks about the different levels, the lack of accountability or inattention to results is what he calls it is one of those.

C (13:06)

Yeah, yeah. So you don't get the results if there's no accountability. And if there's no accountability, I mean, I'm talking reverse. Now, results is the top of the pyramid. The bottom of the pyramid is trust. And the bottom line for that trust to build is some sort of structure, because without structure, you cannot build that trust or a team.

B (13:26)

You also talk about this delta delegation ladder. And in the context of burnout, delegation becomes a very important thing. And of course, it also colors the discussion around accountability. You talk about this delegation letter to help leaders escape this temptation. I guess we could call it to command and control. Can you walk us through it? And what usually makes delegation fail, even when leaders think that they're letting go?

C (13:56)

And so delegation is one of the. Is probably the hardest skill that one can learn. And every time you delegate, it's a different experience. So there's no cookie cutter template to delegate to anyone that you have. I wish there was. And it's a skill as well. So part art and part science. Right. And it's one of those defining things that you learn as you grow and as you start leading teams. So there are multiple ways to do this. Right? So there's, as you mentioned, command and control, right? Which is in my Delta framework. The D is do as I say. Like, hey, this is what I want you to do and just get it done. Now when you hire someone, which is do as I say, it's a bit challenging. And now we've started seeing AI replace the do as I say, because, hey, it's you giving a set of instructions and that just needs to get done, right? So a lot of people are saying, hey, I can use AI for automation and I can just use AI to do that stuff. I don't need to hire like a junior guy to do as I say, because now AI models and the way it's progressing, the do as I say is going to be delegated to AI. I can tell you that the next level is interesting because we say, oh yeah, this is a problem statement. Go research, use AI, use perplexity or whatever model you want and go explore what are the possible solutions for this, right? And then let me know what those solutions are, right? So this is someone young and junior in your team and you're just like, hey, go explore this stuff and just tell us what you found because I don't have the time to do it myself. I want you to do it. Go figure it out. And then they come back and they present you with three solutions and you still are the one making the decision, right? So it's still a lot of brain power because you need to look at everything to make a decision. So that's not true delegation. You just. This is like a VA or virtual assistant, or like a project assistant that you hired. And this position itself will get replaced pretty soon, if not already, by AI. You can get complex models and you can ask them to give you recommendations and solutions. Now the L is lead with the recommendation. So this is where we start using our brain power. This is like the entry level. I would only hire people who are L and above in general. So this is you do the research, you figure out, and then you tell me what's the best way to go ahead, what's the next step? Right? I want to delegate that to you. I want you to take that decision as to what's the next step, and you present me your hypothesis as to why this is a good way to move ahead. And I encourage all leaders and, you know, project managers to always start with this L part because if you're hiring before that, it's probably a bad idea. You can probably delegate that to AI. So, and even in the interviews, you know, you should Be asking, okay, you know, what, what, what would you do? And just walk me through your process, you know, and this is where you get to train people, get to get, you know, this is where the true training happens, where you start molding those guys based on your processes and systems and your thoughts. Right. Because they give you an answer is like, hi, interesting. I didn't think about that. What do you think about this? And this is where coaching and mentoring comes in. Now the T is great because T is what managers do and T is what I would use, which is about taking action from that, you know, with oversight. So I know that I can trust this person because they've delivered in the past. I've shadowed them, I've coached them, I've mentored them, and I understand them. And I'm pretty confident that the decision that they will take will be in alignment with where we are going with this project or with this, with our vision. So that's the T part where people are decisive. They take the action and they keep you in the loop. They say, hey, Sid, I've done this, I'm on track to do this. Just wanted to let you know if you have any inputs for this because we're going ahead with this. Right. And I love people like that because then I'm just, I'm in the loop. If I need to have a comment or two, I can always jump in. But I'm not being a bottleneck. I'm letting them progress. And the last is a, which is, I essentially call this co founder mode. This is autonomous execution. This is outcome owned, end to end. This is someone you deeply trust. You don't even need to be in the loop. You know that they're going to just go do it. You know that they're just going to make it happen. And then, you know, in your team meetings, they'll give you an update about it, but they will just make it happen. They take complete ownership of this.

B (18:31)

So how do you help leaders through this ladder? Also helping them to build that trust maybe through structure, as we just discussed, but without falling into this temptation of still trying to keep everything in control and potentially even getting to the point of taking too much responsibility and burning out.

C (18:52)

Yeah. So delegation fails because leaders skip levels and the delegation fails because I hire a person who's do as you say and I expect them to take decisions and be autonomous. Right. And it's about expectations and hoping for miracles. So number one thing is setting expectations and having complete clarity as to what that person will deliver. When will they deliver and how will they deliver? Right? So it's about me understanding, hey, do you understand what needs to be done right? And what are the steps you're going to take to get it done? When are you going to get it done? Do you need any inputs from me? So this is. Leaders sometimes feel that, oh, I've hired this great person, yeah, their resume is great and you know, I've seen experience. And then they just abdicate responsibility. They're like, yeah, you got it man, just go figure it out, just do it right. And that's probably the worst thing that you can do. And what I advise people is you have to coach them, you have to mentor them, you have to. Delegation will only work if you spend time with the person that you try to delegate to and you completely clarify your expectations. What should you expect from me? And what should you expect What I expect from you? And have I given that person the tools, the training, the resources, my time to be successful? Because if not, then good luck, it's not going to happen. And am I meeting them often enough now? It could be agile, it could be a daily huddle, it could be a sprint. Am I meeting them in a structured way to give them the feedback that they deserve? If not, then, you know, you've made accountability optional because you made the meeting option. And that's why delegation fails a lot of times now. The senior, the position, the more it takes more time it takes to delegate. So if I'm like hiring like a VP or I'm replacing myself from a position and hiring someone else in that position, it's going to take you a lot more time. And that's why I request an encourage and teach leaders to be patient. You need to be patient with that person. You have to give them that, you know, you have to give them your time to teach them what great looks like. Because if you don't show them what great looks like, then you'll always be disappointed because they'll be putting up mediocre, which they think it's great. But you've never clarified the expectation. So a lot of it is expectation management. And there is no compromise for getting the right person in the right seat, which means that they should be competent in doing what you expect them to do. So if you've hired a UI UX designer and you expect them to do QA full time, that's probably a bad idea. They'll, you'll delegate stuff to them, but you'll never get the best output from them because that's not their, you know, core Competence, that's not what lights the fire. So they'll never do the best possible job.

B (21:53)

I want to bring another aspect here that is very important for our industry, especially after Covid, where many teams are now fully remote, sometimes onshore, sometimes offshore. What are, in your view, the non negotiables for maintaining trust? Communication, rhythm. When people are not sharing the same office and very often not even the same time zone.

C (22:18)

Yeah, it's a great point. And I think around Covid, everything changed for everyone. And I think instead of this connection, people were disconnected. Right. And then zoom and all those things come in. The key, according to me over the past few years, is you have to be really good in writing. You have to be good in writing. So when you're using Slack or teams or whatever software, use written clarity beats verbal alignment every single time. So get good in writing, guys. And today we have so much AI I want us to over communicate. Over communication is not a flaw. It has to be the standard in company that is running remotely. Because if you don't over communicate, you don't show up to meetings, then there's zero accountability. There's no way you can build culture. Time zones are time zones help you with the rhythm. And it's not about availability. You can be asynchronous. A lot of teams I work with are asynchronous, but they do find the time to meet at least once a week. And for the rest of the weeks they're communicating, they are sharing their writing, they're updating, you know, asana, whatever you, you have to communicate and write. If you're poor in writing, there's no excuse anymore. You can just dictate something to chatgpt and it'll give you a nice written statement out of that.

B (23:41)

Yeah. Make sure you're clear about the tone, lest it understand a clear message as an ironic message. You never know.

C (23:50)

That's a good point. Because, you know, across cultures, your tone matters a lot, you know. So if I'm in the uk, we are very polite about things generally, not very direct.

B (23:59)

Sometimes too much, I have to say, it doesn't register outside the uk. Yeah.

C (24:05)

And when I'm working with colleagues from the Netherlands, the Dutch people, they're very direct. They're like straight up.

B (24:10)

Yeah. And that doesn't mean that they are being disrespectful. That's just how they communicate.

C (24:15)

Exactly. And then, you know, just okay, so British, we always want to like, you know, have a soft landing and not hurt the feelings. And Dutch, they're not Their hurt feeling, they're just to move things along. That's how they're, you know, that's how they communicate. And you have to understand that. And that's how trust is built when you understand where they're coming from. Right? And trust comes from predictability. So I can predict what you're going to do, not from proximity. So I can be right next to you and not trust you, but I can be thousand miles across the world from you. And I can trust you because I can predict what your actions are going to be. I can predict that you're going to get your to dos done. I can predict that you're going to hit your milestones because you've done it in the past. I can rely on you. But someone who's sitting next to me who's consistently not been able to deliver their milestones, guess what? I will not trust them. I'll keep following up. I'll keep asking them, hey, you say you're on track, but are you really on track? That's lack of trust, right? So get good at writing guys. Get good at over communication and that's what really helps in building.

B (25:22)

Good at writing I think is a wonderful tip despite the fact that we are here communicating verbally on the podcast. So Sid, for people who are really interested in these topics in eos in Delta and other aspects that you can bring and you brought today, what's a resource, a book, a tool, a practice, a video that you'd recommend for leaders trying to build truly self managing teams and finally escaping burnout.

C (25:54)

Yeah, so I wish self managing was a thing but yeah, I would say like light managing you know. Well because where you get to do what you love doing while still keeping your team aligned and you know, with the objective and the goals. A great book I recommend is from my mentor and virtual mentor Guy Love is Gino Wickman. His book is called Traction. It's one of those bestsellers that all team leaders, entrepreneurs, anyone who aspires to be a product owner or team lead should read because it really helps you simplify leadership and management. There might be thousands of books that come out for leadership and management every single year and I read a lot of them and what I find is I can always go back to Traction because it covers the essence of what leadership and management truly is. Highly recommend this book. I also write a lot about this in a weekly newsletter that I have on Substack. So just search for my name on substack or I'll have Vasco.

B (26:57)

We'll put the link in the Show Notes for sure.

C (26:59)

And every week I write a newsletter called Leadership Bites Weekly and I'd love for your subscribers to check it out. You don't have to subscribe, you can just go to Substack and read it as well. And yeah, that's a great weekly resource as well.

A (27:15)

Absolutely.

B (27:16)

I will put the link to all of those in the show notes. And Sid, if people want to know more about you and the work that you're doing, where could they go?

C (27:26)

I'm super active on LinkedIn, so LinkedIn is the best place to find me, Sid Jakshanani to search for me and Substack is where I write my newsletters. If anyone has any questions on EOS or Traction and how it varies with Agile, just start a conversation with me on LinkedIn and I would love to share my insights and work deeper with you in helping you get the best of both worlds.

B (27:53)

Absolutely. We'll put the link to Sid's LinkedIn page also in the Show Notes, so be sure to follow that up and ask follow up questions and get in touch with Sid. Sid, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

C (28:09)

Thank you Esko. It was a pleasure.

A (28:14)

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of

B (29:14)

all of that AI slop you see everywhere.

A (29:16)

And of course, without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together.

B (29:30)

So if this podcast has helped you

A (29:32)

before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important, but doing it together that's next level. I'll see you in the community.

B (30:04)

Slack. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.