How do we effectively work together towards the same shared goal?
That was the connecting question of various meetings and interactive sessions this week.
Discussing and improving how we collaborate
On Tuesday, we met with all disciplines – remotely and in-person – design, engineering, product and transformation management to discuss collaboration.
Magdalena and I started with a framing intro and some input. I reminded colleagues of the Manifesto for Agile Software Development and some of the principles behind it:
Business people and developers must work
together daily throughout the project.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”
I also talked about the team as the unit of delivery, a GDS mantra instigated by Jamie Arnold and illustrated by Paul Downey. I made a reference to accounting class and units-of-delivery thinking and why we must not look at units of delivery as a percentage of units of goods described in a contract. Instead, the mantra helps shift the attention to the team and to outcomes over outputs it helps achieve.
While preparing the section, I looked into a Harward Business Review text on ‘Eight Ways to Build Collaborative Teams’. Among other things, it brings up 4 collaboration conundrums – traits that are crucial to teams but also undermine them: large size, virtual participation, diversity, and high education levels.
I mentioned those, but we didn’t spend time discussing them. Rather, we had 11 small interdisciplinary groups talk about two questions:
- What are your biggest collaboration challenges right now?
- Which challenges have you successfully tackled in your team?
In every group, people not usually working with each other and from different disciplines got to exchange their experiences for some 20 minutes. Afterwards, the groups played back. Some common findings included: articulating clearer roles and responsibilities, establishing a single source of truth, giving teams time to build trust, splitting teams into sub-teams when that is more effective and pairing on tasks where possible.
Later in the week, I discussed collaboration among designers in teams and with other disciplines in the team, how it works well and how it does not. Considering all the things designers do – like questioning the scope, zooming far out and close in, and occasionally stepping on toes – that can be a bit tricky at times. But it needs to be productive and move the team forward. The role of a curious, investigative and principled designer can be challenging, and they might be perceived as disrupting the work in the sprint. Giving them the space but also understanding why they do something will be fundamental for team members. There is, indeed, a lot more to say about this. But it needs a proper in-depth text for that, not a weeknote.
On Friday afternoon, we discussed working together once more: this time in the context of core teams – people and talent management, project management office, communications, legal – and project leads plus heads of disciplines. With a still-growing organisation, we found that various processes became too opaque for our size and structure, and we need to formalise and track activities better. With more people and specialised roles, everyone must clearly understand what others do. More work will follow, but we have looked at some good structural proposals.
Beyond my immediate work, one tweet by a person training German public servants in services design triggered me a little. They ran short training and declared them service designers ready to change the German public landscape. It reminded me of the posters I made for our 2016 Service Experience Camp. It said: “Just writing post-its doesn’t make you a service designer. Only designing services does.”
The service design training Clara and I used to deliver at GDS had a similar big caveat in the opening segment. “This training is not going to turn you into a service designer”, we clarified. Pumping people’s confidence with short training formats and encouraging them to try new approaches in their working environment can have some positive effects. And it can go awfully wrong.
People training with a little bit of UX design, getting a small piece of design thinking or receiving a service design potion can run overconfidently into situations that might damage their reputation or position in their organisation. Rapidly trained design thinking coaches experienced that in the last decade. So some organisations are now allergic to quick testing with users and iterating prototypes cause ‘design thinking didn’t work here’, and anything similar sits on scorched earth.
Public sector service design training in Germany won’t go away, but maybe I can help clarify what one can expect from a single unit of training. And what else it needs to change things systemically.
An online workshop on service design that Lou and I do for Apolitical should mention that. I was asked and thought it was a good idea. The hour-long session will take place in later April.
More than training or workshops are needed to help German government figure out its ever-growing multi-domain approach. This week saw yet another example.
Related, we had internal discussions about how to give updates on projects beyond blog posts. We need to set up product pages like GDS has and openly share feature overviews, roadmaps, and technical documents. But that should not happen on another .de top-level domain – even when getting a government subdomain is incredibly difficult and cumbersome. Unsurprisingly, other countries show that even these internal-facing services can be designed straightforwardly.
I hope very little as I have the coming 4-day week before Easter off.