Show Notes
Andy and Mon-Chaio give some background on their professional experiences and talk about how the TLL podcast is unique and why that’s a good thing.
Transcript
Mon-Chaio: Thank you for joining us for another episode. We realized last week that we’ve never actually told y’all why you should listen to us or who we are or anything. We just dove in to some interesting topics or like we said last time, at least interesting to us topics. So we thought we’d do a slightly different type of episode today.
Just talking about us a little bit who we are, our history, and maybe why we’re doing this podcast and why we think people should be listening. Does that sound about right, Andy?
Andy: Yeah, that sounds like that’s what I signed up for today.
Mon-Chaio: Fantastic. All right, so I guess I will start. My name is Mon Chalo. I went to school for computer science and biochemistry,
Started my career as a software engineer in bioinformatics, and since then have been in a number of different verticals.
I’ve done e-commerce, social networking, ads, platform healthcare among others, I’ve also worked at many different sizes of companies, from three person startups to the Metas, and Microsofts of the world. And of course, as an engineering leader, supported many different sizes of teams, from a really small team, just a few people to teams around 60, 80 to a hundred in organizations of a few thousand people.
I’m based out of the Seattle area and have been for quite a while, born and raised here. I’ll kick it over to Andy.
Andy: All right, Mancho. Going through a similar progression. I’ll say I’ve got a degree in computer science as a bachelor’s. I got a master’s in computer science as well from some German universities. Then I’ve worked as a software engineer at several different companies from e-commerce to I guess what’s now called FinTech, serving London Financial conglomerates, giant banks, and not working in the banks.
I’ll be very clear, I never worked in one of those banks and. Working on open source software from a commercial perspective, working as the lead developer on open source software. And engineering manager for also FinTech companies, finance data companies. overseeing teams between about five to 15 to 20 are the sizes that I’m used to in companies ranging in size from about a hundred up to about 5,000.
So a different range of experience. The companies I would name that I’ve worked at would not be the Ubers or Mades of the world. They would be names that very few people would know who they are. The Tim groups and ions of the world.
Mon-Chaio: I happen to know who they are just because we talk, but,
Andy: yes.
Mon-Chaio: think you’re right.
Andy: And yeah. Maybe we should then move into a bit of why we decided to do this. Man, cha. So why did you wanna make a podcast?
Mon-Chaio: I wanted to make a podcast because I feel like the state of not only leadership by which I mean engineering leaders that are out in the working world as well as the state of leadership, learning, and teaching is missing a little bit from my perspective, I’ve worked in many places and had a chance to interact, learn. Be managed by many different leaders, and I think that for the most part, most of those leaders I don’t feel like have a great stable foundation on which to base their leadership philosophy or leadership skills.
I think a lot of companies hire leaders, and when I’ve been doing interviews, I see this a lot. Or even if you’re not hiring leaders, you’ll see one come in. And how does a company present a leader that comes in, right? They say something like, oh, this person built up a 5,000 person org at Google and they successfully monetize X, Y, or Z, and they transformed this product or whatever.
And prior to that, they were at Microsoft where they led the transformation to x. That’s fine. But I think they’re using that as a proxy to say why you should trust this leader and the actions that this leader is going to perform. But I think that’s actually a poor proxy because I think we have small sample size problems creeping in here.
And I think everybody can think back to a company and think about. Where the context of the company the collaborators that a specific leader was working with you could attribute equal if not more impact those folks on the outcomes that the leader is claiming credit for than the leader themselves?
Perhaps not, but I think with small sample size and that sort of context I don’t think past performance is a great proxy. And so if past performance isn’t a great proxy, what is right? And in my opinion, it’s around the foundations on which you build your leadership practices. I felt that often when you talk to leaders, their foundations are really loose, really poor.
They’re often not founded in research or worse of all, they’re founded in poor research or poor understanding of research. And so then the question is, if a lot of leaders out in the space are this way, how do those folks get better? If you look at a lot of leadership training in the market, They also have the problem where they’re not really built on great foundations either.
Some of them are built very much on personal anecdotes, right? I just heard one where somebody was saying, oh I ran this experiment at one company with 10 people, and that’s informed my leadership philosophy for the last 10 years. Which, I think is okay, but to say that’s some sort of revelation.
Again, with that small sample size, I think is pretty poor. I thought that there was a real need for leadership training that was nuanced and grounded, at least somewhat in larger scale studies in scientific research, and I thought that perhaps I could help provide some perspective there.
Andy: Yeah, do some gleaning, do some reading take our own experiences, combine that together, and hopefully what we can come up with is what we believe is a much more grounded, reasoned approach that others can learn from. And leapfrog the ones who are just taking it as it comes.
We want to provide you the information that. It’s actually out there. And I think I have a similar way of thinking about this. For a while, I ran a little meetup in London where I. Oh, I didn’t mention. I’m in Lancaster, UK and I had lived in London for a while.
I lived in Seattle for a while and I lived in Germany for a while, so I’ve been all over the place. But for a while I ran a meetup in London to read research papers into software engineering because I felt. I often got these questions about why do TD or his pair programming really all that great and I thought, I think it is, but what does the research show?
And so I wanted to start reading those articles and see if there was a more rigorous basis that I could base my beliefs on. That’s what I want to do here as well. I have beliefs, so we need to also be aware of where our biases are.
Mon-Chaio: Mm-hmm.
Andy: But I want to test those against what others have found and how they think about it and the models that they put together in that.
They’ve tried to test. So sometimes I want us to dig really deep into research papers, which some people may find very dry.
But I want to do it because it helps us have a clearer understanding of how we think and what the world is. Even if sometimes that understanding is that’s not the way the world is, because that research method was flawed.
That’s why I wanted to do a podcast is I thought I enjoy talking about this stuff. I enjoy reading about these things. I want to share that with others cuz I think it could help them.
Mon-Chaio: And to be clear, I don’t think either of us, and I think you mentioned this a little bit, think that research papers are the end all, be all. In fact, there are papers that we’ve read where we’ve looked at each other and said, really that’s what,
Andy: They’re inconsistent definitions. They’ve contradicted themself. One of the reasons I stopped reading the research papers Wasn’t because I found them uninteresting. It’s because I had such a hard time finding research papers that I considered high enough quality to take anything from there’s a separate subject there, but basically software engineering researchers, you need to work with your psychology departments a bit more.
Mon-Chaio: Absolutely. I find that to be true as well. And often the study methods that you read about and they’re like they built some towers and that has some relationship to building software, Okay, so some Jenga towers and then translate that to software. So we’re certainly not saying that research papers are the end all, be all by any means, but I think they offer us a lens into something that’s more than my single person’s experience, or me and my buddy’s experience.
The other part is often we will talk about topics. I think perhaps our last topic was about this that aren’t grounded at research papers and so are mostly our experiences and our opinion. And to your point, Andy, there’s obviously gonna be a lot of biases there, but I think what we want to do in those is to really challenge each other and explore those biases and also look at the nuances around the topics.
I think so much of the time, if you’re talking about. Let’s say delegation, which is something we’ve touched on. The answers that you get from leadership training are too easy, quote unquote. It’s do these three things and you’ll be set where if you’ve listened to any of our other episodes, the nuances where the interesting interaction happens, and I think.
Mastering that nuance starts with having a conversation, challenging those biases and saying, okay, so you know, in the 20% case, or in the 40% case, maybe the easy answers work, but what do you do in that other 60% and how do you make it great and not just easy?
Andy: Yeah and given our desire to try to take everyone away from. This arguing from authority. I thought it was a little funny thinking about how we just started this episode, which is, let’s tell you our credentials.
Mon-Chaio: Exactly.
Andy: But I think we did a good thing. I think we said this is basically who we are.
We’re not gonna focus on that too much. We want you to judge us by subjects we talk about, the validity that they have and how much they help you to do your job better.
Mon-Chaio: Absolutely. And if you’ve listened to our past episodes, I think I would say never but maybe we slipped up once or twice. But I would say we never said, Hey, this is what you should do because, I worked at Tim Group or I worked at Meta and this is the way that Meta did it. Or, we were the most advanced organization, largest organization in the world, and so therefore our processes are better tested or whatever.
Rarely I think, will you ever hear us say that?
Andy: In fact, what you’ll more likely hear us do is be a little wishy-washy is we’re like, oh really? Maybe you could do it this way, but
I’m uncomfortable with that. So let’s talk about that discomfort and figure out what to do with that.
Mon-Chaio: And this is actually a marketing opportunity too. If you would like more concrete answers, you can pay us money. We’ll you more concrete answers.
Andy: I should say, You can do that. I am a consultant right now and I think Mancha would be very happy to start stepping into that.
Mon-Chaio: Speaking of consultancy I don’t really wanna focus much on your consultancy, but I did want to ask you, what is your philosophy on leadership? Or do you have a motto or do you have a statement on how as a leader you might be different than other engineering leaders?
Andy: I would say the way that I am a bit different is that I brand myself as the software anthropologist. And my take is that software engineering is very much a human endeavor. And to understand our teams, understand our organizations. We should take this very human-centered approach. Watching how people are interacting, watching how they behave, how they express themselves or don’t express themselves, which is also a form of expression. So the biggest thing in a lot of those things is how we hold conversations and how we think about the world. So I put a lot of effort into. How to hold a conversation, how to broach certain topics with people. And you’ll definitely have heard this in our last episode on metrics, which wasn’t really about metrics where I talked a lot about getting to the person’s feeling, getting to what they were hearing or needing that they weren’t getting.
So applying concepts like nonviolent communication. Chris Argyris’s mutual learning model and those kinds of things, , that’s where I come from. That’s my philosophy is that I should say, I do also have that degree in software engineering. So then I struggle with myself sometimes about this difference between just engineering and thinking about systems as components that are interacting and thinking about humans and the way that we exist in the world.
Mon-Chaio: That’s always, I think, gonna be a healthy balance, hopefully for engineering leaders. I don’t think I have as clean a vision on my style as you do.
I’ll go back to the tagline I use on LinkedIn, for example, is supporting people, scale teams, crafting cloud scale solutions or something like that.
Andy: I think you’re not quite clear on your thing is right there. Yeah,
but I like what you
Mon-Chaio: It’s been a while since I wrote it, so I’m not even sure exactly what it says. But I do have some similarities with what you said. I was an engineer first, right? And part of the reason I moved into ENG leadership was because I was interested in how the organization of people can or cannot make the same engineering problem be solved better.
Andy: Did you have a particular experience that kind of you would look back on and say, that sets you down that path?
Mon-Chaio: I don’t think it was a particular experience, but I do remember the feeling. The funny thing is often we’ll say people won’t remember what you say, but they’ll remember how you made them feel, right? So I do remember that feeling of, engineering problems were becoming easier and easier to solve.
This is not necessarily true. This is just the feeling that I had in the particular domain and the particular company I was working in where yes, there were still interesting problems to solve, but it felt like trying to get to customer value was more held back on how the people within the company interacted and the processes that we put into place and the way leadership interacted with us.
I’ve always been, Very interested in how things scale. And so I felt like that was limiting our ability to scale our impact. And so I moved into there and I think that’s also why I’ve started moving more out of the team scale into the org scale. For a long time I was very much into localized team impact.
Making your individual corner of the organization as best you can. Especially as I mentioned, you work for larger organizations. If you work for Microsoft, you’re not changing their comp model, right? You don’t have a voice into that. You’re certainly not changing how they interview engineers.
You don’t really have a voice into that, right? And so you try to make your local corner of your organization as best you can. And as I’ve done that through larger organizations, I’ve found that most orgs. Are constructed in such a way that it makes local optimization difficult. And so that’s gotten me to think more along the lines of how do we change the org structure or the org culture or the org philosophy in a way that allows teams on the ground to make the most impact that they can through a lot of these skills that you and I talk about on the podcast as well.
Andy: Interesting. so we should probably say a little bit about how we know each other because it goes back a ways how we know each other, and then there’s a long time in between. And so some of the stuff that we talk about, We diverged for a long time and I find it fascinating as we come back together, we kind of exchange these ideas, but we should probably tell people a little bit about how we even know each other.
Do you wanna kick that off?
Mon-Chaio: Yeah, absolutely. So, I met Andy at my second job, my second professional job. So I interned at a place while I was in school, and then I worked there for a year after school. And then I moved on and I met Andy at a company called Car Domain.
It was a very small team when we first met I think it was three engineers, and one of them was the dev lead slash engineering manager. And that was a small organization in the Seattle area. I was a pretty naive little software engineer back then. Obviously had just gotten outta school and was very much raised in the school is the authority.
And you’re taught. What you’re supposed to know and you memorize what your professors tell you. And so I thought, Hey, I know what’s there is to know in software development because I took CS 4 0 3 software engineering, and they told me that you have to write a spec, and you have to do your design documents, et cetera, et cetera.
Car domain was quite different and I slowly learned that it was Andy’s introduction. Of new ideas into that company that made it the way it was when I joined. So by the time I joined, that was a team that was already practicing things like T d D and pair programming.
And I have a funny story about pair programming at Car Domain which I may tell later. But it doesn’t really involve Andy, so I don’t know if it’s on topic here.
Andy: Go ahead. Go ahead. It, I think it’s a good story.
Mon-Chaio: Perhaps you should tell the story first about how you brought XP and T D D into that organization, and this was before I got there.
Andy: Oh, yeah. So I had done a small amount to pair programming a bit of T D D. Before I had this job, it’s something I’d been interested in for a long time. I’d done a little bit as an intern at another place and at Car Domain one day our engineering lead, we were discussing something and he, he was saying just I’m stuck.
I don’t know what to do anymore. And I suggested how about we just pair on it? He’s like, what’s that? I said well, we just both sit down at your computer and work through it. And it’s this whole idea of if code review is good, just code review all the time and you’ll get through things much faster.
And he’s like, sure, why not? Let’s try it. And we sat down and this thing that he’d been stuck on for probably a few days, we finished in a few minutes or an hour. And he was so ecstatic about this that he turned to me and he’s like, what are you working on? And I told him what it was. I was like, let’s pair on that.
And so we paired on that and we had that done in a couple hours and we were on a roll. And so we just started picking up task after task, and it was just going amazingly well. And then Mon-Chaio joined and it kept going amazingly well.
Mon-Chaio: And I think you also brought into. The organization, this concept of chunking up these monster specs that the I guess he would be the CPO at the time, right?
Andy: Mm.
Mon-Chaio: Or VP of product at the time. He’d write these like 30, 40 page specs. And you and Julie and the angel lead would be in charge of, or.
Started to say, Hey, why don’t we put these into phases and we’ll deliver phase one and see how you like it. Which hadn’t really been a thing. But yeah, when I joined the story about that is it was my first day at the company, and Julian, this tech lead said, Hey, for your first task.
We’re gonna have you put a banner on the homepage of our e-commerce site to say that we have different shipping hours during the holidays. And so I said understandable, right? And I know how to do that. I understand how to do Pearl. I understand how to do templates. I, this might not even touch the database.
I don’t even think so. It was really just a front end template type of work. So I slide over to my computer and in slides, Julian right next to me. And remember, he’s obviously an engineer, but he was also my boss. And so I look over at him and I say, what are you doing? He’s we’re gonna pair a program on this.
What does that mean? He’s like, oh, we’re gonna work on it together. And I asked him, so you’re gonna sit next to me and watch me while I type code? He’s like, yeah. He wasn’t as nuanced around the explanation of the benefits of pair programming at the time.
Andy: just obvious. Of course, he’s, that’s of course, he’s just gonna sit there and help you and he’ll be the navigator, you’ll be the driver. You might swap back and forth. You might have a long discussion about Vim versus emax.
Mon-Chaio: oh man, that man and his emax.
Andy: Oh my God, yes.
Mon-Chaio: But we also did not have any discussions about driver navigator at that time. It was very much one thing uh, Julian’s listening, he’ll recognize this. He’s very task focused. And so the task was to put this banner on the page and we weren’t gonna talk about driver navigator weren’t gonna talk about the benefits of code reviewing constantly.
He was just there and he was gonna watch me code and offer suggestions.
Andy: It’s just a practice that works. We’re doing it.
Mon-Chaio: We’re doing it right. And obviously as a first timer I was appalled. But very quickly I would say, if not within the week, within the first couple of weeks, I really did see the benefit of this. And, off we went, right? So that’s a little bit about our first interactions and how we know each other.
But Andy, you left Card Maine, 2005, 2006.
Andy: Yeah.
Mon-Chaio: To go to school in Germany, if I remember. And so that was actually the last time that we materially worked together. We would talk and on, but up until we did this podcast, it wouldn’t be more than once every few years probably. And so since then, as you’ve heard, our experiences have diverged quite a bit and I do agree with Andy.
It’s very interesting how. We still think a lot the same way probably from our grounding of our time in car domain. But our experiences have taken those thinkings and we now apply them in different ways which I think is fascinating.
Andy: I do too. Every time we have the discussions I look forward to it and I think, oh man. This is gonna be interesting. When you select a new paper and you send it over, I think this is different. This is not what I would’ve selected, which is amazing. It’s great cuz I get to see stuff that I would not normally have picked up.
Mon-Chaio: I feel the same thing also when you select a paper and what’s funny is when we read it and we come back and we’re like, Hey, here’s what we took from it. Oftentimes it’s completely different topics and so sometimes as we preuss we’ll say, oh this will be an interesting.
Thing to discuss because, we’ll have disagreements and we’ll be challenging each other, but then often it comes back to a lot of agreement anyway, which yeah. I don’t know how that works, but it’s still fascinating for me.
Andy: I think what we generally do so a little background of what we do for the podcast is we select something to discuss, generally select a paper or an article or something to ground it. We both read that, and then we have a about an hour long discussion. We schedule ourselves for an hour and usually go about an hour and a half an hour long discussion where we make sure that we somewhat agree on what we’re talking about.
those are in some ways the most fascinating. We don’t record them. Maybe we should record them and offer them as some sort of side thing. If you wanna hear us just rambling and arguing with each other we get this. And then usually the outcome of that is, We might disagree on some small details, but when we start going down to, but what is the actual concept here?
We say yeah, I agree with you on that. That is important. That is right. That is the way we should approach this. Just some of the small implications we’re like, no, it’s not. That’s not what I think it means. And so when we then do the full episode, it sounds like we’re in complete agreement because we had that discussion and found where we do agree.
Which is usually about 90% of the entire concept.
Mon-Chaio: And often, even during the full episodes, we’ll say I disagree and. One of us will say, no, actually you agree and this is why we’re like, oh yeah, it’s just it’s a matter of scale, but we agree on different scales or we were using the wrong words or we didn’t use the words that we thought we used or what we meant, things like that.
But yeah.
Andy: Nice. We wanted this episode to be one where we introduce ourselves and give a little background so that you can listen to not only our thoughts, but you can now feel compelled by our authority if that’s important to you.
Mon-Chaio: Or lack of
Andy: or lack of authority, you might say, oh man, that Andy guy, he’s only ever worked at companies up to 5,000.
What the hell? Any closing remarks? Mon-Chaio you wanna make?
Mon-Chaio: I would just leave a pitch about why people should listen to us. I think we’re unique. In the podcasting world, especially around software leadership and ENG management. If you go to our Spotify page and you can click on more like this, it currently says nothing found.
Andy: Yeah, I thought that was fascinating when we started doing this. It’s like there’s, we’re not finding anything quite like this, we hope it’s a niche that has been unfulfilled.
Mon-Chaio: right. And more than anything else, we just hope that. We can spur you to open up your mind to other thoughts and other ideas and make them your own right. What we say might not be right but we do think that not enough people think about these topics on a regular basis.
And we’re hoping that this will seed some of that thinking.
Andy: What I want out of this is just that people think about these issues and that new engineering leaders and engineering managers have a resource that they can listen to and feel like they’re getting coached on what to do because. When I first started, I didn’t get much of that, and when I finally did get some, it was a breath of fresh air and I suddenly had this sense of, I have some confidence in what I’m doing and I’m hoping that I can bring that to people to.
Mon-Chaio: Great sentiment. All right. Join us next time for, back to our regularly scheduled programming. Till then,
Leave a Reply