Tactics for Tech Leadership Podcast

S2E24 – Leadership Insights from the Plato Elevate Conference

—

by

Andrew Parker
in ,

Show Notes

 In this episode of the TTL podcast, Mon-Chaio and Andy review the recent Plato Elevate Conference in San Francisco. As a unique gathering focused on engineering leadership, Mon-Chaio shares his key takeaways from sessions on effective reorgs, experiments in culture engineering, and the innovative EngOS. The duo also explores the broader value of conferences, particularly the networking opportunities and on-the-ground experiences that often eclipse formal talks. Mon-Chaio highlights the significance of continuous learning for leaders and the practical applications discussed in various roundtable sessions.

References

Transcript

Andy: Welcome back, everyone, to another episode of the TTL podcast. This time, Mon Chaio and I are going to do a little exercise that will both be fun and informative. The exercise is an example of how you can support learning in your organization.

Now, this is something I’ve done quite often with my teams, where when someone goes off to a conference, they come back and the expectation is that they’re going to give some sort of presentation, some sort of discussion about what they have learned, what they’ve seen. Get it so that the rest of us can can vicariously live through them.

And that’s what we’re going to do this time. Mon Chaio, you just went to a conference. And now we’re going to have a discussion about what you saw, what you learned, and we’ll do our normal thing of riffing on it. But yeah, we’re going to, we’re going to learn from what you learned. So what, what was this conference Mon Chaio?

Mon-Chaio: So last week I spent two days in San Francisco attending the Plato Elevate Conference. It bills itself as a conference for engineering leaders. And one of its taglines is, it’s the no BS conference. And they use a cute little poop whenever they say that, right? The poop emoji. So I was super excited.

One, I think it’s really important for there to be conferences focused on eng leadership. I mentioned to some folks, if I’m interested in React, there’s a million and a half conferences, probably in my own city, that I can go to, or meetups. If I’m interested in Eng Leadership, there’s essentially zero.

So when I came across a NoBS Eng Leadership focused conference, I was very excited to attend.

Andy: The only other one that I know of that is specifically about leadership is LeadDev.

Mon-Chaio: Mm hmm.

Andy: I, I’ve never been to one. I’ve heard it’s really good as well. I think it has a little bit more of a dev focus, but we’ll find out because we’ll, we’ll talk about this and someone can correct me because I’ve never been.

So,

Mon-Chaio: Yeah, and I think there are some more uh, while I was at Plato Elevate, obviously, doing a lot of networking, there were people that introduced me to at least two and maybe three other Eng leadership conferences. One offered to connect me to the to the facilitators to do a talk. But it happens that I’m actually away on vacation the last week of August.

So, unfortunate. Also, it was in Vegas, so I’m not super disappointed to not be in Vegas the last week of August when it’s probably like 120 degrees

Andy: You don’t want to die.

Mon-Chaio: is in Celsius. Yeah. I mean, it is in an air conditioned hotel, I’m sure. But we will, well, I hope to at least get to one or two more this year if I can.

Yeah. And maybe we’ll continue this learning series if I do get to some of these.

Andy: Yeah. All right. Well, let’s just get into it. Now the. First, I actually don’t know if it was the first session. It was the first session in the writeup that you provided to, to guide our, our discussion here which was something about a thing called EngOS.

What, what was this?

Mon-Chaio: Right, so this was the first talk. In fact, it was the keynote that kicked off the entire conference. And it started off with one of the founders of Plato saying that their goal for Plato was to bring engineering together and they wanted to create great engineering practices or great engineering leaders.

Let’s say practices. Great engineering practices that both scaled and stuck. And they found, I think Plato’s been around for four plus years now, something like that I believe. If you didn’t know they were YC funded at one point. Interesting group. And so the founder was saying he was having trouble finding getting these practices to scale and stick.

And they recently merged with Right? Right? I mean, we do a podcast on ostensibly engineering practices, but more than that. And yeah. I would say learning is difficult, so. They recently merged with Coda which you may know. Coda creates I don’t know what you would call the tool that they create.

Andy: Is it kind of like Notion? Is it the whole new wiki stuff?

Mon-Chaio: Exactly. You can have workflows, you can create mini apps and all sorts of stuff. So, Coda does that. And they recently merged with Coda and he was mentioning one of the reasons that they merged with Coda is because they were talking and they felt like their partnership could get things to scale and stick.

And so one of the scale methods is this thing that they invented called EngOS. Or An operating system for your engineering organization. So that sounds good in theory, right? And I was super interested, actually. They wrote a blog post about it, which we will link in the show notes. And a lot of this stuff makes a good amount of sense, right?

They said basically there’s four pillars. There’s an execution pillar, a team pillar, an engineering pillar, and then a personal productivity pillar that underlies all three of them. And within the pillar, there are different facets, right, so execution has like a planning facet, a collaboration facet, a decision making facet the team has like a formation facet, a management facet, that, that all makes sense, I think and the Coda, I think it was the CEO and founder of Coda, also came onto stage, and he started off saying something that I’m actually a big believer in, he said, look, Over the last few years, I’ve really started thinking about how culture is the driver of engineering organizations.

And if anybody’s listened to this podcast, you know, at least me, and I think Andy too, huge believer of culture as foundational for eng product, or for eng organizations and the impact that they can make. And so he starts saying, and, you know, An important part of culture is these rituals,

Andy: Mm hmm.

Mon-Chaio: okay? And so then he starts going into this idea that rituals build culture, which I think it’s a little bit the other way around.

You have to have your culture and but there is some stuff around, you know, monkey see, monkey do, and then you kind of build culture from there. So there, there, there’s a little bit of that. I was intrigued. And then he said, well, what we’re going to do with EngOS is we’re going to bring the best rituals from the best companies, and we’re going to create templates in Coda so that you too.

Andy: I was with him until this point.

Mon-Chaio: you two can replicate these great rituals.

Andy: It, it reminds me of, so there’s two things that came to mind as you said, all of this the execution, team, engineering, personal productivity. That reminds me of the TSP. The, I think it’s, I think it stands for, I think it’s TSP. It’s team software process. It’s from the Software Engineering Institute.

The same people who brought you CMM. But there’s the TSP and the PSP. The PSP is the personal software process, and the TSP is the team software process. And that was the same I think it even has probably similar parts to it. This, this framework of personally, as a developer, how do you operate to be productive and effective and high quality?

And then the TSP is, as a team, how do you operate to be productive, effective, and high quality?

Mon-Chaio: Mm-Hmm.

Andy: And so this kind of framework, they show up again and again. And, and then as you were talking a bit more and it turned into, well, we want these templates, then I thought RUP. And I think maybe with this I’m showing my age a little bit.

The Rational Unified Process.

Mon-Chaio: Right? I remember

Andy: early days Agile. Before Agile existed, it was, it was the attempt at doing that, which was basically like, Hey look, if we give people templates about how all of these processes work, and we give them guidelines about how to put this together, Then the Rational Unified Process says, here’s a big toolbox of all of these things, and now you can put together the one that works for you.

Mon-Chaio: Mm-Hmm.

Andy: it was effective in, in some ways. It really, it gave people these guide rails and, and, and these specific ideas that they could use without having to feel like they’re reinventing the, the wheel and trying to come up with, all right, how do I plan? That kind of thing.

Mon-Chaio: Mm-Hmm. and RUP. Did it scale and did it stick?

Andy: I mean, well, Rational was bought by IBM, and IBM installed it all over the place. It was a big thing for a long time. Whether or not it actually helped the organizations, I don’t know. That would be an interesting one to research.

Mon-Chaio: We’ll have to put it in our notes. I think it would, it would be very interesting to research that, but I think. In my mind, this idea of learning from other companies to not reinvent the wheel, I think that seems very reasonable. So for me, EngOS had two challenges that I’m still trying to dissect in my own mind.

I think the first one is that a lot of their rituals felt like appeals to authority. And I’ll get into this when I get into my general sense of the conference. One example that I’ll give here is they had this ritual called $100 voting.

Andy: I was going to ask you about that. I saw it in your notes, and I thought, what is this?

Mon-Chaio: Mm hmm. And they introduced it as this very senior leader from this well known company has this ritual called $100 voting. And when I heard it, I thought this was great. And now it’s one of the, I don’t know, 35 rituals that we’re going to launch when we launch EngOS in the next few weeks, something like that.

And $100 voting is this concept that everybody has $100. And when you vote for things, for example, what you want to work on next quarter, or any sort of thing like that, you can allocate your $100. You can say, I’m going to put 45 over here, 5 here. And then you rank them based on how much money each thing has.

Now, when I first heard that, I was like, you know, I heard that called dot voting before. And I’ve done dot voting. Which isn’t as granular as $100 voting, to be sure. And so I was like, well, it’s weird that they attributed it to this senior leader from this well known company, because I’m pretty sure this idea has been around for a long time.

And, funnily enough, I think it was two or three sessions later, I was attending a different talk, and the guy was mentioning, Oh I read this book about how they did search, somebody was lost. A search and rescue person was lost, and so the search and rescue team came together and decided to search the wilderness for them, but the wilderness is big, so how did they decide where to search?

And this was, I think, in the 60s, something like that. And he said the book talked about them using a 100 point voting system. The number was even the same. A 100 point voting system in which they tallied it all up to decide where to focus their search efforts. so, You know, I don’t know, like, I think $100 voting is great.

I think it’s a good thing to put into practice. I think having a Coda template to do it so it’s easy, probably a great idea. But that appeal to authority around it was the senior person at this well known company that really brought it to my attention, and it’s so great, and their name is tagged to it.

That really turned me off.

Andy: Yeah. It’s like, it is a great idea on its own. You don’t need to say that it’s a great idea because someone at a major tech company does it.

Mon-Chaio: Mm

Andy: And, and I can say, I’ve heard of it as well. I know of it for more product management which is that you ask a customer, Hey, you got all these things that we’ve talked about.

Here’s a hundred dollars. You can split it among the, all the features, however you want, but just pay for the things that you care the most about. And that’s where you start figuring out, what do they actually want? And so it’s a great, it’s a great way of giving people that kind of weighted voting. Or ranked choice voting is almost a way of thinking about it.

Mon-Chaio: hmm.

Andy: you can say, all hundred goes on this. And so it’s, you’re saying, it’s that or nothing else.

Or you can do 30 here, 30 there, 30 somewhere else. And you’re like, these three are the same to me.

Mon-Chaio: Right. Yeah, I think we both really love the ritual if you want to call it a ritual. Let’s call it a process.

Andy: To me it’s a process, not quite a ritual. I don’t know. There’s something a little different in the connotation of those two terms, and this doesn’t quite match ritual for me. We’ll have to explore that at some point.

Mon-Chaio: Yeah, agreed. And then I’ll just say real quickly the second thing that I’m still puzzling over about EngOS. Another ritual. I believe it’s called Catalyst. I can’t remember now but like the recordings will be online so y’all can watch it. And what I believe Catalyst was, was this concept of you get a large meeting together and there’s 50 attendees or 20 attendees and you’re giving updates on things and, you know, half the room doesn’t care about Update 1 and the other half the room doesn’t care about Update 2.

And so, again Appeal to Authority, this great person, senior person at this well known company had this thing that they call Catalyst, where they break this meeting apart. And they have specific roles. There’s a decision maker role, or there’s a, you know, an informed role and then you get invited to the meetings that you want to, that you, want to be in or need to be in.

And of course, there’s a Coda template for all of this. Where, you know, emails are sent out beforehand that informs you of your role. And now it’s great because you have smaller meetings where you have a more tight attendance, right? Which, again, I think that’s great. I think the problem with that is in order to do that, it requires, in my mind, a lot of psychological safety on your engineering team.

So people don’t feel like, why was I not invited here? Why am I just a, whatever, why am I just a informed person versus a decision maker? Ooh, I really want to know what’s going on there. When can I find out? And so I think if you took that ritual and just said, well, that’s a ritual that worked at company X, And just stuck it on your team.

I think without psychological safety, it would fail. And we’ve talked about how many teams, probably the majority, probably a huge majority of teams, actually do lack psychological safety. And so I think my challenge with EngOS is, nowhere in that scheme of EngOS, do they talk about the foundations that I think are important to enable some of these rituals?

Things like psychological safety, things like culture building, things like trust building, all of those communication skills, all of those types of things.

Andy: Yeah, so the assumption is that this set of practices are going to work for some groups, and the hypothesis would be it’s working for those groups and not working for other groups because there are foundational beliefs and understandings, mental models, that the group already shares that enables this to work.

Whereas if those aren’t already there, just picking these up won’t cause them to magically appear.

Mon-Chaio: Agreed. Yes. Yeah, that would be my hypothesis.

Andy: Interesting. All right. So anything else about EngOS or should we move on?

Mon-Chaio: No, I think we can move on. I think it’s an interesting topic. I would love and you were mentioning you see a lot of these models. The great thing about it is it did get me thinking about what would it be? Our model, Andy, and something that we can discuss a little bit later about, you know, building great eng organizations.

Andy: yeah, I think that is something we do need to come up with at some point. And I should say, we criticized it, it’s still better to have a model than not have anything.

So, all models are wrong, some models are useful. I hope that this is a useful model from the outset. It does look like it could be very useful.

If nothing else, then it should guide people on to what to think about.

Mon-Chaio: Right. I agree.

Andy: All right. So your next one that I think you attended, or maybe not, I might’ve skipped around, was one called Experiments in Culture Engineering, which is probably a good follow on from what we just said about EngOS,

Mon-Chaio: Yeah. Experiments in culture engineering. I expected this to be about culture

Andy: as

Mon-Chaio: and I

Andy: as well.

Mon-Chaio: and it ended up not at all being about culture. Which is, which is okay. It was still really interesting. It was a, again, a very senior leader, who had worked at a bunch of different places, who was talking about the things that they did at those places, and the main takeaway was, you can run mini experiments on people processes just the same way as you can run mini experiments in your product processes.

He didn’t have a great framework for how to think about that. He did have some framework, right? He said there should be some guardrails because remember you’re dealing with people, not software, and it’s really important to have guardrails when you deal with people. So he had a few things like that.

And then he just gave examples of, you know, how he would run, how he had in the past run mini experiments to improve a performance review process or

Andy: Do you have an example to mind that you could share? Because I’m interested in like, What specifically is meant by guardrails and how, like, the thing I’ve always struggled with is how do you determine the outcome of the experiment?

Mon-Chaio: So, I don’t think I have an example around the guardrails, unfortunately. I think the experiment that I recall the most from that talk probably should have taken better notes, but I was like, they’re going to post the recordings. Unfortunately, the recordings haven’t come out by the time we’re doing this episode. He mentioned changing the way a performance, not a performance review process. Yeah, I guess you would call it that. He mentioned changing the way a performance review process was done, or an annual review process was done. And he talked about, well, we wanted to encourage certain behaviors like better engineering.

We wanted to encourage certain behaviors like mentoring or bringing people up and coaching people. And how they changed the process. It was a very large company and so he said it was difficult to change all at once. And so they ran these mini experiments where they would run it with one team. And then they would take surveys of that team.

And then they would take a look at the behaviors and whether the people that were ranked high showed the right behaviors that they wanted to promote. And then they ran it over three teams. And then when those went well and the metrics went well, then they ended up pushing it out to the larger organization.

So, that was the big example that I recall from that talk.

Andy: Okay. And, and that makes sense. It’s, it’s, you, you, you run it you do an investigation and you do, whatever methods you can. If there’s a numeric measure, if there’s not, if there’s not, you can do a qualitative measure, like interviewing and observing. Okay. I think that makes a lot of sense. Did you, do you remember any guardrails that they mentioned that were put in in that one?

Or maybe the guardrail was, we’re doing it with one rather than doing it with every one.

Mon-Chaio: I don’t recall, I don’t recall. I’d have to listen back to the talk on that. I do think, I do remember that a big thing he mentioned, which I think all of our listeners and all engineering leaders should take into account, is he said, culture engineering, or people processes, and I don’t think that’s culture, he meant people processes, is not an HR function.

HR is there to reduce your risk. And so it is actually an engineering leader’s function to lead these people process changes, as much as it is. to lead product process or product changes. And I 100 percent agree with him. I’m glad he said that. I think that’s something that people need to hear more and more.

So it was good insight and I’m glad he shared that.

Andy: Yeah. And, and I think, have we talked about this before? I can’t remember. But the idea that that may be the outside structure and demand, but you can always translate it to how you’re going to do it and translate it back to that external, like, just like we do with software, you have, you have inner, you have components that do the translation between an outside system and your internal structures and all of that, you can do the exact same thing, which gives you much more flexibility.

And also the, the way that. I think about HR is, HR is a service to the organization. They don’t define what we do.

Mon-Chaio: like that. Yeah, I like that.

Andy: I think we, I think we’ve mined that one for as much as we can get out of it. It was interesting. It’s, it’s a good idea to run experiments with everything you’re doing. Do a small small safe to fail changes where you can check to see, is it doing what you think it would do?

Alright, moving on. The next one was intriguing. Reorg’s Done Right.

Mon-Chaio: So, yeah, it wasn’t, I mean, this is the next one we’re going to talk about. Obviously, a two day conference, we can’t condense it into 40 minutes, right? But, Reorg’s Done Right is intriguing, and this was actually on day two for me. And I had kind of a very disappointing day one. I wouldn’t say disappointing, a very meh day one.

The conference didn’t really live up to what I had built it up in my head. And so I believe this was the, either the first or like just outside of the day two keynote, the first session that I attended. And I loved this session. On the surface, honestly, I should have hated this session. Because the topic was, How to do reorgs right.

And the presenter said, “Hey, at my company, we have decided we’re going to do reorgs every year.”

Andy: Oh yeah, you don’t like that idea. I kind of, I kind of am very open to that idea.

Mon-Chaio: Which already, You’re right, I don’t like that idea. Which already is very viscerally like, I don’t think, I don’t know about that. But there were a number of things that made this talk really good that I had not seen in day one. And I also didn’t really see in day two, I think this may have been my favorite talk out of all of them.

The first thing is, the speaker, she actually referenced a model.

Andy: And not her own, but one that’s been kind of put together and used for other things and, and yeah.

Mon-Chaio: Right. She referenced the Kubler Ross model of the five stages of grief. Now, not a perfect model. Andy, you said earlier, all models are wrong, some are useful.

Andy: Mm hmm.

Mon-Chaio: model, which is well researched, right? This gets past the small sample size. If it worked at my three companies, therefore it’s great.

It’s much more broadly tested. It’s much more broadly stressed. And she used that model. And she said, based on this model, I have overlaid my model of reorgs on top of this model. And now I have these things that go through each stage of the model. And this is why I’m doing it, because it relates to this stage of the model.

First, I love that. I love that. Because then you can actually talk about whether things are right or wrong without criticizing the thing that they did.

Right? If you say, oh, I did this at Google, all of a sudden, if I don’t think it’s right, I’m just going to be saying, well, it’s not right. Like, Google sucks, or whatever, right?

But at least now we can dive into the model and say, okay, well, I don’t believe this part of the model or that part of the model. I liked that. that she talked about the fact that her company does reorgs every year, but that’s not what she’s talking about. She’s not espousing that for all companies. I think that was really important to say because sometimes you can be like, oh well, since I’ve learned how to do reorgs right, let’s just do them every year.

But no, she said listen, this works for us because of X, Y, or Z of the things we learned. I mean, I not work for you. I’m not saying that you should do reorgs every year. But everybody goes through reorgs, and so we should learn how to do them well. Love that. And, the third thing was, I felt like she really was nuanced in the way she spoke about it.

So it wasn’t like it’s this or nothing. And, you know, it wasn’t that this will work for everyone. But this is what worked for us. We had a challenge. We had to reorg every year. So we had to find a solution to this challenge. This is what worked for us. Here’s why we think it’s more applicable because it lays on an overlay model, but let us know what you think.

So felt very collaborative as much as a speaker speaking to 100 or 300 people can be collaborative. There was they had this weird way also of asking Q& A, which we can get into later if we have time, but really like that as a talk.

Andy: I have to say my experience with reorgs. And bringing up this the Kubler Ross model, which people may not know the name, but as soon as I say the words of the model, they’ll recognize it. you’ve got denial, anger, bargaining, depression, and acceptance. I think it makes a lot of sense. I have seen that.

I really like this idea of saying that the things that happen at work are psychological. that these same grief and trauma reactions that we have for other things, for loss of a loved one, or for surviving a car crash, or, or things like that, those same things can happen at your workplace. And I think that is absolutely true and really valuable to call out to a large number of leaders.

Mon-Chaio: Exactly. And that’s the reason why we look into social science and neuro research. It’s because the levers are people.

And so you have to understand how people work in order to be able to do leadership well. And so that’s another thing you’re right. They bring in this model that comes from outside of technology.

Andy: The other thing that you got at this conference was a whole bunch of roundtables. And rather than going through them one by one, do you just have any highlights from some of them?

Mon-Chaio: Absolutely. I think one thing that Plato Elevate did well is they learned previously that people like interacting with other conference attendees. And so they tried to get more of that interaction. And one way they tried to do that was with these roundtables. They’re smaller groups. They’ve got to, they get to talk about a topic in depth for 45 minutes to an hour, usually facilitated by a moderator.

And because they’re smaller groups, there were a ton of them, right? Every session I think had maybe 20 roundtables. There were four roundtable sessions, and so, I think those were great. They were also great because it was a chance to get away from that appeal to authority. It wasn’t a person on stage talking about something they did at some famous company as if they were teaching you that that was the only way to do things.

So, I think that was pretty good. For the most part, it was very interesting talking to people about things like, Oh, you just become manager of managers. How do you track execution? What do you want to track?

What’s too much micromanagement? And so hearing from others and exploring these smaller ideas with a group that was actually practicing them on the ground, I thought was very useful.

Andy: Nice. And you ran a roundtable yourself. What was your roundtable?

Mon-Chaio: So my roundtable was on Continuous Learning for Leaders. Surprise! That is a passionate topic for me, probably for us. And it was very interesting. One of the questions I asked was think about your leader or leaders in your past, both successful and unsuccessful, and let’s discuss what were their growth areas.

Like, what were their key number one growth areas that you would have wanted them to grow in? Right? Not all of them, but like the top one or the top two. And interestingly enough, no one ever, not one person in that roundtable said, oh, the growth area is, I want them to be better at designing platforms and rolling out platforms to my organization.

Or, you know, I want them to be better at figuring out how to balance tech debt with product work. Not a single one was that like the top level thing.

Andy: All right.

Mon-Chaio: Would you be able to guess what some of them were?

Andy: I’m going to say that the top things that they would have said you need to get better at are communication or something around communication. and

Probably something like emotional intelligence. Understanding how other people are feeling.

Mon-Chaio: Yeah, I think you nailed at least two of them. There were also things around. Rolling out processes and how do you know when to iterate on a process and whether it’s working, which I think is really important. That also has to do with communication. It has to do with what we talk about a lot, examining the system, taking a step back, examining the system, feeling out where things are working or not.

But yes, that emotional intelligence stuff, connecting with your direct reports, connecting with your team. Communication was a big one. How do I communicate effectively? And this gets back to that EngOS thing, which is both in EngOS as well as for the majority of this conference, none of those were topics in talks or roundtables or workshops that were presented.

Right? And so when you sit with a group and say, what is it that engineering leaders should be learning the most of? And then you’re looking at what engineering leaders are learning at this learning forum, symposium, it’s really a pretty stark contrast.

Andy: Do you think that that’s because, taking the EngOS as an example, do you think that that’s because they’re already really capable at everything that shows up in it? Or is it, and there might be a third option here. Or is it that EngOS is getting you to focus on things that are not the problem areas?

Mon-Chaio: I don’t know that I know the root cause. I think I know the symptoms, so I can kind of guess, right? Hypothesize maybe what the root causes are. I think the first thing is most eng leaders don’t know what they don’t know. I think we’ve talked about this before this isn’t my original idea. Somebody tuned me on to this concept of merit badges versus, I can’t remember what they call the other thing, skills, I’ll call them skills. And merit badges are the thing that you learn for three weeks and then you get a merit badge pinned to your vest, right?

And then you move on. Where skills are sort of this lifelong thing like if you’re cooking, knife skills, right? You never. stop learning knife skills and it continues to be more, more, more, more important.

Andy: Right. I

Mon-Chaio: And I think a lot of these conferences and a lot of leaders end up with merit badges. And I think these processes, what they call rituals, are simply merit badges.

Andy: we have entire industry based on that, the certification industry of Scrum and all the different Scrum certificates and other things along those lines. SAFE is the new one. And there’s training that goes along with it, but I think to your point, Mon Chaio, there’s like this idea that you do it for three weeks or four weeks or five weeks or whatever, and there you’re changed.

You’re modified. You’ve had the, you’ve, you’ve had that downloaded into your head and you wake up and you say, I know Kung Fu.

Mon-Chaio: right.

Andy: And you can just do it. And, and for the skills that really matter for a lot of these things it unfortunately doesn’t work that way. It takes practice and repetition and reflective reflective thought on what is it that you’re doing and how is it working.

And also admitting to yourself that, I didn’t do that as well as I think I could have.

Mon-Chaio: And practicing, right? You a big thing for you, Andy, you talk about practicing conversations. where you sit down and you have the same conversation over and over again with a peer or a mentor to practice that conversation. It’s the same thing on these skills. If you’re not practicing them and practicing them in a safe space, you can’t really get better.

And so to think, I mean, even what we’re doing right now, I’m going to download this conference to you. We have our learnings. But if we don’t have an action plan about, hey, every day how am I going to practice this thing a little bit, or every week how am I going to practice it? Honestly, in a couple weeks, it won’t have mattered that I went to this conference at all.

Andy: Yeah. Forget about it. It might sit around in your head, some of the concepts, but that’s about it.

Mon-Chaio: Yep,

Andy: All right. Well, that was a great recap Mon Chaio. Let’s try to close this up. What were your overall feelings from the conference? What, what are you speaking about what you’re left with and you should practice or anything like that?

What are you left with? What, what are you going to take away from this conference? And actually, I’ll make, I’ll make it even a harder question for you. And this, this is the question that I do at the end of study groups, and actually it’s a good question at the end of conference discussions as well. From what you’ve seen, from what you’ve heard and learned.

If you truly believed all of it, what would you change in your practice?

Mon-Chaio: If I truly believed everything at the conference, I think I would be implementing EngOS, right? I would grab Coda and sign up for EngOS to get access to all of these rituals that have templates and I would utilize as many of these rituals as I could in order to create the impact and culture that fuels these quote unquote successful companies.

Andy: All right. But that’s not what you actually believe, because I don’t think you believe everything you heard at the conference. So let’s go now to what you actually believe.

Mon-Chaio: The big thing that I learned from this conference was about what the value of a conference is.

Andy: unexpected turn,

but I’m

Mon-Chaio: yeah, and I, and I really think one, the value is the people that you network with. So many people that I actually talked to regardless of whether they thought the talks were good or bad. Almost all of them said, yeah, I’m not really here for the talks like they’re great.

But I’m really here for the, to talk to the other people. Right? The underground experience, the stuff that feels more real, honestly, than somebody on stage sanitizing something and they’re storytelling, right? So, they’re doing fictionalization and whatever, they’re using their ethos, pathos logos to convince you of the of what they’re telling you. But on the ground, it’s a little bit different. And if I were to go to another conference, or if I were to run my own conference, I think that would be the thing that I would focus on the most.

Andy: All right. Nice. And I agree with you about it’s outside of the The talks is the most interesting part. This is why I pretty much only go to one conference anymore, which is CITCON. It’s all open space, so it’s basically only that.

Mon-Chaio: Mm hmm.

Andy: decide what we’re talking about, we decide who we’re talking to and all of that. I just love it. I think it is the most useful way to learn. That’s not to say that set piece talks aren’t useful. They absolutely can be, but they’re a different value to me. And I would prefer the networking. All right, Mon Chaio. That was a very interesting recap. Thank you. I’m, I’m intrigued. And even though I just said that, I might consider going to one of these again.

Mon-Chaio: If they invite me back after this somewhat. I wouldn’t say scathing, but definitely not a glowingly positive review of their conference. I think there were good things. I met some great people. A lot of them, you know, really identified with some of the topics we talk about on the podcast, and that was really interesting to be able to actually talk in depth a little bit more, more than we usually get to do.

So yeah, I’d say it’s interesting. I’d probably go back.

Andy: Excellent. And just as a reminder, you don’t have to go to the talks. You can spend the entire time in what’s called the hallway track. Ha ha ha ha.

Mon-Chaio: And I did that for one of the talk slots. I think there were three talks and I was like, Eh, I’m done. I don’t think I want to attend any of the three. And I actually had a really interesting conversation with a gentleman around. He, his point was, he’s like, I’m at the university and this conference is grade school. He’s like, I’m running, you know, my budgets are in the hundreds of millions of dollars a quarter and my biggest problems are not being talked about at all in the conference. My feeling, actually, was that he, you know, was kind of in enterprise, enterprise, right? And he’s talking about how do I get the right vendors to do X or Y, but still very tactical.

But it was interesting, it was I would say that conversation was probably more useful than any of the three talks. Difficult to know, I didn’t go to the talks, but yeah, I did the hallway track for one one of the sessions.

Andy: Excellent. Alright. Let’s close this out. Thank you. If you have any conferences like this on leadership or related disciplines that you think that people should go to, well, share our podcast with them and let them know what conference people should go to. Share our podcast online, on Twitter, on LinkedIn, wherever, and tell people, hey, this was an interesting conference and I have these other ones that I think you should go to.

And tag us in those, because I’d be interested in knowing what they are as well. Or if you have any direct feedback to us, we are hosts at thettlpodcast. com. And Mon Chaio, until next time, be kind and stay curious.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *