Dion Beetson, Author of Leading Software Teams with Context, Not Control

Len: Hi I'm Len Epp from Leanpub, and on this episode of the Frontmatter podcast I'll be interviewing Dion Beetson.

Based in Sydney, Dion is a software engineering team leader with over twenty years experience in the industry. He has worked for and led teams at big companies from NewsCorp to William Hill and Yahoo, and he is currently Head of Software Engineering for MNF Group, a cloud communications software and service provider based in Australia and New Zealand.

You can follow him on Twitter @dionbeetson and check out his website at dionbeetson.com, and his blog at blog.dionbeetson.com//.

Dion is the author of the Leanpub book Leading software teams with context, not control: Effective practices for creating alignment and engagement within software teams. In the book, Dion aims to help software engineering team leaders learn reusable practices that can help with team effectiveness and alignment, and achieve greater efficiency in their leadership roles.

In this interview, we’re going to talk about Dion's background and career, professional interests, his book, and at the end we'll talk about his experience as a self-published book author.

So, thank you Dion for being on the Leanpub Frontmatter Podcast.

Dion: Thanks for having me.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you first became interested in computers and programming?

Dion: Well, I started my development, I guess, habit or hobby, back in Perth, maybe 20 years ago, sort of at the end of high school. I wasn't one of those people that was coding at the age of seven or eight. That still impresses me when I hear those stories. I followed that sort of, I guess you'd call it typical, boring career progression, that some people might call - but it wasn't boring for me.

What I mean by that is - I started as a developer over in Perth, into a senior developer. I moved into a lead engineer role when I came to Sydney, and then moved into engineering manager, head of engineering in Sydney, where I'm based at the moment. I said it's boring, because it's sort of the one career path you would typically follow say 15 or so years ago. And if you look at the tech industry these days, there's so many different career paths that you can follow as a software developer - whether you want to stay in a technical track, or the people management track. But in saying that, I've got no regrets. I do enjoy it.

I guess the reason I enjoy it is because, like probably a lot of developers - you work on all these platforms as you go through your career in different companies, and sort of outside of your control, is the life of those platforms. Whether it's through acquisitions, through changing in business priorities that platforms get shut down, or if they're done and decommissioned. It's mostly out of the control of the people that are on those teams. And it's a little bit frustrating, a bit sad at the same time. All this - many years and years of work that I would put into it all, people on my team would put into it - all of a sudden for it to disappear.

That's sort of what got me into the leadership space, where I was trying to find a way to do something that would live on past decisions that were outside of my control. That's why I say that going into management and leadership for me, wasn't boring. Because it was a way for me to try to build cultures within teams around how teams learn and how they're engaged and motivated. Because then if the platforms were shut down or they moved into different organizations - hopefully they learned something, picked up something that they could carry across into their own career, for many years to come.

So, that's sort of where I'm at - based in Sydney at the moment, working at a company called - you actually pronounced it correctly, which is surprising - because most people can't, MNF Group. It's very hard to say.

Len: What do most people say?

Dion: Like NMF Group, it's like -

Len: Oh, okay.

Dion: It's like, doesn't really pass the pub test sometimes, it's hard to pronounce. But yeah, we're a telecommunication provider. First time I've been in telco. I definitely try to jump into a different industry for every job I move into. It's a bit stressful sometimes, because you've got to learn everything from scratch. But obviously there's skills you've had previous to that, that sort of carry across.

Telecommunications is interesting. Probably one of the most technical fields I've been into. I'm y no means an expert. Long way to go. But it's definitely keeping me on my toes, to try and understand both the tech - and obviously lead the team that we've got over here, which is based in Sydney, Melbourne, and a small team just over in Manila - about 15 people in Manila.

Len: Thanks very much for sharing that. You mentioned career paths, and there are many different career paths people can take, in software engineering. One of the questions that I always like to ask people who are working in this space is, if you were starting out now - and people who did a Computer Science degree like you did - if you were starting out now with the intention of having the career you've got, would you do a full Computer Science degree, or would you start out just learning on your own? Given that -

Dion: Good question.

Len: Given all the tools and stuff that are available now that just weren't available -

Dion: There's so many things out there.

Len: 20 years ago.

Dion: Yeah, you can pretty much learn anything you want online now, which is amazing - if you've got the motivation. Well, secretly - so, I finished high school and went straight to university, but secretly I actually really just didn't enjoy university. I thought it'd be amazing. I could do what I wanted to do. Learn computer programming. But when I got there, I was like, "This is just like an extension of school." And I didn't really enjoy it.

So after about six months, I decided to - well, maybe about a year, actually - I decided to go and grab a full time job in programming. Because I'd been doing programming on the side for about two years, and studied university part time. I had a supportive mom who said, "Just finish uni, Dion, just finish it." So I did that part time. It took about six or seven years in the end, so it took a lot longer. But I managed to work, and that's where - I don't know if you agree, but that's where you sort of learn the most amount of things.

I know I learned in the first say five years, six years of work - compared to six years of study, was just incomparable. I just learned - I was leaps and bounds ahead of what I learned. So I guess I really sort of leaped or jump started my career, being able to get all those many years of experience while studying.

But I guess - would I do it again? It's a good question.

I went back and did a post grad a while later, and I sort of loved it, because I was the youngest person in the class, and everyone else was about 40, 50 years old - and I was just sitting there, just absorbing all the information from everyone. So I enjoyed that a lot more.

But an undergrad wasn't the most exciting. So I would probably do it again. Maybe what I would do differently next time, is - I would definitely stay in the career, stay in what I've done.

I would definitely travel overseas and work overseas earlier. Or maybe I didn't do it, but I moved to Sydney - that was my extent, and that was a great move. I've enjoyed it, loved the city. But I would definitely go get some experience in - whether that's over in the west coast or east coast of the US, or maybe over in London somewhere. But I think that would've probably helped me a bit more. It seems to - you get some amazing companies over there, with some amazing scale, that is hard to get in Australia. It's getting a little bit better, but will never be at that level of - as those sort of countries.

I would probably try to stick through my degree, mainly because it was a personal challenge. I mean, every now and then you look back and you go, "Oh, I remember learning about this very high level thing back in the day," and it sort of does come back. I think database normalization was something that springs to mind. I was like, "Oh, I remember learning about that." Still, I had to go back to the books.

But you're right, there's so many things online that you can basically learn for free. It's unbelievable. Or learn at a very low cost, rather, with a $30/$40 monthly subscription. And you can learn far more than what I believe a degree will offer you. Obviously I'm a bit biased there.

Len: No, no - thanks very much for sharing that. And I really like to hear about people who have strong opinions about things. I actually didn't know that you worked while you were studying for your undergraduate degree. With regards to whether I agree - my position, I studied English - I'm Leanpub's resident non-programmer. So although I do some programming and stuff like that, I didn't go to university with the intention of like getting trained for a job, and it ended up working out great. I became an investment banker after getting a doctorate in English literature. But I can say like, the kinds of things you learn when you're doing a job are different than the kinds of things that you learn when you're studying something formally at university - they're just two very different things, in my opinion. And I mean, I've seen like our - I've worked with a lot of programmers over the years, and mostly what I've heard from people is they - whether they liked their university experience or not, they do talk about how actually working for a company is when they really learn.

Dion: Yeah, it's all the people you work with, right? It's all those different experiences that you get and all the problems that you find.

Len: Yeah.

Dion: Late at night when something goes wrong, the best ways to learn.

Len: Yeah. We've actually had the experience this summer. We hired a bunch of co-op students from the local Computer Science department.

Dion: Oh wow.

Len: And for some of them, it was their first job. So they've only ever worked remotely, because we're a remote team. And it was really interesting seeing people learn - not just how to do their tasks, but actually learn how to learn to do their tasks - all over Zoom. And using collaboration software and stuff like that. So it was a really interesting experience.

Dion: Yes.

Len: On that note, I wanted to ask you - so one thing that's come up - starting about six or seven months ago on the podcast, is - how has the pandemic affected you in your life and professionally, and what's the experience been like in the place where you live? I was wondering if you could just start by talking a little bit about what things have been like in Sydney in the last few months? Were there mandatory mask requirements? Did everything get shut down?

Dion: Yeah, it was a - I guess we - I'll say, in Australia - well minus Melbourne, potentially - we sort of escaped a lot of it, which is good. There was definitely a lockdown for a while in different cities, where you had to - well, but it wasn't as strict as other countries - but you sort of had to stay within your area, I guess your "suburb," we call it. Most people were - let’s say 80% of the population - that at least I'd seen, were wearing masks, which was good.

But it took us a little while to catch on. Probably took about two months. Probably around that sort of June, late June - sorry, late May, early June time frame - that it really started to set in. Supermarkets, all their - everything was selling off the shelves, which wasn't great. But we've actually - I guess if you compare the amount of casualties in Australia, versus elsewhere, we've been very fortunate. Probably because we're an island in the middle of nowhere, and they restricted overseas travel quite considerably. You can't even actually really travel between our states at the moment - or very easily, I should say. So we've been okay.

Most organizations have started to work remotely from about the April-May time frame. And we've been remote since, yeah - since about late March, I guess? If anyone had asked me, I would've said that by July, we'd all be back in the office, but I clearly would've lost that bet. Because I don't think there's any intention of going back until sometime early next year. And even that would be very casually-based.

We did a bit of a poll in our team. We've got about 100, or just a bit over 100 software developers across our company - and we did a poll about four weeks ago, to see how many people wanted to come back to the office. I would've expected maybe 50%, just over 50% would've wanted to come back - they've had enough. But it was about four people in the entire group, was like, "Yeah, I'll come back." And mostly that was just to escape a small apartment or something similar, just to get back into the office. But yeah, it's - and so we've been very fortunate. But yeah, I can sort of see us working remotely for quite some time.

But it's hard. Like - selfishly - for a second, it's hard. When you lead people, lead teams - it's a lot easier to do that in person. You can just walk around to people's desks, ask how they're going. Catch up, go for coffee if there's a problem. It's not as mentally exhausting.

But when you're on Zoom conferences, or - well, we use Microsoft Teams for video conferencing - when you're doing that all day - because as a manager, you're basically in meetings all the time. You're just in more of them. Or it feels like you're in more of them. Because you're constantly on video calls. And just a standard nine-to-five day, which doesn't really exist - but when it does exist, you're just - you're absolutely shattered. So for me, it's easier to manage in person - which is a silly excuse.

But I know for the team, they're loving the remote work and the flexibility around that. And the commutes in Sydney are pretty crazy. There's people that travel an hour and a half, two hours each way to get into the office. So for them to save that time, is - you can sort of see why people are just enjoying that extra time they get back in their life. Which adds up throughout the week.

Len: Thanks very much for sharing all that. That's really fascinating. I mean, particularly to hear about from the sort of like leadership side of things. Personally, I grew up having to bus to school. And it was like a 45 minute bus ride either way, for what was actually -

Dion: Wow.

Len: Only 10 minutes away. And I remember just like - at a young age, developing this acute awareness that I was just like wasting my time. And there were no phones, there were no smartphones or anything back then. Like you would just sit.

Dion: Not even the Nokias with the snake game on them?

Len: No, no - there was nothing.

Dion: I remember those.

Len: I was just sitting there with my brain racing and just feeling - and so anyway, my point is that my whole professional life, I've always related to commuting as just this calamity. And so that's one of the reasons I work on a remote team now. But it's, sort of - to me, it's not surprising at all, that most people - once they realize they can save all that time and even do, or use it to do more work - that they would find it attractive, at least in the short term.

And on that note - so part of the story of your book is that you actually have a new addition to your family.

Dion: I do.

Len: Has working from home been -? This is something that people have been writing and talking about a lot. Has working from home made that easier, or is it harder to get things done?

Dion: Well, it's our first kid or first baby. So I'm going to assume it's a bit easier. I know my boss, when I told him - he's like, "Oh, this is the best time to have a baby." He goes, "You can be at home, you can help out when you need to." So it's actually been pretty amazing, just to be able to sort of go from the - I normally just work in the front room and just jump into the living room and say hello to my wife and newborn and spend a bit of time with them throughout the day - which is actually pretty amazing, which I know a lot of people just generally can't do. So that's - yeah, that's a huge win.

But yeah, I don't know the opposite. I've seen friends that have come into the office every day after having a baby, and they look absolutely shattered. So I'm hoping I don't look that bad. I'm guessing it's a little bit easier. Yeah, pretty fortunate, I think on that perspective. Is that what other people are saying that you've been speaking to?

Len: Oh it's different for everybody. I mean, it depends on their circumstances. I think most people I've interviewed have reported enjoying being able to spend more time with their families and being able to take care of their kids. But I know there are some people - I think people with maybe more than one little kid, were having a really tough time - and particularly if they're young and school age, that's really -

Dion: Okay.

Len: It's just really heartbreaking. Because from what I hear, like a five year old can't learn anything online. And also, a lot of people that I've talked to - or some people I've talked to - have like kind of woken up to something that maybe was obvious to other people. But that - like, kindergarten and grade one and grade two aren't really about learning learning things. Although you do, and it's an important part of the day. But it's kind of like having the kid be active and engaging with other people and doing things.

Dion: Yeah, that social interaction.

Len: Yeah. And looking at screens just doesn't cut it.

Dion: No, not at all.

Len: I think a lot of people have reported it's heartbreaking - they just don't know what to do. So yeah, it's -

Dion: Yeah, a tough situation.

Len: And different places are managing it differently. So it's very - things can change day to day, and can be very confusing. And like one of the things, just to - not to go on about it - but particularly with young kids who are - it's their first encounter with reality, right?

Dion: Yeah.

Len: And that encounter is people wearing masks and getting out of the way to avoid you.

Dion: Yeah. They wouldn't know what to expect, would they?

Len: That's a strange way to be introduced to human society.

Dion: Yeah, it really is.

Len: So yeah, it's going to be - I mean, pandemics have come and gone in the world before, and humanity has endured.

Dion: Yeah.

Len: But it's going to be -

Dion: So strange to be in it, isn't it?

Len: Yeah, it's got to stick with you.

Dion: Surreal.

Len: Speaking of changes - there's a segue for you - so you moved from Perth to Sydney, and you ended up in leadership roles. I think you write in your book, or at least on your blog about how there was a kind of a two-stage transition for you - from being an engineer to being a team leader. And I was wondering if you could talk a little bit about how that happened for you?

Dion: Yeah. I guess it was semi-natural. But the way I sort of broke it in - it was in the book actually - around how and why I jumped into leadership.

It's an entire career change. I think there's been some amazing articles and recognition about that from other leaders in the tech space - and I'm guessing, even outside of tech, saying that you can't just jump into a leadership role and expect to be good at it. You're actually terrible at it when you start. And a lot of people are thrown into the deep end.

But for me, the first step - the first stage was sort of when I had moved into more of a - like a lead engineer or a team leader role, I should call it. It's a little bit different in every company. And it was when you are still hands on coding, but you're leading a team, normally a small team, maybe four or five people. And because you're still hands-on, you still have that option of moving back into a fully individual contributor role - so coding again, if you feel like the leadership role isn't something you actually want to continue on in your career. That gives you a bit of peace of mind, a bit of a backup plan.

That was the first phase when I did that. And I started to enjoy it. I started to realize that you can be involved in more. You can actually have a - well, hopefully, a positive effect on - or impact - on people within your team.

Obviously looking back, I feel like I wasn't the greatest manager back then. I wasn't terrible, wasn't the greatest. You learn a lot by your experiences. So that was the first phase.

And then, the second phase was over a few different companies. I think it was about two or three different companies, over a few years. When I was over in Sydney, actually. And it's when I started to step into a role - a leadership role, where I was leading multiple teams - and it was when you basically turn into a manager that isn't doing any hands-on coding in their role. You're sort of stepping away from that. And for quite some time, I was definitely coding at home, and I still am actually - coding at home, just to stay up to date. But you are more involved in more of the architectural side of things, and trying to find ways to make teams more effective and engaged.

For me, that's a big jump. I feel like a lot of people who go through that would feel a similar thing, where you sort of have to make that decision, if you commit down that pathway, or not commit. Because you can't do both. You'll burn yourself out. You'll do a poor job at both if you try to keep control of both the code and the people side.

But at the same time, when you make that jump, you can't exactly go, "Oh, it's not working," and then jump back into a coding role. Because trying to go through a coding interview at an organization, they're not easy. Most tech companies put people through pretty challenging technical interviews. And it'd be very hard to jump back into that.

So it was a bit of a leap of faith. Fortunately for me, because I've done it, I did over quite a few years - it was a gradual transition. I was pretty confident that it would be something that I would enjoy and hopefully be decent at. So it worked out for me.

And I feel like - yeah, definitely working on side projects - off to the side, at home, at night - it's definitely helped me make sure that I get my outlet of coding. Because for me, coding is extremely relaxing. I can just put the headphones on and hack away at a few things at night when I've got the time - a bit less time now. And it relaxes me, actually.

Len: And what have you found to be the biggest challenge? I mean, you mentioned that being in person is actually a really important thing for you and your leadership style. But what has been the biggest challenge that you've faced in going remote with your team, if you can think of a specific thing? Is it getting everybody together? Having successful one-on-ones?

Dion: Yeah, a few things. One-on-ones are harder in my mind. Because one-on-ones, for me - are always a very kind of casual thing, a casual encounter. It's a time where you and the individual get to - we, literally - just about every single one-on-one, we would be outside at a coffee shop. I do like a bit of coffee or a tea. Just catching up on any topic that they find relevant, or I find relevant. And it's far more of a casual interaction when you're actually outside those meeting rooms or the office walls, even though our office is actually okay. It's not a Google, but it's an okay office. It's easier outside the office.

So for me, definitely one-on-ones are harder. We actually try now to catch up with someone - because I don't live too far from the city, and a few of us are in - my team - are maybe within about 15-20 minute drive, so we do try once a week to catch up with someone in person, and at least do one of our catchups in person. Which is really nice, it's amazing. Because like a lot of people don't see other people, so it's good to see someone that's not on a flat screen. So that has helped.

We've actually been relatively okay in regards to like team meetings and running a technical solutioning meeting, or a retrospective. Those, we were doing them with online tooling before the pandemic. So there's a lot of great tools out there that I know a lot of companies use. But yeah, definitely making use of the Atlassian suite and - well, even Trello's part of them now. A few teams are jumping onto the Miro bandwagon, which I've just started to use a little bit of now. I was a bit behind the curve on that. So they think the tooling's alright.

But probably the biggest challenge that I would see, is - when you're trying to create - I spoke about it in my book, but I'll relate it - it's harder working remotely. Well, it's harder working remotely for a company that wasn't entirely remote to begin with, like some organizations. It's like - creating alignment on key decisions. And what I mean by that, is if you're wanting to go off and -

Actually, here's an example. We're talking right now around - MNF's grown from, by acquisition - so we've acquired different companies throughout the years. And because of that, you end up with four, five, six different platforms that are actually doing very similar things. It's very hard to deprecate platforms in technology. Sometimes it's cheaper letting it go. It doesn't help the mental state.

But one of the challenges we're trying to fight now, is - how do we align our payment implementations across all of our systems, and how do we architect a solution to do that? And then how do we actually get four different teams on board with that solution, while getting another team to build one of those core set of services for that capability?

Normally to do that, you could have a quick whiteboarding session with a few of the team members in person. Brainstorm a bit, come back in a week or two once everyone's had an idea to understand the context and come with some ideas. But doing it remotely, you've got to have quite a few well-structured, well-planned-out meetings. So when people come onto a Zoom meeting, they've understood the context upfront, they can come with ideas, we can have some debates about it - and we can go off for a week or two and think about it and come back and actually make some decisions.

I find like some of those key technical decision making's take a bit longer than they normally would. I definitely feel like we could get better at it. Because I look at other organizations that do this - that have been doing this for a while, and they're a lot more efficient than we are at that. So it's an area for improvement, but it's just harder. It's not simple for me. But, you might be able to share me a few tips, because you said Leanpub's entirely a remote organization.

Len: I could talk about that forever. But actually, one thing I did want to talk to you about, and I can share some experiences of my own about this. But you write - at least on your managerreadme.com page that you direct people from various places, and that trust is really important to you as a leader. And what that involves is obviously expecting people to trust you.

But the way I saw - or the way I read it when I read your page, was that trusting someone out of the gate is actually a really great shortcut if they're a trustworthy person. And I don't think you said this, but - if they're not trustworthy, then you're fucked anyway. So you might as well trust them.

Dion: Sure.

Len: And I was wondering if - working remotely, if you've like - particularly for someone like you for whom trust is so important, explicitly important - has working remotely affected that? Have you found yourself doubting people in ways that you wouldn't have if you were working together in the same physical space?

Dion: Actually I love that you called that out. Because there's a few - everyone has a different mindset, right? Some people come into a new relationship trusting by the flow, which is - as I said in my Manager Readme, it's something that I do. And some people come in a bit cautious, and they actually want someone to earn their trust. And there's no right or wrong way - everyone takes their own approach. But you determine trust, even if you're going - if you're interviewing someone, doesn't matter which side. I determine trust by -

You can read a lot from people's minds - or people's faces, I should say. And their expressions. And that is a lot easier to do in person. One of the things that we do in our organization is - whether it's for interview or even one on ones - unless the internet goes terribly slow for a moment, we all do our videos with videos on, our video conferences on.

We even had a meeting, actually a rather big meeting, between a bunch of different leaders across our group - it was probably an expensive meeting, but it needed to happen. It was around some pretty important topics. And the one rule for that meeting - it was about three or four weeks ago - is like just, "Everyone leave your videos on. If you've got to go away and do something else, turn it off. But when you actually have something to say, turn your video on." Because the way you express something, people can read a lot into that, and it allows people to help get them on the same page. So that's something that we're doing.

But you're right. It's very easy remotely, I've found - even find myself - when you're having conversations over chat or even emails, it's very easy to read into someone's tone accidentally or incorrectly. Happens all the time. And I've got a few people on my team actually that are really good at just giving me or other people very quick little two, three minute video conferences, just to quickly chat about it. Rather than responding back on email, because - yeah, text is hard to understand tone. Which I think a lot of people would agree with.

But it's actually easier to keep communicating that way, right? It actually takes someone a bit of effort to jump in and actually click a video call - to call someone, to chat to them for a few minutes. Because it's - well, I'll say it's a little bit unnatural. It's very natural to go to someone's desk and just say, "Well, did you actually mean this? Did I interpret it right?"

But I definitely find you've got to keep continually checking yourself, if you actually are - if you're reading it right. Is this the right medium to have that specific conversation? Because, yeah - I would say that the video conference is the next best thing to meeting someone in person. Emails aren't the greatest.

I was actually reading the book at the moment, or just finished reading a book that actually talked a bit about it - Radical Candor, which has been recommended to me by a fair few people. Kim Scott, I think, is the author. I'm very bad with author names, by the way. But yeah, she was definitely talking about that as well. Around just - email is literally the worst, can be one of the worst mediums to have any conversation other than like scheduling meetings or sharing some context, just due to the fact that people interpret them in very different ways. So, but yeah - easier said than done though, isn't it?

Len: It is. And it's really fascinating. Because there's another side to it, which is that a lot of people don't present very kind of well in stressful contexts.

Dion: Yeah, they don't.

Len: And so, for example - the kind of person - and I totally identify with this - who doesn't know how to dress well. The office was always a bit of a challenge that way, right? I had to do extra thinking, and I always knew I'd kind of like - the best I'd ever be is average, as it were. And so there can be a lot of people for whom not being in that context is actually - helps them be a lot more productive.

Dion: Yeah.

Len: And work more effectively. And actually be better understood by their colleagues. But for other people, yeah - it's an exact opposite. It's like, I can't get a sense from you of what you're into. And I mean - at Leanpub, we give people a lot of rope. It's kind of like, "Here's your list of tasks." And just to be specific about it, more or less in our culture, when someone - we actually do do video calls, like kind of tapping on the shoulder. And that's the way we want people to think of it. So my colleague Peter will just like start a Zoom call with me in Slack. And when I see it, I'll either just click it and join - and he might not even be in the room. And he'll come back and be like, "Oh yeah, hey. I just wanted to talk to you about this." And basically we interact kind of when you need to.

The one thing that kind of - and Peter does most of the managing of our programmers and stuff like that - but the one thing that kind of concerned me was that - if you're older and professional and you've been around the block a few times, you can kind of get that. Whereas if you're young and it's your first job, you might think, "Oh my God, the boss just put a link, I'd better answer it as quickly as possible." And so getting people to trust us, that we're not going to be cracking the whip at them or something like that - that's not what we're doing when we're trying to catch up.

Dion: And interested, right? How they're going.

Len: Yeah, exactly. It's been an interesting challenge. And yeah, as you say - being in person can really help get a sense of how a person's feeling and stuff like that, in ways that you can't necessarily do on video calls.

Dion: Very hard to.

Len: Yeah. Speaking of books - moving onto the next part of the interview. You've written a great book called Leading software teams with context, not control I was wondering if you could talk a little bit about what your motivation was to write the book?

Dion: Yeah, of course. Many years ago, I had a friend actually who - a very good friend who's very technically minded, and wanted to write a book with me. I was telling him how hard it would be. I stuck with it for about two months, and in the end I was like, "Actually, it's not the right time in my career to do this." He ended up going off and finishing it and writing that book, which is impressive. So it's always been in the back of my mind to write a book sometime later in my career. But I just didn't know when.

When I moved into more of the leadership roles, I sort of found myself doing - you do lots of repetitive tasks. You try to do them a little bit different each time, to keep them interesting and to learn. But because - whether they're one-on-ones, team meetings, road mapping etc. - even going through that process, it takes quite a lot of mental energy.

Well, it does for me. And I was like - when I was a developer, I used to have all these libraries or frameworks or my own bits of code that I could definitely take from project to project - to really like fast track an initiative I was working on. But for management or leadership, I didn't necessarily have that. So it was taking me a lot of time.

So I started off with the idea of, "Why don't I write a little bit - like a 10 part, 12 part blog series on things that I do, so I can use it as like a cheat sheet for how I lead teams?" I wouldn't do everything by the book every time, but it would be a way for me to sort of fast track getting back up to speed on something that I needed to do, maybe once a year, or even once every few weeks.

But as I started to write this out, flesh this out a bit - it evolved. And I was like, "Oh well, I may as well just write a book, right? How hard can it be?" I knew it would be hard.

So anyway - as you said, as you touched on before - I've written a blog post about how I wrote my book. But I started to have more than 10 topics that I wanted to write about. I ended up having about 40 different topics, then I culled that down to about 20, 22 topics - or 23 topics or chapters in the end.

I basically wrote the book so that I could put down on paper, or digital paper, all the things that I do when leading a team - or leading individuals, specifically in the software engineering space.

It was essentially a reference point. So I could go back and look, I had different exercises in there that I would follow when I - like, as I said - run a team meeting or try to define goals or collaborate on goals, or write position descriptions or run interviews. I've got different exercises and processes that I follow, that I can just reference back and take bits and pieces from. Just to, generally - just selfishly, make my life a bit easier. But at the same time, share it around the community - see who else is leading teams, and who can maybe take a little 2% here and there from the book, and use that within their role when they're leading teams.

Len: It's a really fascinating description, which you touched on a little bit earlier, of - your motivation is, in part, with respect to re-usability - it's kind of moving, right? Because you had the experience of working on products that get cancelled. You might have been working on them for a very long time, and all that work just kind of feels like it went out the window. Whereas you were talking about before - a number of companies can get acquired by a bigger fish, and then become redundant, and one or two might fall away.

But you realize that there is something that can persist, which is what you've learned, and what you've taught, and the culture that you've created on the teams. I found that actually kind of moving. Because - you can get caught up in the sort of moment-to-moment, and maybe not even lose like never have any sight of the bigger picture of what's really going on. And that you're going to have a career that's going to go other places, and you should be keeping in mind right now what you're developing in yourself that will help you develop in the future.

And you talk about - it's in there in the title of the book, about focusing on context rather than control as a way of developing this kind of team culture and attitude within people. I was wondering if you could talk a little bit about that, and why it's the opposite of a command and control kind of approach?

Dion: Yeah, of course. I'll start with - so I didn't create that term. It's definitely something that I've heard over the last few years, four or five years in the industry. And Netflix is one of the companies that talks about it. I think it's in their employee handbook. But it resonated with me when I heard it. Because I was like, "Well this is actually how I'm trying my best to run teams."

And what it means, essentially, is that - you should spend a lot of your time trying to provide context for a problem, all the boundaries that you are aware of with the problem, and then let the teams go off and try and solution a problem to that.

The reason for that is, it pushes the decision-making down to the team level. And the more decisions that a team can make, the more effective they're going to be. It is a key ingredient, in my opinion, in building high performing teams.

But what made it even more important for me as I progressed throughout my career in leading different sized teams, is that - as you're leading one team, you've sort of got the mental head space to - you can lead in this way, you've got the mental head space to understand all the architecture, every bit of the code of the platform, all the team members really easily.

But as you start to lead more teams - like two teams, ten teams, team of teams - you need a different strategy. You physically can't do that. You will do a really bad job, and you'll burn out. You just can't do it.

So by following this context, not control - or context over control, as it might be termed as well out there on the internet - it allows you as a leader to invest your time - as I said, in the context and the boundaries. You're sort of contributing that 10%, and the teams are working on that 90%. They're doing 90%, which - as I said, encourages ownership. But because you're only doing 10%, and there's guiding and pulse-checking throughout the course of a project or initiative - you can then spread yourself across many other projects, many other teams - because you're not as heavily involved.

It's a really good way of stepping back, but ensuring that there is a level of context and a level of boundaries that are understood by the teams. They don't go off in entirely the wrong direction. So it's really helped me maintain my level of sanity.

But it's also - I believe, helped the people I've worked with. Because they can all step up and take a much more bigger level of ownership than they would have, if I was trying to be involved in every single aspect of their role and what they do. Which - in all honesty, they would do it far better than I could have - if you just give them the opportunity to do so.

I really think that is not just a software engineering industry thing. I think it's definitely something that can resonate across any single - or just about any single industry out there, that's revolving around leadership.

Len: Thanks for that great explanation, and for talking about the origins of the context versus control kind of idea. I find it really interesting. Because the sort of - the crudest way of putting the bad case for the command and control style is - that if all someone has been trained to do is react and obey, then it's not just that they won't be able to - in your context, they'll never be able to make decisions themselves. And this is actually one of the reasons that command and control is just so fundamentally inefficient.

Dion: Yeah.

Len: People who adopt the kind of command and control mentality often think that they're being more efficient by being harder on people, and getting them to obey the boss. But actually they're - in my opinion, that kind of thing actually involves an incredible amount of wasted time and inefficiency and failure.

Dion: And even when those leaders who follow that command strategy, when they move on - like all of a sudden, the team just is in dismay, right? They just can't function. Whereas if you can leave and they - or you know what they're doing and they can keep themselves going - that is your job done pretty well.

Len: Yeah. One of the genres of article that I love to hate read nowadays is the kind of person who's like, "But if people aren't in the office and I can't see them, how do I know they're going to work?" And it's like, "Wow, you must suck to work for if -"

Dion: I know.

Len: If you won't work unless you're beating them into a -

Dion: Crazy, isn't it?

Len: And then - not to go on about it, but the funny thing to me about it is that - people who do that adopt the affect, like internally - they really feel like they're being a hard-charging manager. And it's like, "You're a mess. Why are you hiring people who won't work unless--"

Dion: It's just a vicious cycle, isn't it?

Len: "They feel like they're being punished. Like what are you -?"

Dion: Yeah.

Len: Anyway, not to go on about that.

Dion: I had a friend that I caught up with over coffee, just a month or so back. And, yeah - that person's not in technology. He said, "How are you managing people remotely? How do you know that they're doing their job?" And I was like, "Well, there's specific things that they're trying to achieve every sprint, if they're working in say two week sprints - as an example. As long as they're achieving that or, and progressing in those goals - that's all you need."

It doesn't matter if they can do that in two hours or 40, 50 hours. If they're getting that done, that is ultimately a great outcome, right? Now, if they're doing the two hours, maybe we should find them some more challenging work for them to work on? But in saying that, it goes back to trust, that we spoke about before, right? You've got to trust people. And usually you pick it up quickly, and hopefully course-correct. But yeah, it's far more efficient doing that than it is, as you say, whiffing the stick as manager.

Len: One thing - when it comes to sort of the practicality of creating a context, or setting a context, you talk at the beginning of the book about "baselining" a software team. I was wondering if you could just talk a little bit about what baselining is, and at what stage that happens in the process of leading a project?

Dion: Baselining a software engineering team - that's the first chapter in the book. Because it's mistakes - "I've made this mistake in the past, and well, you should always learn from your mistakes." It's very easy for a new person, a new leader, to come into an organization and just look at what's going on really quickly, and then start to make rather significant strategic decisions, whether that's projects that they should invest time in, or types of roles that they should fill.

And that is extremely dangerous. I say that from experience. Because if you do that, you're making decisions that will ultimately impact the organization in three, six, 24 months’ time. But if you've based that on the wrong foundations - as I said, it's a very expensive to undo.

So for me, it is a necessity. It's a non-negotiable actually, to invest a significant portion of your time - whether you're stepping up into a new role in the same organization, or moving into an existing role - to invest time to understand the current state of that team, and from a software perspective or software team perspective - understand how the teams function. How they're delivering code into production. Their testing practices. How they - different design patterns that they use. What their after-hours support looks like. Do they even have after hours support, etc.?

So understanding all the things. I gave in the book, essentially, a list of different measures that you could take into account - both technical and cultural - that you could use as the baseline, and you can obviously include your own - I think every team can use a subset of those, and obviously add specifics that makes sense for their organization. But once you've got that - it leads onto all the different things that allow you to move from where you currently are, into your target state.

This baseline allows you to start to talk about goal setting, road mapping, creating an aspirational target state for that team to reach in many years’ time. It is really the foundation for that.

And as I said, if you don't do that at the start - yeah, you can find yourself as a leader making decisions that you will probably realize in six or twelve months’ time, that it they weren't necessarily the right decisions to make.

Len: Right, right. It's really important to know where you are in order to know where you want to go, and how you want to get there.

So, we've talked at a very high level about these things, and I just want to make it clear that in the book - although there is a lot of high level stuff going on - there's a lot of very practical, discrete advice about how to do various things. There's a chapter on effective software team metrics, software team structures, onboarding effectively - and even specific things about adopting a new technology, and things like that. So for anyone interested, there's the theory and there's also the practice in this book. It's really good, and I highly recommend it.

Just moving on to the last part of the interview, where we talk about your experience as a self-published book author - you've got a blog post where you write at length about your experience. Without going into the entire story, which would take quite some time - can you talk a little bit about what your journey was through the process of writing the book and what you learned, a little bit?

Dion: On that blog post, I've still got one little thing to add, which is like a graph on hours invested over the course of nine months or ten months. So I'll add that quickly, it was on my to-do list.

But I self-published - qell, for a few reasons. The main reason was, I've always dabbled in side projects and start-ups - very unsuccessful start-ups, I'll say. But still, I tried.

Self-publishing for me was like a mini start-up, right? You have to do everything. You've got to author the book. You've got to create the cover. You've got to edit it. I did get some help editing. I'm still getting a bit of help with a few things at the moment, just to make some tweaks, because it's never ending. Then you've got to publish it. And it's the same as starting a start-up, right? You've got to do it all. So it's quite exciting for me to try and think, "Could I, can I do this?" It was a challenge. Like, "Do I have the skills to go off and do it in a good enough way?" It's not going to be a New York Times bestseller, but it's hopefully a book that people get some value out of.

So that was the reason I did it. But yeah, as you touched on - the blog post, I won't go into it - because it took me too long to write that. But I think it comprised of about, I think I probably put down about 20 or 19 different stages I went through when writing the book. I'm a first time author, so I know there are many different ways I could've done that a lot more effectively if I was to do it a second time round. I probably could've condensed it down to about nine steps. But it was - look, I knew going into the project was hard, I knew it'd be really hard. It was probably considerably harder than I actually had thought.

But yeah, probably the biggest wall I hit was when I thought I was about 25% of the way through, sorry - 65% of the way through the book. And when I actually went back through it all and reassessed the situation, I was about 25% of the way through. So I was like, "This really is a marathon."

But yeah - look, I did what every challenged software project does. I just kept investing more and more and more time.

Because I had a deadline. Obviously I wanted to finish the book before my baby was born. So I just invested more time, until I got it completed - which was around three or so hours every night, and then most weekends to complete the book.

But in saying that, I'm glad I did it. I'm glad there was a deadline. I could definitely get a lot better at smaller milestones, which I would do in any project I'd work on at work. I just didn't do it for my own project, which is another lesson learned.

And then I unfortunately discovered - I'd seen Leanpub before, but I discovered it probably around the 70% of the way moment. Say 70% of the way through the book, and I was catching up with a friend. who I had a suspicion was writing a book. And he wrote a book, I think, Effective Kafka was the title - and he's telling me all about Leanpub. And he's like, "You've got to use Leanpub. You've got to jump onto it." So it's like, "Okay, okay." So I logged in about a day later and then had a look around. And I was like, "Wow, this is a pretty extensive platform."

So then I started to - well that's sort of partially where I realized that I had to get away from like Google Docs and move into Markdown as well, and start to link it all off.

But yeah, it was a book that just had an evolution of its own. I learned a lot of different tools, and a lot of different ways to author it and to publish it. And yeah, and then it ended up finding itself onto Leanpub and to a few other platforms later on, for the print copy.

It was a good experience. It was tough. I think I need a reset, a bit of rest before I do another book. I don't know how you've written, is it five or six books now, Len?

Len: What? Me, myself?

Dion: Yeah, how many books have -? You've written a few.

Len: Oh, I wrote a novel and I wrote a PhD dissertation, but other than that - if you've seen those books, those are probably chapters from my doctoral dissertation

But, yeah - my approach to writing has historically been very similar to the one I sort of gleaned yours is, from your blog post. I really, really like to structure things a lot before I get going.

Dion: Yeah.

Len: And I don't know why - I used to be Editor-in-Chief of a couple of university student papers, and stuff like that. And always, what I did - well, I mean as gently as I could. It was like - before you write an article that I've commissioned, you need to structure it. And one of the reasons you do that is so in the introduction, you can set out what you're going to do. So even if it's like a news piece, the first paragraph should kind of tell the whole story of what you're going to be doing. And you can't do that, unless you've structured it.

And now one way to do that is of course - always write the introductory paragraph or chapter last, once you know how everything's settled out.

But yeah, I've just always been drawn to a similar approach to the one you took for the book, which is to like plan it all out in advance, and then fill in the details. And actually, planning it out like at a high level - and then at the chapter level. And then you actually set upon a structure for each - a four part or five part structure for each chapter. And yeah, that's exactly how I aspire to do things when I'm writing.

Dion: That's good to know. It definitely helped.

Len: It's not for everybody. I mean, a lot of people, they just dive in and start writing, and then see where it goes, and that's another really great approach to writing.

One of the things you learn if you write a lot, is - everybody's got their own personality and preferences and time available and motivation, and things like that. And it's important to be forgiving of - I mean it's important to punish yourself a bit, but it's also important to be forgiving, and to accept that there are some things that you like, and some things that you don't. Try to minimize the latter and maximize the former.

And so you started - this is the last part of the interview, where we really get into the weeds - but so you started out writing on Google Docs, and then you switched to Markdown.

Dion: Yeah.

Len: And you ended up using Pandoc to create your ebook files, if I understand correctly? And you used our Bring Your Own Book writing mode, where you create your own ebook files and then you upload them yourself. Is that more or less the story?

Dion: Yeah, I tried - well, I didn't go into all the details in that blog post. But I tried a few approaches, yeah. Started with Google Docs - it was just easier to begin with, until it started being too slow. Then I jumped into Leanpub.

I actually used the inline editor. I also linked it up into GitHub at the start. But then I found out I wanted a little bit more - I wanted to be able to control some of the CSS more. That was after I had it sort of semi-ready to publish. So then I ended up - because it was already all in Markdown and linked up through GitHub, I kept seeing GitLab. Because we use it at work with GitHub.

Then I ended up - in the end, pulling it back and then - yeah, using Pandoc to convert it. Because then I could apply custom CSS. Which - again, I didn't put this in "lesson learned." I got the formatting I wanted, but in hindsight, it's harder to format an ebook than it is to format a website, in my opinion, now. Because there's so many different readers and formats now out there though, I realized.

So that was what I ended up doing in the end. Because - yeah, just some specifics I wanted to be able to do - around like formatting tables. Again, you shouldn't have large tables in ebooks, but I'd already committed down that way, and I just didn't want to - I didn't want to rewrite that in the book, because it was working.

So I ended up - yes, in the end I ended up bringing my own book to Leanpub and publishing that out in the ebook, EPUB, MOBI, and PDF formats. And oh, and the samples as well, and created a little build pipeline at my end, just because I'm a programmer at heart - to script that publishing out, and then script out also a publish to a print format as well.

Len: You mentioned you got it in print, I think on Amazon? And you've got a Kindle version up there as well.

Dion: Yeah.

Len: And you're on Apple Books and Google Play as well. How have you found -? How have you been promoting the book, I guess? Because you've got it on these different channels, which is a pretty good approach that successful authors take. There's some people who are like, keep it all in one place. But there's also the eggs-in-many-baskets metaphor that people use. How have you been promoting the book?

Dion: Yeah, I definitely try different baskets. I don't know if that's the right way. It's like putting a bet on in a sports game. Too many bets, and I don't end up winning enough of it. In this, I - most of the sales come from Leanpub. There's a few on Amazon as well, mainly for the print version, obviously.

Marketing, I've tried a few things. Well, a few things on different platforms. But mainly - and so, trying to write some - I've been writing a few blog posts that are chapters of the book. To get them out, smaller subsets of the chapters - publishing them on different social channels. I've done some paid advertising, which definitely got some good interest. It doesn't always convert, but that's just what normally advertising does. You get a small amount of conversion.

There's a few other channels where I think I can definitely do some more advertising, that I've been looking into over the last probably two or so weeks. I feel like you could have like a healthy level of advertising going continuously and not just - I probably went a little bit too hard at the start. But I can sort of drip feed that over the course of a year or so, just to build some momentum.

I'd love to get out there and - I used to do a few talks at some different conferences and then talk about it, but it's a little bit harder to do that now. It's getting a bit better now, because most things are turning actually online - so you can probably get more exposure to do that. But that's on my list in maybe 2021, if I'm being honest - seeing the year is getting close to the end already.

So I tried a few different techniques. I can't really pinpoint on anything that has worked better than the others. I definitely feel like - I sort of launched it a little bit early, and created a website that linked off to things like Leanpub and Amazon, and linked it from my blog. That's I think getting some organic traffic coming in, and I feel like that's the best long-term approach.

Because it's like - SEM's a bit of a drug, right? You can keep paying for it, but you need organic growth to really sustain itself. So it's an ongoing challenge. I've never been a good marketer, so I'm always open for advice.

Len: Yeah, it's one of the big challenges. People can be excellent writers and create excellent books, and then getting the message out might just be a new skill you have to learn. Just like everything else you're learn in life.

Dion: Yeah, exactly.

Len: And it's important, again - like I said about writing. I think the one piece of advice that I have come across that I like the most about self-published book marketing is - do what you enjoy. Again, as much as possible.

Same thing with writing. If you find yourself really hating a certain type of marketing effort, don't do it. Like, if talking at conferences is the way you like to do things, if creating meaningful content in blog posts and stuff like that is how you like to do things - then do that.

Dion: That's good advice.

Len: So just wrapping up. The last question I always like to ask Leanpub authors, if the guest on the podcast is a Leanpub author, is - if there was one thing we could fix for you that really bugged you, or one feature we could build for you, what would you ask us to do?

Dion: So this might have been created in the last few months or so, but yeah, as I touched on before - if I could have one feature - so in Leanpub you've got the different templates. Different, I guess - I don't know if you call them "templates" or "themes"?

Len: Themes, yeah.

Dion: Themes, thank you. So you've got different themes. Being able to essentially bring your own theme, bring your own CSS - but then be able to tie that - because I couldn't do that exactly how I wanted to do it when I first tried to publish it. And that would've been amazing if I could have.

And then if I could just throw in a sneaky second. Because I know a lot of developers - like technical people publish on your platform, which is amazing. Having a basic sort of mini-build pipeline, where you could build out your ebook - like into different formats. But then that could also fit into - I guess it'd allow you to build your own - so, maybe you don't actually need this now I'm talking about it. It's funny how that happens. But definitely to be be able to apply your own formatting and CSS.

But the reason I said, "build pipelines" as well, is that you can then tweak how you do your page numbers and your margins and things like that. It's a bit more relevant to print, but maybe that's somewhere that Leanpub maybe will go to, I'm not sure?

Len: Yeah, I think - I mean, the short answer is that philosophically, that's not really our approach to things - "lean" is in the name of the company.

Dion: I know, I know.

Len: In our Help Center - for anyone listening, we actually have - we do "wall of text", like way too long explanations of our policies on things sometimes. But the big picture for us is that we want to provide something that makes it easy to write and publish and produce things.

But, we understand. I mean, we're perfectionists. And my colleague Peter's joke is - like semi-joke, is that, "Formatting is procrastination." With the important caveat, "Until your book is finished. When your book is finished, take all the time you want."

That's one of the reasons we have InDesign export. If you want to, you can give your manuscript to - and it might already be published on Leanpub and a bestseller. But if you want to hand it over to a professional book designer, we've got InDesign export.

But also the reason we have our "Bring Your Own Book" writing mode - which lets you do whatever you want, and then just upload PDF, EPUB and MOBI - or even one or two of those, if you like - is because over the years, we realized that like we would never be -

I mean, it's a simple thing to say, but we'd never be able to satisfy everybody's formatting requirements. And we used to have multiple - even more writing modes than we do now. Like a Google Docs writing mode and stuff like that. Because we were trying to accommodate people. And realized after a while, "No, we are about keeping things simple and making it easy. We love formatting, it's really important, but that's for finished books."

And so we try and give people the opportunity to put beautiful books up for sale on Leanpub that they've made using their own tooling. But yeah, the kind of thing that you're describing, I mean I can't - I can't make any promises on behalf of the company for all time, or whatever.

But - one last thing to say is that we do, however, listen very closely to authors' needs and requirements. We just spent quite a bit of time - we're in the middle of a big redesign. But we actually carved out some time to satisfy an author’s requests for finer detail control over tables and table formatting.

So if you go to Leanpub to create a book, we've got these three Themes that you can just choose. And if you've got a paid account, you can also customize your theme. And under there, there's basically a bunch of like cheesy like buttons and dropdowns and stuff like that, where you can tweak things.

Dion: Was that for table formatting, was it?

Len: Yeah.

Dion: Yeah, I'll check it out.

Len: We're definitely receptive. But we won't - I guess what I'm saying, is we won't necessarily do everything everyone asks us to do. But thank you very much for sharing that though. I really, really appreciate that, it's good to know.

Well, Dion, thank you very much for taking some time out of - I'm sure a beautiful day in Sydney, to talk to me and talk to our audience about your career and your approach to software development and team leadership, and about your book as well.

Dion: No it's great, thanks Len - I appreciate the opportunity to come on the show.

Len: Thanks very much.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.