A couple of weeks back a few of us from Atlassian paid a visit to the lofty colourful environs of The Difference, a wholly-owned division of PWC. The aim was to share ideas and tactics about how to be creative at scale. Or at least that’s where we kind of started.
The Difference are like a creative agency within a big corporate (PWC). But rather than take a brief on a pre-defined thing, then present concepts, and then work an approved concept through to completion, they involve their clients at every step along the way. And this doesn’t just mean lots of feedback meetings; they help form the very team of stakeholders from a client that are going to be involved with a project, and together work on the problem to be solved first, before even talking about what thing it’s going to be that will solve that problem.
It’s design thinking all the way. It’s highly collaborative, exploratory and creative. It’s focused on bringing out the latent ideas in the team, helping them to see those ideas take shape, and communicate those ideas to their broader organisation.
Design at Atlassian works in a similar way. We too, want to start with the problem, ensure we’re focusing on the right problem at the right time, and work as a team to – as The Difference put – unlock ‘group genius’ and reduce the time it takes to explore a problem space, gain insight and ship inspiring stuff.
So first up, the workspace at The Difference is fantastic. Everything is purpose built to reflect their philosophy and the way they engage with clients. Visually, it’s invigorating and lively: pieces of creative client work share space on colourful shelves with a giant soft snake toy and this LEGO model of the Opera House. Desks are arranged in pods in an airy open plan space, with huge curved whiteboard walls on wheels.
Their space and the way they work (using loads of creative workshops and so on) brought back great memories of the way I used to work with clients at Digital Eskimo, so I was like the proverbial kid in a candy shop.
Comparing sausage factories
And so to business. We started off just comparing notes about how we work, ways of working in teams that we like, and what we avoid. We talked about how we want to ensure every team has the confidence that they’re shipping the right things in the right way. We described the way we let teams ship in the ways that work for them, but staying accountable to 8 key areas that are the same for any project going on in the business. We talked about issues of scale: how do we keep this spirit of empowering teams to do things their way, yet not become fragmented?
Lawrence Goldstone and his team talked about how they help create safe constructive spaces for their clients to form, storm, and ultimately come up with unifying problem statements, stories and visions. What comes next is not only a workable solution, but ways to communicate and roll out that solution. So much of what they do seems to be about sparking and carrying out change, rather than a ‘traditional’ consultant ‘imagineer, veneer then disappear‘ approach. They bring clients to realisations like “We cannot solve our problems with the same thinking we used when we created them” by getting them to do workshop activities where they experience these lessons for themselves.
The Difference also implant their tools and processes into their clients’ teams and spaces as well, as ‘hubs’ for others to use. Actually getting this up and running is written into their project plans, rather than it being an afterthought.
An a-HA moment: don’t skip the intent and insight
And here’s where I got a big insight out of our conversation. At a high level, what we (Atlassian) tend to do is envision it (i.e. (re)define the problem, research, conceive and prototype solutions, come up with a vision) and then head into make it (design, build and release) … BUT see the arrow Lawrence has drawn from VISION to DESIGN (ENGINEER) in the photo below? Sometimes we can skim over how we can absorb insights we already have from research and intuition into the idea we want to push ahead with. Maybe we need to spend time and effort on the intent and insight of the thing we’re envisioning. Or:
- What’s the positive impact of this to customers’ teams and work?
- What’s the positive impact of this to our business goals?
- Is this idea the only/best way to achieve the outcome we want to achieve?
- Will this improve our own dynamics and processes internally, or cause hassle and grief?
- Is that a necessary short-term thing? Where are we willing to trade off our own pain or customer pain?
Metrics and so on at the beginning help us answer questions like “How will we know this is successful?” but things aren’t always that binary. I wonder, do we need to spend time exploring what it would mean for customers beyond making a certain feature more efficient?
Example: improving speed/performance of Cloud instances of our products is good. Yes. But what else would that mean for customers? Will more speed mean more engagement? How?
How do we deal with change? How do our customers deal with change?
At the root of this is the way we deal with change. We tend to approach problems (and therefore change) from 3 perspectives: rational, emotional and political. This pattern comes in very handy for change management and selling a vision to others, and it got me thinking about how it applies internally as think about – and solve – product-related problems. From a design/build perspective, our natural habitat is the rational: what needle are we trying to move… map it out… solve a pain point… improve performance… ship. Bam. But I wonder what further insight we would gain if we sat in the emotional and political perspectives for a while. Take the customer view, for example:
- Emotional - What does [this product change] mean for me, and my responsibilities? Can I still trust this?
- Political - Who will win out of [this product change]? Who will lose, or be set back in some way? Will those relying on me still trust me?
I wonder if we have some more crucial conversations about these perspectives earlier on, if it would save some hassles down the road to implementation. How do we trigger that, and help that? I think telling stories about how [this product change] works in customers’ contexts, and visualising with storyboards and mocks is a great start. And I’m sure The Difference has some other ideas on that too.
We talked about how communication and shared understanding can get tricky as organisations scale. Mat described a multiple ‘hub-and-spoke’ model that we often use internally, drawing out his model on the table. The thinking is that we scale by clustering small teams together around core groups. Each team needs specific key roles, and communication needs to happen where groups overlap or intersect.
This triggered a conversation about ‘Patchwork Theory’, which as Alex (from The Difference) was describing, is similar to what we have come up with. We (teams) operate in patches, and within each patch are nodes (that’s you), much like bacteria thingies sprout and spread in a petri dish. Some nodes can transmit with more connection points than others.
Seeing teams in this way can help us to understand what is an optimum level of collaboration, involvement, decision-making, information broadcasting… and where things start to break down. What’s important is that good information is not only broadcast and received well, but retained and used well. This kind of ‘patch’/small team set-up also only works super-well when given autonomy. Because of this autonomy, it’s really important that each patch works on its own health.
Bottom line? Loads of small teams (patches), where nodes have the freedom to make and maintain connections with several other nodes and patches for each others’ mutual benefit. What this looks like in practice are these 3 neat lines which I really like:
SHIP WHAT YOU LEARN
USE WHAT YOU GET
OPTIMISE THE PATCH
There’s more to this patchwork theory and team dynamics, which we plan on unpacking next time we get together…