Podcast Ep32 – David Horowitz – Performing Brilliantly

This is the thirty-second in a series of podcasts where Judy interviews people who have a track record of successful collaboration. This series is for anyone interested in the nuts and bolts of real-life collaboration, especially collaboration among creative, intelligent, free-thinking individuals who are geographically dispersed. The interviews go well beyond the obvious, as metaphor master Judy Rees explores the hidden thinking that inspires collaboration that works.

Listen here

Judy: Hello and welcome to collaboration dynamics podcast! I’m Judy Rees and with me today is David Horowitz. Hello, David! Would you like to introduce yourself and what you’re up to?

David: Absolutely. Thanks, Judy, so much for having me on this podcast. It’s a real pleasure to be talking to you and everyone who’s listening today. As Judy said, my name is David Horowitz. I’m the CEO and co-founder of a company called Retrium. We make software that enables teams to run effective retrospectives. In essence, if you’re not in the agile software development world, it’s a methodology by which teams can achieve continuous improvement. It’s an introspective meeting. And we make software that makes them more effective.

My background – in 30 seconds – I’m what I like to call a “Recovering Software Developer”. I say that because I was, as a programmer and as a tech lead, working with software developers and actually doing coding for many-many years, but I quickly discovered that my real value was not so much in the technical aspects of coding, but in the people aspects of coding. So I shifted gears a bit, and focused more on how teams can try to perform at a higher level. That’s in a nutshell how we came up with Retrium, and where I am today.

Judy: So much of what you’ve just said – I want to follow that metaphor of a “recovering software developer”. What kind of collaborations do you get involved in?

David: It’s changed over time, going back to the shift in my life professionally also. I used to work for a big bureaucracy. I’ll leave it nameless here – that was a big international bank. I was trying to shift away from a traditional style of software development called ‘waterfall’, very top-down, very upfront planning, heavy, towards a more agile, flexible model of software development. The problem in that organisation was that while there was a directive from the top to become more agile and more flexible, the culture of the institution was quite the opposite.

The collaboration there was – I should probably change the word ‘collaboration’ to ‘lack of collaboration’, because it was so hard to work together, since the rewards and the incentives in place were really to protect your turf, even though the information and the direction coming from the top were, “Hey, respond to change. Work together.” There was a disconnect there.

It was really a lack of collaboration that I’m coming from. The company that I found at Retrium is focused on fixing that problem. I’m working in a team of two today. We’re distributed. We don’t have an office. Despite the fact that we don’t see each other face-to-face, we are highly collaborative and at the same time highly autonomous. I’d love to touch on how those two interplay together during the course of the podcast.

Judy: You’re highly collaborative and also you’re highly autonomous. Just to get the sense of the thing, where about are you and where about is your colleague?

David: Geographically?

Judy: Uh-huh.

David: I’m in the Washington DC area. I have a house and a family, so I’m very settled here. My co-founder is quite the opposite. He is a single guy and he goes wherever he wants to go. Sometimes he works from the beach, sometimes he works from his family’s farm. He’s planning to go to Mexico later this year. It depends. And it’s very liberating for him. It works well for both of us, because we’re happy with where we are in our lives and don’t have to move to a particular city to work together.

Judy: Interesting. So he’s one of these digital nomads.

David: Digital nomad, yeah. The up-and-coming digital nomad movement, yes.

Judy: And you sound more like me. I’m a digital stay-at-home.

David: Very much.

Judy: Great thing about virtual working for me is that it means that I don’t have to travel.

David: Yeah, absolutely. I love travelling from time to time, but I have two little ones, so travel is a bit limited these days. And that’s fine – my life is digital, so I can be at home and still be digital.

Judy: You and your colleague are both highly collaborative and highly autonomous. When you are highly collaborative and highly autonomous like that, when you and your colleague are collaborating at your very best, you personally are like what?

David: I love this question. You’re putting me on my toes here, Judy. I think the best way of describing what I’m like is to think of a high-functioning high-performing basketball team. Let’s go to the sports world here. I know that people like the sports analogies and I’m going to go in that direction because I think it is true.

Think of what a good basketball team looks like. There’s a lot of instincts that the team has, both at a team level, and also at an individual level that without speaking, without any sort of direction coming from the coach the team just has. Together with that, you have good relationships on the team and you have a vision. If you’re playing offence, it’s to score a basket. If you’re playing defence, it’s to stop the other team from scoring.

It’s the combination of these collaborative instincts that everyone just seems to have – they know where the next player is going to go, where the path should be. That in combination with the good relationships and the vision, everyone knowing what the goal is, creates the best set-up for the collaborative team to function within.

When I’m collaborating at my best with my co-founder, it’s because we know exactly what we’re going to try to achieve that day, that week, that month and even the next year or two, without having to talk about it. We just know. We’ve been working that long together. Correspondingly, when we have good relationship together, that helps us to be on the same page and support the other person when something goes wrong or perhaps when something comes up in their personal life that’s taking them away from the business.

It’s very similar to that highly functioning basketball team. That’s a highly functioning team in my life too and therefore when I’m best when I’m collaborating.

It’s very different from how it was before, when I was working for this big bank. That was quite the opposite. We were not highly functioning and not collaborative whatsoever.

Judy: We’ll come back to that in just a moment. Just to explore that basketball team just a little more – it’s a highly functioning basketball team. And when it’s a basketball team like that, where about are you?

David: In many ways I like to consider myself as a point guard, but not the scoring-oriented point guard, more of a pass-first point guard.

For those who are listening, who are not into sports, not into basketball, there are two types of point guards. This is the person who has the ball, who leads the team. A scoring first point guard is someone whose goal it is most of the time to try to score the points for the team, which makes the team win. Whereas the pass-first point guard is somebody who is more distributing the ball to others and trying to make the other people on his team score the baskets, and to put them in the best situations that they can achieve the goal, which is to score points.

There are two different types of point guards. Neither one is better than the other. They are both very good. They are both fine depending on the goal of the team. But I like to think of myself as the latter, more of a pass-first point guard. Okay, we have a vision. We know what we are trying to achieve. How can we put the other people on the team in the best spots to enable them to achieve their potential and reach their goal? That’s what I like to think of myself.

Judy: Just to check that I’m hearing this correctly, because I’m amongst the people who know nothing about basketball – it’s a pass-first point guard? Someone who passes first rather than trying to score first?

David: Exactly. Absolutely.

Judy: I see. They have a similar notion in that ball I believe, but it’s all to different level, I’m sure. When you are a pass-first point guard like that, is there anything else about how that works?

David: In terms of how we enable collaboration?

Judy: Yeah.

David: To me, if you are a pass-first point guard, your goal is to not take the credit yourself when things go well, but instead to ensure that your teammates are the ones who are the people actually achieving goal in the end. And your job is just to put them in the position that they can most likely achieve those goals.

In my life professionally, as well as my life personally, what I try to do – and just like the best of us, we fail from time to time of course, we fail many times – but what I try to do is to make sure that I am doing what I can do to the best of my ability, but not doing more than I have to do to get the job done. In other words, I only want to do what others can’t do, or perhaps aren’t as good as I am at doing it. The rest, I want to make sure that I am enabling others to perform to the best of their abilities, such that they can get the credit for all the things that are going right with the company. In your personal life, I think you can think of it the same way, as well. Collaboration doesn’t stop when you leave the office of course.

That’s how I like to think about life. That’s how I like to think about my professional world. In many ways, professional and personal are very much tied together anyhow. You can’t be one person at work and someone else at home.

Judy: When you are like that, and your job is to put people in the position like that, what kind of position is a kind of position where they are in to do their best work?

David: We have two people in the company right now. My job is much more the customer-focused type of job, where I’m talking to our customers, potential customers, all day long, making sure that they see the value in retrospectives, and making sure that they are getting the value after they’ve run retrospectives to achieve the continuous improvement that we’re targeting. I’m very much on the customer-focused side.

Remember, I’m a recovering software developer. I have technical skills – I can code. My partner is however the lead on the coding side. He’s the guy who actually builds the software that the company is based on. You can imagine a situation where, if I was a shoot-first point guard, someone who tries to score the points, rather than a pass-first point guard, where I could be stepping on his toes pretty easily.

If I’m trying to solve some technical issue, fix a bug that we have in Retrium, I as a recovering software developer, probably could do it not as well as my co-founder can. But I could probably do it. If I wanted to get the credit, if I wanted to make sure that I’m the person who fixes everything for the company and I’m the hero, I would fix that before I gave my co-founder the opportunity to fix the problem or to add a feature.

Instead, if you take a step back and say, “These are our roles. I’m the person who’s talking to the customer, who’s doing the marketing and the sales, making sure that customers achieve the success we are intending for them to achieve. My co-founder is the one who’s doing the coding.” The side effect is that I could also do that. We have these roles that we understand going into our relationship together and we try our best to make sure we don’t step on the other person’s toes, and to make sure that the other person is feeling like they are achieving their goals and are in the place where they can best achieve their goals as well.

Judy: Thank you. And you are saying that this is very unlike how it was back in the bank.

David: Yeah. I could say that 10 times in a row and not get bored of saying it. Yeah. The set-up there was very different. We had people all over the world who were trying to work together. Similar to us, that was a distributed set-up. But there was very much a sense that it was “us against them”, that the people who are in Washington DC working together are a team, and the people working in India are a team, and the people in Europe are a team.

Even though we were one big team working on a project, there was no sense of “We are in this together” at all. When things went wrong, rather than trying to collectively figure out what we can do to improve the process, or improve our relationships, we immediately went to the blame game. What a terrible, terrible working environment that was!

I tried as a quasi-Agile coach there, as someone who was helping improve process, to implement a regular program of running these retrospectives, trying to improve the process in a structured way. But the retrospectives ended up going down this cliff, this hill of immediate blame, rather than constructive comments and constructive criticism. That didn’t help either. That made me think, “If this company has this problem, how many others have this problem too?” That’s how Retrium started. It was about personal pain-point that I had at my last job that I wanted to fix not just for myself, but also for everyone else struggling with that type of work set-up as well.

Judy: So you had a team in DC, a team in Europe, and a team in India, and a disconnect between those teams. And when you tried to do retrospective, you went straight down that cliff of immediate blame. Is there anything else about how the disconnect worked between the teams? What kind of disconnect was it?

David: Disconnect didn’t work possibly. Nothing worked. There are a couple of things. On the one hand, there are time zone issues. That’s something you can’t overcome. Time zone issues are time zone issues. But given that you know there will be a problem if that’s your work set-up, there are things that you can do to try to make those problems less severe.

For example, rather than always running a meeting at 9 AM Washington DC time, forcing people in India to work very late at night every single night, you could possibly try to share the pain. For one week, the people in DC have to wake up early or stay up late, and the next week the people in India have to do the same. In that way, you build the trust, you build the sense that we’re in this together, and no one party has to be suffering all the time. So, there are time zone issues.

There are also of course the cultural issues. I’m being very careful with my words here – but I think that people in DC, we felt like we were running the project, and the people in both Europe and India were the ones who had to implement the project. That to me is a distinction that actually should never exist in a team.

A team is quite simply a team. Therefore, there should be collective and collaborative responsibility for everything from setting the vision to gathering requirements, to actually implementing it, to testing it, to going out and getting feedback. Everyone is in it together. The moment that you start to say, “We do this, you do that,” and there’s no sense of “I can help you when the time comes, if the time comes,” then it’s so easy to jump off that cliff, not walk down that cliff of blame.

That was the situation we were in. That was “We do the vision. They do the implementation. When things go wrong, that’s their fault.” Maybe we should have looked at ourselves. Maybe we have set the vision wrong, or maybe we weren’t clear enough. But that never happened there.

Judy: That’s so interesting! Just listen to the two metaphors. And comparing. In the bank, you’ve got DC running the project, Europe and India implementing the project. Somebody could be listening to it and think, “That sounds pretty much like being the pass-first point guard and just passing the ball to Europe and India to do the scoring.” And yet clearly it’s quite different.

David: Yeah, very different. You can be a pass-first point guard, who dribbles the ball down the court, and then does nothing else but pass the ball and say, “You score,” and then goes to extreme, goes and sits down. That’s very different from a pass-first point guard who dribbles the ball down the court, calls out a play to get everyone on the same page, and then is actively involved in the success of the play, meaning scoring the basket.

Both are pass-first, but only the latter one is collaborative. That to me is a big difference between the set-up I was in before and the set-up I am in now. Before we were pass-first, and then “Okay, if it doesn’t work, it’s your fault. I’m going to sit down and blame you.” And now we’re in a set-up where we’re pass-first and “I want to help you achieve your goals. And I will do everything in my power to do that.” It’s a very different style of pass-first.

Judy: Because I don’t know basketball at all, I’m trying to imagine what “calls out a play” means, but I want to ask you instead what does that mean – you call out a play?

David: Typically, in any sports team, but also basketball of course, there are certain set plays that the team has. They practice them ahead of time, and they know that if you’re the big centre, the tall guy, then you have to go to this side of the court and set a pick to enable another person on the team to run across the court and get a pass, for example. At a very high-level, I’m going through a possibility here.

You call out a play, and maybe it’s “Play #2”. Only the people on your team know what “Play #2” is. Because they’ve practised it together they know what to do and where to be. But it’s not just calling out a play – to a certain extent that’s setting the vision, that’s the corollary there. But it’s not just setting a play.

All teams have plays, even the bad ones. It’s not the case that that’s some secret that I’ve just revealed. Everybody knows that there are plays in basketball, and that teams practice them. It’s not just that. There’s also this sense that in a good highly functional basketball team, a sense of “I know what you are going to do next, even if it’s not predefined in that play. I know where you are going to move on the court, because we’ve been playing together for so long, and we have such a good relationship together that instinctually I know what’s going to happen next.”

That is something that is the result of establishing good relationships, establishing trust, and also understanding that we are going to work together to put each other in the best position possible to succeed. It takes time to achieve that on a basketball court. And it takes time to achieve that in your professional life as well. You don’t just immediately have trust with somebody, but overtime you get a sense of what they are good at, what they are not good at, what they are going to do next, even if you haven’t talked about it ahead of time.

In many ways, that extends the analogy here. You can be a pass-first point guard, call out a play. If that play is not working, then you kind of know what your teammates are going to do next anyway to make sure that this trip down the court is actually going to succeed.

Judy: Interesting. That’s particularly interesting for me of course, because one of the things I do with virtual teams is help them to know each other better, understand each other’s ways of working. Speeding up that process of getting the basketball team to know instinctually how each other works. That is very interesting.

When all that happens, and it’s a high functional basketball team, and you’re calling out plays, and you’re doing everything in your power to help them achieve result, then what happens to that cliff of the blame game?

David: If you have good relationships, and things don’t go well, that’s okay. It’s not okay that you fail, you don’t want to fail. But at the same time, your relationships won’t suffer if you go into a set-up, whether it’s on the basketball court, or in your professional life, with the assumption that what you and your teammates have done is to the best of their ability. If that’s the assumption, then when you fail, you know you’ve done the best you can do.

In retrospectives there’s something called the retrospective prime directive, which I love so much. I wish more team used their prime directive, even not for retrospectives – just as an assumption going into you as a team. The prime directive says, “Regardless of what we discover we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand.”

I love that as a prime directive. We use it in our teams, we suggest to the teams that are our clients to use that all the time. When you enter the retrospective and you are trying to figure out what you can do better next time, presumably because there is something that didn’t work in the past, if you go into that meeting with the assumption that everyone did the best they could do, given what they knew, their skills, their abilities, their resources, then it’s almost impossible to have a blame game, because of the assumptions you made going into that meeting.

One of the things that I like to recommend to teams is, “Don’t just say it once and then move on. Whether at the beginning of a project, or at the beginning of the retrospective itself, have people actually sign their name underneath that quote.” There’s something about signing your name that makes you feel more committed to it. People hesitate to sign if they don’t really believe it. Whereas if you just say, “Hey, repeat after me,” people will just go through the motion. There’s something about signing your name that seems to change how people think about this. That seems to get teams to a point where they can start to improve their relationships and start to improve the trust that they have in each other, so that these meetings can be more productive, and actually help achieve the continuous improvement that we’re all after in the first place.

Judy: That is a very inspiring idea. Presumably, if people want to find that, they should just google for retrospective prime directive?

David: Absolutely, it will come up. You can also go to retrospectives.com – there’s a link there for the prime directive.

Judy: Lovely. Lots of people listening to this will not be involved in agile software development, so there are some brilliant ideas here that could be applied in all sorts of different situations.

David: Yeah, that’s one of my favourite things about the agile movement. There are a lot of teams that try to implement agile and fail miserably. There are a lot of team that try to implement agile and do a great job. In either case, you don’t have to be a software team to try to implement the agile best practices. It came out of software movement, but it’s not limited to software teams whatsoever.

The retrospective and all other meetings in agile, and all other parts of the methodology that the retrospective in particular is really just aimed at how we can get better at what we do, and how we can do it in an iterative and incremental and as quick as possible of a fashion. It’s really applicable to teams doing anything anywhere. When I talk to non-software teams, I highly recommend to at least look at the principles behind the agile movement to make sure that they understand what they are. And if they apply to the team, they should learn a bit more about it. It’s not just software. It’s really not.

Judy: And of course the idea of retrospective project review is already applied very widely outside of the software development movement. And presumably Retrium could be applied so.

David: Absolutely. We’re starting with this software development market simply because we know that market very well, and the agile methodology is something that a lot of teams are trying to pick up. So retrospectives are big things – they are a natural fit for us.

But ultimately what we are building is a meeting facilitation tool. The goal of the tool is to keep people engaged in the meeting and feel that they have a voice in the meeting, even if they are not extraverted, even if they are junior member of the team. We want to make sure that everyone democratically is able to contribute their best ideas, and then vote also on the ideas that resonate the most with them in an anonymous way. The goal of Retrium is to keep people engaged, bring out the best ideas from everyone in the meeting, so that you can have a discussion that leads to true actions and true improvement. That’s a good goal for any team anywhere.

Judy: Having seen the Retrium tool, I can see that it really applies to some of the ideas that I teach teams to use when I talk about communication, where there’s lots of visual, there’s lots of opportunity for people to write rather than speak, which can help people who aren’t working in their native language – all these things. A lovely gadget!

David: Thank you very much.

Judy: If people want to contact you, find out more about Retrium and how they might be able to use it, where can they find you?

David: First, the obvious place – retrium.com. I’m happy to share my e-mail address. It’s David@retrium.com. Lastly, I’m on Twitter. That’s DS_Horowitz. Feel free to tweet to me on Twitter, send me an e-mail, or just come to the website.

Judy: Brilliant! Thank you very much indeed.

David: Thank you, Judy. This has been a lot of fun, I really appreciate it.

Leave a Comment

Your email address will not be published. Required fields are marked *