Coaching teams at hipages

Background

• hipages launched its GetQuotes product back in 2013
• This new product drove considerable growth for the next five years with the company going from about twenty people to nearly 300 in two countries.
• When a new CTO (Chief Technology Officer) joined the company in 2019 he had ambitions to modernise how hipages built product
  

Problem

The start of the year 2019 was a turbulent time for hipages, we had a new Chief Technology Officer who had also taken the reins of the product team by becoming the new Chief Product Officer. Plus we were in the middle of transitioning from a mainly waterfall development philosophy into dual-track agile. Our new cross-functional teams didn’t really know how they should operate and we’d cleared each team’s backlogs so we were effectively starting from scratch.

In the previous five years hipages had expended a lot of energy in maintaining and improving its product but the majority of the changes implemented were not visible to our customers or were of little or no value to them. The net position was that from both sides of the marketplace, the product had stagnated and was in dire need of evolution. This situation was compounded by our competitors moving quicker than us and new competitors appearing regularly.

Our new chief product and technology officer, Herry wanted to overhaul both the product and engineering teams to help make our modus operandi more contemporary and more likely to lead to rapid product evolution.

As the acting leader of the design team I collaborated with Herry and leaders from product, engineering and data to help plan the transition and devise guidance structures that would help make the transition as smooth as possible.

Objectives

I set myself three objectives that I thought would help us transition smoothly:

1. Make sure my design teammates guildmates were set up for success with the new way of working
2. Help the triads become established
3. Help modernise and evolve how we build product

Approach

Preparing designers for working in a triad

My first task was to coach the designers on being a member of triad. Up to this point, although design had become an essential part of the product development process it was still subservient to product management. In the new cross-functional teams, designers were expected to stand together with their product manager and tech-lead and help decide the direction of the team. I was incredibly lucky to have an amazing team of designers but none of them had leadership experience so this was going to be a big step up for them. I needed them to gain an owner’s mindset for their piece of the product and quickly become extremely familiar with it then proactively suggest improvements.

We started by sharing lots of UX and design articles that talked about working in triads and we reviewed lots of material from organisations such as Atlassian (Atlassian are actually really great at sharing lots of great insights on how they work and how they structure their work) and Spotify who were already working in a similar way to how we wanted to work.

We then discussed our anxieties both in our 1:1s and also as a team and I validated these to help normalise them whilst stressing the positives of the situation. I asked a designer I knew who was already working in cross-functional teams to come in and spend some time with the team as I thought it would really help us to meet someone who was already working in the way we were planning to. Daniel, gave a really great introduction, shared both the advantages and the pitfalls and talked walked through his design successes. He explained how he worked with his PM and his tech-leads, he showed examples of documentation they had collaborated on and talked about the balance between triad thinking and normal team working. He really helped the team see that this was a change for the better and although it meant more would be asked of them, it effectively gave them the superpower of being able to help influence and decide what problems to solve rather than just working on how to solve them.

In another session we listed out as many new responsibilities as we could think of (for example helping to prioritise backlogs) and then spent some time exploring each and brainstorming some strategies we could employ effectively.

We also discussed how part of the magic of a triad was that all three members gave up a piece of their world but were granted two pieces of new worlds in return. We discussed working collaboratively and socially so the other triad members have opportunities to input and collaborate whilst also collaborating with them on their own areas of specialisation. This was a sticking point for some of my teammates as they didn’t yet understand the value of this sharing their world in order to strengthen and grow the bonds between the three triad members. They had no interest in the technical or business aspects of a project plus they were defensive about letting someone unqualified in design impose themselves upon the design process. I remember that being a surprisingly difficult session, especially as I thought we had quite a socially aware design practice that encouraged early collaboration with all team members not just designers. Following this session I had a number of one on one follow up sessions where I probed each designer’s concerns and employed different strategies for each teammate to help them come to terms with the changes. It was particularly hard trying to convince the more junior members of the team that sometimes to level up as a designer you need to actually do less design due to having to spend a lot of your energies planning, discussing and defining initiatives. 

When the transition started I maintained the individual coaching and design guild check ins to see what challenges each team member was facing and get feedback on how the various strategies we discussed were working. Then in our guild meetings I focused on the common issues and encouraged the team members to share their experiences, again to help normalise them. We revisited the strategies we had created and explored them to see if there were common answers that could help everyone. These sessions carried on for a number of weeks and we still discuss a lot of the same topics regularly in one to ones and team meetings. 

Establishing the triads

As we transitioned into our new cross-functional teams I also began to have check-ins with the newly formed triads to get a feel for how they were gelling, the ceremonies they were using, how they managed their backlogs and how they made decisions. I encouraged them to: 

• Hold regular meetings with just the triad members to agree priorities and make decisions then share the decisions with the wider team
• Build the relationship with their exec sponsors to gain trust and get more familiar with their goal
• With their exec sponsors agree the direction they're to go in and what constitutes success over a given period
• Think autonomously and plan their own backlogs based on the definition of success and then reframe their catch ups with their exec sponsors as playback sessions rather than sessions where the exec provides a wish list of features to build
  
• Experiment as much as possible in as quick and lean a way as possible
• Talk to customers as a often as possible to build out their discovery backlogs
• Do things like early value tests to help stop us building the wrong things

In these sessions I discovered the product managers were still very much running the show despite my work with the designers so I worked with each of the product managers on how to empower their fellow triad members. I also worked with the engineering managers to help support and grow our new tech-leads into leaders, again trying to imbue them with a sense of ownership for their part of the product.  

Modernising how we build product

When our new Chief Product and Technology office had joined hipages he had wanted to change how we engineer our products, moving away from a style that was waterfall in sprints into a more modern philosophy based around building complete slices of the product so that the outcome of each sprint was releasable. He also wanted to run more experiments and function like a modern product orientated company. 

I had previously written processes and frameworks and watched them gather dust on the shelf so I knew the process had to be flexible and lightweight, not linear and draconian. Such processes stifle creativity and afterall we were trying to empower the triads. Instead I designed a collection of activities that could be connected or run as single activities. They encompassed a lot of the activities recommended by Marty Cagan to help put some structure around the discovery phase that gave our teams some new tools for understanding our users.

Again, I worked with leaders from data, product and engineering to collectively design a process that people felt was simple enough and modular enough to adopt.

When we were happy, I ran a walkthrough and feedback session at an all hands meeting to get broad feedback. Finally after a couple of tweaks and documenting it, I ran a series of coaching sessions with each cross-functional team to understand which activities they were most interested in, get their feedback and talk through any anxieties they had.

I think the sessions really helped get people on the same page and start to build some alignment around the language we use, the activities and processes we document and our general approach. This in turn helped the teams outside of product, engineering and data better understand how the new teams worked as they all followed a common model with a common glossary.

Outcomes

We’re now eighteen months into working in cross-functional teams and things are going ok. The teams changed a few times early on till we found the right collection of focuses and of course some people have come and gone but we’re much further along the road than where we were in 2018. The designers are now much more ‘in’ the triad than they were previously and the triads are getting more mature with experience. They’re growing in confidence and becoming more autonomous which is great to see. 

We’re now starting a rewrite of the product development process and this time people seem more knowledgable and excited about updating it which is thrilling to see. We’re also able to address some of the gaps the original process had, like a lack of structure around opportunity sizing and experimenting within a release at scale process. 

We still have lots of problems to fix such as how we work with our senior leadership team and how we experiment in a leaner way but we’re definitely getting there.

Cover image by Xuan Nguyen on Unsplash
https://unsplash.com/photos/jAke8NofTtE 

Contact

Jules Munford
Phone: 0431 414322
Email: julian.munford@googlemail.com
Twitter: @julesmunford

© Julian Munford 2020