How to use flowcharts when collaborating remotely

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.

• Southport Technology Group
• Southport Ventures
• Trevor's social media profiles

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.

On axiology in project management with Traci Duez

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 Traci Duez an expert in axiology, or the study of value, in the context of project management. It's all too common to focus on the mechanics of delivering projects, while missing the whole point of the work in the first place.

In this episode, you will discover:

• What the three hierarchichal dimensions of value are, and why they matter on every project you will ever run
• What axiology has to do with a Nobel peace prize nomination
• When a discovery phase creates or destroys value for the customer and how to go about it effectively
• How to collaborate while taking into account potential biases

About Traci Duez

Traci has been teaching project managers, program managers, and portfolio managers for the past 10 years for the Project Management Institute. how to implement the Project Management Book of Knowledge (PMBOK) with the human souls that work on your projects and in your organization. Traci uses the little-known science of axiology - the study of value and human value judgment to show leaders how to use all three dimensions of value to create an engaged and productive team.

• Traci Duez on LinkedIn
• Traci’s company website: Break Free Consulting

Key Takeaways

People matter more than than the mechanics of projects, particularly how they perceive and generate value.

Transcript

Tracy Duez welcome to the managing remote teams podcast.

Thank you. Pleasure to be here.

Sure. So can you say a few words about how you got into axiology in the context of project management?

Oh, yes. Great question. Axiology was presented to me when I was the director of an it consulting company. I had a lot of project managers that I employed and and it was more from a personal perspective.

At first, when I was introduced to axiology, I took this assessment and I had. Never taken an assessment like that before it took 10 minutes to take and rank two sets of 18 items, and then it spit out this report. Didn't tell me about my personality or behavioral style. Cause I know how to manipulate that.

I know how to make sure those assessments say what I want it to say, but this one this one I couldn't trick in any way. I didn't know how my boss would want me to answer it so that I could show him that I was brilliant. And so I started to look into axiology to say, okay what was this?

Now? I would love to say it was because I wanted to know the science behind it. And I was really curious, but I'm going to be very Frank with you and that it was so that I could manipulate the assessment. The next time I took it. So I could tell my boss what I wanted to tell my boss. But anyways, I found this science and axiology is the science of value and human value judgements.

And I think that's what project managers do is they create and generate value. And so that's one side of it. And then the other side of it is it measures how you think and how you make value judgements. Which is the other side of project management from the project manager side in terms of how do I think and how do I make the best choices in the best decisions in order to create the greatest value.

So how did your boss actually reacts after he saw it?

Great question. He didn't know what to do with it either. My boss didn't react to my assessment in any way. He reacted to his, and it said that he was a creative genius or something. So he was like, yes, this is the best assessment ever. And that he should be running a strategically running the company. See, I told you guys.

It really measures your capacity to think in a specific dimension of value, it doesn't measure whether you actually do it or not. So that's part of it, but he assumed that, because the assessment measured that he's obviously that way and that we just didn't appreciate how strategic and how much of a big thinker he was.

Yeah, it wasn't about me.

Okay. So if axiology is the study of value, then how does it, or you define value then?

That's terrific question. My background is my degrees in chemistry, which, makes me a little bit of a nerd. I was really a lazy chemist. And so I got into kind of robotics and computers and became a geek, which is how I ended up leading an it consulting firm. And so axiology, while when people look at it, they think, oh, this is like psychological or psychobabble or something along those lines. It's actually based in math, it's based in trans finite calculus and set theory. So I told you I was a geek and a nerd. However, it's also very practical.

It's very practical. So when it comes to relating to project management and the science is really about three dimensions of value, where most of our lives, we just deal with. With two dimensions of value. And so that's basically what it taught me and it taught it from a mathematical perspective.

People always say who determines the correct order of these things that you rank? Cause when you take the assessment, you ranked two sets of 18 items and People will say who determines the right? Nobody determines it, math determines it. And so it isn't based on statistics, which most behavioral assessments are like, they'll have you rank these things and then you, they go and they observe you.

And then they come back and statistically say, oh Because she did this, or he did that and these measurements match up then statistically that's relevant. So this isn't based in that at all. It's just based in math. And it's basically, we were asking you does your personal hierarchy of value, which is what we ask you to do rank a hierarchy of that between two sets of 18 items.

Does it match with the mathematical hierarchy of value and then where it does. Is where you have the strongest capacity to see value and to make great choices and where it doesn't. You have what we call a cognitive bias, meaning your brain has filtered out some of the information that it needs to make a decision, a good decision from that perspective.

And so you might not want to use. That thought habit or that perspective to make your decisions. So anyways, it can be very powerful for a leader as well as for a team.

What is, what's this mathematical hierarchy of value? Exactly.

Let me give you the kind of layman's. Terms of this value rather than getting in to transplant that calculus and losing your audience, let's just do it kind of high-level.

So there are three dimensions, hierarchical dimensions of value that everything on the planet falls within. I'll start with the lowest. So the lowest dimension of value is what we call systemic. And so this deals with. Systems as in the name, but it deals with things we make up in our head. So ideas expectations as well as policies and procedures and rules, that those aren't things that exist in nature.

We as human beings create them in our brain, right? So a project plan, perfect example is systemic where we're trying to lay out a system of how things will work. So that's the lowest dimension of value. Now it's not worthless. It's just worth less when you take that system and create something measurable or tangible from it.

So you have your project plan and you create a thing. Yeah, I was in it. You create a program, an application, whatever it happens to be, and now it's measurable and tangible. And so anything that you can measure, you can sense in some way, see taste, smell, measure. Those are extrinsic. So that's the next dimension of value extrinsic.

And when we work in project management, I've read the different versions of the PIM Bach from a project management Institute. The whole book is almost in those two dimensions of value. What are your best practices? And then what are the metrics? What can you use to measure them? Which by the way, that's still a system, but when you actually do the measuring that work that's extrinsic.

And so axiology tells us that those are the two lowest dimensions of value. Again, not that they're worthless. There is value in all dimensions of value. The highest dimension of value is what's called the intrinsic. And so I often ask project managers like what's a successful project. So Luke, what's a successful project.

How do we determine if a project is successful? So I come very much from a products, slanted angle, and I think it's largely based on whether or not it was the customer was satisfied. And not necessarily the internal machinations of it. Obviously you don't want it to be late and all of that, but that only matters to the extent that the customer cares about it.

I love what you just said, because if you talk to. Typical project managers, they're going to say is it on time? Is it on budget? Is it within scope? That's determines a successful project. Those things are systemic and extrinsic. And so I ask project managers when I speak in front of the chapters or different organizations as, Hey, have any of you ever had a project that was deemed successful?

That was over budget late. And maybe outside scope and they say, yeah, sure. Yeah, we have you ever had a project deemed unsuccessful that was within scope under budget and on time? Not so much, but yes, there have been people that do that too well. That's because you're only measuring in two dimensions of value.

And Luke, what you talked about was is the client happy? Intrinsic is about the personal or spiritual. It's about the human experience of the extrinsic thing that we've created from the system. So every project plan creates a product, something, and it, that isn't the greatest value that you can get from it.

It's what does that product do in the lives of the people who are paying for it or the people who are using it? And that intrinsic value is infinitely more valuable than the product itself or the plan that's used to create the product. Does that make sense? Yeah. I It makes sense to you cause you, you had basically said that early on, but we can show that mathematically.

So the system is a one or a zero. And the extrinsic is a number you can place a value on a pen that I have or an iPhone or whatever. There's a certain value, a thousand bucks or whatever it is, but that tool, that product is invaluable depending on how you're going to use it. So taking the iPhone, especially now in the pandemic, that's the only way we get to see people's faces sometimes.

And. When my mother-in-law passed away last April, that's the only way we could say goodbye was through an knife, not, I was one of those frugal people that said, God, who would pay a thousand dollars for an iPhone. Then when it came time to use it in that way and experience that thing, that extrinsic thing in that way, it was priceless.

I'd have paid whatever I needed to pay in order to say goodbye. And that's how axiology fits into to project management. Although we've been trained so often to just focus on the low or two dimensions of value, the extrinsic and the systemic, even our schooling teaches us that right.

Is it just a matter of perspective on that this the customer perspective on to all of it? Or is it more than that?

Yeah, that's a great question because. It's a little bit more than that. The whole basis of axiology, if you trace it back to, and I'll talk about formal axiology, which came about in the fifties and sixties a guy by the name of Robert S. Hartman put this together. And he was it was actually German raised in Germany fled the Nazi regime and. He was a genius. He had a PhD in math, PhD in philosophy. He had a JD law degree just an amazing man. And when he fled Germany, Nazi, Germany, he made it his life's mission to organize good the way he saw Hitler organized evil, and that.

Mantra went with him throughout the remainder of his life. And he passed away in 1973 after he was nominated for a Nobel peace prize. So here's a guy who had to figure out one thing. If he was going to organize it, he had to know what is good. And so how, and this goes to what you were saying in terms of subjective, right?

So how do you know what a good product is? How do you, what's a good project. Let's just say you're running a project, Luke. What's a good project.

Something that's serving some kind of needs of a particular person or a group and yeah, and fully serving it, not just attempting to, but actually doing so. That would be my definition.

Yes. And that's not too far off by the way, from what Hartman discovered, because people, if I were to say, okay, what's your definition of good. How would you define good.

Good. Okay. Nothing is good when.

Clearly when it's not a bad thing, it's a good thing. This is where people go, look, thank you. Because this is where I went to. It was like it's not bad. It's not evil. So we're describing it by telling you what, it's not right. We're giving you a definition. And then some people will say, oh it's it's beneficial.

It's productive. That's what. That's what good means, right? It's it doesn't cause any harm. Okay. If that is the true definition of good, how can we have a good criminal? Wow.

Because you can say, oh, that guy's a good criminal, but what are you really meaning? You're not meaning he's beneficial. Robin hood is in that category now. Yeah. A good criminal is a guy that gets away with whatever crime he's committing or she's committing. That's what we would consider.

Yeah. Good, good. As an effective, but not necessarily good as in. Good. Not in terms of that, right? If it all depends on how we define the word. Good. So Hartman spent a decade trying to figure out because of this mess that we'd gotten ourselves into here, he's trying to figure out a definition of it.

And he said that a thing is good. This is what he came up with when it has all the attributes needed to fulfill its purpose.

When it has all of the properties. Needed to fulfill its intention. So now the subject, if part is the intention or the purpose, and then we come up with the attributes to it. So for a good criminal, I'll just go with the criminal, right? What's the purpose. The first let's say they're they steal stuff, right?

The purpose is to steal stuff and get away with it. And maybe even resell it on the black market, whatever. Okay, great. That's your purpose? What are the attributes that you need to be a good criminal? And in this case we could come up with some, would you agree? They need to be stealthy. I don't know what fine black clothing.

I don't know what it is, but you can just put a little cartoon together. Okay. So thinking of your current project, what's the purpose? And this is where most project managers, I just want to say fall short, but I don't mean that it's intentional or that it's just that we end up focusing on attributes and properties before we fully focus and hash out the intention or the purpose of the project.

Part of that, I think is just that it's actually quite hard. you need to do discovery and that costs time, that costs effort, it takes a while before you really get at the essence of the problem that you can solve often. And if you make a plan before you've gotten there, then you know, the value of that plan is limited.

Absolutely. And that's where we see people cutting back as well. We see people cutting back on the discovery and the requirements and coming together to decide, Hey, these are some of the requirements that we have. Are we going for all of them? Or which ones are we really going to focus on? And what's the clarity around the purpose and the intention of this project. That's what we need to spend a lot of our time.

There and okay. What are the attributes that we need in order to complete this so that it satisfies all dimensions of value. So that delivers systemically it's effective, it's efficient in getting it out. It creates a product or service that is measurable, tangible, according to the parameters that we decide. And then it impacts the lives of the people. Who we want to impact who are going to be impacted by this and focusing on all three dimensions of value here at the very beginning, because the rest of the project will fall out.

And if your team knows very clearly what the purpose and intention of this project is and what the intentions are of it are not, which is where scope creep comes in, right? They start this with make up their own things. What it's not intended to do now. Those self leading teams that we want. We start to have them because we all go always go back to this purpose or intention and we know what a good one is.

So how do you going back to this discovery? How do you make sure you don't burn too much of the resources you have on discovery?

Another great question, right? How do you make certain that? One of the key reasons why we either a burn too much or B end up creating a product or service that doesn't serve our clients full, fully their needs fully is because we don't Keith Ferazi calls team out.

We decide who is going to be impacted by this work. And those are the people we talk to. That's it. And so this is going to be I used to work in pharmaceutical. So this project is going to impact the quality assurance laboratory. And so we'll talk to the quality assurance laboratory and we'll talk to.

The people over the quality and we'll talk to the VP of quality and then that'll be it. But we don't talk to finance. We don't talk to research and development. We don't talk to any of those folks. And so we end up with a perspective that's very narrow. Now. I'm not saying that we take the attributes from finance, from R and D from the other marketing.

We don't necessarily take those as part of our equation, but we take time to go talk to them and say, Hey, this is what we're doing. Does this, can you see this impact you in any way? And you may get some really amazing ideas that could actually save the quality assurance department. A lot of time, a lot of effort, a lot of money.

Yeah, we don't team out that way typically, because we think it's going to add more scope to the project. When in fact it doesn't have to, it may actually take away scope from the project because you may find out that they have a system that you were going to recreate that you don't need to recreate. No.

I don't know. So for me, that part of it, how do you know when it's too much? It, I think we always assume that we've done enough and we haven't and you don't, it doesn't need to be a big burn rate to do that. Just include them at the very beginning.

I'm just trying to figure out how to fit it into more of a project framework, as opposed to product as in product there's concepts like continuous discovery. In certain contexts, it's going to be much more natural to work towards more of a project. You don't want to burn a lot of just the lapse time, not even resources, but elapsed time on discovery when you've got to go and create value or the sum of it, even if, because then you won't have enough attributes to actually. Create the thing at the end, that's going to make the customer happy in the first place.

Part of that loop is also, we tend to focus a lot on it, more so than the team, more so than the individuals and people on the team. Do we typically figure out who on our team can see intrinsic value really well. Can see extrinsic value really well or systemic. I will tell you the answer is typically no, in the tens of thousands of people that I've worked with because it's usually the systemic person who is the loudest. And that's usually the one that we listened to. It's the one who understands the systems and the processes and this, and they dig into these details and blind everybody too. The other dimensions of value. And we ended up focusing there on the lowest dimension of value and then the loudest, because they're usually the most emotional direct demanding, because systemic thought occurs near the part of the brain that is right next to the emotional part of the brain, the rational logic peer in your prefrontal cortex, doesn't create a whole lot of emotion, but that's where the extrinsic part.

Of our project is thought of. And then the intrinsic is in the deeper part of the brain where the feelings and emotions are around. What's this going to feel like when it's done, what's this gonna look like? And so certain people on your team have abilities and capacities in each of those dimensions of value.

And. We don't always listen to them, especially the intrinsic people. Cause it's hard for them to come up with the words while the systemic guy is going through all of this stuff. Or even the extrinsic is going through all this knowledge and stuff that they have. And and we're not listening to the other side of it.

Because there's no place for emotions in business. Is there.

To change topic a little bit and slightly? What about dependencies? So things like resource dependencies or dependencies within a plan in terms of like task breakdown, that kind of thing. How do you see that through this extrinsic view this third view, third eye view,

the third I view the intrinsic. As you're putting that plan together,

how is that typically accomplished?

Okay. So for example, on the resources side, I think quite often you've got a fixed pool of resources in the company you've got, would say a handful of projects going on at the same time. And then there's a certain people whose skills you want on certain projects at certain moments in time.

The thing that I've always been trying to avoid in that kind of a context is that we don't want a situation where the client is forced to accept things that are only possible because of internal constraints, for example, such as resource constraints. That's just like the resource one, then there's similar, like ordering task type dependencies, you can also potentially talk about, what are your thoughts?

so I find that, and I don't know if this is the case for you, Luke, but I find that in many organizations. The project managers are given the project and they put together the plan, and then they're given access to these resources and then they've got to figure out how to use those resources to deliver what they've been asked to deliver. And it's a very non-collaborative problem-solving process to get these things done.

And. I believe in a more collaborative problem solving process where we get together. And we talk about what's going on and we talk about what this means to the company, what this means to our clients, what this means to the team, because there are some team members who they're in this bucket of having these certain skills and they're just tired of it.

Like they're really good at it. I was really good at managing projects and I hated it, but they just kept having me manage and manage more projects because I was good at it until finally I had to quit in order to do something I really wanted to do. And that's the intrinsic side of it. You can get so much more from people when it's measured between 40 and 80% more cooperation productivity, and buy-in from people when you see them as human beings, but most of the time in a corporation and in these kinds of environments, we see them as human doings and we are actually lowering their productivity, lowering our delivery,

our effectiveness, are efficiencies because we don't see them as human beings. And so how can we collaborate more? What collaboration is all around questions. And so we teach a collaborative problem solving process where we bring people together. And not only that, but we understand what a person's skills are, but also what are their desires?

Who is it that they want to be? Not just, what do they want to do? And why don't you sometimes when I ask people, who do you want to be? They'll say yo, no, that's not. That's still what you want to do. Who do you want to be? Is a completely different one question. It's what kind of man, woman, individual do you want to become like at your funeral?

What do you want people to say about you? Do you want them to say, oh my gosh, that Luke, his Gantt charts were priceless. The colors. He had really great risk management plans. Oh my gosh, that Luke was just, this might not be like the top of the list thing you want people to say about you. So what is one thing you want somebody to say about you at your funeral?

And just for instance, I don't mean to kill you off.

I'm dead. I'm dead. Okay. They'll say that. Yes. Yeah. How do you want to be described? What kind of words do you want to hear? From your family, from your colleagues, how do you want them to describe who you are?

I think I've already heard some of it, but certainly kind is something that seems to come up and it's something that I try to focus on with varying success, but yeah. Yeah. In that let's use that as a that's fine. Absolutely. And so the, every role that you play in your life, you want, you only want to take on roles where you can practice being kind, which is probably almost all of them, but you want to have all of your roles, your extrinsic roles, support, who you want to be intrinsically.

And when we have that matched up, there's a formula. It says be times do equals have when, who you are aligns with, what you do, you're going to have great success. You're going to end your Workday feeling fulfilled. In organizations, when you allow that when you create an environment that allows that to happen. That's when your question about dependencies, not that there aren't arguments, Luke don't get me wrong, but that's when they take care of themselves because you know what a good organization is. You understand what the purpose of your company is. Then you understand what the purpose of your projects are. So you can understand what good attributes are to those. And then you use the intelligence, the emotional intelligence, as well as the technical intelligence in your organization. To keep everybody moving in that direction.

The other aspect of it is you understand what people want, who they want to be and what they want to do, and you get them all moving in that direction. So dependencies has to do with this collaborative problem solving where you pull everybody together. You talk about the problem. The problem is we have limited number of resources and we have these three high priority projects. Okay. So how can we accomplish our goals for our customers with this constraint?

And you break everybody out, three people into a group, and here's the question. What's your solution. What's your solution. You will end up collectively with a much better solution than any one, two or three project managers could have ever come up with on their own. And people say, oh my gosh, we don't have time to do that with every question.

Okay, then keep delivering lower level projects, but it doesn't take that much time. It can take 15 minutes, 30 minutes and you will come out of there not only with a great solution, but with buy-in from the rest of the people, they will feel intrinsically valued. Like you valued them as human beings, not just human doings.

And those are the processes that a lot of companies are missing. And so when I go into a company, these are some of the things we implement and right away, they start to see value from those processes. It's not just about the technical side in many cases.

How does this apply in an agile environment?

I give talks on agile all the time and how the agile manifesto fits right into The hierarchy of value.

I forget the agile manifesto. Now it's been a few months since I talked about it. They say, Hey, we value the things on the left, but we do things on the right more. It's true. Actually, illogically the things on the right are more valuable. Then the things on the left. So it fits very well into that framework and in agile and a lot of when we get into like self leading teams and things like that being able to take a look at. And teach people the hierarchy of value and how to use their best thinking to make choices rather than using their biases to make choices.

But just raising that level of awareness increases the results and productivity seven to 10%, just one simple that level of awareness. I love working with folks who work in an agile environment. Because. It is about short sprints to value, basically.

More and more. I hear the opinion that, especially these big scaled agile frameworks, they're becoming almost more waterfall than waterfall yeah, precisely because they don't have that manifesto aspect to it. It's just super, detailed monitoring and planning out months ahead of lots of teams. This isn't what it's about supposed to work. If you really get at the essence of the spirit of it. Even though you're using the rational the first layer stuff, the system stuff.

For me, my perspective on seeing that happen, exactly what you described is because it's more from an emotional standpoint, people are afraid. And so they believe that if they get all of these months and months planned out in advance, we have something to which to hold people accountable and that makes them feel good that they have somebody to yell at when the value isn't delivered.

I believe I'm going to yell at people. Yeah. And excuse me. Fear has a lot to do with what you're talking about because agile isn't meant to be that way. You have to trust in order for agile to work. Yeah, absolutely.

How was this approach relevant for team leads or leaders?

For leaders themselves, this is all about self-leadership. And I think a lot of times we want to go learn leadership skills when we can't even lead ourselves. How many times have you said, oh, you know what, I'm going to start. I'm going to start my exercise program on Monday. Because you can only start things on Monday. For some reason. I don't know why you can't start on a Thursday or whatever, January 1st.

Yeah exactly. And so we can't even lead ourselves to do the things that we say we're going to do, but we're going to learn leadership skills in order to lead others. And I think that putting the cart before the horse, as they say sometimes gets in our way and it erodes our confidence.

And so we think, oh crap, I can't even eat a salad instead of those big burgers or whatever. Even though I told myself I was going to, how am I going to lead this team? When you become a better self leader, leadership naturally flows from that. And that's what this can help with figuring out what's going on up here in a way that allows you to be a better, you.

Which allows you to do better things and then have greater success.

During the last year, has there been any difference in terms of how it applies to remote teams compared to how it used to be?

What we're discovering? As a use of this over the last year is really helping. And this may not be directly associated with specifics of project management, but it's just of people in and employees.

And we've really looked at it from a mental wellness perspective because we've noticed that teams that previously were thriving are now. What they call languishing. So it's not that they're depressed or terrible. But they're not thriving either. They're not flourishing, they're in this language.

And so what this, what we've found is that this, our tool helps people understand what's going on up here and how to shift their perspective so that they can see. See ways to thrive in ways to F to flourish and really increase their own emotional intelligence of what's going on. So emotional intelligence, I believe in a model where thoughts create emotions.

And emotions, give us the energy to take action. And the action leads to our results. I call it a tear model T. And so a lot of us see our actions and we see the results. We see the top of this model, but the emotions and the thoughts, we don't really have any insight into. And so this assessment gives us optics into our thinking.

That's creating these emotions. And once you can see that you really are able to. Look at it and make your own choices and decisions and get out of the languishing and shift into the flourishing again. That's fascinating. Yeah.

When you get started within you company that you're working with or somebody wants to just even get a sense of, is this the right approach? What do you do or what should they do?

One of the things that as I talked to, I don't know how many, it's over 70, 80 PMI chapters around the world.

One of the things that I do is I offer a free assessment so that you, that assessment, that Dr. Hartman put together that measures how individual people think and where they think the best, but also where you might have some cognitive biases. I offer a free assessment and a, like a really short. It's four, 15 minute videos course that shows you how to use the report. This report, isn't about putting you in a bucket it's about helping you understand how you think and how to use your cognitive assets better.

by the way, in this assessment, unlike personalities and all that, you don't need to share your results with other people because this isn't about.

Your boss treating you in a certain way, because you're a green or you're a yellow or you're, whatever. This is about you taking accountability and responsibility and ownership of your, of yourself, of your thoughts of your talents and bringing them to the world. So what we do is we assess your team and we compile the results.

And I can get a link for your listeners to just go try it out, take that phrase and you'll learn more through that process. We can probably put it in the, we just put it in the show notes. Absolutely. Absolutely. Yeah. It's pretty simple. It's my VQs VQ. M Y V Q S because as we measure value judgment, quotients.com and then we'll put slash.

Great. Where can people reach out to you to find out more other than your survey?

Then my survey LinkedIn is usually the best place to to reach out to me, just I don't know that there's too many other Tracey do as it's Tracy with an eye out there, but delete, reach out to me on LinkedIn. And and then we can continue the conversation and you can ask any questions there as well.

I'm there almost, so that's the best way.

Great. Thanks a lot.