Transcript: Digitization of Effective Team Building Strategies of Major Projects

Those groups that feel that they can talk to each other openly and honestly without fear of ridicule or punishment tend to be far more successful than those groups that don't. If that's an accepted fact, what does that mean in reality? And where does technology play a role in potentially in that? I think how to establish psychological safety tends to come through behavioral norms and those rules of engagement, because it's the norms in the end, they set the culture of the team. Culture is the things that we feel we can or can't talk about.

And so setting the right norms, going through the process that creates the norms and then training your leaders and your managers to be highly competent in that process is going to be the way that one builds psychological safety. It's about process. It's the application of process that makes the difference. So the application is a skill, but you've got to have the process in place first. It's all in the setup.

Most people look at blockchain technology, particularly around smart contracts within a project environment and say, yep, well, from a technical point of view, and particularly a commercial point of view, we can see that this do X, then Y happens, works quite well. My argument is, well, why limit that to technical and commercial? Why don't we put in these activities that have been found to generate better team outcomes? There's a requirement to do this. It's not optional.

At the moment, things like creating a shared vision or talking about roles and accountabilities are things that are on a project manager's list. But they're a checklist. There's something just go tick tick. There's no proper application of the process and what I see in the potential to actually go no. If the project cannot progress beyond a certain stage until these different components have been put in place, because if we don't put them in place now, we spend the time one way or another picking up and trying to correct the mistakes that we've made through not putting these processes in place early enough.

And if we do these things, we have a much higher chance, not a guarantee, but we have a much higher chance in major projects of getting a successful outcome. Hello and welcome to the Constructor Podcast, The Best Way to Build It, Episode Number 91. I'm your host, Brittany Campbell-Turter, and this podcast is dedicated to helping property owners have certainty in their decisions about their construction projects. We talk about fostering trusting relationships, help you to understand how to lower risk, be under budget and on schedule, and most importantly, exceed your end user's desires.

In the last episode, we spoke with Amy Wan Esquire, founder and chief legal hacker at Sagewise. Amy was previously a partner at a law firm and original general counsel of real estate crowdfunding startup. We talk about how Sagewise provides dispute resolution for smart contracts and what her thoughts are on the future of smart contracts and how to respond to more enterprise needs. Lastly, we talk about how private and permissioned blockchains can provide more flexible scenarios. Today, we're speaking with Tony Llewellyn.

He's the collaborative director at Resolex. He's the author of two team coaching books, Performance Coaching for Complex Projects, Influencing Behavior and Enabling Change, and the Supporting Toolkit, the Team Coaching Toolkit, 55 Tools and Techniques for Building Brilliant Teams. We review team dynamic and how the industrial age has conditioned us for productivity, but has gotten us to a stopgap. We talk about how blockchain can teach us about effective teams and resilience within those teams. We talk about Tuckman's stages of development, resiliency building, and how to build effective teams.

With that, let's get into the interview. Today, we're speaking with Tony Llewellyn. He is the collaborative director at Resolex. He is also the author of two team coaching books, Performance Coaching for Complex Projects, Influencing Behavior and Enabling Change, and the Supporting Toolkit, the Team Coaching Toolkit, 55 Tools and Techniques for Building Brilliant Teams. We're here today to review the team dynamic and how we can learn about how blockchain can teach us about effective team and resilience within those teams.

Tony actually did a presentation to the Construction Blockchain Consortium, which is how I learned about him. And it particularly talked about how blockchain technology influences team behavior. So, Tony, welcome to the Constructor Podcast. Thanks for having me. Yes, happy to have you.

So you've been in the team coaching, team dynamics realm, and you have industry background, construction-based background. How did you get interested in blockchain? Blockchain is a fairly new area for me to, and I really don't claim to have any great expertise in it. I was asked to come and talk blockchain conference and I accepted on the basis that it would force me to go and explore something that previously had just a limited exposure to. What I found most interesting is I delved into different articles and looked at the ideas that others were talking about within the context of construction.

But it's really major projects is my area of interest. What was the idea of smart contracts and how they could be used to coordinate and to add a dimension to the technical and commercial process of development by refining the detail and connecting the client or the project sponsor more directly with the supply chain of those guys who are delivering it. So my interest was less around efficiency and much more around how does one add in a behavioral framework into the process that becomes consistent and so allows the entire team, the much wider project team or the team of teams to work as a coherent unit, all focused on the same objective, working in the same direction.

And I think that focus on removing waste. Sometimes that includes the intermediary and just sharing the information transparently. Really interesting about the behavioral framework aspect and we're going to dig into that a little bit more. How do you see gamification affecting behavior as you're investigating this? I use games and have used games quite a lot in the past as a learning methodology.

What I like about that gamification process is a way of encouraging people to explore something that otherwise they would avoid because they would immediately assume a risk based position. No, I'm not going to do that because it's not been done before. I've not seen it done before. So using gamification, the game element to say, well, we could try this and take a chance, see what happens. But it's in a safe environment.

And certainly when one comes to think about lean, I really see the lean to work in construction in particular, the environment where people feel safe to take risks is absolutely crucial. I threw gamification in there, but I'm curious also as to the concept of governance within blockchains. How does that fit in your perception of blockchain? Are you familiar? Are you that familiar with that?

So governance to me is one of the crucial elements. I look at success in a project as working around three core components, which are a technical intelligence, those things that we do. That's what we pay to do. That's what we know. That's what we learn at university.

We've talked in our career, but there's then also the commercial component because the money and risk and those processes that every organization has to manage, whether it's financial risk or reputational risk, those things are also important. But there's a third element which is critical to project success, and that's the social intelligence element. And that's the one that's normally regarded as, you know, people call it, you know, it's the soft stuff, soft skills. It's almost as if it's too difficult to learn and too imprecise, and therefore we can't spend an awful lot of time dealing with it.

But I would argue is the other way, but actually it's the third component. There are social processes we'll talk about a little bit later. When you look at them, they make perfect sense. There's no reason why we wouldn't do them other than most people don't, and therefore they're rushed through. What I like about the governance element of blockchain is that in my version of the perfect project, project managers and project leaders are paying equal attention to all three of those elements rather than just the technical and the commercial, and that the governance process requires them then to pay attention to the social.

Yes, very valid. So the industrialized age has really been influenced by Frederick Winslow Taylor, and that I would say that that revolution came with. And we've had a lot of productivity gains, but there is a particular reductionist thinking. That connects with that as well. I think personally that at times we get stuck in that mentality of, you remove so much waste.

Sometimes we're not thinking about that human interpersonal team building relationship. So my question to you is, how does that connect to your idea of teams and the potential that blockchain has? So if we take that kind of Taylorist idea, which was that essentially human beings are working in a repetitively skilled environment, and that once somebody knows how to do a job, which they can be taught and trained to do, if they do it, if they don't choose to do it, then somebody else can come along and do that for them.

Those ideas grew in a period when the world was relatively straightforward, the process, industrialized process was relatively straightforward. What is interesting about large complex projects in today's environment is that they rarely work in a planned and complicated environment. It's nothing wrong with complicated. Complicate, we can control, we can manage complicated. But as we move into complex and there are so many moving variables, that idea that one can distill a production process down to a series of sequential activities becomes much more tenuous.

And of course, therein lies the challenge with blockchain, which is that it has somehow or other, it's got to take into account the fact that we don't know all the variables at the beginning. But I don't necessarily see that as a problem. I think that's just a way of how the system will evolve and how it will be designed. More crucially, however, is the way that the technology might be used to start to require the role of the leader to shift. So that if the role of the project leader in the past, based around that command and control paradigm, where all knowledge sits at the top of a hierarchy and it's just a matter of requiring people further down the hierarchy to do what they're told to do.

Now, modern management thinking is continually exhorting managers to let go of command and control, because all the comfort that comes with that and to accept the world we live in now is much more rancid and react. So if that leadership skill needs to shift and it takes on board, not just, as I said before, the commercial and the technical, but also recognizes that social element, then the requirement is what are the activities and processes that are known to have a positive impact on behavioral norms so that you are creating a team that is able to sense and react, to look at the information they've got, make decisions around where they stand at a particular time.

But then as information changes or as the environment changes, they're able then to quickly adapt and keep the project moving forward. Let's start to dig into those activities that build the effective team norm. Well, there's a model that we'll come to in a little while. But what I found in the research that I have been doing and continue to do into effective project teams is that before a team to work effectively as a group, there are three components that need to be in place. One is that the resources need to be there.

Essentially, the money's got to be right. Any team that goes into a project where they're hoping that the money will turn out right, it's not going to work because in any kind of commercial enterprise, if you're not going to make the profit or indeed you're going to make a loss, that is going to affect a commercial team will behave. The second one is that the project requires a level of leadership that is able to move the team through these processes that are often ignored or they're treated as a sort of tick-box exercise, which have been found to make a difference.

And then the last component is that one has a sponsor or a client who is competent enough to make the decisions to set the brief and continue to develop the brief along with the project team. I say that because we can then follow that framework or a model to the letter. But if those three components aren't in place, then the team has a problem. And to me, that information is valuable because I would say as a project leader, you don't go forward until you've got those three elements bottomed out.

And of course, that's in an ideal world. There'll be plenty of your listeners sitting there saying, we don't have a choice. This is just, you know, we are where we are. So in an ideal world, that would be how I would try and control my project environment. The client being able to continue to develop the requirements throughout, to really develop the requirements and needs and be able to make those decisions quickly and adequately throughout the entirety of the project is essential.

I'm just really glad that you mentioned that. Too often, clients, sponsoring organisations don't understand the resource that they're going to have to put into the project throughout its life. They either put the wrong people there, they just don't understand the scale that's going to be required, particularly in designing a building that's going to be for their use. My argument with those in the construction industry who perennially blame the client for their problems is to say, well, it has to be on us to help them work out at the beginning of the project, have the open discussion with them, let them make sure they understand.

This is what your commitment is going to be. This is what we need of you if this project is to work to this plan and get them engaged in a dialogue about it. Absolutely. Completely. 100% agree with you.

Did you have more activities that you wanted to share with us? My step one is about assessing the project environment. In terms of the question around, OK, what are the determinants? What are the things that are important in terms of creating positive behavioural norms? It's really interesting how the research on effective teams comes back over and over and over again to three key elements.

One is a shared vision of what we're trying to do. And the key word there is shared. I'll just talk to you quickly about the two, the other ones. The second one is having clear roles. And the third one is an agreed set of rules and engagements.

So going back, point about the shared vision is that anybody who looks back at a successful project and says, well, what were some of the features that we're continually here is we were all on the same page. We all knew exactly what we had to do. In some ways, you might say, well, in construction, it's easy. We're just trying to build a building. That's not a shared vision.

The shared vision is much more around what are we as this collective group trying to do? How are we going to get there? And sharing comes through talking about it. So back to my point around social intelligence skills within a project leader. This is not a discussion that one hammers through and says, right, what's our vision?

And people check up a few sentences and we go, right, that's our vision that we'll do. It's a slower discussion. It's one that's going, well, what do each of us want from this project? What is the thing that's going to make a difference to us? It's kind of discussion, I would say, requires a good hour, hour and a half.

You know, it's not something that needs to take weeks, but it is something that requires everybody to contribute to. Second one around clear roles. I find the word roles and responsibilities. People use that phrase a lot. My sense is that it's just about alliteration because nobody really has a clear idea about what responsibilities really mean.

And I far prefer the phrase roles and accountabilities. The difference being within an effective team, it's what are you prepared to be accountable for deliverables? So within the team, these are the things that you're doing. What are you prepared to actually say? Yeah, out loud and in writing, you can hold me accountable for delivering X, irrespective of whether other people don't deliver.

You can hold me accountable. I will get this done is a very clear feature of effective teams. I've tried to avoid the word high performing because in reality, a genuine high performing teams, you rarely find them outside of the military or groups and individuals where their lives depend on each other working that way. An effective team works fine in most commercial circumstances. And then my last point around, I use the phrase rules of engagement.

And I like that better because we've slipped into this idea. We have a team charter. The team charters are a more common part of a project manager's toolkit these days, but they tend to be ineffective. They have too much information in them. Mainly, they're not co-created.

And what I mean by co-creation is back again to a discussion that says, OK, guys, when we're together, how are we going to work together? When we meet, how are our meetings going to work? It's the mundane stuff around what's a good meeting. Is it acceptable to turn up 10 minutes late? Is it acceptable to sit down and flip open your laptop and start reading your email?

Is it acceptable to send a substitute team without telling anybody? Is it acceptable? And so on and so on. The point is, as human beings, if we feel we have made or contributed to the making of the rules, we tend to be very good at making sure they're then implemented. And if we don't feel, if we feel rules are imposed on us, then we can quite often go to extraordinary lengths just to gently subvert them, just to make a point.

And it's when we come back to this point around behavioral norms, behavioral norms are the norms that a new person coming into a group will see that are different to those that he might have seen in other groups or projects he's working on. But once he sees them and sees everybody following them, then that's what he does. So in that project set up process, you have this one shot opportunity as a project leader to set your behavioral norms. And if everybody feels that being part of their creation, they start to become embedded and then they continue to roll.

In the same token, bad behaviors work in just the same way. And therefore not paying attention to getting a set of clear rules of engagement. You can see a lot of bad behaviors just, well, nobody seemed to worry about this, so I'll just continue to work this way. It's all in the setup. You hit some very key components here.

So you talked about the requirements that a leader really should have at the start. Resources, leadership skill, social intelligence, being able to continue to be engaged throughout the process, shared vision, establishing clear roles and accountability, and then getting everyone to agree on how they're going to be engaging throughout the project. So let's talk about the Tuckman stages of team development and your opinions about that. When I lecture to my students, I ask the question, OK, so what do you know about team development? Most of them can rattle off forming, storming, norming, performing without really knowing quite clearly where it comes from or even necessarily what it actually means.

Then he later added a fifth one, which was a journey. But that doesn't rhyme quite as well, so it's not quite so memorable. These were based on observations he made back in the early 60s. It certainly wasn't originally based on any form of scientific study. As a model, it does largely hold true, and I quite like it as a base point for discussion.

One of the crucial things is that the big people don't really understand is the storming stage. And particularly from work, say, in construction, which is projects are formed or delivered by groups of professional specialists coming in from different areas. A group comes together and it forms. And then that forming stage, the point of forming is that everybody's looking around the room and working out how is it going to work here? What are the rules?

Who's doing what? Who's in charge? And what's the natural pecking order? And this is a subconscious process. Now, within large organizations, large corporations, there's then that sort of natural pecking order will be a reflection of internal politics and internal structures.

A study done by a woman called Connie Gursic back in 2007, 2008, she noticed that actually in professional groups, that storming stage isn't so obvious. So it probably exists to a certain extent, but it's not something that one would always see, because if you're an engineer or an architect or a contractor, you're there because you've got a fairly clear role and your position in the hierarchy of decision making is understood. As a group of individuals, yeah, there may be a little bit of sharp elbowing just to try and establish, particularly if there's some big egos around the table.

But otherwise, professional teams can move very quickly from forming to norming. Now, that's the challenge, because if you don't take that intermediate step to shape those norms, you end up with something that you might not necessarily want, because lots of bad behaviors come in from previous projects or previous teams. The interesting question is around a move to the word performing, because the inference in performing is that one is doing a good job. Well, that's not necessarily the case. And when the team dynamic is poor, and it's one of the crucial things to understand about behaviors of groups is when we're sitting around the table and in the calm light of day, when everything's fine before anybody's under any real pressure, then most of us behave in a very polite and rational way.

When we become a team, however, is how we deliver under pressure, how we deliver to a tight deadline, how we deal with bad news, how we deal with change and how we actually react collectively to find solutions as opposed to instinctively going into a blame response and just assuming that we're helpless because it's somebody else's fault. So this performing word could be, is it poorly performing or is it strong performance? Or is it just mediocre? Just mediocre. And of course, just stumbling through, which of course is in reality, that's what most of us do.

The model, I think, is fine. His final bit around adjourning was recognizing that teams need endings. We know human beings, we need endings. When things just stop, some people find it quite traumatic. You can be part of a very tight team, which just suddenly ends.

It's a bit like losing family for some people. There is a process that should be added in at the end, which is around how to help people end the project and move on to the next step. So you mentioned quite a bit about performing. And I wanted to ask the question about developing that resiliency within a team. How was that developed?

Resilience, I think, is an interesting word. One of the words of this decade, one sees resilience in individual resilience and corporate resilience, resilience in the built environment. And of course, what we're talking about is how do we respond to difficulty? How do we respond to problems, to challenges? But really, actually, it's how do we respond to substantial change?

And in a world where one can quickly find oneself continually overcommitting, becoming stressed, team resilience in some ways is quite distinct from individual resilience. Individual resilience is that ability to cope, that sort of grittiness. Quite a lot of research being done into individual resilience. The different traits that we each of us have. But team resilience is more interesting to me because all teams will go through a period of pressure and some people will respond well to it and some people won't.

Teams that do very well tend to create an environment where they're supporting each other. I look at team resilience as a leadership challenge and it starts before the team is under extreme pressure. So it's almost like looking at how do I build a team? I know at some stage in the future. As I look at this project, there are going to be difficult times.

There are going to be storms. There's going to be changes. There's going to be things that make us uncomfortable individually and collectively. How do we anticipate that? How do we keep an eye out, keep a watch on the horizon for those kind of events coming?

And how do I as a team need to prepare my team to be able to cope with those things? It ties back to where we started in terms of how the relationships formed. To what extent by the time the turbulence hits, are the team started to build those interdependent relationships where they trust each other, where they're prepared to take a risk in terms of somebody suggests a solution rather than deferring it and delaying it or looking for somebody else to confirm it going, yeah, I trust you enough.

Let's try that. Let's just try and see. There's also then that leadership element that's not necessarily from the leader himself or herself, but that comes from within the team where one has a team of leaders and that different people take on responsibility and take on the role of support at different times as the project progresses. So that when things do get difficult, the team starts to have individuals help each other through the process. So you don't need every team member to be highly resilient.

In fact, actually looking at the character traits of highly resilient individuals, they don't make great team players. But having people in the team who care enough about each other to actually try and help them and support them has been found to make a huge difference. And of course, you know, our personal experience and logic would say that's the case. But there's one other really important element, I believe, to resilience. And it comes to final steps.

And one is after a team goes through a period of intense pressure or individuals have been through intense pressure, time must be given for recovery because when we're under pressure, we're under a lot of stress. We have a great deal of adrenaline, cortisol, other survival chemicals going through our system. And they're exhausting. And if you want a team to get back up to speed fairly quickly, then individuals have to be given time to recover. And so this idea of just relentless pressure is to be avoided.

And it comes back to that Taylorist idea that human beings are machines. Well, we're not. We can do amazing things only within certain defined limits. And then the last element, I believe, of resilience is that the habit of reflection just pulls not necessarily too long, but ideally as a group and just say, OK, just looking at that last period, what went well, what do we do well that we need to do more of and then what could have gone better? And it's important to ask those questions in that sequence, because if you've got through something, there will be things that have gone well.

But if one focuses straight in on the errors and mistakes and difficulties and perhaps individual failings, that doesn't necessarily create the learning that you're looking for, because what you're looking for is that collective sense of, yeah, yeah, we can do this better. We can find another two weeks off the program. We can catch up. We can do this. And if we won't do this on a regular basis, what one finds is that resilience is less of an observable issue.

It's just a way that the team works. And one could even almost look at it as a source of competitive advantage. But there is a process to it. And leaders need to get better at learning what that is. Speaking about reflection, those were some helpful components to reflect on, but to really be aware of as to how resilient teams work.

And also what I find is interesting is that individual resilience doesn't necessarily put together a resilient team. It is that care that people have about the other individuals on the team that makes it successful. I want to tie this back to blockchain. And I want to ask you about some of those objectives about establishing an effective team. But I want to ask you, how does that resiliency tie to blockchain for you?

So one could listen to the things that I've talked about and say, well, yeah, that's all nice and good. But it's all a bit wishy washy and down to the individuals. And it's about soft skills. And I'm saying, no, it's not. It's about process.

It's the application of process that makes the difference. So the application is a skill, but you've got to have the process in place first. So what I'm saying is if most people look at blockchain technology, particularly around smart contracts within a project environment and say, yep, well, from a technical point of view, and particularly a commercial point of view, we can see that this do X, then Y happens, works quite well. My argument is, well, why limit that to technical and commercial? Why don't we put in these activities, some of which I've been describing, that have been found to generate better team outcomes?

There's a requirement to do this. It's not optional. At the moment, things like creating a shared vision or talking about roles and accountabilities are things that are on a project manager's list, but they're a checklist. There's something just go tick, tick. There's no proper application of the process and what I see in the potential.

I call it technology. There are other potential solutions for this. But what I like about blockchain is it's engaging minds and thinking in a different way and in a deeper way to actually go, no, if the project cannot progress beyond a certain stage until these different components have been put in place, because if we don't put them in place now, then they won't happen. Some of your listeners are sort of rankling, and we never have time to do these things. It's all the good you're talking about, but in theory, and I would come back and say, there's always time.

There's always time because we spend the time one way or another picking up and trying to correct the mistakes that we've made through not putting these processes in place early enough. The learning is actually educating the professions involved in major projects, particularly project managers and project leaders, and then working very hard to explain to sponsors and clients, this is how the project works. This is how the process works. And if we do these things, we have a much higher chance, not a guarantee, but we have a much higher chance of getting a successful outcome.

The point is, the activities that I advocate, and I've talked about some of them here, there are more that one can find in my books or on the website that I've created, but they're not time consuming in themselves. They just require a different level of thought and application. A whole suite of them might add a week or two weeks to the program. My argument would be that you will save that time and more at the end of the program if you get the team working effectively.

So I've read the book, Team of Teams, by the McChrystal group, and they talked about the, similar to how you've discussed, change of the top-down siloed approach to more of a networked approach in order to increase collaboration, whereby people are constantly sharing information to the correct person at the right time in order for the information to be relevant again. I was curious as to your thoughts about that model, and are you seeing the linkage to blockchain here? It's a very interesting perspective that can be seen from looking at the traditional top-down hierarchical flow of information, which makes an assumption that the guys at the top always know more than the guys at the bottom, to the recognition within a team of teams that says, actually, no, the guys that know the most about a particular issue or problem or challenge are often the guys at the coalface,

and so there is no bottom anymore, there's just connections. So I love that different perspective because it requires so much more from a project leader to think, how is that going to work in practice? When it comes to the use of technology, then, I think it's how do you map out those networks so that you can actually see where the crucial interdependencies are? And as a project leader, you can see, right, is that connection working? What's the feedback?

What's the process? What's the data that I need to be collecting that I can see that that connection is live and that there is a collaborative and cohesive bond working there? Tying that into blockchain, for me, this starts to become very context specific and much more difficult then to say, well, this is how this specific bit of technology would apply in that situation. Where I see technology making a difference in the short term, however, is just being able to find the data from the communications that are going on through the team, whether it's analyzing email traffic, whether it's looking at the data that's going through the project control systems, but being able to get that information quickly.

And of course, the process and the static, a major project is evolving over time. Relationships that start at the beginning are not necessarily going to be there at the end. This is, I guess, where it starts to see, well, is there going to be an algorithm? Is there an element of artificial intelligence that's going to be able to do this much more quickly so that project leaders are getting the information they want, but also project participants are able then to feed back through and recognize and understand, I'm not getting what I need here.

How do I feed this back into the system to ensure that things work for me next week? And I think that reminds me now of the objectives that you listed out in your presentation when I looked at your PowerPoint for establishing an effective team. And one of them in particular, psychological safety. It's about the information, the data that you're actually sharing, because you can offer information that's not necessarily relevant, but it's about being or about feeling as if you're OK to offer that up. I'm curious as to your thoughts about that.

I find it really useful about the work that Google did with Project Aristotle. So the concept of psychological safety has been understood by people looking at groups and effective communication with groups. But it was just really useful to look at what Google did, because in that Project Aristotle initiative, they created something that suddenly project managers couldn't ignore those words. The word psychological doesn't appear in a lot of project management training, and yet it now will. And yet the concept is fairly simple.

It's just those groups that feel that they can talk to each other openly and honestly without fear of ridicule or punishment, tend to be far more successful than those groups that don't. And then the question is, OK, well, if that's an accepted fact, what does that mean in reality? And where does technology play a role potentially in that? I think how to establish psychological safety tends to come through behavioural norms and those rules of engagement, because it's the norms that have, in the end, they set the culture of the team.

One of the ways of thinking about culture is, culture is the things that we feel we can or can't talk about. And so, again, setting the right norms, going through the process that creates the norms, and then training your leaders and your managers to be highly competent in that process is going to be the way that one builds psychological safety. That's really good. That's really helpful. And I'm really appreciative for you sharing your perspective.

At this point, I'm just going to thank you. Thank you for being on the podcast. Thanks for doing this interview with me. Not at all. I've enjoyed it.

If people are interested in learning more about your thoughts about effective teams and your books, where can they get in contact with you and learn more about what you're doing? I have a website, which is called theteamcoachingtoolkit.com, and that has a framework model there. And my idea is, over time, that it's a depository of places that I put things that are interesting to me. In the short term, I just wanted to set some tools out to say to different people, you know, this is not just about theory.

There's a very practical how you can go about things here. It's my small contribution to the project world. I'll keep on adding as long as I keep working in this area. If you want to know more about the books, you can find access to them there. I am always really pleased to engage with anybody who's interested in this area.

I'm a part-time academic at the Electric University of Westminster. I help people through their dissertations. I'm always grateful to receive ideas and thoughts and references and studies from other people. I certainly don't know it all. Also, very, very happy to share what I've found with anybody who's interested.

And sometimes people just want to call up and have a chat. That's great as well. This is as much a hobby for me now as it is a job, which is great. So please, guys, get in touch. Do you have an email address, a social media that you want to share?

Yep, tony.luellenresilex.com. If you want to learn more about Tony Luellen, check out the show notes at constructor.com slash EP 91. If you learned something valuable in this episode, share it with your friends and colleagues. You can also let me know if you enjoyed our discussion by connecting with me on Twitter at Brittany underscore CT or find me on LinkedIn. Or you can just email me to at Brittany at constructor.com.

That's B-R-I-T-T-A-N-I-E at construct double R dot com. Last week, I told you that I was going to be speaking at the Voice of Blockchain Conference hosted by the Chicago Blockchain Project. I actually spoke on Friday along with my fellow panelists who included Kimon and Uma, Bim Storm Creator, Michael Bordenaro, Asset Leadership Network, and Rob Salvador from DigiBuild. We spoke about how we're transitioning to an industry where what we produce is lots of data that can actually help us improve more trusting relationships. We see that long term vision about how that can be done all the way from design through construction, through the asset lifecycle, and specifically with blockchain technology.

I'll be releasing this talk in the next episode. And I just want to say a special thanks to the organizer, Joe Hernandez, and all the people who made this event happen. It was really well done. And I made lots of amazing connections with people, some of whom you'll be hearing from in the coming weeks, some of which have been previously guests on the Constructor Podcast, including Lexi Progenmos and Paul Doherty. I look forward to sharing these Voice of Blockchain interviews with you in the next few episodes.

If you haven't already subscribed to the podcast, you can subscribe at Constructor.com at the website, and you can subscribe directly to the podcast, an iTunes, Stitcher, iHeart radio, tune in, and I'll be posting on YouTube in the near future. I look forward to connecting with you in the next episode.