My name is Lukasz Szyrmer. If you are new here, I am the author of the book Align Remotely. I help teams thrive and achieve more together when working remotely. Find out more at alignremotely.com. In this episode of the Managing Remote Teams podcast, I speak with Trevor Ewen, CEO of the Southport Technology group, a technology consulting company specialized in serving non-technology businesses. We get rather practical in this episode, specifically exploring flowcharts. While primarily coming from the software world, a flowchart can be used to communicate a complicated idea visually.
In this episode, you will discover:
- Why the ethos and management practices behind building open source software can be quite powerful
- Why flowcharts enable asynchronous workflows because they communicate concisely on a complicated topic
- How to use flowcharts to break down a complicated scenario so that anyone can understand it, even a non-technical user
About Trevor Ewen
Trevor is an experienced software engineer and project manager. He's overseen full stack teams in clean energy, insurance, finance, and media. Notable engagements include Morgan Stanley, HBO, Bloomberg, Honest Buildings (now Procore), RunEnergy, Black Bear Energy, and PRco USA. He has an MBA from London Business School and an MBA from Columbia Business School.
Transcript
Trevor, welcome to the managing remote teams podcast.
Thanks for having me live.
Can you say a few words about, What you do and how you got to where you are at the moment.
Yeah. So I'm a software engineer by training, and I think that's probably the most relevant point of information when thinking about my background, when you do this, you start up your career.
Usually just taking orders from the older developers and learning how to fix bugs and works through the application life cycle. And. Because I graduated from college in 2010, I entered a terrible labor market. So I was ready to take whatever came my way. And I had the good fortune of ending up at a digital agency and started working with some of the bigger companies in New York that weren't specifically tech companies, but had a big tech component to their business.
Think about banks or media companies and the like, and as I went through that, I did. People do at that time, I joined a startup at one point, then joined another small agency and made a lot of twists and turns to the point where I would say I'm relatively self-sufficient in terms of the skills that you can gain in the workplace and wanting to go out on my own and innovate more on the business model side, as well as continuing to do technology services and software develop.
Okay, cool. How you fared under the last year in terms of the pandemic ? how have things been in terms of that?
I regret saying this to some extent, but it was actually a pretty good year for me because it did allow that close time to just hang back, being a force remote situation.
So we were not pushing against the grain, my partner and I at all, everybody was working remote. And so all of a sudden, the talking point that we'd have to have with a lot of people about being a fully remote business and why that's okay for us. It just went away because everybody was doing it.
And that was really nice as a lower point of friction. The other thing I'll mention is I was finishing up my MBA, which actually just finished up in 2021. And so that was negative from that side because of , not being able to be in person for a lot of the education there. some of the positives though, were that we, my classmates and I, lot of other people in the program.
Have to get in the habit of connecting virtually more. And I think that was something that wasn't happening as much. And this is really critical too, because it's a pretty global group of people. One of my early issues going into the program that I went into was, how am I going to stay in touch with everybody?
It just, it's just hard to maintain connections when you know, people are not in your life on a day-to-day basis. And broke us all apart, but it also brought us together in some virtual ways that I find the whole group is a little better at reaching out to each other and said, Hey, are you available for 15 minutes zoom or 30 minute chat?
That just wouldn't have happened as much before. , I'm trying to see the silver lining. there was a lot of negatives. I think of our customers held back their spending a little bit because it was just a wait and see situation. One of our customers are. oldest and most loyal customers in the auto industry.
Going back to the original period in 2020, when lockdown started, I don't think there was a consistent thesis on what was going to happen with the auto industry that turned out to be a record year. And now, the used car surplus is so low that they're getting inflated prices, but I don't think anyone would have predicted that early on.
So there was a little bit of slowness in terms of people investing.
In terms of the patterns of keeping up with your various friends and colleagues in the MBA program, what actually worked well for you?
In-person is always nice. And we had prioritized that, so it was a.
Just for some context. So it was a specifically global program. It was a half at London business school and half at Columbia business school in New York. And so we would actually, prior to the pandemic, we would travel to each one monthly and spend a week together there. And that is absolutely the best part about the program and the fact that you're getting these pretty close relationships with people all over the world.
Obviously once the travel stopped, we were, in some cases, the people from the smaller countries or countries just where they didn't have the ability to travel into Europe or the U S they just had to stay, put and take everything virtually. No, I had the good fortune of being in New York, so I could at least go to Columbia, but I didn't make it back to London after February, 2020.
And, I think everyone was shook up about it. We still had a good year of the program together and they just made a priority to reach out. It's a lot of WhatsApp, as I'm sure you can imagine which we are already doing, but then there was a little bit more of the impromptu zoom conversations.
And another surprising thing that happened is people started building other relationships that maybe had not been so strong before. You get cut off from this existing group of people that you hang out with a lot. And you just can't see them. So you're going to start building new relationships.
So it's very strange to see the, the people I spent all my time with in 2019 and 2020 in the class, I think we're just, with a few exceptions, very different from the ones that I spent more time with after that. And a lot of that just had to do is where were the travel restrictions?
But you mean people locally where you live and not like in the student body.
So it was that there was some local. So obviously yes, there was, I saw the New York people more often, but there was also people who were just more able to travel. For instance, depending on what country they come from, people coming from the UK, France or Spain had an easier time getting into the U S versus say, we had several colleagues from Russia or Algeria.
Those places were just less likely to be traveling. So I think that was the big change and really a shift that was mostly negative for them. And, only partially negative for us because at least we had a large cluster of people in New York, locally. Yeah.
Interesting. In terms of the business, how big is it? What. What types of customers do you have, and you mentioned automotive. How does it work?
The company is called south port technology group and we do custom software development. We're focused on a, I did another show about this recently, but we're focused on a non-technical buyer and some people hate working with this kind of customer.
I really enjoy it. And I think there's a lot of advantages to it. This is typically a company that may actually do, anywhere up to $50 million in revenue annually. So they could, it could be a fairly sizable company, but their primary offering is probably not technology. And they have looked at the budget or at least have a back of the napkin understanding of their budget, that they wouldn't hire developers on staff.
And that's our best kind of cost. One of the things I like about it is having worked. I've done agency work or work by the hour in the past done what is effectively a high-end staff augmentation, where we come in, we were paid very nice contract rates, but we work with the existing tech team.
And a lot of that is covering up, performance or staffing deficiencies in the organization. And so you end up in this team situation where. You're not working with the people that would really help accelerate the project. Usually there's a problem.
That's brought you in the door and some people really thrive in that environment. I think I do okay in it. But I think long-term the culture weighs me down a little bit. So what I've enjoyed about this is these are genuine, only good businesses. They have a technology problem. They have even a good amount of money allocated to solve that.
But the gap is they don't have the amount of money that it would take to hire a dev team, which are really good senior people, two to three really good senior people is going to be over a million dollars a year. So there's a huge gap between zero and a million dollars in your technology planning that, there's a lot of companies who need something right around there.
And we like working on something more boring things, something made with the back office or the operations side of the business. Oftentimes. Personally speak to in the organization. It's someone I refer to as the champion. It is not only thinking of projects on their side, but also thinking of ways to get us doing more projects for them.
It's often an operations manager. Sometimes these companies will refer to this person as an it director. But it's not the way you'd think of it. Then it directors have a large firm, which has a very specific set of responsibilities around network security. They're really more just the person, the man or woman who knows the most versus the technology, the software.
They're like a utility person who has all the planning. Yeah. So it's interesting. We, it's not industry specific auto insurance is one that's one of our oldest customers. We've really enjoyed working with them. We're getting a lot of green energy stuff. And I can't tell if that's just because there's so much growth and need there, which is obviously a story.
But the other side of it is I do know a few people in that industry. So those relationships have propelled us in that direction.
Interesting. You mentioned before the call that you found flowcharts to be really helpful in this kind of remote work context. Let's dig into that a little bit more. Yeah, what why flow charts? What are they helpful?
Yeah, I think that was the original launching point for our conversation. Let me step back a moment and talk a bit about how we staff up a project. So I think you're familiar with the fact that hiring good developers is hard and if you're not, I'm sure you'll talk to many guests who could agree with that statement.
It's one of the things we've tried to do with our staffing up is utilize a model that's very common and open source software. And open source software. It seems almost completely bizarre to people who've not been in this industry, but the idea is that you have a code base that's out there and hundreds, if you're really lucky, maybe thousands of people all over the world can just make contributions to it.
And because they're, hopefully skilled developers or people following the spec, you can actually have meaningful contributions and these things can just get formed. Out of the ether, I think of it a little bit like a home building and Amish communities which is, just everybody from the village to starts coming in and helping to build a home from the home is exactly the barn of the home it's raised up.
It's a similar thing and it's very async and It's just cool. And a lot of great software is created this way. I think that makes some people nervous, but there's really just a lot of the amazing core software that we use in so many applications today is developed in this way.
Yeah. I wanted to do is bring as much of that as possible to our staffing model. There's a couple of things that are really nice. It's about one is it obviously allows you this asynchronous workflow, which helps us with times. Yeah. And we work primarily with offshore developers. So I don't want to keep them on some kind of schedule with us.
I do have to have some overlap just so we can communicate, so there's a certain, degree east usually right around Turkey, we're all, it's harder to hire people farther east than that, just because of the time zone issue. And obviously Europe and south America is fine, especially when you're in the.
And they, they will make contributions just like an open source software developer will, except in this case, someone will be private customer software, they'll make pull requests to it. And because they're working in this manner, I'm also treating them much more like that. So instead of having a morning meeting and saying, okay, here's the priorities for today?
And here's what we're doing. I need to almost have this sense of anonymity with the developer and to do that, we use project management systems like anybody. And the devil is in the details, but in this case, everything's in the details. So we try and load up these issues so that they could be picked up almost generically by any of the developers who work with us.
And we do assign it to certain people. we, they have certain skill sets that we look for obviously, but we're trying to give them something that if they wanted to do this without talking to me, they probably could do it and get the pull requests going. And then for that, you just need a whole nother level of detail.
Documentation's big. You gotta be able to write a lot about what's going on. Explain how a problem works. I use links to code all the time. So I'll use get hub has this great feature where they have links to a specific line in the code and I'll point out, Hey, here's what this is doing. You need to replicate this behavior or something like that.
That's been incredibly powerful. I use a lot of screencasts have a screencast on almost every issue, just like in a walk through something. And that way there, in an async way, getting my actual feedback on what they're doing. And then the last one, and one of the most powerful tools is flow charts.
She brought up and so we'll use lucid chart or draw.io. It doesn't really matter which one you use. And we're creating flow charts that are in a very simplistic decision tree format. So I think you're probably familiar with that format, right? The blocks and yes, no diamonds.
Yeah. Diamonds and rhomboids and parallelograms on an angle and that kind of thing. And arrows of course, between them.
Yeah. Lucid chart. I, I issued Wiziwig tools for a long time. I always said, I didn't want to use a Wiziwig. I want to have a tech space. And there was actually there is one open source, right? Heard that it has a text-based where you could just create a little text file and we'll create the flow chart for you.
But lucid chart is really good. They've improve the product so well that I can build something very quickly with that. I have been using that mostly. And this idea was given to me probably a decade ago by a very talented UX designer. Someone. Yeah. Let a big UX team. And she just said, this is the way I get into every decision makers workflow really quickly.
And I start, making them agree to an actual flow chart because this is going to expose all the side issues and all the other stuff they are not thinking about when they initially asked you for that shiny new.
That sounds really interesting. So someone let's say you're, let's say you're starting with someone and you're working with the decision maker what do you ask them to do? Or how do you actually structure the conversation?
Sure. I'm using flow charts, mostly I'd say the 90% cases for my developers, to give them information
internally,
but I will do it to clarify with decision-makers from time to time as well. It depends how much ownership we have of the project versus them. There's a difference. I'll say there's a different scale. There are certain people who are really particular about what they want and then there's another kind of customer.
And to be honest, I prefer this a bit who, who lets us just take it and says, we'll go with best practice on this one. And that's really nice because it just saves us time, saves us iteration cycles. And because we've done it before we can get them pretty good stuff.
But what I would do with the decision makers they'll come to you and they'll have, the happy path version of it. So they say this should except apple man. I want you to, just to be able to use apple pay now to buy this item and what they're not thinking about is what are all the attributes of that?
The flow chart gets into, okay. If the apple pay transaction is accepted, yes. You pay that's happy path. But on that note, On the, on the rhombus is going to be well, what if it doesn't get accepted? Do we allow users to save their apple pay into the profile or is it something they enter new all the time? Are we allowing them three transaction limit and then saying, Hey, you got to choose another method. Do we have some kind of scam protection for people who might be able to might be trying to use apple pay. That's not theirs. I haven't even integrated with that API. There might be other considerations as well.
What kind of error notifications are we giving people? Are we emailing people later about failed transactions? So you'll have what, in the mind of the stakeholder was just a line, do this, then this, it becomes a much more. Complicated web, but also pretty well-defined. And I think it's the simplicity of it because the blocks are yes or no, a thing happened, you really have to, you have to hone in on what, what happens when that specific problem happens and not a kind of a generalized view.
I do think, a lot of people defining requirements and customers can get, they can get lost in abstraction. When they want to talk about a problem or they'll do the famous, oh, just do it the way Facebook does it, of course you want to tell them they have one of these slow charts back there too.
There's a giant decision tree is probably a team of five or six people who built this thing. So they're going through the same process and they're making different trade-offs in you because maybe they have a more intimate relationship with apple and they actually do have. Some backdoor into the security API or something like that.
I don't think apple provides back doors, but it's just starting to think about why you wouldn't be able to do it the way LinkedIn does it or why you could, and then what is that way? And then let's write that down on the flow chart too. And it's harder to argue with at the end and by the way, it's just great.
It's deliverable too. You give that to the developer. Okay. Here's what we talked through with the stakeholder, go build this and they understand it. It's like magic for them because most code is written in that linear decision like format. If else statements is primarily what you're working with.
Okay. So with decision-makers it's more of a requirements gathering type tools in a way.
Yeah.
Have you ever used it to explore how they themselves make decisions or does that getting a bit too Meda?
It is pretty meta Yeah, I don't, I can't say that I have wouldn't be anything wrong with that.
I think that's an exercise. I'd go through with a closer collaborator, probably more so than a customer. But certainly someone who I'm working closely with and want to get a gauge of what they're actually prioritizing. That would be helpful.
And one of the things I've started to start to think about in terms of the way we're looking at customers, which might be related to this is what is their level of defensiveness. So how bad does an issue impact them in terms of how they view the system and how do we tailor a solution to them? Better help them with that. . I've done very generic up until now, because I do want to try and standardize things as much as possible. It's just something I'm constantly trying to improve on. But I would like to also have a risk scale that I apply to different customers. And I think the decision tree could help because it would say if this person really wants the error notifications and states to be well-defined, and they're probably very concerned about these things happening, as opposed to someone who says, oh, we'll just figure it out.
When the customer is need. And that really is two different personalities that you get. We had a no, a small issues for one customer is, oh yeah, no problem. They'll just email us and for another customer it's well, this is a big deal, right? Part of that has to do with the way they perceive their own business or their brand.
I think it's also the kind of customers they're working with. So if they're mostly consumer oriented or have a fragmented base, Businesses that they work with them. Stuff happens. It's not a big issue. The companies we've worked with who are delivering a product to larger businesses, much larger than themselves, and obviously much larger than us, banks, places like that. They want the systems to work and what that means exactly. We don't take shortcuts on security for instance, but I think there is just a trade off on stability questions. Did we do a one-week testing cycle or a three week testing cycle? That's up to you.
You're going to have to decide how slowly you want to release this, but the three week will be safer for your customer experience. So I think that's the, that is the one area where I'd use it. Cause I haven't started to think a bit more about these risk profiles that people have.
Okay. So then let's flip to the other. So in terms of internal processes, we have clearly for requirements communication and that kind of stuff that that's to some extent where were, where they came from in the first place. What about for things like internal company processes that aren't related to code or delivery or that kind of thing?
Yeah. Do you use them at all? Or how does that work?
Starting to so this is interesting now, so we have two sides of our business, right? My day to day is running the south port technology group arm. And my partner is involved in a business. That is working on acquisitions. So where we're buying small software businesses, either buying the company or just buying them as an asset purchase.
Yeah. And that's a fascinating, different areas, obviously super related. We're working together on it. He steers the ship more day to day. And one of the big things we do there is we use analysts. And yeah. I also have summer interns to work the process. Yeah. Because it's a pretty tight knit sourcing process.
There's a lot of procedures they've got to learn really quick to ramp up on. So we're yeah, we're building up the knowledge base. So we've had a Wiki going pretty much since we started with the intern program and we're gonna move on to some new interns this summer when the summer term starts after schools are out.
And, my hope is to just get them up and running in about a week. And the big thing we do is we source a lot of businesses. So we are pulling down and it just, it's a classic funnel type process. So we're pulling down maybe sick about 10,000 companies and just saying, does the company match on a number of filters?
Now the filters can be listed out on the spreadsheet, but there are some of the more nuanced things. One, I think visualizations are great. I just think people like them, but just how certain are you about something? Cause there's ambiguous. So you could say let's filter our company on, it's gotta be in the U S or Canada.
Okay. Pretty easy to figure that one out. And if you don't have the data point, okay, fine. You can figure it out. But beyond that, it's pretty easy. But then there is, we want to have certain kind of customer service. That's a little more ambiguous, right? I can't quite tell if this product is serving a business buyer or consumer or prosumer buyer.
And in those situations, we want to have flow charts for them. The interns in particular, just look at it and say, how certain about this decision are and always use simple scales, odd numbers, anyone in the creative arts will tell you that. And so it's one to three or one to five usually.
So are you really certain, are you medium? Certain, are you not. And on the really surgeons, we just want them to go with it because it would just waste our time to take a second look on it on the medium toss up, and maybe we have them weigh it on a number of other factors. Is it in a niche we really like, is it, does it look like it's got good marketing or, some other characteristics that we're looking for the business.
And on the low end, you said you got to throw it over the fence. You got throw it over to us. Like you have no certainty about this. And we're trying to bucket these things so that, our interns work with scripts because we, we've developed a lot of automation so that they don't have to manually do this stuff.
They'll just run a script and we'll pull down the data and ask them to rate things. And, we want to have the script and be able to say exactly what the flow chart would say. I'm very certain I'm I meet him certain I'm not very certain and then do something accordingly. So there's a weird way in which that flowchart would allow us both to design the actual system the interns are gonna use, but also inform them as to how they're supposed to make the decision and think about what they're doing.
And it is, a human tendency to just go for the middle one. If you give people three options. So you want to also create a incentive for them to go higher, low. And sometimes that just means removing the middle option as well. Trying to just make sure it's a rare choice or having four, although yeah.
Even numbers,
a lot of the creative people say that's a bad idea, but I don't know. Maybe I should try it. We're big into experimenting so we will try it.
Do they also create these or modify the ones that you have or is it more just something that you thought about, and then like, how does, how do these things live?
So to speak? That's a good question.
I want to get them more into it so far. It has been a pretty one-way street. My partner will do this. He comes from a user research design background. He's very familiar with this and he will go more in depth for different kinds of tools as well, tools that I'm not even super familiar with.
My, one of my things is I'm. I'm like an inch deep and a mile wide, I'm not a flowchart expert, but I do use it aggressively, in terms of how we get these processes, these software processes done. That's probably the only topic I'm really deep on is actually building out the software.
But I want them to do it. I'm like an evangelist in my own company for screencasting. I say, put it in a video, just make it easy. And then also any kind of visual. Charged for it say, you can write five paragraphs or you can give me a pretty quick flow chart on this.
It's not hard to do. And I think the proof of that is, they asked for the license, I'll obviously give it to them. I don't want to give people the license if they are not going to use something anyway. But but if someone is really excelling in doing that'd be fine. And the screencast at this point is, lucid chart is very affordable.
And I actually, I think the free version would give them a little while, but the screencasting is awesome. Pretty much free at this point. I don't know if you've seen the new Google thread that it product. No, I haven't actually, it's very nice. It's a, just, it's a Chrome extension and it's, it's now my screencasting tool.
What I do is just very quickly, let you record a video, obviously record your screen. You can record your camera too, or you can take it off. You could be in the corner. You would, if you want to narrate over the screen and then it integrates directly with your Google workspace organization.
So it can create a link that's only shareable within the organization or a public link for the video. And that's pretty much all I ever need. I'm just creating tons and tons of videos, putting them into different issues in the project management system, wherever. So you just drop a link and then people can watch it pretty much.
Yeah. Yeah. Yeah.
So going back again on flowcharts, so you mentioned that you use them to reduce the uncertainty around how to classify things. Curious about any particular cases where that happens . What does that mean? Exactly.
Sure. Here's a good example. And I didn't quite use the dishes and tree flow for this. It was slightly different and that's probably. Good to highlight here too, is that you don't have to be super strict. I like those decision trees a lot. Cause a lot of times you are dealing with a linear process where things happen and then X X, but this one was actually about a permission system.
And it was a needless to say it was a complex permissioning system. So the customer had spent hours explaining it to me. I had intuited it, a lot of it had to do with the unique characteristics of their business model. So you think about the generic permission system is there's an anonymous user, there's a member and then there's an admin and maybe above that, there's a super admin.
And it's just, it's a Russian doll of permissions, where they're all, the super admin has everything and everybody below him has slightly less. And. Once you get into business use case specific permissions, it starts getting really weird. And especially when different kinds of users based on the kind of user that they are, can do different things and should do different things, especially when you have a two-sided market, which was the case for the system.
And what happened was, the industry is solar power and there was two sides of a transaction. The permissions were set up, according to that, each side did different things, depending on what it was. And on top of that, there was also just a high level administrator and, they could do whatever on the system.
So I would have issue after issue with the developers saying why is this different than this one over here? And I would try and be clear. There was two sets of issues, right? And say, this is for this side of the transaction and this is for the other side of the transaction.
And they would still just come back to me, oh yeah, don't know why this behavior is different than over here. These should be the same thing. They're both users, they're both admin. And I said this is a different kind of Edmond. It's a different kind of user. So what I did is I just finally, know, bit the bullet did the full line chart that just showed here's how all the inheritance patterns work on the permissions and.
Repeatedly referenced that, tech head on about 15 different issues. And all of a sudden, understood like the realization was that the container unit for the permission was the kind of organization that uses or was in. And they had not really internalized it. There was just a big difference.
There's two kinds of organizations and why they would be different.
And then, on top of that, in addition to the hierarchy itself, we had a, a certain amount of description texts at the bottom, just stating, this is what these things are just to let you know right in the theoretical transaction here. Here's what side of it they're representing. So I said that was a good,
that was a good recent one beyond that. It's the day-to-day experience of, I, the thing I always say is you can solve this in the requirements so you can solve it in chat. And so there was a certain kind of person who just likes to have their day broken up into a million pieces by everyone asking them for requirements all the time.
I have no problem with people have genuine questions about it, but, to the extent that I can get them as much detail up front, I want to do that. So creating that flow chart is the thing I'll do before I even tell the developer about the issue. And it's partly out of respect for them so that they don't have to spend their whole day. Figure it out. Yeah.
Listen, there's a certain kind of person, sometimes you're so overwhelmed in your business that you just hire somebody and you say, listen, I don't know what's going on. I need you to track down a bunch of information, but the offs there is you have to pay that person a lot of money and they have to have a level of thinking that goes beyond their specific skillset. So they have to know a ton about your customers. They have to know a ton about the internals of your business. They have to have, an appropriateness meter in terms of the kinds of things they're asking about or the kind of things they're doing.
It's just not something I can rely on any developer to do . Instead, what I want to do is focus on hiring developers. The very specific skill of being good at programming. And then if they have growth that they want to do in some higher areas, that's fine too. Like we can have that conversation, but the vast majority of these guys aren't coming to me saying what I really want to do is piece together, all the various requirements coming from all your customer emails and the nuances of their business, they want to just get to work on something. there is money to be made there.
The people who are willing to do that, that like work and piece it together. That's a, that's an extremely valuable skill. But in my case, we want to keep that money, frankly, on the company side, on the management side, because we just feel like we owe it to our developers to give them clear requirements.
Cool. Yeah. Where do people find out more, or get in touch with you or reach out to do that? So you can check out south port technology group@stgthatsoftwareandthensouthportventuresisjustsouthportventures.com. And you'll see those two sites look fairly similar. People can hit me up on LinkedIn if they like Twitter as well.
Happy to have a discussion I'm at Trevor underscore UN so just my name at the underscore in the middle and yeah, I'm in New York. So if people are around, that's a not a good reason to give me a shot. Yeah, that's great.