Design Thinking in the Team Thinking
“But, the actual improvement was not being made in that numbers or in the meeting methods. It’s in the structure that is tailor-made for the team from a set of a process involving design thinking.”
Every design team needs to have a clear way of working together,
— having a team system that is environmentally healthy, promotes collaborations, and supports individual growth. Yet, objectives are changing once every quarter, the working process is progressive and expanding, and team dynamics are evolving. So, working together means the ability to recognise, adapt, and plug away at challenges, but what other means to make it stay intact?
One thing that pulls different working factors into unity is the way the team thinks as a whole, or as we called it: the team thinking. You are right, it is the thinking process of a team, the organisation of the cerebrum of the amalgamating team complex, the way the brain of every eye, nose, mouth, and hand of a team works.
During 15+ years of experience in the design industry, both as a practitioner and as a leader, I often caught sight of those who underestimate (and undervalue) the importance of team thinking, only a few who seem to actually value this connection as leverage to their team power. Even when it is being acknowledged, the setup wouldn’t instantly respond to leverage without adjustment and improvement, and this is where design thinking comes into play.
But, to the other part of the world, putting design thinking into team thinking would probably trigger the design thinking right-wing extremists, as they would issue the misused of the term and probably point out to the danger of losing the literal meaning of design thinking.
But no, design thinking never gets old.
Why?
First, it’s only a framework, meaning that it was already there before the term was invented. Beyond the 1960s of Horst Rittle on the creative thinking of the designers, it was not our Homo sapiens ancestor who discovered problem-solving tool-use reasoning, it is in fact the Homo habilis who achieved the first cognitive evolution in using tools. Framework utilisation is known in a four-points approach: the 4E cognition approach — where mind, body, and environment have to be connected as it embodied, embedded, enactive, and extended.
Second, it does not exclusively belong to designers. Design thinking is not a function (which could deliver process and result) but it’s an approach (the construction of the process). So, it basically belongs to everyone who has problem-solving headaches, not just designers.
In Niagahoster, through its company value, we are encouraged to continuously self-evaluate and innovate.
Our product design team has more than 15 different specialists and three different fields, each with their own certain type of process, tools, career ladders and personal growth. Lucky for us, the hiring process has always been reassuring — kudos to our team in People Department, meaning that whoever joined our team they are already a strong individual with some skills. So, sharing visions and setting up objectives are relatively easy with smart people. However, to work with this amount of talent and bring them together for success is something laborious, it wasn’t as easy as copying some successful startup method. First, the team is not all about the tasks being burned in the product development sprint, there are tools and processes that need to be defined before everything could actually work. Second, we work with humans which would require empathy and understanding to make it function and operate properly. However, before everything can be started, it is important to deploy design thinking into the team thinking — where the team mindset are to be in cycles of improvements.
To get to know team members, we have one-on-one sessions which could be requested by any level of designers to talk to their subordinates, peers, or leaders. However, to get a common understanding of our own team, we set up a periodic event to facilitate the team to understand their peers. It’s a session where everyone joined the meeting and two to four team members became our meeting guests. Apart from that, we also tried to utilise team retrospectives and team health checks to get deeper and have something emotionally meaningful from everyone. Another ongoing project that also lined up with this is our DesignOps project to get a view of how everyone is working, their time, their setup, process, workflow, and more.
Since design thinking is non-linear, none should think it is restrictive to the methods, especially those popularly used in common design thinking workshops, and we actually use design thinking to invent and improve the methods being used.
As the discovery events were underway, we would simultaneously try to interpet them into insights, finding the meaning from every meeting documentation and conversation.
Collectively, we would turn insights into ideas. A few notable results and currently ongoing are the initiation of Virtual Cafe Interview, Design Operations, and internal and public events. These events are never meant to be completed, instead, we set our milestones periodically and try to improve each time. Among those improvements, one that is particularly vital to our team is the answer to the team dynamics: the team organisational system.
Product designers in Niagahoster had previously employed both centralised and decentralised team workflow. Without having a real structure definition, everything went well until the team expanded, large enough to make a sprint planning occurred for more than one hour and a half. As I was being onboarded through the team, we started to prototype time, schedule, participant compositions, and topic. We tried to employ a 7±2 setup, adapted the “Eins + Eins = Drei” ratio to leverage the outcomes, and implemented the 8–18–1800 proposition to balance the cognitive load and individual focus. At that instant, a team meeting of 15 that used to cost €336/year could be reduced to 88.4%.
But, the actual improvement was not being made in that numbers or in the meeting methods. It’s in the structure that is tailor-made for the team from a set of a process involving design thinking.
First, we defined the team according to its objectives, so the team could be aligned with the product development process. Secondly, we split it up into each of its disciplines so they could work in tune with their peers. Third, to define responsibilities, they are then arranged into five different functions. From these break-ups, we found out that we need to enforce two team organisational systems, which are centralised and decentralised. But, at the same time, we also need to resolve team size issues and reporting, which is why at the function team split (which is the endmost of our structural scale) functions are required to be led by a function lead to making sure continuous alignment between squads to work on feature sprints. That is where we ended up in a hybrid (centralised and decentralised) and matrix (multiple lines of command) organisational structure.
In the final form, we have three main factions of development objectives (discovery, design/planning, and development delivery), three different chapters (researchers, designers, and writers), and five different functions (research, experience design, interface design, experience writing, and technical writing).
Such a concept could only be obtained from thoroughly and continuously iterative improvements and has to come from discovery and experimentation by converting design thinking into the team thinking.
