culture – Joe Blogs

What’s in a name – Owner, Manager, or Leader?

My esteemed colleague @benjiportwin just wrote a parting post which talks about job titles, and how much they matter, if at all.

He opened with the the Product Owner vs. Product Manager job title thing, which I’ve also been thinking about.

When I joined the NHS Choices team a few years back we had Product Leads who each looked after a specific area of the service. They did a great job of defining the changes needed for their particular products, but didn’t always interact directly on a day-to-day basis with the people building those products.

Changing titles to indicate change

We spent a couple of years changing this as we implemented agile methods across the programme. At the time I pushed for these roles to be called Product Owners, mainly because I wanted to force a distinction between the old and the new way, and that’s what the methodologies we were adopting (like Scrum) tended to call that role.

Shared ownership rules

I tend to associate the Product Owner role title with Scrum, and over time have gone off it a bit. Partly because I don’t like the idea of sticking with just one fixed methodology, and partly because it could imply one person having sole ownership of the product. I much prefer the idea of a team collectively owning the product that they build and run together.

Industry-standard

Instead I shifted towards the Product Manager job title. This seems to be much more of an industry-standard these days. If I see a Product Owner job ad I think “they do Scrum”, when I see Product Manager I think “they have Product teams”. Generalisations I know, but that’s what it conjures up in my mind.

Full circle

Most recently I’ve come back around to Product Lead. I like the idea of somebody leading the development of a product, rather than managing it. I think we all know the difference between a manager and a leader.

Managing a product could perhaps be read as holding it back, pruning it, keeping it in check (thanks to @st3v3nhunt for this). Whereas leading it talks of setting a vision, inspiring progress, and taking the product forward to exciting new places!

Does it matter?

I’ve thought about this mainly because I’ve been taking on a product role myself, but really, as Benji said in his post;

job titles are interchangeable and frankly unimportant, but what matters is the impact you make each and every day.

Good luck in NYC, Benji. See you on the sun deck!

Resources, or People?

Workplace language is interesting. We hear a lot of different jargon and cliches that we wouldn’t ordinarily encounter outside of the office. I think we know some of it is a bit silly and acknowledge it as such, but other workplace language is treated as totally normal.

One of the most common, but perhaps pernicious, examples of workplace language is the use of the word Resources, when we mean People. It really does seem to be workplace-only vernacular too – I’ve yet to hear anyone say “We need some more resources for 5-a-side tonight.”

I understand that it’s a fairly industry-standard term, but that doesn’t mean there aren’t issues with it. Lots has been written on this before – posts like this, and this – and there’s even a day dedicated to the cause.

oxforddictionaries.com defines resources as

A stock or supply of money, materials, staff, and other assets that can be drawn on by a person or organisation in order to function effectively

So technically speaking using the word resources to describe people isn’t wrong, and sometimes it makes sense to use the word resources to describe a particular ‘thing’. Resource management isn’t just about people – it could be about laptops, office space, or beanbags.

But 99% of the times I hear ‘resources’ mentioned at work, it’s being used to refer solely to people.

The problem is that the word resources seems to imply an interchangeable quantity –

“we need more resource”

“add some more resources”

“this resource is leaving, let’s get another one in”

From a management point of view this is great. It would be fantastic to be able to swap interchangeable resources in and out at will, in order to maintain performance.

But of course it doesn’t work like that. People have different skills, personalities, likes, dislikes, attitudes and so on. You cannot simply switch people in and out of a team, and expect things to continue at the same level or pace.

Because in knowledge work, value is generally delivered by teams, not individuals. A team is not just the sum of its parts – it’s the product of its interactions. The relationships between the people in the team determines the success of the team – it’s not about just adding up the raw skills of the individuals in the team.

The word resource obfuscates this fact. It helps us to kid ourselves that we can work in this way – swapping people around. It’s hiding the reality of the situation that when you’re dealing with knowledge work – people are not always going to be completely interchangeable.

That’s not to say I’m not against moving people around between teams on some regular basis. This can keep things fresh, and helps to share knowledge. But I think I’d get better results from trying out a new winger in my regular line-up, than swapping out the entire midfield.

I know a lot of people don’t like being referred to in this way, but I don’t think this is just about individuals being sensitive to being called a ‘resource’ – it’s about our cultural definition of how we view and treat our people, and about how we plan and manage work in a realistic way.

Having shared language is really important for building shared understanding, but next time you’re about to use the the word Resources, maybe pause and think; would the word People explain the situation in a clearer, more helpful, and more realistic way?

Building consensus around product ideas

I’ve spent the last year or so working with teams in the early stages of Product Discovery – examining the needs of users, and forming ideas and prototypes of services we can deliver to meet those needs.

One thing I’ve seen is the tendency in those teams to have the same conversations about a particular topic or idea several times over. Sometimes in the office, sometimes over lunch, and sometimes in the pub after work (which is where a lot of good ideas form).

This isn’t necessarily a bad thing while we’re shaping our ideas and building consensus in small groups. But once we’ve found ourselves repeating, and agreeing, the same concepts a few times, it feels like it’s time to get things out of our heads and onto some paper, so that we can share the idea further, and build a broader consensus.

The worst case scenario is if we don’t do this, that a small group forms an idea and assumes everyone else is also thinking the same thing. In the early stages of delivering a new service for users, building shared understanding across the whole team is critical.

Audio recording

A nice idea we tried recently was to get a small group of us (three worked nicely) to record the conversation. Kudos to @evilstreak for taking inspiration from the work @mattsheret has done with us on blogging.

We found a quiet space and used a USB mic (that we use for remote meetings) and Quicktime to record our conversation for about 30 minutes.

We didn’t write anything down beforehand, but the conversation was fairly structured, as we’d already had similar versions of it before.

One side-effect of the recording was that we were a bit more conscious of what we were saying, and avoided any unnecessary rambling. Being aware of the recording also stopped us from talking over each other at all. This is something we sometimes suffer from, as everyone has so many ideas to share, people just want to get them out there.

After the recording we transcribed it verbatim into a document. By sharing the audio file, two people were able to work in parallel for 30 minutes to get the whole conversation transcribed.

Pro-tip – using VLC to play back the conversation at a slightly slower speed (about 80%) allowed the typist to keep pace with the conversation without having to pause and replay bits. If you’re a really fast typist maybe you won’t need this.

Listening again to the recording actually helped ideas to crystallise in peoples’ minds. You were listening more intently, rather than thinking about what to say next, as you might in conversation.

Getting feedback from the wider team

As it was just three of us that had the initial conversation, we needed to gather feedback from the wider team.

Initially sharing the transcript was a useful way to share the ideas. Teammates reported that reading the transcript was a very natural way to read, and understand the ideas.

We then began to structure it into a more coherent narrative. Using a tool that enables quick electronic collaboration (like Google Docs) is really handy here. Everyone can be in the same version of the document at the same time – teammates can add comments, responses can be seen instantly, and everyone can see updates as they’re being made.

Crits

We supplement this electronic collaboration with group crit sessions.

Anyone interested in providing feedback gathers around a table and we read through some ideas and have a time-boxed discussion with the goal of gathering specific change to make to the narrative.

In this case we quickly realised that we didn’t have consensus across our team. Lot of new ideas came from these sessions, and the original narrative gave us a way of framing this discussion.

A picture speaks quite a few words

Another (fairly obvious) way of clarifying thoughts and ideas was to do quick sketches of your thoughts. Drawing something and showing it around was a really quick way of prompting further conversation to build shared understanding.

It’s handy to draw something and then pass it to a colleague without explaining what it shows, then ask them to explain their understanding of it.

Building consensus in public

So we’ve built some consensus amongst ourselves, within our team. Next we need to build some consensus with the wider world outside of our team – with our stakeholders and with the public.

We need to be open with our ideas as early as possible for a couple of reasons –

All the services we’re delivering are created for, and paid for by, the public. We should be transparent about how we’re spending public money.
The health and care system is complex. There are many different organisations involved. Being open about our ideas and proposals early on is a good way of getting the message out to these organisations, and starting a conversation with them.

One way in which we share our ideas openly is by blogging.

The document and drawing described above were drafted into an initial blog post by @evilstreak and @paul_furley, the drawing was redrawn by @demotive, and the resulting post is here – Booking is critical for transforming healthcare

Failure IS an option

I wrote this post after coming off a daily ‘stand-up’ call where one Developer admitted he “didn’t know what he was doing” because he’s covering for one of our UI Developers while she’s off , and a DBA told us we weren’t seeing the data we expected that morning because he ran the wrong package by mistake.

It got me thinking about how it’s important to encourage an atmosphere where people aren’t afraid to talk about the mistakes they’ve made.

No-one admonished these people for saying these things. We respect someone for being open about the fact that they made a mistake, and then fixed it. We admire someone for actively stepping out of their comfort zone to work on something they’re not used to – it broadens their skills and reduces the number of single points of failure in our team – which in turn helps to keep our work flowing.

Whilst failure can be bad – it is also a chance to learn, and improve. It’s okay to make mistakes, and to admit when you don’t know the best way to do something, as long as you learn from it!

photo credit: ncc_badiey cc