Several years ago, while working as an Android developer, I built a prototype with multimedia features. The possibilities were exciting, the Product Owner was enthusiastic, and together we found a productive flow. Then a colleague pointed out the technical complexity we would be introducing into the product. He was right from a technical perspective. Even so, in that moment, it felt as though he was slowing us down.
I saw a working prototype, new possibilities, and enthusiastic reactions. My colleague saw risks to maintainability and stability. Both perspectives were valid. The difference lay not only in our technical assessments, but also in our preferred ways of working.
Two useful responses to the same task
I like to move work forward quickly and playfully. A visible first step helps me understand an idea and get others excited about it. My colleague preferred to analyze before getting started. He raised the questions early that would later determine stability and usability.
Within a team, either of these approaches can irritate the other. The person who moves quickly may experience the more analytical person as obstructive or overly cautious. The analytical person may experience the faster one as unstructured or too willing to take risks. A difference in approach can then easily turn into a judgment about the person.
Friction is not automatically a sign of poor collaboration. It can indicate that relevant perspectives are coming together.
Complementarity doesn't happen on its own
Differences do not automatically make a team better. As long as those involved notice only the disruption, their strengths remain directed against one another. The difference becomes a shared resource only when the team can identify the distinct contribution each person is making.
Concrete questions can help:
- Who creates momentum when a task is still unclear?
- Who identifies risks and blind spots early?
- At which stage do we need exploration, and when do we need safeguards?
- How can critical feedback be expressed without unnecessarily shutting down the process?
- How can enthusiasm have room without ignoring legitimate risks?
The aim is not to create fixed types by permanently labeling people as “creative” or “precise.” People behave differently depending on the task, their role, and the situation. What matters is understanding recurring preferences as contributions to the work, rather than judging them as personality traits.
Sequence can make the difference
Different perspectives do not always have to compete for priority at the same time. A team can consciously decide when each way of working should have space. During an early exploration phase, ideas can first be allowed to grow. At a clearly defined point, they are reviewed critically. The team then decides what to pursue, change, or discard.
This protects both sides: playful exploration is not interrupted the moment each new thought emerges. At the same time, analysis is not postponed until so much has already been invested that the idea can no longer be assessed objectively.
Leadership translates between different ways of working
In situations like these, leadership does not have to decide which style is the correct one. It is more helpful to make the function behind the behavior visible. What is this person trying to protect for the team or the product—speed, learning, quality, safety, or reliability?
Looking back, my colleague’s critical intervention was valuable both for the product and for my own learning. Our users benefited because the team explored possibilities while also examining them carefully. His comment was uncomfortable in that moment. That did not make it any less important.
Questions for your own practice
- Which way of working do you regularly experience as disruptive within your team?
- What useful function might lie behind that very behavior?
- When does your work need more exploration—and when does it need more safeguards?
- How do you discuss these differences before they turn into personal judgments?