Participatory Leadership and Developing a Culture of Psychological Safety

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I have the pleasure of sitting down with Nick Takavadii. Nick, welcome. Thanks for taking the time to talk to us today.

Nick Takavadii: Thank you, Shane. Glad to have you here.

Shane Hastie: So you and I have met a few times, particularly around events where you've been facilitating and digging us into areas of psychological safety, and that's what we want to explore today. But before we go there, who's Nick?

Introductions [01:04]

Nick Takavadii: I recently became an Australian, so I like to now call myself an African Australian, born and bred in Zimbabwe, which is where I lived most of my life, and started in the software development much early in the '80s, high school in fact. And those days, there were no certifications and things like that. It was you get a computer and you play around with it and change some code. And that was my first love.

I got into organizations, worked for one of the biggest software company, worked in bureaus with governments. I was fortunate enough not to go on a COBOL programming course because I had gone on an aptitude test for that. And after I had qualified, I got a call being offered a job instead. So I was in there and worked with the old computers, did some Visual Basic, the old basic, and also worked around when basic-2C, which later became Niakwa Programming Language(NPL-4).

We were running programs back then with 286 computer running with dongles, and I remember back then we needed a board approval to get a 20 meg upgrade for the server. So I don't know if I'm revealing my age at this point. But fast-forward, I was involved in that organization then I went on to another organization. You know what happens in the software industry. And I ended up at one point running a software house, Microsoft based, where we had two big products, an ERP system and some investment system.

And I had a big team reporting to me. Back then, I was not so good at handling people. I was good at writing code. Good at sitting with a client and getting the specifications to do away with because those days if we got a tender, we would get thick spiral bound requirements document, which when you went on to start writing the code, you would find that you probably need to put that aside and engage with the customer, particularly those that were resistant to what you were developing and get to understand where they're really coming from.

So that helped me to develop the listening skills, but I was not good at managing my team. Even industrial studies and industrial psychology study and BCom studies did not help with that. Because part of my life, I used to be a dancer as well, and I was with a particular contemporary dance company and we went on a retreat. And at that retreat, we were hosted by somebody, Maaianne Knuth from Kufunda Learning Village in Zimbabwe.

And Maaianne is a practitioner of the art of hosting, and my eyes were unveiled. I discovered that participatory leadership practice. At the same time, in my software organization, I was still trying to come up with methods that would be less hierarchical, empowering the developers to work with me. But I had not discovered Agile, although the Agile manifesto was in existence then, it did not come my way. So you can say I was trying to create the Agile practice and I found this to be a best fit for what that Agile practice could do.

So I then went on a journey to learn more about this and to incorporate it. And my team went on the trainings. Fast-forward, I relocated to come to Australia in 2018, and I made a conscious decision to focus more on the people side of things. And I joined Campfire, which is now Percolab, and that's where I am.

And at Percolab, we develop and share new ways of working, governing learning, pretty much in service of the social ecological transition. We function as an applied research lab. In 2007, that's when Percolab was formed in Canada and it's growing.

And here in Australia, we've joined Percolab to become the Percolab archipelago. We operate as a worker-owned cooperative so we have no bosses. We work on the shared leadership model and what we share with others, we experiment, we actually practice and do ourselves in our organization. And sometimes we describe our work as conscious, courageous, creative collaboration.

I am married, moved over here with my family, teenage kids. So this practice, I also bring into my family as well. I'm an active member of the multicultural community here in Australia. I practice that as well. I am involved with promoting entrepreneurship among African Australians here in Australia. And recently we had the Afripreneurs Summit where people in all sorts of lives are involved and we support each other in developing and growing that.

Shane Hastie: There's a lot there. I really want to dig into and unpack some of these, but let's start with participatory leadership. What do you mean by participatory leadership and how does it show up in the workplace?

Overview of Participatory Leadership [07:07]

Nick Takavadii: Participatory leadership is really about how we show up in the workplace. We turn the leadership, flip it around from the industrial hierarchical structure, which you might think of shaped as a triangle into more circular where everybody is equal, which is more aligned with the ecosystems as well as the traditional indigenous systems.

So where there's dominance, there's collaboration. Where there's seeking permission, there's proposals, everybody in their power. The way we hold the meetings is really looking at changing that. So you can think of it as decolonization of our organizations. That's participatory organization.

Shane Hastie: Let me think about this or put myself in the position of one of our audience, probably a team leader in a large software organization. And being put in the position, getting some feel for, okay, I'm no longer the individual contributor. I'm working with people. I'm not writing as much code, probably not writing any code some of the time now and I'm struggling. I'm trying to get my head around how do I lead these people? What can you give me?

The shift in role from individual contributor to leader [08:41]

Nick Takavadii: Wow, wow, wow. I've been there, Shane. I think maybe three things there. You know with the Peter principle who talks about people being promoted to the next level of incompetence. That was me. So I think a lot of people experience that as well. But I think the thing is about what is it that you value?

So the value that you bring changes. You are now more responsible for the overall value of the delivery, and it's more than just the features, more than the products or more than the outcomes that you're getting. It's also the capacity building of the team. There's also the element of alignment, the alignment within the team itself so people are relating better and hearing each other.

But also alignment, as much as we talk of horizontal leadership in organizations, you still have people that you report to. So the alignment with that and then alignment with the organizational goals, and then alignment with the client objectives.

So to really get that, most of the time it's not so much dependent on you, but on your listening skills, not just your listening skills. The way you allow your teams to be liberated so that the talents can really shine in the work that you're doing. What if the work we did was more valuable than the outputs that we do? And that is the question that you sit with as the lead that is coming to that position.

And to help you as well, one of the things at Percolab, we have created a number of small micro practices that are accessible to yourself as well as the team. For example, the Listen For ... game, Shane, that you experienced at the FOBA (Festival Of Business Analysis). It contains a lot of things. And within that game, you've got the seven domains of practice, which are really key to the practices that we bring in.

Principles for going horizontal [10:54]

This come out of the book written by the founder of Percolab, Samantha Slade, and it is called Going Horizontal. It's classified into seven domains. They're not like scientific categories, they're just ways that help us to just look at what things are we looking at and what focus even for our learning and development, what are we focusing on to develop and to grow.

So for example, you spoke about the team lead who just come in. One of the key things or key powerful questions that we always bring in is as you come in there, you need to know yourself. What are my learning intentions? What are my learning edges? And you also need to know for your team, what are the learning edges for those teams? And these domains help with the language of knowing what to categorize so that you can then focus and work on that.

So you've got AUTONOMY, which is claiming your personal leadership. You don't need to wait for the people at the top or head office to declare transformation before you can actually be in there.  PURPOSE. As much as you are the leader, the most important thing is to clarify your purpose early on, what your purpose for how you're working, purpose for the product, purpose for your relationships in working together.

And then the purpose becomes the invisible leader. Where you have differences, purpose leads you because it's clear and it minimizes the possibility of conflict, the negative conflict, I'll say this. Conflict is not a bad word actually. It's actually something that energizes and builds organizations.

MEETINGS. The question of how do you hold your meetings? For example, one of the practices that we've brought in called Co-Managed Meetings, very similar. Some of the people that have been in core feeds, it sort of has that element, but it has more, the meetings are not chaired, but they're facilitated or hosted.

Anybody can bring a topic to the meeting and they host or facilitate their session that they've brought in into the meeting. So everybody as the autonomy to be able to do that. There are other ways. You have your long meetings, you have your short meetings, all sorts of meetings, and each meeting has a purpose and category.

Then there's TRANSPARENCY. There's a lot of secrecy in organizations and some of it is not necessary. So really, we talk about defaulting to open. Open is effective and open is efficient. DECISION MAKING, this is one of the other things where a lot of conflicts happen, particularly in development because working with the product owners, the business analysts and so forth, and guess the team, you're making decisions of what your priorities are and things like that.

We bring in clarity into understanding of that decision-making process, people usually have the go-to, there's the autocratic and then there's the painful consensus decision-making at the very end with a few things in between. But at Percolab, we've come up with the Generative Decision-Making (GDM), which is a very fast and efficient, consent-based decision-making process.

So contrasting consent and consensus, and it works on the Agile principles of "Is it good enough for now and safe enough to try?". And you move on and you can always come back and another proposal comes in and you change. No decisions are cast in stone.

LEARNING & DEVELOPMENT. This is something that is very important. Historically, we've made the mistake of separating learning from work. Here we talk of the work being the learning and it's self-directed. And this is the other thing, not to tick boxes based ... It’s self-directed, people in their own power and autonomy, but it's collectively held as well.

So you know what others are working on and what development plan they have. And there's a peer support for each other, relationships and conflict, tending to them together. And with each of these small micro-practices that we go through, you've experienced, I mentioned the listen-for game.

We've had that powerful question session. That's one of the many things. And some of the basic things are like the check-in and check-out out of meetings. You'd be surprised that many people don't do that. As we are talking today, it's after the US elections and different emotions are going on with people there.

You might just come together at work and you just plunge in to do the work. But we say no, check in with each other before you plunge into the work. And check out, this helps to cover a lot of things. And this checking in with each other, both at the team level and across the organization to bring in the harmony in the decision-making and alignment. It's useful and it is important for the health of individuals.

Psychological safety is the combination of practices and behaviours that enable people to flourish [16:02]

So psychological safety, when you talk of psychological safety, it's not something that gets declared from the top. It is these small practices that allow an organization to develop. Remember, we have to unlearn and remember what things were  like in our indigenous cultures, in our traditional cultures, how people related and valued each other.

So we have to undo some of those organizational practices to be able to make space for new ways of working to come in. And none of these are cast in stone. When we engage, pretty much when we get into an organization, we build capacity to build capacity, which might sound counterproductive, but the intention is to really get ourselves out of that particular organization after having built capacity so that people can.

Because the people that can work best in developing their own culture and their movement from the hierarchical to horizontal culture is the people that are in there. They're the ones that are best qualified to make the decisions, but they just need some accessible tools that can help them to get there.

Shane Hastie: This is a culture shift. This is a significant change for many organizations. As the team lead, I might not feel I have the authority to make those changes.

Make change in your areas of control and influence [17:34]

Nick Takavadii: Yes, and that is always the big challenge. I was listening to a recent survey where it was an engagement survey and I was surprised at the huge percentage, I can't recall the actual figures. Yes, a huge percentage of people that said yes, they've withheld back the knowledge that they have because they don’t feel safe bringing in ideas or making suggestions because they're making themselves vulnerable. They are exposing themselves.

So that's why the psychological safety and having these practices that help develop that culture and break us into this way of being able to bring up and talk about things. And some of it might be very radical.

For example, at Percolab, we do not have salaries, we have conscious economic conversations. We choose the work that we work on, the projects that we work on. And at the end of the project, we look at our contributions and it's done in a healthy way.

It's actually one of the processes that I really love. But when we engage with organizations, we don't go there first because it's a journey, if you will. And a lot of us, we find ourselves standing with our legs on the triangle, which is the industrial way, and another one in this way, which the whole world and a number of people are really looking at moving towards.

For example, you might have heard of the sustainable development goals because the targets were not coming in close and they were moving further away. It has given birth to the formation of the IDG (Inner Development Goals) movement, which is about inner and outer development.

Shane Hastie: You mentioned IDG, what does this mean to us?

Inner development goals [19:36]

Nick Takavadii: A lot of our work, us as developers, we are measured and valued by what we produce. That's the output and that's the outer bit. But who we are and how we show up is a key element to the products that we develop. And the inner development goals, they're not just limited to development, they are applicable in all factors of life.

So you have five groupings of them, number one, BEING. Number two, THINKING. Number three, RELATING. Number four, COLLABORATING. And number five, ACTING. That is enabling change. So there's a number of elements in them. So for example, if you look at the acting, within acting, you have courage, creativity, optimism, and perseverance.

Anybody who has really debugged code like I did in my day, there's that perseverance element, which if you don't enjoy your work, it affects your well-being. And if it affects your well-being, it affects what you produce. It affects the people you work with. It affects everything else. And it may lead to burnout, but usually with the way we work around burnout is to just move on to another gig, get another job.

But what if our work really had value and we did great work, we produced and still liked each other and related to each other in ways that we'd never done before? What if in your reviews, what if one of the measures was probably responses to the question, "Will you work with this team again?"

Have that as your metrics that you go on measuring. And our teams are measuring all sorts of things. One way you can go about is introducing some of these metrics. You can find these Inner Development Goals, they're publicly available on the internet and see how it can influence the metrics that you set for yourselves and your team.

Shane Hastie: Influence the metrics that are guiding my team in these Inner Development Goals. People stuff, which of course, is what this podcast is all about. We care deeply about that people stuff, and we're inviting our audience to lean into some of that stuff. In a conversation we've had previously, you were talking about unpacking value and digging into the ethics of what we, as the software engineering industry, what we bring to the world. You want to dig into that?

The ethics of software development – expand the definition of value [22:40]

Nick Takavadii: I don't write code anymore, but all the projects that I've worked on, the greatest joy that I've got was from work that really made a difference more than how fancy the code was, how the screens were, but that the output of what we did helped make a change in this world, both for people and for planet.

Now, I strongly believe that as software engineers, we are in a privileged position into shaping what this world would be like, how we impact people's lives. Where it is right now, everybody is impacted by the products of our work. Check that further and bring in AI.

We are going to be very connected and affected, negatively and positively, by the use of the products that we produce. So my invitation to my fellow software engineers is to really expand the definition of value. So when you're doing your value streams, expand it to include people on planet, to include wellbeing, to include those who are marginalized.

As we develop the products, create space for them. Have that at the back of your mind. That's all I can say, Shane, in terms of this value. Bring in all that and add more meaning to that value.

I recently read the book, Tom Peters, he was acknowledged in the author's work and said, "I'm the one who coined the phrase the customer is king. But after I read this book, I am taking that back. It is the people". It may be the developers, it may be the customer. There'll be whoever is affected in there. I liked the phrase you used the other time, the Kiwi phrase for it's the people, it's the people.

Shane Hastie: He tangata, he tangata, he tangata. The Māori term. It's the people, it's the people, it's the people. And Nick, that's a beautiful point for us to wrap this up.

If people want to continue the conversation, where do they find you?

Nick Takavadii: LinkedIn is the best place. I'm the only Nick Takavadii there. Easy to find me there. I may not instantly respond, but I'm always there.

Shane Hastie: Nick, thanks so much for taking the time to talk to us today.

Nick Takavadii: Thank you so much for the opportunity, Shane, and thanks to your audience too.

Mentioned:

• Nick Takavadii on LinkedIn
• Kufunda Learning Village in Zimbabwe
• Percolab
• Book: Going Horizontal
• Inner Development Goals