Category Archives: Product Management

The last year has made us rethink how we do many things in our lives. Forced to adapt, we have found alternative ways to see friends and family, to do our work, to spend a lot of time at home… One thing that I reflected on this week was finding new ways to learn. 

There was the initial boost of creativity and impetus to try new things in the first lockdown – maybe you also tried baking, gardening and sewing. But that enthusiasm went away for me as restrictions and lockdowns became a routine. Also, I was very focused on learning crafty things – but learning at and for work became secondary.

Learning at work became secondary

The first few months, I was in survival mode as we figured out how to adapt all our ways of working to the remote environment, while also getting to grips with how the world was changing. 

Following the initial shock, I have spent most of last year on creating a work/life balance. And this has taken a lot longer than I would have expected. I have experimented with my work hours, eg when I do what type of work. I have also experimented with my free time, eg what type of activities are best to get me out of the work mode. It has been journey of self-discovery and how to best motivate myself. 

I think I’m 80% there. I still have days where I find it hard to let go of work thoughts, despite all efforts to create better boundaries.

When it comes to ‘work learning’, this has been difficult to fit into my new system. I have always learned for and about work outside my work hours, be that on the weekend, or in the evenings. It’s something I am passionate about, and it’s something I’ve always done that way (just like I write this blog). But it also means that this has conflicted with the boundaries I have been trying to set up in the working-from-home context. There are days (and they are still quite frequent) where the thought of a work-related podcast or book just feels too triggering. I am in self-protection mode, where I ward off any work stress. But through adapting to the new context, I am slowly getting to a place where I can learn again.

What learning looks like now

Podcasts: I used to listen to podcasts on my daily commute, which means that my podcast consumption went down dramatically this year. In my new routine, I use food shopping and occasional walks as my podcast time. It’s not as much time as I dedicated before, so now I curate my listening more carefully. I only regularly listen to one product-related podcast (The Product Experience), my other regulars are HBR’s Cold Call, the Wired podcast,Intelligence Squared and Squiggly Careers. They don’t specifically apply to Product Management, but are real food for thought, opening my mind to new ways of doing and thinking. 

Reading: I have been trying to read, but as I used to love reading in coffee shops (and in France these have been closed for a good 6 months now) this has been harder. While I can read ‘fun’ books at home, I have struggled to read work-related books at home. That’s to do with the boundary-management I mentioned above. I splashed out on a Harvard Business Review paper subscription, and quite enjoy the format, as I can pick it up and read only an article a time, and don’t have to commit too much.

Learning with my colleagues – This is a completely new thing for me, and a much more intentional practice that I’ve developed this year. This can take different aspects, but to give you examples:

• I recently watched a talk with a colleague (she shared her screen and sound), and we paused and discussed what was being said, how it applies to our context
• With the product team, I’ve been organising learning sessions. We’ve been reading Product Management in Practice, and chapter by chapter we sit down to talk about what we found interesting, and what we could take away from it.
• We also do a product clinic, where one person comes with a problem and we swarm around the problem to think of what we might do about it.

These practices are the most rewarding and effective. They are fairly easy to do, so I manage to stay focused, they are directly applicable to my work and they have also further strengthened the ties with my colleagues. 

Learning other things  Particularly after I listened to the episode of Intelligence Squared with David Epstein, I felt even more inclined to learn about things not related to my job or career. He argues that in most fields – especially those that are complex and unpredictable – generalists, not specialists are primed to excel. So learning about random things you’re interested in isn’t only fun, it can also be useful!

For the past few months, I have been learning to play the piano – fulfilling a childhood dream of mine. I have also been doing free courses on Coursera (one on Financial Markets I recommend!) to learn about things just because I find them interesting, for the joy of learning.

You’ve just joined a new team, you’re being assigned to launch a product which is nearly ready, and from the moment you set eyes on it, something doesn’t feel right. You don’t quite get its value, you don’t see how others might want to use it, it doesn’t feel right… but then you don’t know your users yet. So what do you know. 

That feeling doesn’t go away the more you learn about the product. It’s your responsibility to manage the product, but what if it was your responsibility to kill it? 

This is what happened to me last year, and here’s how it went.

I found an ally

Coincidentally a new UX designer started at the same time as me on the product. After some getting to know each other, we started to feel enough trust to speak candidly. In theory the product was ‘ready for launch’, yet we both couldn’t understand how this product was going to do well. 

It was very complicated, didn’t look particularly modern, and while it did some things well, it was a NEW site that our users had to start going to. Considering it was meant as a daily productivity tool, we really were not confident.

However, we also didn’t want only our expert opinion to shape the course of the product, and wanted to seriously consider the possibility we could be wrong. We therefore tried to approach the process as objectively as possible.

Get evidence, all the evidence

While we felt that there were some big problems with the product, we also knew that the team had been working on it on and off for 2 years and the director had been selling it to stakeholders as an answer to some of our biggest problems. So we couldn’t just go and say ‘hey, we know we’re new, but we don’t think this is a very good idea’. 

So we did the following to build a case.

A private beta

We promoted the product to some 100 odd users we randomly selected to represent different job families, seniority and locations. We intended to observe their behaviour over 2 months. We saw that most went onto the tool and checked it out. Yet, only 1 user returned. 

We sent a reminder to see whether a second go at discovering the tool (or maybe a first for those who hadn’t visited) might trigger them to come back. But still nothing. 

Apart from that one user who seemed to like it. 

Design workshops

Through several co-design workshops we explored what users might possibly need from such a tool. Previous user research had only included interviews on work habits and testing of an initial prototype. We thought a co-creation workshop might help us learn more about the daily habits of our users. We pretended we were still at an early design stage and didn’t show them the live tool in order to get a fresh perspective. 

What we found in the workshops were that the things the users pointed out to us, were so different according to what type of job you worked, what your local conditions were like and your personal preferences, it would have taken a complex and highly customisable tool to actually create significant usefulness for our users before they would start using this tool. And we certainly didn’t have the budget for that.

User interviews and tests with our beta users

We also conducted user interviews and tests with some of the private beta users to see what happened. There we learned that indeed the page didn’t meet a significant enough need and they already had their ways of getting around and checking notifications, that they didn’t need another thing to manage that.

Some of the verbatim quotes the user researcher highlighted were a brutal wake-up call.

Bringing people along

Ok, so now, we had a lot of data to confirm our intuition, we needed to make a decision on what’s next. The way we approached the above steps were crucial in bringing people along to get to that decision point. All of the data-gathering was done in full view and often with participation of the two crucial groups we needed to bring along with us – leadership and the product team.

The leadership team

We needed to get their buy-in to stop developing the product, as they are ultimately responsible for our team’s work. We knew the evidence will get us most of the way – as our leadership team is very open to our inputs and will listen to facts (not something one should take for granted I have learned). 

However, we also needed to understand internal politics and the implications that a strategy change might have for the relationships we have with other departments. We also needed to understand the potential emotional attachment the leadership team had for the product, and their openness to change course and defend a new strategy. 

All of this was important to know, so that we could manage the change for them. Through my weekly conversations, I started sharing my doubts, first subtly, then more candidly. I asked about implications, first asking in terms of hypotheticals, then talking options. I also explained our approach to gathering evidence, and what we were hoping to learn from each step. By preparing them in increments, there was never a big ‘tada’ moment in which I revealed how I knew all along that the product was a bad idea.

The team

The concerns we had regarding the team’s acceptance were different. We knew that they would go along with a decision that was validated by the leadership, but we felt it important to keep morale high, and not let this process demotivate them. After all, this had been 2 years in the making. 

Especially as a newcomer it was important that others were on the same journey. We didn’t come with a new vision for the product immediately, we facilitated enough of the reflection so that the change felt gradual for everybody involved.

The feeling I wanted them to take away was pride in the fact that as a team we were able to take tough calls to do the right thing. To listen to evidence, and challenge ourselves to build what’s valuable.

The different team members, a junior PM, a developer, a UI designer, a content strategist discovered the data with us. They had access to our beta test dashboard, and we reviewed the data together and prepared the user research together. With the UX designer, we tried not to jump to any decisions too quickly and mainly discussed the facts, and we asked the team what their conclusions were. 

When deciding what to do next, we put the team in front of 4 scenarios (including one to go ahead with the launch). We empowered them to help us shape our next steps, and in the end they all agreed to go back to the original problem we tried to address. We also showed the leadership team the conclusion the entire team had drawn from the evidence.

Reframing failure

We had a final meeting with the team to discuss how we all felt about the fact that we stopped the launch of the product. It was a bit like a group therapy session. This also marked the end of our work together, as the next stage (back to the drawing board), wasn’t going to be with the same exact team. By giving everybody one last chance at sharing how this process made them feel, it gave us all the necessary closure.

We also had a big discussion about failure, and the role it played in product development.

How we talk about failure is very representative of our organisation’s culture. The reason it was important to bring the team along in this decision is to ensure that we could talk about failure in a constructive manner. They needed to co-own the process and realisation.

Yes, we got it wrong, yes we had good intentions but we lost ourselves on the way there. Then we all used evidence to stop the launch just in time to avoid investing in a product that was truly going to be a waste of money.

We insisted on celebrating that as a team we stopped a thing that was going to be a much bigger problem. Instead of feeling like we failed as a team to launch this product, we felt proud to have done the right thing and prevented a much bigger failure.

Sometimes you’re not the newcomer

In this process I had an advantage from the start, as I was new to the team. It can definitely happen that you’ve been part of a thing and it suddenly hits you that maybe it isn’t a great idea. Yes in theory we should be reducing risk and learning as much as we can as we go along, but in practice things can get out of hand before you know it. That could be because of stakeholder pressure, the difficulty of getting data, working in a reduced team, or just not being that experienced in product management. 

So what do you do when you start doubting your product? 

I believe you can follow similar lines to what we did, just the thing that’s missing is the ‘newcomer’ effect. As a newcomer people expect you to bring a new perspective. As an established team member how can you suddenly defend a new perspective – especially if you had previously defended this product? 

I think it’s important to start sharing your thoughts with people you trust most, see what they think. Phrase them as doubts, not a complete loss of confidence in the project. Establish what you need to know to eliminate those doubts. 

In addition, use the language of risk. Explain that you’ve identified this new risk – like the project might flop if we’re not completely sure we’re solving ‘x’ problem. Say how you want to mitigate that risk, and then start the process described above. Start working with your team on this, as soon as you can.

When one realises something that feels truthful, it can suddenly appear obvious, yet it doesn’t mean that it was easy to realise it without someone pointing it out or something triggering that realisation. (Most times when I realise something about the bigger picture of my product, I get the immediate feeling of ‘I should have realised this ‘x’ months ago’.) So, be kind to yourself and act with what you know now. It’s never too late to make the right decision and to change course in order to achieve user value. And even if it might be a tough thing to do now, in the long term the focus on user value will always be the right one.

Last week I had my performance review, and for the first time I actually enjoyed it and was grateful for the conversation we had.

Until recently I would have described the performance review or annual review as the yearly awkward moment to talk with your manager about your achievements and skills.

When I worked at smaller companies, there wasn’t really a process, it was just a discussion based on impressions and opinions, a retrospective on what had happened. Sometimes it was an opportunity to set yourself learning objectives, but it wasn’t really helpful in making me think about myself. 

In my last job, the annual review looked at your objectives (that you had set yourself) and depending on how well you achieved them, you got a specific mark. As product manager that was often a bit difficult , as the success of your product and your objectives may depend on all sorts of circumstances outside of your control. Most importantly, it also never really gave me an indication as to how I could personally grow. 

I want to emphasize that this isn’t a stab at my previous managers, who helped me in many other ways. I firmly believe that they were not given the right tools to do performance reviews well. 

What specific process are we talking about?

I attribute the fact that this year’s experience was much more positive to the process set within Ubisoft, and to my manager who knows (and has learnt) how to have these meaningful conversations.

You’re evaluated against attributes defined by Ubisoft HR. They include your job competencies, how well you achieved your objectives, your leadership and your collaboration skills. I don’t think it matters whether these are the best attributes, but what’s important is that they look at your individual performance from different angles. 

This is what happens in practice:

1. Line report or manager seeks feedback from closest colleagues
2. The manager sets a mark against each attribute
3. The HR Business Partner meets with the manager to discuss each of the marks and act as calibrator to challenge your marks (and in practice they don’t consistently challenge downwards, as you may cynically assume)
4. Ahead of performance review, both the line report and manager add comments against each attribute in our performance tool – these comments are only shared the day of the review. The manager’s comments will include the mark as well as quotes from colleagues’ feedback.
5. During the review, both discuss what they have written, talking strengths and opportunities for growth.

(There is also an element of performance-based salary, but I’ve left that out, as it wasn’t what made the process so different.)

Why was it better this time?

I tried to figure out what made the process so much better, and I have boiled it down to the following factors (which are somewhat difficult to emulate at an individual level, and mainly come under the organisational processes):

1. Individual performance and competencies are evaluated, not objectives. This allows a tailored conversation on skills and self-discovery, not one focused on external factors versus personal input.
2. The organisation trains their managers:
   1. There’s a 5-day management training for all new managers 
   2. Prior to the review, lots of drop in sessions with HR are available
3. The manager is forced to spend considerable time to reflect on their line reports’ performance
   1. They have to justify each mark to the HR Business Partner who will ask probing questions
   2. They have to add comments against each attribute into the internal tool
4. The line report also has to reflect on each attribute (and can’t just show up) because they too have to add their comments in the tool

Nothing I have written here is particularly revolutionary. Yet, this well-executed performance process made a real difference to me.

It helps me be a better manager

I directly manage 6 product managers and I now feel much more confident about having the performance conversation with them. In retrospect, I cringe at performance reviews I have held in the past. I’m grateful for having experienced this process, which will change how I do them from now on.

In preparation for my team’s performance reviews I’m also reading Petra Wille’s Strong Product People, which is about managing and helping Product Managers grow. I’m only halfway through but I’ve already drawn lots of useful things from thinking about my team’s development.

I wrote this reflection a while ago, but as this week has been intense and my thoughts are all over the place, I thought I’d share this.

…

It’s a drab drizzly day in January. I’m queuing at the post office. Courtesy of covid-19, we’re of course queuing outside. There’s also a queue system inside: There are 4 queues, one for the bank, one for the post office, one for the ATM, one of the post office self-service tills. The queues with people (post office and bank) are very slow. The two with machines have no-one. Yet, the member of staff guarding the door insists on us queuing in one queue outside. 

I need the self-service tills, several people in the queue simply want to go to the ATM. We’re fuming. There’s no reason for us to queue in the cold. Some give up, whispering insults under the breath. My heart is racing, I’m pissed off. This is my lunch break, I’m wasting my time. 

Then I remembered a thing my high-school French lit teacher said:

‘There’s 2 types of people in life. There’s the person walking home in a snowstorm at night, gripping tight onto their collar, swearing and cursing, eager to get home. Then there’s the other person, who’s going through the same snowstorm yet whistling their favourite song.’

I often think about that, even if I feel Monsieur Tenret probably forgot he said this in one of his many tangents. Too often, I am the first person he described. Frustrated with the world around me when things don’t go my way.

It’s especially bad since I’ve been working as a product manager, because I made it my career to make things easier and better for users. And I know how they could fix this bug or that workflow on a website. It got so bad, my husband sat me down one day and asked me to stop complaining when a website or app was terrible. 

Similarly, since working at the UK Government Digital Service, I have much higher expectations for public services, and a much lower tolerance for absurd bureaucracy, because I know they can do better.

But here I was at the post office, suffering another pain sprung out of someone’s process they had devised. But I thought about M Tenret’s point, and I needed to let go. Yes it sucked, and yes they could do better. But right now they didn’t, and I could just stand here, breathe, maybe listen to some music,or a podcast, and have a good time. Then I really won’t be wasting my lunch break.

This week I have been thinking about product communities. In my last organisation, there was a fairly active product community, both at cross-government level and within the organisation. However, in my new job, there is no such community, as our product team of 7 is integrated in the ‘business’ and fairly isolated from other PMs.

For the last few weeks, my colleague who supports communities of practice across the company has teamed up with me to find those other product managers. Because our main business is video games, and product management is in a supporting role, product people don’t sit in the same departments (nor countries) and therefore don’t know each other. The organisation also grew organically so it’s even hard to look for people by job title. For example, we have already discovered that ‘IT project management’ could mean you could be a product or a project person. There is also a role called ‘product specialist’ that we aren’t yet sure about.

Yet, we have started finding pockets through reaching out to people recommended to us and their subsequent recommendations. We’re curious as to whether there is an interest in a company-wide product community.

What struck me was a conversation my colleague had after she found a small community of product managers, all from the same department. They had a structure and sharing practices in place, so this seemed to be a good find. Yet what a person told my colleague was that they are happy with their community how it is, and don’t think that other people in the organisation would have the same challenges so wasn’t quite interested in a company-wide community. 

I was very surprised when she told me that. I automatically assumed that product communities are great! So why didn’t that person realise that? As I didn’t speak to the person, I can only make assumptions as to what created such doubts – maybe a fear for how much work it would be, maybe a lack of confidence in the quality of product management in other parts of the business? Most importantly, maybe what wasn’t obvious to the person is that we need communities – plural.

Therefore I thought about the different communities that form my product network.

1. PMs who work on the same product or domain in your organisation

That’s simple, that’s the product managers I work next to. We’re a team of 8 and we meet twice a week to share what is going on with our products, so that we can manage dependencies and identify opportunities for collaboration. We also do learning activities every month. For that we watch a talk/ read a book chapter/blogposts and discuss them. We also have monthly sessions to inspect our product practice (I wrote about this here: Setting up a product practice).

While this group will understand your problem space well, they will also have the same assumptions as you, and won’t challenge you in the same way someone external might. What I’ve also found is that sometimes it’s difficult to focus on the product craft, and dissociate it from team challenges we experience.

2. Organisation-wide product community

That doesn’t currently exist for me, but from previous experience, it’s a coming together of product managers every month or every 2 months where different people may present what they’re working on, a specific method they’re trialing or hearing from people in other disciplines (UX, accessibility, tech…). Of course this only makes sense when the organisation is of a certain size.

This community is better for talking about the product craft dissociated from specific team issues, but still within the context of your organisation. While our products may vary vastly in terms of what problems they solve, we can see how they complete a bigger picture. We can also identify opportunities for collaboration and to reduce duplication of work. Plus, sometimes you want to talk candidly about organisational challenges and that tends to be easier within the company.

This type of community will make us all better product people, and a company should really invest some resources in helping to organise it, as without a structure, such as a community lead or a committee, this will very quickly fall apart.

3. Product communities outside of the company

I’m typically thinking of the networks that exist on Meetup, such as local chapters of Product Tank or Women in Product, and other such networks. They are a brilliant resource because they bring together a large diversity of voices, allowing you to learn about new practices, reassure yourself that everyone has the same problems and learn about how other organisations do product.

These often rely on the goodwill and enthusiasm of a few people, but those that persist over time tend to have really good content.

4. Personal network of PMs

This is less a community in the strict sense, but more my personal network of people I regularly catch up with to talk product things. They are all people I worked with at some point. I tend to meet them one-to-one on a monthly basis. These conversations help us both reflect on our practice, and offer suggestions and ideas to the other person. In this community is the product circle my PM friend Tobi wrote about as well as people I mentor and support in their journey across the product management jungle gym (we know it’s no longer a career ladder).

Why it’s important

All these communities bring complementary benefits, and any product manager not taking advantage of these networks is missing a trick in growing themselves and their practice.

Having more than one community also creates resilience and allows you to be flexible when you’re moving countries/cities or say – the world is going through a pandemic. While going to product events was part of my routine when I was living in London, in the last year I’ve been much more engaged with my personal circle and the immediate PMs I work with. While industry events will still help you gain knowledge, there is a gap of personal connection, which I now get from my smaller networks.

In the meantime, I will also see what I can do about a company-wide community. Even if it starts small, I hope it’ll be a fun project over the next year to try and spark a product conversation.

As product people one of our roles is to ensure people external to our team know what is going on and where we’re heading. That is simple enough as a principle, yet in practice, this is hard.

The situation

This week, I’ve trialed an email to share updates across all our products to send to the whole department.

We know people have been asking for more information as to what has been delivered and what’s coming. They told us so in person but also in a survey we conducted. But the question I was struggling with was – how do we know we’re providing the right amount of information?

People are likely to speak up when they have too little information. Maybe not immediately, maybe not obviously. But what struck me is that people never (rarely?) complain about there being too much information. That is also a problem, because too much information makes it harder and sometimes impossible to get to the information that is needed.

For me there’s two imperfect but complementary strategies:

• Understanding our stakeholders, their role and the pressures they face
• Trial and error, and getting feedback

Understanding our stakeholders

If we invest time in understanding the people who need information from us, we’ll be able to adapt our communication. Spending time with them, shadowing them, seeing client meetings first hand can help us understand what type of information they may need. And we should definitely do this. 

However, this strategy isn’t perfect: 

1 – This takes time, and when we’re new (and product people do tend to move products if not jobs fairly regularly), we can’t wait to fully understand all our stakeholders, before we need to share information. Getting them to trust us and for us to understand their world will take time.

2- Things change and we can’t predict all the changes that will occur. That could be new clients, industry changes, a new tool. We have to try to keep up with them, but doing so in real time is often impossible. So we’ll always have to combine that with the trial and error approach.

Trial and error

Trying something out and getting feedback complements the first strategy. We can make some informed guesses about what would be useful and seek feedback. However, I have often heard people say ‘we stopped sending out that information because we didn’t know whether it was helping anyone’. 

For this approach to work, we have to be proactive and persistent. We have to spend at least the same amount of time trying to elicit feedback, than we spend writing the information. 

If there’s too little information, people might ask follow-up questions. While stakeholders will not be able to tell us that they need to know about something they don’t know exists, they might tell us that they needed certain information earlier. So we’ll get feedback, even if it’s a bit later.

However, I’ve never heard anyone say : “there’s too much stuff in your update that I don’t bother reading any of it”. Even though I hear people say it about other people’s updates and presentations ALL the time. 

And I know I’m guilty of the same. How often do you admit to someone that you don’t read any of their updates or emails because they’re too long, too confusing? Yep. Somewhere between not wanting to offend, and not wanting to look like we’re not doing our job properly, we’ll never say that. We also might assume that maybe it’s just us that don’t find it useful, so we don’t want to be the person to complain about a format that must work for everyone else.

What we can do to prevent this as the people providing the information:

• in doubt, keep it shorter and only add more if requested
• provide easy opportunities to access further detail
• most important: spend time learning to write clearly and format well (or ask someone who can help us with that)

Finally we need to also accept that our communication is never going to be perfect, and therefore we can only strive to making it good enough.

In conclusion

I hope this week’s reflection is interesting for some. I worry a lot about striking the right balance, not wanting to overthink things to prevent me from moving fast enough, while also not wanting to storm ahead and having to deal with the consequences of implementing a half-baked idea. So with the release notes, I went with my experience with what had worked before, plus what I’ve understood our stakeholders need, even if the information wasn’t perfect. Let’s see what the feedback will be!

Ok, that’s it, I’ll try it out! For several years I’ve been seeing colleagues and people on Twitter write weeknotes, and I’ve finally reached a point at which I feel like I should do it and I have sufficient motivation and courage to do it.

Something happened this week, which brought it home to me how journaling can help you.

Last Thursday evening, I was in a good mood and I couldn’t understand why. My week had been pretty standard, nothing special to see here. To give you some context, I generally finish work feeling mentally exhausted. I can’t even read a book about work, an article or even podcast in the evening. I find them just too triggering. (working from home clearly isn’t the panacea).

But not on Thursday. I went back to my laptop and read stuff about digital employee experiences.

What was going on? I couldn’t explain it, but I enjoyed it.

On Friday, I was too intrigued. I needed to understand what had created that positive feeling, and how I could make it happen again! So I wrote down what had happened that afternoon (I boiled my feelings down to the events of the afternoon, as I had a quasi-breakdown over Jira in the morning. There were tears. I think we’ve all been there).

In the afternoon, I had 6 meetings, all back-to-back with different sets of people. I don’t want to go into details about the meetings ( as it’s probably quite boring for you, and the not-so-boring bits are probably the ones I can’t write about publicly). Overall, I met with

• a team we previously had a strong disagreement with
• the product team to discuss a feature improvement
• another team and the leads to discuss the collaboration with a supplier
• a team with whom collaboration has been tense in the past
• our design lead

While I expected some of those meetings to be quite easy (my one-to-one and the product team chat), that wasn’t the case for all of them as you might imagine.

So what was it about the meetings that had made me feel so energised?

I could rule a couple of things out: It wasn’t about the specific people, as I saw a few people twice during the afternoon but always in a different configuration. No meeting resembled another one. I also hadn’t done anything special at lunch time, or had got particularly good news.

Once I had written down in more detail what the meetings were about, I could finally see what the common factor was: the level of trust was high. By that I don’t simply mean for me personally, but in general for the whole room. It’s rather difficult to describe and you might think this is quite subjective. I understand. However, I also noticed the absence of markers that have been quite common in our meetings:

• people stay quiet and later tell you they’ve been annoyed by something that was said in a meeting
• Tumbleweed moment when walking through a plan (nobody has anything to add, or just one person says that the plan sound good)
• People taking a sharp or accusatory tone
• Rehashing of things that had gone wrong in the past
• Blaming something we can’t change for our problems

None of these happened, but what did happen was that people:

• cracked jokes
• shared how they felt
• challenged what others were saying with empathy
• asked thought-through questions
• took responsibility over things that happened
• recognised that others did the best they could

This day was different.

I think what amazed me is how much this change affected me personally. Clearly the lack of trust and psychological safety in some of our meetings and collaborations has really been wearing me down. Despite most of my interactions with my colleagues being actually really positive, the few meetings that are more difficult (and some weeks there have been more than a few) clearly really affect me.

I don’t know whether that’s particularly the case for me. I suspect that most people will have somewhat similar reactions to me, though maybe stronger, maybe much more fleeting.

Next week, I’ll start tracking where I feel high or low levels of trust. I hope that’ll give me some indication as to where we can make things better.

Also, it was really clear that it is much easier and faster to get things done when we do trust each other and can challenge each other with empathy.

When trust isn’t there, I’m not sure why we bother trying to get things done. We should figure out how to work together first, even if it’s hard. If we don’t do it, the value we’ll be able to deliver will be negligible compared to the effort it’ll take to get something done, and the emotional strain of disagreements further down the line.