Building High Perfomance product Teams

(upbeat music) (crowd clapping) - [Anna] Thanks John and thanks Padma and Simon. I don't know if Simon's here.

For putting together the programme and I think for any of us who have been at more than one Web Direction's event in the past. I think the genius of John is that he curates the programme so well.

So it's fantastic to stand here and build on what David said and what Padma said and tie it all together.

I don't have dogs but you probably will be really hungry for a cookie by the time I finish the next 20 minutes or so. So I'll talk about building high performance teams and just a little bit of background, as John said and as David confirmed.

Once you're over 40 no one listens to you.

So that's kind of a very fragile position to be in.

But my background is in product design, IT and that's the space I've been drifting in and out of for a while and in the last six months, I stood up on one of the founders of a product called, thnx! And thnx! Although it's young, it's just gathered a whole bunch of momentum and I've just returned from Vegas, where Microsoft used our product to send thnx! out to 10,000 people at their annual Microsoft Inspire Conference In front of 35,000 people, the fourth senior person at Microsoft stood up and said, "I'd like to thank you all for partnering with us and as a token of our gratitude have a coffee on us" And in the first four hours, we had a coffee bean redeemed every second. It was wild.

And so to go from zero to that to being in front of 35,000 people and speaking to, not just a speech writer for Gavriella Schuster but a team of speech writers.

It was like dealing with the president.

Pretty wild.

And obviously not just exciting for me, myself, and my product thnx! but also for Australian tech in general.

It's just really exciting to be called out on the global platform and landscape and have a very new and emerging product, that's built and located in Australia, being showcased on a national podium.

Today, I'm going to talk about a good product team and David did a beautiful intro to all of that this morning and so we'll all have a different sense of what a good product team consists of.

We'll probably not disagree too wildly on all of this. We'll have UX Designer, 2 to 3 developers, very often we forget to put someone who's in charge of QA into the team but I think that's a pretty important role.

I had a Product Lead on there but I changed it to Product Manager after hearing the discussion this morning so that sort of function, which, of course, is distinct from a Project Manager, we generally will lean on Graphics Designers and UI designers and for me, the Marketing person or the Marketing CRO or Content Strategist is a role which I like to include in the Product Team as well. I think it's really important, especially when we're dealing with SES products and we talk about influence and nudging someone along their product life-cycle from cradle to grave.

It's important to have that built directly into the product. But that's all a separate talk.

In general, we won't argue too much about what the structure is and depending on what your particular needs are whether it's a tech-heavy or a marketing-heavy organisation you might have more or less developers the ratio will change.

But whatever this structure looks like for you, we have a team structure and we have roles. And in our day-to-day we go about defining what those roles are and then going through the laborious process of matching people's CVs to those roles and hiring people in.

And then we hold our breath for a little bit of time hoping that the next hire is a net plus and not a total fail, right? I see nodding (chuckles) I think we all relate to that.

And so today, I'm going to echo John's opening remarks. We're not here to hire people or interview anyone. We're here to take a departure from what we do everyday, which is filling people into these slots.

Join me on this journey and it's a bit of an exploration and so for the next 15 to 20 minutes I'll talk about a couple of ideas and I hope that you challenge your own thinking. I definitely hope you challenge my thinking. I hope we all walk away a little bit stronger and do all of that but don't throw tomatoes 'cause I'm not an arts nerd like David So I'll probably get scared of tomatoes.

Today, my proposal to everyone here, my proposal to myself, is that we can build efficient and consistent high-performing product teams by looking at two factors. And those factors are hum and scale.

And I'll start with hum.

And hum, you probably haven't read in scientific literature but one of the great benefits of being super over-educated is you can make up words and it sounds credible. We'll talk about hum.

Now, I don't have a formula for hum (laughing) but intuitively we all kind of know what hum is at an intuitive level.

And we can point to the All Blacks and talk about how they're the best performing rugby team of all time and how their hums come from comes from culture and even though the players swap in and out their culture of sweeping floors and humility and all of that is built into the team and that's what makes them an amazingly high-performing team We also can look to things like leadership and Cameron Smith and again the people come and go from the team, from the Melbourne Storm but the team is high-performing.

Now we've got a couple of these different things. Is it the person and their leadership? Or is it the sweeping the floors? And what exactly makes a hum? And again, at an intuitive level we do understand (talks to herself) we do understand what hum feels like and what the results of hum are, right? When we have a team, a product team that's performing really, really well it's fun to show up to work.

And we have creativity and we're all in flow and everyone is working together and we're not pointing to road maps to say, you didn't get this done by such and such a date. We create magic.

And for those of us who have been lucky enough to be in that kind of team, it's memorable and it stands out and we know what that feels like.

And then we (talks to herself) And then we ignore it all.

Right? We ignore it all.

And we go back to having our structure and putting people into slots and hiring people, matching CVs against role descriptions. And we ignore it all.

And this process is reasonably laborious so we put people into slots, we ignore it all, - and this happens all the time not just in product teams but we look back to the high-performing sports teams out there and a team will perform super well and all the commentators and all the journalists will give lip-service to teamwork and how the team is doing really, really well and the day the season finishes all the players get poached, right? During season it's all about teamwork and at the end of the season it's about taking those star players putting them on different teams and everything is broken and the hum is all gone. Part of the reason why hum is hard to define is that hum is an interesting property.

We have our team structure, and we fill it up with people and the reason why hum is hard to pinpoint is that it's not what's there.

Right? When we have a team of people and they're all, let's say, super high-caliber, we've maxed out our budgets, we've hired the best, we stand up another team and we do the same. And so we've got two teams and they're equally good people but those two teams are different.

They're not gonna have the same kind of hum that is happening inside their team.

And one of these teams will be creating magic and the other team might not be creating magic. And it's like, why is that? And I think part of the reason why that is, is that hum is what is not there.

It's not a property of what is there, it's not a property of a CV, and it's not a property of the person that is hired into a team, and it's not a property of the structure of the team, it's actually the space in between.

What do I mean by that? Let's say we have our two teams and they're all very, very high-caliber.

One team might be very open and embracing of ideas and change and people might feel very equitable.

And another team will have a really different flavour. And when we grow and when we stand our different teams even though we replicate the structure and we have all the budget in the world to hire the best, every team we stand up is a little bit different. And again, it's that space in between individual people that's really different.

And that's what flavours the team, and that's what creates the hum.

When we break it down, I'll look at what makes up a hum in a slightly more detailed level rather than it's just a coloured cookie.

What makes hum? We have a team structure and we fill it up with people and the hum is there.

We already have decided it's the space in between the people and when we break that down there's different kinds of pyramids and and models out there, but most of them will have some kind of a flavour of this. This one is Patrick Lencioni's work, he is terrific.

And he talks about how in order to optimise for results you have to have a team where people are accountable. And again this comes back to Padma's talk about road maps and that road map gives us accountability which is both a plus and a minus.

You have to have people who have commitment. You've got to show up every day.

You've got to show up as David said this morning. Part of being a high-performing team is that you show up and you do the work.

You've got to have conflict.

This is one where you go, "Huh?" "What do you mean?" "We shouldn't be fighting, we should be working together" but the ability to have conflicts and table differences of opinion and discuss that in a respectful sort of way is really necessary.

If you can't have conflict your team doesn't perform. But underneath all of this, regardless of what kind of model you adopt and you take on, all the models across there, when you look at the very foundation of them, they have trust.

And trust is the foundation.

And without trust, it doesn't matter what else you layer on on top of that you will not have a high-performing team.

And as a plug, showing your gratitude for someone is one of the best ways to build trust.

So there you have it.

But trust takes time.

It's not instantaneous.

I'm going to pause for a moment and ask you all to take out your phones.

Take out your phone.

It's okay to do it.

I don't mind.

And unlock it.

Type in the number that unlocks the phone.

Or stare at it or whatever it is.

And now take your unlocked phone and give it to the person two down.

Because the person sitting next to you probably knows you. (chuckles) (crowd movement noises) (crowd talking amongst each other) - Well a lot more controversial than I expected! Right-O.

And so we're all friends and we're all product people and we're all very open but there's an edge to that.

I don't know what you guys have found on the person two doors down phone but back to me.

All right.

It takes time to build trust.

And it takes time to build trust and when you hand over your phone to hopefully a stranger but probably a friend because that was all too easy.

There is an edge to that.

And even though we've all shared morning tea outside and probably swapped names and what we do and hellos and all that, it takes time to build and the seat people will have the right numbers on this but I think it's usually around six months, in general when you hire in a person who is a good fit the overhead of that new hire is about 50% of the first year's salary.

Just in lost time and productivity and also because we're building trust.

And that is what hum is made up of, right? We've got the formula.

We've got the roles.

We've got the budget.

We've put the people into those roles.

And we take the six months and we build the hum and now, give the phones back by the way.

(crowd laughs) - [Anna] Right-O We do all of that and then the product it's screaming along, it's going really well and we need to scale because we need more people. So how do we do that? How do we make this process of creating really high-performing product teams a little bit more efficient? Let's go back to the cookies.

We have the structure and we have the hum and we know that it's a property that exists between individual people. So each table here, given six months sitting in this room, you might develop a good level of trust and then if people swap chairs, that trust is broken and we start again.

And again to refer back to David's story.

David, you talked about how you change roles and how that process of hopping into a different team, even within the same organisation, it takes time to do all of that.

And because hum is a property of individual people, sitting in a specific context, the bad news is hum can't be scaled.

It's impossible to scale that.

So thanks very much and have a good day (chuckles) Right-O.

We can't scaled that.

It's a property of individuals sitting in particular seats, and so that's rather bad news.

We're gonna take a segue and look at the product lifecyle next.

Let's look at the process of creating a product and pause for now the fact that we can't scale hum. Bit of a disaster.

So product lifecycle generally, these are the way I look at a product.

And we start with ideation and everything is up in the air and fuzzy.

And then we execute on the idea.

And we stand up that MVP or the minimum story or whatever it is.

We execute on that.

And then once it's ticking along and going pretty well we start to systematise stuff because everything is kind of chaotic and we're not being efficient.

And then after that, we go into a phase where we optimise. Theoretically, Microsoft and companies like that which are in that very late stage of product development lifecycle will be more looking at how do we optimise things? And then, how do we ideate? Although there's different teams working on things. But so when we look at all of that and we look at the role the team's playing in all of this in the very simplest case, if we look at a start-up that's tracking along you might start with a team and that team moves from ideation to execution and then the product evolves and it's still the same team working on all of that. And if we have a slightly different example, which is a bit more complex, we stand up a team and then we grow and so we stand up another team and we wait six months and that team ticks along and then we stand up a third team and that team ticks along and all the while we're repeating the same process and not really being efficient, but recognising that, what could we do? We can't scale hum.

And so I want to look at something which we tend to forget in that process of product development and the product lifecycle.

And that is that even though there are four distinct steps and even though we take a team and we often move it along that, from ideation all the way to optimization.

The end points are really, really different. The ideation phase is chaos.

- The optimization phase, there's a lot of order. There's a lot of knowns at that end of the spectrum. Which is why we can optimise.

And again, tying back to Padma's talk, part of the reason why road maps are both your best friend and the most evil thing you've ever seen it depends what phase of the product lifecycle you're in. When you're in chaos, a road map is like a noose around your head. You don't want to talk to a road map.

When you're at the other end of things, where things are in order, well that's fantastic.

You want that product road map, you can have certainty that yes you will tick off these boxes and deliver on the following things in the next six months. More or less.

More or less (chuckles).

And so, if we take these two end spectrums, chaos and order and we look at ourselves internally, without doing a personality assessment or a personality test.

We'll all have kind of a feeling of whether we lean more towards thriving in chaos or towards thriving in order.

And when we've looked back and you think back to the times where you've been on a team where things really, really hum, it's usually not just that your skillset and all the other factors line up and you match with the people in your team. It's probably also that that team's quite wired for performing either on the chaos end of things, in complete disorder, or prefers to be on the other end of things, where things are more systematised and there are far more knowns.

And so what could we do to make standing up teams more efficient? And this is why I cancelled dinner last night. The next couple of slides might blow your mind. It's an animation done key note, and it took me 27 hours and so (crowd laughs) Can you just take a moment and appreciate this, right? Try and repeat this at home, yeah.

So going back to the content, How can we make the standing up of teams and developing product far more efficient and consistent? Here's my proposal, that is that we take a team and when it gets to the next phase, so we take a team which really is amazing in chaos and the people on that team work really, really well and they build that ideation phase all the way through to execution.

Rather than tasking the team with going on a little bit longer than they want to, bump them out.

Bump them out and put them onto the next project where we're dealing with ideation and stand up a new team.

Ideally a team that has worked before together. So the hum is there, the people know how to work well, and they fit in to the execution phase of the project a lot more where there is a little bit more certainty. And then not surprisingly, repeat that process. Take that team, take them along to the point where they reach the end, not in necessarily of their skillset but of their personal preference in relation to that chaos and order spectrum. And then bump them down.

Put them onto the next team.

And because the unit that we're moving these cookies along that is a team, not an individual, you've got a lot more consistency and a lot more efficiency in that process of building out product and standing up teams. To sort of summarise all of that, hum is something that is real and it's important and just because it's a non-entity, it's a negative space, it's the space in between individual people, doesn't mean it's not important.

It's actually fundamental to high-performing teams and how they work.

And I think that to gain consistency and efficiency in the creation of high-performing teams it's really important to optimise for hum and not for scale.

Not for growing teams far beyond where they should be. When we think about that cookie moving along and dropping down and moving along and dropping down. You think about the SAS team, the Green Berets, those people where they work in teams of 6 or 8 and they go and destroy a place and come back and they never existed, right? They don't stand around to hand out parking tickets. They're in there to destroy and they're out and another team hands out parking tickets. So we don't really use that same philosophy in designing product.

Also, zooming out.

Have I got, how many minutes have I got left? 'Cause this next part is just fun, I've got five minutes, terrific.

I'm a product person and so it's impossible for me to explore all these different ideas and not immediately go to, "Hey what kind of product could we create at the end of all of this?" And I'm delighted that SEEK is here 'cause you guys will all want to talk to me after this talk. So cool.

So zooming out, let's look at some macro-trends. We're in a Gig economy.

At the moment, 36% of the American workforce are freelancers. And that is predicted to grow to 40% by next year and increasingly so.

Especially in product and in the creative field, it's pretty normal to be a freelancer and to jump around from gig to gig.

So this notion that you don't stick around in a job for life, is all pretty normal for us.

That's not an unusual mindset.

Co-working spaces are on the increase.

Everywhere when you look around the world, we work just IPO debt, I'm bad with numbers but a gazillion dollars or something like that. The co-working space is everywhere you look, there's a co-working space.

And that again speaks to that notion that freelancing and contracting and the idea of non-permanent job is something that's on the increase.

And fluidity.

You read the HBR, you know, business model kind of nerdy stuff and fluidity in the workplace, this notion that teams come together for a project, high-performing teams, you come together for a project and then you dissipate after and then you come together for another project and you dissipate after.

That's something which is, again, on the increase and there are business models around that if you want to read around that formally.

What all of this, taking all of that together, people are tending towards being contractors and there is great efficiency in standing up and working with teams that already have hum well established.

Co-working spaces are on the rise.

Fluidity is a normal kind of thing.

The proposal that I think and with products in this sort of space and the future lie is creating products which will enable us to hiring teams and not as individuals. That notion where we stand up a team structure and we have a perfect team structure, and we put people into roles, and we wait six months, and someone leaves, and we do it all again.

What if we change the unit of measure? And the unit of thought? And we started about all of this in teams as the baseline and not as individuals.

And that's what I've got for you this morning so as I said, challenge me, challenge your own thinking, challenge all of these ideas.

Some thoughts.

So thank you so much.

(crowd clapping) (upbeat music)