How to communicate with Product Managers

- Thanks, John.

(applause) Hello everyone and thank you, John.

Thank you, Web Directions for having me.

I've attended a number of Web Directions conferences over the years and always kept my eye on the programmes and the things that are happening in them. And I have to say that I really appreciate the work that John and the people who work with John have done to create an amazing hub for information about our industry and an amazing, always ethical, very conscious of having diverse speaker line ups, like just a really terrific series of events for a really long time now.

I think that the culture of internet in Australia has to some extent formed around Web Directions. So I'm super grateful to John for having me here speaking at this conference for the first time. Thank you, John.

(applause) And I also wanna thank Cath for acknowledging the traditional owners of the land again.

A couple of weeks ago I listened to the Uluru Statement from the Heart and if you haven't listened to it or read it, it's an incredible, incredibly clarifying set of ideas and principles about how we can forge a much better future for indigenous Australians, and really a much more authentic, real Australia. I just can not recommend that you go and read it strongly enough.

It's a terrific and important document for the future of Australian culture.

So this was, I think this is the title of the talk that I'm going to give today as written on the card, but I think it's important for this to be a mutual thing. Is there anybody here who is actually a product manager or sort of product-side person? Or are we all, other than me, engineers? I'm totally outnumbered, awesome.

Okay, what I wanna talk about is really not working with product managers or communicating with product managers, but specifically the challenge of getting tech leads and product managers to work effectively together.

There is real mutuality to this.

It's not like, it's not that product managers or tech leads are foreign species that we have to come to understand.

What we have to do is really invest in strong relationships.

And the reason that I think we have to do this is that product managers and tech leaders, particularly in cross-functional product teams, are leaders of the people.

And without sort of strong collaboration between those two people I think we miss real opportunities to develop energy, productivity, sort of clarity of purpose in the teams that we work in.

The other thing that is important to me to note is that I think that all forms of product delivery, technology delivery, are creative works.

It's not art; I'm not saying that developing software is art but developing software is creative.

It's empathetic work; it has an audience at the end of it. And one of the things that I think sometimes we lose in the process of doing it, is a really strong sense of the customer and the user.

And I think that that relationship between tech leadership and product management really can help to keep that thing central to the work that we do.

So that's why I think it's important.

About me, just very briefly, Director of Product at Culture Amp.

I've been at Culture Amp since, I think I was about the 90th employee and I'm pretty sure that in the next week or so we're going to be about 400. So Culture Amp in the last three years has grown dramatically.

And a lot of the things that I'll be talking about are things that I've observed, that are not just functions of team dynamics in a fixed organisation, but also things that I've observed in a high growth environment.

I think growth is always an extra complicating factor. So it's something that's really dear to my heart. When I started in technology, I worked in a firstly, very early on, a two person business that became a three person business, that become a ten person business. And that business was then acquired by a bigger software company and then I got my first taste of working in product in a much bigger software company, that was a slightly weird one.

And then I worked at O'Reilly Media, which if you were writing, particularly learning about writing software, ten plus years ago, you were probably doing it from O'Reilly printed books rather than from websites.

And so O'Reilly is also one of those organisations that's kinda of central to internet culture. So that was a really interesting place to work. And then I came back here to work for Culture Amp and Culture Amp is a fascinating, growing fast company. What I wanna start with, is talking about these guys. I was talking to Rod, on the left is the Chief Product Officer at Culture Amp and these four guys are the founders of Culture Amp. And Rod was really embarrassed when I said I was gonna show this photo and talk about this, but we are now a 400 person company.

We have, I don't know, Kevin probably knows off the top of this head how many product teams we have. I think we have about twenty cross-functional product teams now.

Every one of them has a combination of engineers, product manager, designers.

And to some extent I think we always assumed that the culture that was sort of formed among this group of people when they sat together in a room and developed the initial version of Culture Amp, that that culture would some how scale.

Or that our teams would over time kind of develop that sense of trust and energy and productivity and purpose that these guys had that really got Culture Amp off the ground. Again, Rod would hate me saying this, they would all hate me saying this, but have to point it out.

They're all white guys; they're all Australian. They all are probably plus or two minus years from 40. They have a lot in common and I think that we underestimate how important and effective having a group of people with really similar attributes is at bonding a team.

It just makes it really, really easy to get started if you can assume a lot about each other's personalities, cultures, ambitions.

I think that that makes it very easy, and not to discount, I have to say, the incredible work and talent that these four have as well, but a lot of the things that can make it hard for a team to get working together are absent from this scenario.

These guys had, in various combinations, worked together previously; they knew each other well. So when they came together with an idea, a lot of the ground work of forming their team had happened, or could be assumed from their backgrounds. So what I wanna talk about is, I guess there's some hacks or some models that we can adopt in teams. And I'm particularly talking about the relationship between product side people, product managers particularly, and tech leaders, but I think they are things that apply really to any key relationship in any team. Things that we can try with teams to get them functioning well together and to try, particularly when you throw a bunch of random people together, to try to create that sense of trust, empathy, productivity that we are looking for in our team. So I'm gonna be talking about a few different, they're sort of partnership models.

I say partnership models, this is a fancy term for them. I had to put something on the slide.

Ways of working together or ways of forming relationships that should help.

I think it's also worth noting that you have to have a great product vision and a strategy and all of that kind of stuff as well.

You can't form teams with no future in front of them or no purpose to go after, but product strategy is a whole other day of conference so can't cover that now.

I was actually really pleased to see, first Cath talking about onboarding, and then I know that we have people talking today about things like user manuals and peer feedback and remote teams.

I think all of those will also have things to offer to this discussion.

And as is traditional, I'm going to illustrate this talk with some extremely contemporary pop culture references and don't worry if you don't get them all, they're pretty edgy. We're gonna start with Elton John and Bernie Taupin, very up the minute pop culture reference here. Elton John and Berni Taupin are a really interesting creative pairing, enormously successful in pop history. They, I think, co-wrote something like fifty Top 40 hits.

They had an incredible run in the early 70's where they were number one or in the top ten in the U.K. charts and the U.S. charts, for ages. And the fascinating thing about these two is that basically Bernie Taupin would sit down and write the lyrics, like on a piece of paper, put them in an envelope, post them to Elton John, and Elton John would read the lyrics and go, yep seems like a good story, bash out some music, and then get out on stage and perform those songs in front of, initially thousands, and then tens of thousands and hundreds of thousands of people.

They had this incredible role delineation.

If you looked at their roles, they looked something like this.

Elton John is kind of the product guy.

He's the one who is taking the product to market. And Bernie is the one actually kind of producing those technical underpinnings.

I watched the movie recently and they implied that Bernie also took drugs, but it was very obvious that that was mainly Elton. To make that a bit more concrete in PM and Tech Lead roles, so these are obviously real sketches of things that a product manager might do and things that a tech lead might do.

And what I wanted to talk about was, recently when I got my, I've got a camp we call them, sort of tribe, of product teams at Culture Amp. And we got all of our team members together and we said let's just sort of brainstorm all of the activities and responsibilities and accountabilities that we think a tech lead has, a PM has, a UXer has, and see if we can find from that an emergent description of the expectations of each of the people in those roles. And what we discovered, firstly, was that nobody has any idea what a PM does, and secondly that there was quite a lot of divergence and quite a lot of uncertainty at the edges about what people are responsible for in each role. And so what we decided to do was start putting in place some basic templates, role templates, for each of the named roles in our teams.

And then actually encouraging our team members to discuss them and vary them if they felt like it was useful.

So one thing that came up was that we have some highly technical PMs, we have some PMs that come from agile delivery backgrounds, and then we have PMs who have been much more market focused, or market looking, and have no delivery experience whatsoever.

And it was really important to actually recognise that and try to get that crucial delivery activity stuff into the hands of people who could execute it and who could do something about it.

And so in one case what we saw was that a PM had been responsible for running sprint planning and they just weren't, it wasn't their thing. They weren't really great at it.

They didn't really understand how it could, how it should work effectively.

And so the tech lead and the product manager in that team agreed that the tech lead would actually take on that job.

And what we expect from our teams is for this to be an ongoing negotiation.

What are the things that you think you should be doing? What does your team expect from you? What are your responsibilities and accountabilities? And how can we make sure that's really clear? Because unfortunately, in most cases, it's not gonna be as clear as it was between Bernie and Elton.

And so having that conversation is a really good way of establishing what the boundaries of work are in a team.

So I'll share the slides later.

Just some simple ideas for how you can actually get this happening in teams, and I think particularly important in cross-functional teams, but you will also find it helpful in any environment where you have to work with another, with a bunch of other people, and you wanna be really clear about what you are all working on.

Next highly contemporary pop culture reference, this is John Lennon and Paul McCartney, also quite popular.

John Lennon and Paul McCartney obviously were part of the Beatles.

The Beatles, another band from the 60's who were enormously successful, enormously productive. John and Paul had a very different kind of relationship from Bernie Taupin and Elton John.

They were, particularly early on, really up in each other's business.

They would sit together, they would write both the lyrics and the music together.

They would scribble on each other's stuff.

And what they did was, they basically said, the thing that we both want is over here.

We both want like this squealing hordes of girls lining up outside the hotel.

They wanted this fame, they wanted to be out there, they wanted to be super successful and popular and famous.

And that allowed them to get over the initial awkwardness and competitiveness and the kind of anxiety that develops between two people working really closely together.

And they developed this bond that allowed them to overcome that stress of, you know, actually messing with each other's work.

So there's this famous story about Paul McCartney, wrote this lyric: she was just seventeen, never been a beauty queen.

It's a gross lyric, right? It's kind of icky; Paul McCartney famously icky. If anybody is a Paul person, then don't hate me. John Lennon came in and was like, dude, that's a terrible lyric.

I'm gonna make it a little bit more edgy, fixed it for him. And obviously one of the most famous pop love songs of all time and just much more, despite being more abstract, much more immediate and punchy as a lyric.

This is an example of these two guys just absolutely getting up in each other's stuff. What we encourage our tech leads and product managers to do together is co-create.

It's really easy to fall into a situation where a product manager is writing like a road map and putting together product briefs and working with the designer to produce, this is what it's gonna look like.

And for the tech lead to take that and be producing an execution plan or an implementation plan and for them to work on different artefacts and different objects. What we are trying to get product managers and tech leads in our teams to do is do that together, is co-create to co-present the stuff that they are working on back to their teams. To adopt joint responsibility for the outcomes of the teams.

And to really try to, it feels awkward, I think that they find it stressful and difficult to get that understanding of each other's domains that is sufficient to allow them to do this effectively. But what it does is give them real empathy for each other's roles and a real joint responsibility for the stuff that they're actually doing in the team.

And it doesn't always come naturally, but it is aided by physically sitting together or spending lots of time together and making that a priority in the day to day of those roles. Finally, some women, I'm sorry it was really hard to find famous, creative pairings that were not romantic pairings.

I didn't want to go there; I didn't want to imply that there needed to be a romantic connection between tech leads and project managers, and there does not, and there never is - it never happens. (laughing) So we've got Ilana Glazer and Abbi Jacobson from the amazing TV show, Broad City.

And the reason I think, Kev my colleague will appreciate this, that Ilana and Abbi got to know each other doing improv and comedy in the Upright Citizen's Brigade, which is a kind of famous nursery for comedic talent. And the reason that I wanted to talk about these two and about this improv and comedy, is because of the risk taking element.

We talk about how important risk taking is to innovation. That innovation like only occurs if we are prepared to take risks and leaps.

But the problem is, that you can't expect people to take risks and leaps together if they don't trust each other first.

And I think the reason that these two are interesting is that they started out in this improv environment which really builds, like you have to trust the people that you are performing with and working with, so it builds that trust.

And over time, with these two, that trust turned into an ability to start to tell extremely intimate, personal stories in a massively public forum and to bring that stuff to life jointly.

Which is a set of personal risks, like professional risks building on top of original investment in personal risk taking.

I think one of the reasons, lost my train of thought here, I think one of the things that we encourage at Culture Amp, start-ups are sort of naturally risky environments, like we talk about start-ups being high risk and high growth is high risk. And that it's awkward and difficult to operate in these kinds of situations.

At Culture Amp, we invest a lot in the foundation blocks of an environment that tolerates and celebrates risk.

We have sort of encoded in our organisational values the idea of courage to be vulnerable, which I think is what these two really do.

They expose their personal selves, like massively on stage, and in their show.

So we try to get people at Culture Amp to do that, to have courage to reveal their personal selves and their personal beliefs.

But we also try to, alongside that, develop a culture of feedback which I think also builds that kinda of relationship between people and trust in the relationship between people. If you can give feedback and receive feedback while recognising the kind of individual hopes and dreams and fallibilities of the people that you work with, it will happen in a much more trusting environment. And then finally, the sort of third Culture Amp value and speaks to this, is the idea of trusting people to make decisions.

And we know that that value at Culture Amp doesn't succeed if we are not actually creating a trusting environment, an environment in which people feel able to share their personal successes and failures.

So creating an environment in which it's safe for people to take risks I think is a super important thing to do.

See, I don't have enough slides.

I'm not really a slides person, generally, didn't have enough to it going to sleep.

Okay, so what I have here is just a bunch of suggestions, and there's like so, so much buried under all of this, I think Cath's talk is probably a bullet point that we could add to this.

There's a lot to try here.

It's not like a simple thing that you can do, but I think the very first thing that you can do as a leader in an organisation is to model vulnerability. To share your own personal difficulties and failures and successes and life stuff with your team. To enlist, like I said there's a lot hidden under, enlist your leadership counterparts in a project of creating psychological safety.

We know that's not easy, right? But you have to be able to, as a leader, give a lot of yourself in order to start the process of creating psychological safety. Asking for feedback and then asking again.

Trying to get people around you comfortable with giving you feedback.

We talk at Culture Amp about being a feedback rich environment, which is sometimes a kind of slightly coded way of saying it's a terrifying place to be at times.

But asking for feedback and then giving feedback generously helps to develop that sense of trust and support. And I think really importantly, if you wanna build a culture that is risk tolerant, celebrating learning rather than just celebrating shipping or delivering stuff, is a really key part of that as well.

Yeah, so these are the kind of models that I think that you can try.

And they're not mutually exclusive.

They're not things that you have to institute variations of all of them in every team, or every relationship.

I think the key is to try different things that bring your product managers and tech leaders together as a really close unit, with the obvious end goal of producing work, like building teams that are confident to deliver work that satisfies your customers and your users.

I think it's a really, really hard thing to do, but I think when I look back at the Culture Amp founders and the success that they've had, so much of it seems to emerge from the trust and the relationship that they've built between the four of them.

And it extends even today now that the company is so much bigger and they have left, they sit together less in a room having ideas and being brilliant, than they used to in the olden days. So yeah, too long didn't listen, is be clear about what you expect from yourselves and from each other. Co-produce works, actually produce artefacts. The product itself is often a lagging indicator. Produce stuff together ahead of the product that bonds you as a team and gives you that sense of common purpose and ownership. And be vulnerable, build trust, and create space for taking risks.

And before I wrap up, I just want to share this text message I received from my friend Mike, which is in real Mike language here, hard to read a little bit.

But basically what he realised was when he joined a government department that he expected that as a hierarchical organisation that everybody was gonna do what was expected of them, according to the role that they'd been given or the policy that they were reporting under or structural incentives, whatever.

And LOL he said, because it didn't actually work out like that.

I think this is a really fundamental thing to recognise is that, he went on to tell me nine thousand very specific weird hacks that he has for creating relationships with his team members in order to actually bring to life the dream of getting people to do stuff in an organisation. He said it's so much not about the hierarchy or your role in an organisation, and so much about the relationships that you have with the people that work with.

He felt a little bit silly for not having realised that before he went into this environment.

And it kept coming back to me over and over again, like firstly his hopefulness that, I'm gonna work in this structured organisation where everybody will be really clear about what they're doing, and then his despair that it didn't actually work out like that and he had to resort to a lot of social manipulation to get his way.

Don't let it get to that; try to intentionally create positive relationships and role model positive relationships in your organisation so that you don't have to resort to weird creepy hacks for like learning people's names and buying them coffee on the second Thursday of every month or whatever special thing Mike does. Thank you so much for your time.

If you have thoughts or questions or feedback about the talk, feedback - I'm asking for feedback, please do email me and Culture Amp is almost always hiring so if you are interested in a new job get on the Culture Amp website and we'd love to hear from you.

Thank you so much.

(applause)