Working From Home: Episode 5 – How to manage a remote team – with Luke Szyrmer
In this episode of the Working From Home podcast, Nelson is joined by Luke Szyrmer. Luke is an author and consultant who is experienced in the agile management of remote teams.
Topics of conversation include: common roadblocks to taking a team remote in the agile format, building culture with a remote team, deconstructing societal norms around work, the importance of visually mapping out a company’s organization structure, quality control checks with remote teams, and other topics.
Resources Mentioned:
Timestamps
[1:02] – Luke shares his background as an international worker, author, and business consultant.
[10:50] – How Luke transitioned from a regular job, to working remotely, to managing a remote team.
[12:49] – What are the barriers to entry for teams that are interested in going remote? Experience with agile team management, sprints, setting deadlines, etc.
[17:24] – Is it easier to take an existing team and transition them to remote work, or to build a remote team from scratch? It’s less about the team, it’s more about the organizational context.
[20:27] – What are the greatest difficulties when it comes to managing remote teams? How do you ensure people are working and submitting vetted deliverables?
[25:41] – Creating a culture of quality up and down the chain of command.
[30:17] – Examples of how a company might prioritize quality in different industries.
[32:46] – Luke discusses his podcast Align Remotely, and his forthcoming book on the topic.
[37:21] – Reconsidering norms and beliefs around remote work.
[42:22] – The importance of visually mapping out the organizational structure of a remote team (e.g. how work gets done, communication guidelines, deliverables, etc.).
Transcript
00:45
Nelson: Hi there. Welcome to the ‘Working From Home’ podcast with your host me, Nelson Jordan. And today I am delighted to be talking to Luke Szyrmer. Luke, hello!
Luke: Hi Nelson.
Nelson: How are you doing?
00:58
Luke: Yeah, good, good.
01:00
Nelson: So Luke, tell our audience a little bit about yourself, where you’re from, where you are now, and what do you do?
01:08
Luke: So I am essentially from, originally from, Poland, I lived for a long time in the US. And then I also lived in London for 14 years. So I’ve been here and they’re professionally speaking. At this point, kind of like a manager and consultant. I’ve managed teams within larger companies, and I consult in terms of new products being launched. And other than that, I’m also an author. So I wrote a book called ‘Launch Tomorrow’, about five years ago and that kind of kicked off a side business, which became a full time one at some point. And yeah, that’s, that’s basically who I am.
01:58
Nelson: Cool. Well, so much we could dig into there, obviously, you’ve moved all over the globe, and held various jobs at different levels and things but then went to strike out on your own and become an author, and start a side business. Yeah, you’ve got a lot of lot of things to dig into there. I think we’ll start by talking about your moves, if you don’t mind. So you said you originally from Poland, and then moved over to the US? What age was that?
02:28
Luke: Yeah, so I left at the age four, four and a half actually. The situation was my dad went over on a Fulbright scholarship to the US. And when we left, this was in ‘81, I think roughly six months later, martial law was imposed in Poland. So I think we would only expect it to be over for a year. And it was quite complicated to get passports and paperwork and that kind of thing. But yeah, kind of halfway in, it turned out there, it made no sense to go back and family was just like, ‘Don’t…bad idea’. So I ended up growing up there, going to school, going to college. After that I went back to Poland, now as an adult, for a couple of years to see what it was like. Because I always heard lots of family stories and that kind of thing. Worked a bit, did another degree, and then move to London. And there I worked for quite a bit in various roles and software, basically, for largely kind of a medium-sized software company for the financial sector. With the last role being a team manager, development manager.
04:03
Nelson: So within software then, what did you do? Were you on the programming/coding side, or – ?
04:10
Luke: Yeah, so I started as an implementation guy, became a developer later and then moved into products. And then at that point, moved from product more into managing and delivery, and that kind of thing. And owning more and more responsibility, I guess. And was trying to coordinate the work of more and more people so that it’s effective.
04:38
Nelson: So when you say managing, do you talk about project management? Or are you talking about managing people or a bit of both?
04:45
Luke: Both really, I had really good technical people looking more at that angle, and everything else was pretty much on my plate. And I was coming from a technical background, so at least I knew what questions to ask. But I intentionally didn’t want to get into the detail of how things are done because that takes all the fun away from the developers.
05:12
Nelson: Sure, sure. Just giving them the environment through your management skills, that they can still be creative, they can still implement their solutions that are in their head, rather than you telling them what to do.
05:24
Luke: Yeah, exactly. So I think that that’s what I tried to do pretty much from the beginning. I mean, it pretty much was a full-time gig. As soon as I realised that, I was creating the environment, unblocking them, making sure everybody’s clear, making sure the goals are clear, make sure everybody’s agreed on what’s going on, what needs to happen when? Yeah, getting that clarity for everyone. And that’s more or less how it looks in practice. And thing is, I think, starting with when I was in more of a development role at that point, it was already starting to be part of the team of remote offices. So we were still in offices, but kind of working from different locations that the company had. And then yeah, I think at the point where I did start moving more into kind of the management role, I realised, I had a pretty big team of people who I was coordinating. And I think at the peak, it was close to around 30 people. And there was only two of us in the London office, a number of people were totally remote. A lot of people were in, I think four or five different offices. So we had, let’s say, nine or 10 locations across 13 time zones.
Nelson: Wow.
Luke: And, you know, as a long run effort to build various things, I realised that, you know, it’s totally optional for me to stay in London, from a professional perspective. The main reason it was convenient for, let’s say, the immediate people above me, were in London. So from a stakeholder perspective, I think it was good to be in touch with them and that kind of thing, but because I’d already, you know, I had a decent relationship with them, I’d been with the company for a while, and it was just like, well, since nobody else is in London, and from a personal perspective, it makes sense to be elsewhere. Then why don’t we go and do that? I mean, there was another aspect there that my wife got a job offer in Poland. Initially we weren’t sure, but then it was like, well, with a small daughter, it makes sense. Because it’s, you know, a family around and it just would make things a lot easier, basically. And, yeah, so we did some prep work, but the actual move was we packed up all of our belongings into a van, the guy was weighing it to tell us how much we would cost. So it was 2.3 tonnes of stuff, we came initially with two suitcases. Things just expand right?
08:37
Nelson: As they do.
Luke: As they do. So the van drove across and we were chasing after it in our car, basically. So it was a mad rush. Ended up roughly 36 hours. We didn’t stay the night anywhere on the way.
Nelson: Wow.
Luke: Just took the ferry and kept going and switching out. So fortunately, nothing bad happened.
09:02
Nelson: Yeah, exactly. Well, I think that makes a lot of sense. I think a lot of people are kind of realising that now when they do manage either wholly remote teams or teams that do have several key components, and characters that do work remotely, and people that do work remotely. So why do you need to be in one place when everybody you manage isn’t there anyway? Right?
Luke: Exactly.
Nelson: Something similar, not from a management perspective. But with my wife and I, and my job, I realised that I could do it from anywhere. I was actually working for an agency who allowed me to, I’ve been working as a full-time employee for them and I continued working full-time for them, but they allowed me to work from a different country and then just kind of commute back every month, for two days, and like cram all my meetings in one day and go again, which was lovely. And then my girlfriend at the time, now wife, was a primary school teacher. So again, one of those jobs that kind of can transfer and we’re lucky enough to speak English, and a lot of other countries want to learn English, want their children to pick that up, because it’s kind of the business language. So yeah, we’re in a very fortunate position there that she had a skill that could be transferred. And we were kind of in demand. And that kind of opened the door. And it’s fantastic to hear that it’s done the same for you. So once you did that, did you stay kind of within that environment for a little while, from Poland? What did that kind of situation look like? What was the spur for you to kind of go and do all of these projects that we were talking about earlier, so you writing your book and multiple businesses and, and things like that? How did that develop?
11:06
Luke: Yeah, so it was kind of from an organisational perspective, similar to what you have. Also, in that, I kind of went in once, I think, initially, it was once a month, and then then it kind of became less and less, because we realised it’s not quite as needed to go back and visit London, to speak with people. And, yeah, other than that, I mean, in terms of that transition, all it kind of meant was at that point, I went freelance. So as a contractor, as opposed to an employee, and just kept on doing what I was doing. And then also started taking on other clients, and plus, I could it within whatever time I could get by, I could go and do more writing or whatever it is that I wanted to do, while still pretty much keeping things ticking along at the at the old place.
12:20
Nelson: Nice. I just want to dig into your expertise a little bit out if that’s okay with you.
Luke: Sure.
Nelson: So you’ve obviously got a lot of experience of kind of managing teams remotely. And then obviously, that’s, as we’ll talk about in a minute, you’ve transitioned into other things because of that, as well, which is fantastic. So what kind of things, firstly, what kind of things stop people from having teams that work remotely in the first place, that sort of need to have people face to face? And let’s talk about that first.
13:04
Luke: I’ve mean, I’ve spoken to various people about this, since I started focusing specifically on it. I think a lot of it’s just the staying in the same environment and way of thinking that you are. It’s kind of –
Nelson: Inertia.
Luke: – like inertia or some sort.Yeah. And I think once you get beyond the obvious answer like that, there’s things you need to start thinking about hiring, which therefore means you have to think about what the HR aspects are in different jurisdictions, what that would actually look like just purely from a, let’s say, mechanical level. And then beyond that, a lot of its thinking about how does having a remote team actually work? Because I think a really common question, especially at the beginning of the whole pandemic, everyone was like ‘How do we know they’re working?’ Right. And that’s something which I heard quite a lot from people who were experienced managers asking me like, ‘Okay, you’re managing this team, but how do you know they’re doing anything?’
14:26
Nelson: And what was your answer?
14:28
Luke: Well, I look at what’s delivered, like, I don’t care when they do it, a lot of the work was setting kind of short-term deliverables that they would then go for. They would either do it or not, and then it would just be feedback and based on that. I would know exactly where things were without sitting there, watching each person over their shoulder and recording their keystrokes or whatever. You know? Yeah, I mean, that’s kind of the short answer, I guess.
15:09
Nelson: With the deadlines and deliverables and things like that. Is that something that you purpose the experimented with? In terms of like, ‘Okay, I wonder what it would be like if I set a three day deadline versus next week’, or was it very much just the project dictated that ‘x’ needed to be done by ‘y’ date?
15:31
Luke: It was something that I was experimenting with, particularly since a lot of the work we were doing was on a larger thing. So yes, there was this overall deadline that we had. But then, we were working in an agile format, so with sprints, and that end, in itself, gave a little bit of a context. We experimented quite a bit. So looking at how long things take. We did all the estimation stuff as per usual, in terms of you know, how big various things are, and then we would look at what we could do and plan out each sprint and that kind of thing. But, you know, I was open to experimenting with pretty much everything around that. So, we cancelled meetings, we added meetings, we had different types of meetings. Yeah, a lot of it was just about not so much efficiency, but making sure that each person was effective, so that if they were doing something, they were doing something that would contribute to the building of the overall system. Right? And that partially was just a pure technical thing, because it was quite a complicated piece of software, and partially, it was this kind of thing. So just having something concrete and clear that you have to break it down into a concrete enough task, that this is the next thing I need to do, and then I’ll figure out what I need to do after that with the team.
17:17
Nelson: That makes sense.
17:20
Nelson: So, and this is might be something that occurs frequently or not at all, but do you think it’s easier to take an existing team and turn it from a face to face to a remote thing? Or in your experience, is it more like, we need to create a remote team from scratch?
17:39
Luke: I don’t think it’s as much of an issue of the team, as it is the organisational context. So I think a lot of what managers might pinpoint to say that, ‘The team’s like this or like that, or they’re not doing this’ or that kind of thing. I think a lot of that is based on the context in which everything happens. So by that I mean, things like: what the incentives are, organizationally, how clear goals are whether everyone’s agreed on those goals, how long that takes. And in the meantime, you know, elapsed time goes, like time still happens, whether you want it to happen or not. So if yes, in the context of moving to remote, like, I think a lot of the challenge many companies had with the pandemic, going into remote, is that there’s a lot of, let’s say, work arounds, which are implemented from a management perspective. Which can work because we’re face to face, like, you know, you can see if people are at their desks, are they doing stuff? So there are certain types of information which you have a lot more of, right away, but it’s not necessarily tied to, are they actually being productive? Right?
19:20
Nelson: Like, are they there?
19:21
Luke: Yeah, are they there? Yeah, which is a proxy, kind of, but it doesn’t actually mean they’re doing anything useful other than sitting at their desk. So whereas if you have a clear context and a clear set of goals that you’re aiming towards, and that the whole team is aiming towards it, so they’re working together, they’re supporting each other. You know, if you have that kind of a thing already in place, then moving that online I think is going to be a lot easier, than being this kind of traditional, kind of top-down hierarchical, or even worse, multi-manager style situation; where everybody has their own agendas. In that context, moving to remote just becomes super complicated. And it just makes it a lot harder.
20:27
Nelson: What are the kind of main problems or challenges that, that you kind of hear from people that they encounter, in terms of managing remote teams? What are the big ones?
20:40
Luke: I think the big one, especially initially was what was what I just mentioned. So like, how do we know they’re working? I think in terms of what I’m hearing and speaking to people.
20:51
Nelson: That’s super interesting, because, to be honest, I’m obviously a lot further away from this than you are because I’m a freelancer, and I tend to work with other freelancers, and because I understand what they’re doing. I know that like, I’m working, I have to do stuff, I know that they’re reliant on doing work to actually make money as well, because they’re not salaried employees. But I would have kind of assumed that a large challenge would have been communication. How can you go backwards and forwards? And how you can align people in the same on in terms of the same goals, and getting everyone on the same page? But it’s interesting to hear that the big thing is, it’s something that I just would assume, almost as a bit of a given if you were to do remote teams, like how do I know they’re working? Like, well, if that is your probably biggest thing, then I would be like, maybe managing a remote team isn’t for you? I don’t know.
21:58
Luke: Well, it’s also this kind of a company culture thing, too. And, you know, if you have teams, the actual execution team separate from the ‘strategy silo’, for lack of a better term, then that’s kind of the main concern that the money’s being paid to various people, and we want to be sure they’re being efficient. But in fact the efficiency is irrelevant if they’re not effective.
Nelson: So, in terms of actually understanding what that looks like on a practical level, then, obviously talks about deliverables. So would that be? Firstly, looking at the deliverables, if all of the deadlines have been met, per person? But if they’re doing the work, is that something that you’re periodically look at the quality of the work that’s done? Or do you kind of rely on other metrics or, or outcomes to measure that?
23:11
Luke: Yeah, so you bring up a great point. So there’s individual work, but actually, the only thing that I was focused on was the team output, which included quality as a step, which meant that when we said that something was completed, it already had been fully tested, confirmed. So it’s not just build, but you know, as much as I could, I tried to not give the team credit for finishing it until it was through quality. And, yeah, I think another part of it was we tried as much as we could to keep this style of working, where the developers would also write automated tests. So before they would even give it to the QA team, they would have they would write tests that would confirm the software does what they think it does. So then they caught bugs at that level before it even got to QA. Then additionally, it was inspected by QA, which didn’t know the internals of the code. And therefore, you could finish parts of the system without having the whole system and actually have it be finished, with, you know, very few expected bugs later kind of thing. In practice, it was it was part of the daily challenge, in terms of, you know, actually keeping to that. So, it was a definitely good ideal to aim for and sometimes, you know, we had to spend a bit more time doing a bit more ‘catch up’ than then I would have liked. Paradoxically, it does end up being faster doing it that way where you start with quality in mind from the beginning. Even though it seems like it’s more work that you’re, you know, you’ve got to write extra tests, and you’ve got to, you know, do all this other stuff, but you don’t have any bugs later. All of a sudden, this big unknown time just goes to next to nothing.
25:15
Nelson: No exactly, before you know it, like, your deadlines have passed. I’m just trying to think of how we can extrapolate that idea of quality being part of processes outside of software. Obviously, we’ve got a large audience who, who won’t be involved in kind of software development at all. And I think that idea of having quality as a part of your projects, or a part of your management is quite appealing. I’m just wondering how you think, and might not be, you know, but if you’re able to kind of give an example of what that might look like, for somebody, say, who is managing an ecommerce brand, for example, and they have a lot of remote workers. Whether that’s a remote worker who is involved in customer service answering queries, or maybe that’s a remote worker who is on the marketing side, or, or things like that.
Luke: Oh, before I go to ecommerce, let me let me try a different one.
Nelson: Oh yeah, go on.
26:33
Luke: So there is a great story of Alcoa, which is a aluminum producer, in a book by Charles Duhigg, called ‘The Power of Habit’. It’s shown up in the news and other places. Basically, the idea there was a new CEO came in, and he said, the company wasn’t doing very well, the financial numbers are really bad. And then this new guy comes in, he says, ‘I want everyone to focus on safety’. The financial items were like ‘What? What are you talking about?’ Wall Street was just completely scratching their head, like ‘What’s going on?’. And he just kept repeating it, like, ‘Worker safety, we’ve got to be safe’. And there was a number of incidents and, and each time he kept repeating that this is the first thing. Then once workers realised that he was serious, and he actually cared about it, and it was something which everyone, at every level of the organisation connected with, then all a the sudden, the whole thing just picked up and the company started doing really well. So in my little context of this, this one little remote team, I kind of felt quality was the same, it was something which all of the members of the team could identify with. They wanted to write good code, create good products, basically. And it was something which they all agreed with. And also, it was something which, you know, pretty much by default, the whole company, both people, let’s say, that I was, you know, quote, unquote, reporting to and people below me like that. Yeah, of course, we want to write good quality stuff. So therefore, that became like, the kind of the right-angle type of approach into this is the motivation: ‘let’s create something that’s really good’. And that’s kind of how it works in that case. So I think, to make it less dependent on those two examples, part of this aspect of building, let’s say, alignment, and communication, I think is you’ve got to go and find out; figure out what the common thing that motivates everyone involved is.
29:02
Nelson: That sounds an awful lot like their concept of identifying your North Star. And that one thing that is important, that brings everybody together to deliver that final product, to the final services. Is that kind of what you’re saying?
29:19
Luke: Yes, it is. I think that’s a good way of putting it. I think it’s important that it’s also not something that’s done on an individual or in a closed room setting, but literally, with as many people as possible. And in a remote setting, that could just mean a lot of one-to-one conversations with various people. But eventually, if you pay attention, you’ll pick up cues and see what people are responding to, what are they saying, what do they care about. And then once you get that common thread and you start communicating, almost about everything that you do from the, from the context of that one perspective. So how does this affect quality? Well, okay, this is this is going to be later, this is going to be more complicated, how does how’s that going to affect the overall quality of the thing?
30:17
Nelson: With quality, I guess to just to give like a concrete example it could be this thing is ready, like this thing is still a little bit buggy, but we’re on a deadline, it will work pretty well, but not perfectly. And then from a quality perspective, you might go actually the quality is more important, we’re not going to push that live, even though we’re getting this pressure to do so.
30:43
Luke: Yeah, yeah, exactly. So for example, let’s release less features, but make sure that everything we release is good. And on the other hand, you’ve got to release something which is usable for customers, because you’re not doing it for the team, you’re looking for the customers, right?
31:00
Nelson: Just to pull out a few more examples as well. So obviously use the manufacturing example, and safety, and then the development example, and quality. And then you think of maybe somebody who’s famous, like Zappos for their customer service. And so it’s about kind of establishing that, obviously, with the manufacturing example was quite interesting, because it seems clear, like the CEO probably didn’t talk to everybody in the organisation to get that in terms of directly asking them, what do you think the most important thing is? It seems like it’s probably something that he talked to a lot of people and observed and pulled out, ‘Okay, this theme keeps coming up, we had ‘x’ number of days lost last year because of employee injury. We had this line of the manufacturing plant has to be shut down because of that injury, and that cost us ‘x’’. Okay, that’s really interesting. I think that’s a good way to kind of develop it. And also, to figure out more about your business as well. I think it’s got that side effect.
32:18
Luke: Yeah, exactly. And it also ties into what actually is important, like, what are the principles at play? What do you care about? And what does the whole organisation care about? And then when you’re referencing it, then everybody knows and agrees, and it’s kind of a common platform to build everything else from.
32:39
Nelson: No, it makes a lot of sense. I’d like to switch gears for a little minute, and just talk about what you’re doing now. And why you kind of made that change.
32:51
Nelson: So at the moment, I am writing a book called ‘Align Remotely’, and also started a podcast for managers and leaders, I think initially, out of wanting to reflect on my own experience, and share with people who suddenly are managing remote teams, knowing that I have some experience that I can share both, being on them and then later managing them. So from both sides. And yeah, at the moment, it’s a lot of it is kind of thought and research, and speaking with various people. So that’s, that’s, that’s the bulk of it. I think.
33:36
Nelson: That’s great. So are you doing that on top of your regular work? Or are taking some time out to make that your main goal?
33:44
Luke: It’s Yeah, it’s some time out, basically. So until I get that done. So that’s the one thing.
33:55
Nelson: Not that I want to put the pressure on and hold you accountable. So I’m definitely not trying to do that. When are you sort of hoping to have the first draft together?
34:10
Luke: Well, I’d like to have it done by the end of the year. And yeah, and the podcast is out.
Nelson: Is that under the same name; ‘Align Remotely’?
34:19
Luke: Yeah, ‘Align Remotely’. Yeah. It’s under the same name. I felt there was a need to get something that’s of value to leaders and companies, as I’m working on it. So that’s already happening. And plus it gave little interim deadlines, which is –
34:41
Nelson: Which is just what you said earlier about managing other people. It helps manage yourself as well.
34:45
Luke: Absolutely. Absolutely. Yeah.
34:48
Nelson: With format of the podcast is that similarly, kind of interviews like we’re doing or is that kind of a kind of monologue on a particular topic each week or each episode, I should say?
35:02
Luke: It is interviews. It’s largely at the moment mostly focused on either people whose work I came across, and I wanted to speak with the more. So with authors who I, just wanted to dig deeper on certain things. Or basically people, who I knew, were doing interesting things related to working remotely, because I spoke with them a lot when I was managing this team. And it really helped me in one form or another.
35:37
Nelson: Kind of like mentors?
35:40
Luke: Something like that. Yeah, I think, in particular, the aspect of making sure things are interactive, making sure everyone’s working together, I think that’s one thing that I’m starting with. And the whole topic of meetings, because I think that for the for the team, I think that was, in a way, the hardest, surprisingly. And getting that piece sorted out, I think once I got that, it made everything a lot easier. So in the early days of pandemic, there were all these articles about, you know, ‘27 different remote work tools you can use’ and that kind of thing now that you’re working from home and that kind of thing. And yeah, of course, all that stuff is useful. But it’s like, it’s this almost surface level need, right? Whereas once you actually get into the human dynamics of the situation, like, ‘Who are you working with? How is it actually going to work? How are we actually going to do anything?’
Nelson: So it’s likely the organisational, strategic things that are more important. Whereas like, 27 tools, to be able to even use those tools well. Firstly, have to have done a lot of work before that and deciding, like, ‘Who’s going to do that work? What’s that work going to look like? What is that process going to look like? Okay, then you can pick the tool that’s that you need for this?’
37:20
Luke: Yeah, yeah. I mean it’s both to be to be fair, and it’s like, you’ve got to learn, look at different tools, figure out what the right thing is. I’m not saying they aren’t important, I mean, they definitely are without them, you kind of suck, but there are a lot of this technology has been reasonably good. For the last 20 years or so, it’s just, we’ve had this whole set of cultural assumptions around how work is done, which meant that, ‘Johnny’s working remotely from India, or whatever it is’, and, you know, but most people, the “real work” was done in the office, quote, unquote. Now all the sudden, because we were all forced to re-examine that it turns out, that’s a lot of these things, which were ‘the sacred cow’s, so to speak, they’re not true. And, on the other hand, you’ve got to go and explore, ‘How does it work? Do we still try and organise work in a top-down way too? Do we try to give people the ability to interact with each other without kind of monitoring everything they do? Is that actually going to help or not, you know, that kind of thing?
38:47
Nelson: Do you have a framework or a process you use when somebody comes to you and they say, ‘Look, Luke, my remote team, I don’t think this is working’. Where’s like the first place that you’d, you’d need to kind of look at?
39:04
Luke: I’m not sure if it’s matured as a framework at this point? I think the starting point, with all of these, is essentially perspective, realigning perspective. So I think a lot of things (in the context of a larger company) are missed, because the IT teams over here, the developers are over here, QA is over there, marketing is over, their product is over there. They all kind of talk to each other, but they don’t really talk much across the department boundaries. And I think creating a space where all of that can come together and you actually look at, from an end to end process, what actually is happening at the moment. To then open up the discussion of ‘How can this be improved?’. So basically, I don’t want to go in and start telling people this or that, because they’re the expert on how things work within their organisation. And a lot of these organisations do have some, fantastic people have great resources, that kind of thing. But I think a lot of what happens, given that people stay shorter companies, given that people even when they are around, there’s just a lot of this organisational fabric that isn’t there, like it used to be in the 60’s where people would work until they get their pen for their 30th year anniversary, or whatever was. That’s not the case anymore. And in terms of actually making things happen, I think it’s often even if you have individual teams working well, it’s across the boundaries, where things tend to be contentious or missed or dropped or that kind of thing. That’s kind of the first place to start, if there’s a problem.
41:28
Nelson: Maybe that that sounds to me kind of like ‘siloed’ communication, right? That they’re good at talking within their own discipline within their own team members, but then they’re not really necessarily either thinking about what’s going on externally, or to that much degree, in a different a different department. Or if they are, there may be thinking that it’s it’s somebody else’s problem. How would you kind of go around countering that opening up those channels? And as well as that, is it typically that you’re trying to encourage one person to lead that, who sits above those departments? Or is it a case of trying to encourage somebody or multiple stakeholders within each department to try and kind of force these communications?
42:23
Luke: You need both? Right? You need to do both for it to work. In terms of the practicalities, it’s basically kind of more of a workshop format, where you map things out visually, as much as you can.
42:40
Nelson: When you say, map things out, what are those things?
Luke: How work is done? How do those things get to the customer? I mean, ultimately, it’s about existing customers or potential future customers. So mapping out, first of all, what’s happening at the moment, and kind of in terms of the process. Quite often across department boundaries in there, if you look at, step-by-step, how things actually do work, then you start identifying where there’s gaps in people’s understanding. And you do it with people from across all of these areas, and both top and bottom, ideally, which then is gives you the starting point for that gap analysis basically. To then figure out what is the ideal? And before you start there, like, ‘What actually is going on? And why are we seeing the following challenges related to delivery, or whatever it is’.
43:55
Nelson: Okay, so it’s interesting. So you think it’s about fostering, well, firstly, kind of putting together an overview of what’s happening at the moment, in terms of how things actually get to a customer, how the works done, who it’s done by, what that kind of actually looks like, from a concrete, like literal visual level. And then establishing both people, within different parts of the organisation that will have some sort of channels, but also somebody to oversee it and to make sure that they’re actually accountable for at the end of the day that this person is talking to that person about what was agreed.
44:37
Luke: I don’t think there’s as much oversight needed afterwards, once you get that initial map done, because if it’s done with everyone, they form relation, relationships, which aren’t there otherwise. And that’s part of like the actual mechanics of these silos, right? People have close relationships with other people that are exactly like that.; people within their own little micro tribe. But they wouldn’t even know the first person to ask within marketing, you know? Like, who is that person? First of all right, literally, if I needed to ask someone? Do I just look for people with marketing in their title? It’s almost like a cold approach, but it’s within a company. And ideally, other than the actual knowledge of how things are working, it’s about creating the space where the relationships can start to happen, and across the company, and then that way it just becomes a lot easier to work, it’s a lot more fun to work. And with all of these online tools, it can very much be done remotely. And I know because I did.
45:56
Nelson: Exactly. I mean, what are you saying about the cold approach actually reminds me of when I actually got my first job in marketing, I worked for Hitachi, in the UK, but they’re obviously a Japanese company and their headquarters are in Japan. And it was a very similar like, cold, almost cold approach. So if you wanted to be introduced to somebody who is kind of your equivalent, to find out what how they’re doing in another country, it would technically involve you going to your boss, your boss, reaching out to the boss of the other headquarters, then putting them in touch with their manager, and then their manager, putting them in touch with that person. And then it would reverse and come back. And I’m like, okay, but now once you have that relationship, you can then talk to that person. But you can go from here to there and just send them an email.
47:00
Luke: yeah, yeah.
47:01
Nelson: So I mean, that stuff existed way before we were doing remote working. That stuff probably still exists today. Yeah. No, I just found that and that quite funny.
47:15
Luke: And then because of all of that some people will feel comfortable just doing the cold approach, but most won’t. And then, it’s no surprise that as a result, you have silos, right? You have geographic ones, you have functional ones, there’s all these little micro micro-tribes, you know, with their own chiefs.
47:39
Nelson: There’s a couple of things that it’s about, firstly, knowing who to communicate to, or with I should say, those very poor English. And also making it as easy as possible to do that, because even if somebody knows that that person exists, and they’re the one that they have to talk to, if it’s hard to do that, then they’re not going to do it. I guess, creating the cultural norm within the organization, but it’s an expectation that if you need something from somebody, doesn’t matter who they are, that there will be that kind of two way communication that’s expected of you.
48:25
Luke:Yeah, yeah.
48:26
Nelson: No, I like that. Cool. Well, I think that is a fantastic place to leave things. So Luke, obviously, you’ve got a tonne of different projects, where can people find you? What should they expect from your book? And I think you said, you’re also doing an audiobook version as well.
48:47
Luke: So all of the information as it comes out is on alignremotely.com, which is at the moment, primarily the podcast, but there’s links there also for the work in progress for the book and an audiobook. And, yeah, I’m very happy to answer questions. There’s contact details for me on there. So if anyone wants to get in touch please, please do so.
49:18
Nelson: Fantastic. Yeah, you heard it here, folks. If you want to get in touch with Luke, ask him anything about his experience managing and being part of that remote working environment, or if you’re struggling with your teams, or you’re thinking of setting a new one up, please get in touch with him. And that’s it for today. And we’ll speak with you next week. And that’s it for today. You’ve been listening to the working from home podcast with me, Nelson Jordan. We’ve been talking about the good, the bad, and the ugly side of remote work. Thanks so much for listening. And I really hope you’ve enjoyed the time you spent with us today. If you’d like to discuss the podcast, you want to make a new friend or you’re interested in working with me on a copywriting or digital marketing project, then visit nelson-jordan.com. That’s nelson-jordan com, where you can also sign up to my newsletter to hear about this podcast and other exciting projects. Until next week, goodbye!