There’s a shift happening in software that is steering teams away from acting with curiosity. Tools like AI and Figma have only helped speed up the process.
A Paucity of Curiosity
It’s becoming too easy to create without understanding. Too often, at the beginning of a project, a team has data collected over time dumped into their laps without a reasonable expectation for synthesis. The team must then create solutions that meet user and business needs, while also being easy to code, or it will be rejected as too expensive. Time or resources spent understanding the product domain, instead of just making, is often targeted for cuts. Yet, teams are still expected to deliver useful software.
Have you noticed that Design Thinking all but disappeared from the conversation? It’s a symptom of the move away from curiosity, and it reminds me of a quote from Erika Hall.
“The fundamental problem Design Thinking attempts to solve is that 90% of design is…thinking. And thinking is invisible. Invisible work makes managers really itchy.”
Why is a lack of curiosity a threat to any software project?
Subject matter experts are too good to be true.
That is to say, they are too good at what they do. Relying exclusively on domain experts to drive the direction of the work, have all the questions, and provide all the insights into how things work is dangerous. The fact is, they’re too close to the work. They don’t realize how complex their mental model and processes are.
Experts go through their day navigating business constraints, domain rules, contradictions, and gaps in knowledge and filling gaps with common sense. Software can’t do this.
That’s why the team building the software needs to be curious about the domain, the problems, and the people using the software. Giving people the space to be curious and learn will lead to a more successful piece of software.
Curiosity Causes (Useful) Trouble.
Without curiosity, we’re all blindly following what we think is the right path. By simply asking a few questions we can tell if that’s true and identify false alignment or gaps in knowledge.
These questions appear simple on the surface. However, watch how often team members will have different answers or whether they can answer them at all.
Cause some useful trouble and be curious about the answers.
- What are we trying to solve?
- How do we know that is a problem?
- Why are we trying to solve that?
- Is there a better way to solve it?
Curiosity isn’t a cure for burnout, but it can be a vaccine.
Project work, features, products, etc. can start to feel homogenous. Over time, it’s easy to become jaded or lose motivation. It can begin to feel like you’re doing the same thing over and over. You might lose sight of what value you’re adding to the work. By giving people space to be curious and learn and/or experiment within the domain of their project enables them to be creative and better understand the positive impact they are having.
On a personal note, even when you’re working within a domain you wouldn’t normally be interested in or maybe even find boring, having curiosity can go a long way to alleviate these feelings.
Wanting to understand how things connect, how information flows, why people use the software, and how your decisions can help or hurt can make any topic or task less likely to burn you out.
Curiosity enables innovation.
Do you want to foster curiosity? Start by defining project principles and tell your team:
- We’re going to study problems before we jump to solutions.
- We’re going to treat requirements as assumptions and validate them.
- We’re going to diverge on our best ideas before picking the one that matches the solution best.
Curiosity enables creativity and creativity enables innovation. To get more from your software structure your process to provide your team room to be curious.