How we work: Forming and running our cross-functional working culture

This article sets out to explain how we went about forming cross-functional work teams at Unmade, and how we run and maintain this way of working now. It incorporates a lot of the things we have learnt from working this way over the last 18 months including insights from retrospectives along the way that have led us to iterate on our approach.

What is cross-functional working?

We use the term ‘cross-functional’ to mean a working group where team members from different disciplines at Unmade join forces to deliver a customer implementation project, a new product development initiative, or another common goal.

In other words:

• It is when a group of individuals with different skill sets come together to achieve a shared goal.
• It is made up of people from all levels and areas of our company — not just product and engineering. If their skills are relevant to achieve the goal, anyone can and does contribute as part of a team.

Why do we work like this?

It’s kind of like building our own Avengers-style task force!

Over the last year or more of working this way, we have seen proof that:

“By working in cross-functional teams, having a singular focus towards a clear objective, and by empowering people to take ownership and make decisions, we can deliver better outcomes, faster.”

Working this way brings value to us as a company and as individuals in a number of ways.

Alignment to our company values
Cross-discipline collaboration leads to increased empathy, communication and innovation — and it’s fun! Everyone has good ideas and working this way better harnesses that potential as everyone can input to everything — we’re literally all at the same table.

Driving our own decisions makes us faster
By creating dedicated cross-functional teams with a clear goal, it allows the team to have ownership of how to achieve the goal, rather than this being decided by customers or other stakeholders. Empowerment to make decisions ‘in the room’ to reach this goal minimises the time a team will need to meet with or wait for another team or external stakeholder, so we can achieve more.

Customer and business value
We can and should drive our customers towards the highest value decisions. By working holistically and collaboratively we can bring greater value to our customers quicker through real working outcomes— for which they will obviously start paying us revenues sooner!

Supporting a full supply chain
Because our on-demand supply chain technology is ‘end to end’, we need many disciplines working together across manufacturing, physical and digital to solve problems and reach the best outcome. A cross functional team who all start and finish at the same time means we have all the skills to deliver every aspect.

Managing change
Being a startup and having many external factors and dependencies to work through when we deliver a new initiative, we need a way of working that can cope with blockers, uncertainty, and changing course. Cross-functional teams mean we can communicate frictionlessly, adapt to new information and make sure all aspects of the initiatives are considered when decisions are made.

To summarise, cross-functional working is well suited to agile working practices where co-designed solutions trump chains of hand-offs; motivated individuals with shared goals beats ‘the business’ calling the shots from afar; and delivery of end-to-end value is our primary measure of progress.

Why did we start working this way?

A hand-off, last year

Previously we largely worked in a more waterfall style with far more segmentation and ‘hand-off’ between disciplines. There were occasions where this way of working had less positive team and customer impact.

Here are two example occasions as context for why we decided to try a change in approach:

1. Because manufacturing development timelines are long and a customer was keen to start, we tried to ‘get ahead’ on a new garment development in advance of the product and engineering teams, who were still working on a previous project. When it came to build the UI and technical integration we realised that the manufacturing output that had been developed with the customer was not compatible with our system and would require a lot of updates to our product to support. This led to a stressful period for the team to deliver a compromised outcome in a short deadline-driven time span, and a temporary loss of customer trust that had to be won back.
2. We presented UI mockups for a new customer project in advance of a delivery team forming and without getting input from engineering on the features shown in the mockups. These were approved by the customer about six months before the build work started. By the time the team was formed, we realised there were several new capabilities in the mockups, and we felt committed to decisions made in the past which might not actually have been the best way to design and build the UI. This again led to tight delivery timeframes and a need to re-present options to the customer, increasing time on feedback loops and meaning we took on a much larger scope to make the project a success.

Our design, product and engineering teams initially trialled working in a more agile and cross-functional way in early 2018 to deliver a large R&D initiative, and after some success realised we needed to expand this method to the whole company so we could use the full force of Unmade’s collective knowledge and experience.

We expanded the approach beyond product and engineering to form the first true cross-functional team while working on a customer pilot in late 2018. This team found lots of benefits from working in this way, which were presented back to the company and provided a route for buy-in to continuing this approach.

We continued to iterate on this way of working throughout 2019 for new product development and project delivery initiatives, running regular team retrospectives and whole-team quarterly wash-ups to make sure we were moving in the right direction.

Team practices and processes

Team mission stickers

We try to maintain a good balance between standardised processes, tools and rituals that each team uses to create scalable ways of working which build on things we’ve learned along the way, while not enforcing too rigid a process which does not leave room for agility and improvement.

Here are some of the things we have learned so far that have worked well and we tend to reuse for most new initiatives.

Starting

We begin each new initiative with an all-hands kick-off. Depending on the project scale, these can be one session or several over the course of a week or two so it’s important to schedule in this time to get everyone up to speed. We’ve seen that an effective kick-off usually includes:

• Context sharing: Depending on the nature of the initiative this might be customer context, some data or insight that points to a target problem to solve, or an outline of the company priority we are aiming to work on.
• Milestones: We share clear dates, deadlines and external dependencies and check upcoming team member calendars and holidays.
• Team: Introduce everyone and run an icebreaker exercise (examples: 1, 2). This is really valuable even if you’ve worked together before! Teams also all sit together at the same desks, so we move seats if necessary.
• Roles and responsibilities: Explicitly decide who in the team is responsible for key tasks, communication or outcomes.
• Questions: Make space for questions and discussion. Surface risks and unknowns. It’s much better to over- rather than under-communicate.
• Goal: Define a clear, specific and tangible mission goal for the initiative.
• Name: We give our team a name to unite us and tell other people what we’re doing. These can be straightforward or somewhat silly: previous team names have included Slayer, KISS, The WI, and NASA.

During

We organise ourselves in a regular cadence of planning, standups, iterations and retrospectives. Here are some of the rituals we follow and, more importantly, the purpose we want them to fulfil:

Iterations
Purpose: A cadence to encourage continuous delivery of value via working software (or other output) that can be demonstrated or used and gets us towards our goal.

• Teams usually break down their time into weekly or two-weekly cycles called iterations (sometimes called ‘sprints’ but we prefer iteration).
• Some teams choose to have a ‘break’ for planning and reflecting, so run an iteration from Wednesdays to the following Friday, with alternate Mondays-Tuesdays outside of the iteration cycle.

Planning
Purpose: Make sure the team is clear on the goal, that the work to do is clear and prioritised, and any new information or context is communicated.

• A planning meeting is held at the start of each iteration. The team typically reviews outstanding/at-play work (we use Trello to track goals and tasks), organises the backlog for the next iteration, and checks on progress against the overall initiative goal.

Standups
Purpose: Align on the latest information and status of work and surface any blockers, via a short, efficient daily meeting.

• A daily standup is usually held in the morning. The team meets to review their Trello board and share any other new context or information, so that the whole team is informed on progress or updates.
• A facilitator is nominated to run the standup; this person usually rotates weekly. It is the facilitator’s job to gather people on time, load up Trello on a screen, dial in any remote people, and keep things on topic.The structure is generally to ‘walk the board’ to discuss Done and Doing work.
• Standups should be as short and focused as possible. If a discussion is getting too detailed and/or doesn’t require the whole team, it should be moved to a separate conversation.

Retrospectives
Purpose: Learn about things that are working well and less well within the team and identify actions to address areas for improvement.

• A team usually holds a retrospective every two weeks, at the end of each iteration.
• A retrospective has a facilitator, who should ideally be an external person so all team members can participate. They will pick the format, keep things to time and ensure everyone gets a chance to speak. They will usually reiterate the prime directive of retrospectives at the start.
• A common format is to write post-it notes around three areas like continue/stop/change or good/bad/questions and discuss the key themes that emerge. Actions may be decided on but it’s not necessary to leave with actions.
• The facilitator writes up notes and actions for future reference and shares with the team.

Demos
Purpose: Show the company the progress that has been made in a team, to create wider visibility and a sense of achievement for the team.

• We have a whole-company meeting every Friday where any team can decide to show their progress in a short demo. Progress to show might be a working thing, talking about an insight or learning, or anything else that has happened over the course of the week.
• For something more in-depth, anyone can book a slot for our regular Tuesday all-hands team talk.

Finishing

We have learned that there is a ‘pain’ to starting, stopping and re-shaping cross-functional teams. So we now run much longer-lived teams who are responsible for a broader range of outcomes over a quarter-year or more, as opposed to the 6–8 week focus on a single project approach that we started with.

But when teams do change up or we decide to wind down an initiative, here are some things we do:

• Explicit time should be factored in for the winding-down period. Generally in the last iteration of an initiative, new work should not be started, so the focus can be about drawing at-play work to completion.
• Make sure that any changes or improvements are communicated to those who will use the software so that this knowledge is not lost when the team moves on. e.g. training Customer Success on a new tool, providing metrics for the business development team, or producing a technical summary for the next engineer who visits the codebase.
• We often hold a whole-initiative retrospective or wash-up to analyse the bigger picture and assess what went particularly well or less well from a process and mission-achievement point of view. Based on that, we might update the company on what we learned so others can benefit from it too.

Documenting and sharing this working process

We have written a lightweight guide to these processes and some background to our working style which is aimed at new starters to the team or anyone else who wants a refresher — it actually formed the backbone of this article. This helps new team members get up to speed on how we work quicker, especially those who do not come from an agile software development background and might find it unexpected that they are encouraged to speak up and make decisions at a pace that might feel jarring. (Our agile study group helps with this, too.) This guide is editable by anyone in the team and questions, suggestions and deviations are encouraged.

What we have learnt?

To wrap up, here are some of our top learnings from making this change and running and adapting it over the last 12–18 months.

Keep the process lightweight and agile
While it’s been important to create some discipline around our shared rituals to provide structure and transparency, we’ve optimised for ‘just enough’ process with room for teams to make autonomous decisions to change things. It’s really important that everyone knows that nothing is dogma and our ways of working can and should adapt. We have seen our way of working evolve (and improve) to the point that the guide we wrote six months ago really needs a substantial re-edit already. We must all continually assess that we are putting meaningful outcomes before ‘process for the sake of it’.

Regular retros and washups are crucial
Scheduled time for reflection provides a dedicated forum for feedback and discussion on if current ways of working are really effective, as well as building trust and empathy across the people within the team. We have made a lot of changes based on conversations during team retros, and whole-team quarterly washups are a good opportunity to share successes, difficulties and learnings with those outside and across teams.

Don’t isolate or exclude any discipline
In our first attempt at cross-functional teams we neglected to look much beyond product and engineering and this led to people outside of these disciplines feeling isolated and unable to contribute. Our teams are now a truer representation of more disciplines in the company, however they are still pretty software-development-driven, so in the future we may look to create teams to work on more varied initiatives such as R&D projects, sales & marketing initiatives or team culture improvements. (I liked this article on how these ‘working groups’ are formed at Etsy.)

Trust and communication are key
There needs to be a layer of communication into and out of self-organised teams to build transparency on what is going on, share what the team needs help with, and understand decisions the team has made that will impact others. We have all had to make time and effort to communicate with people in other teams so we are still aligned on both our discipline and the overall company mission as well as our team’s: for example engineers spend time on cross-team code reviews to keep up to speed, and product managers meet regularly to check we are setting cohesive context and goals. We are still learning how best to regularly and clearly communicate teams’ progress and show how this contributes to company goals — this will be a focus for this year.

Finally, while a lot has been written about the challenges of starting to work in autonomous teams due to management nervousness about devolving control away, I’m pleased to say that hasn’t been an issue at all at Unmade and the level of trust placed in the teams has been paid back with reciprocal trust, high motivation, and some really transformative and exciting work getting shipped much more effectively than before.

With thanks to our COO Simon for co-writing our original guide.