.png)
Every team has one. The person who shows up to Monday's standup having found a better tool over the weekend. The one who reads the new framework's documentation for fun. The one who hears "that's how we've always done it" as a challenge rather than an answer.
That's high openness at work, and depending on where you sit, it either looks like your team's greatest asset or its most exhausting habit. Both readings are true. That's what makes this trait worth understanding.
What Openness Actually Measures
Openness is your appetite for the new: new ideas, new methods, new ways of framing old problems. Like every trait in the Five-Factor Model, it's a spectrum, and it's largely fixed. Nobody chose their setting, and no workshop is going to move it much. What you can do is understand what your setting is optimized for.
High-openness people run what I call the Discovery Drive. They have a fluid comfort with ambiguity that most people find genuinely uncomfortable. Rapid pivots don't rattle them. Architectural overhauls excite them. When the ground shifts under a project, they're often the calmest people in the room, because uncertainty is their native terrain.
Low-openness people are not less intelligent or less creative, and this needs saying plainly because our startup-soaked culture implies otherwise constantly. They are process architects. They extract maximum value from proven systems, they protect institutional knowledge, and they keep the trains running while others scout new track. An organization made entirely of explorers ships nothing. An organization made entirely of architects ships the same thing forever.
The Superpower
The Discovery Drive is what keeps a team competitive over the long run. Markets shift, tools improve, and yesterday's best practice quietly becomes tomorrow's liability. High-openness people are your early-warning system for opportunity. They spot the workflow that saves ten hours a week. They ask the question that reframes the whole problem. They are the reason your team isn't still doing things the way it did five years ago.
There's a quieter superpower here too: high-openness people metabolize change on behalf of everyone else. During a reorg, a pivot, or a messy quarter, they model what comfort with uncertainty looks like, and that steadiness is contagious.
The Pitfall
The same drive that finds the better tool will also rebuild a working system in the middle of a scaling quarter because a more elegant version seemed possible. I call this shiny-object scope creep, and it's the signature failure mode of unmanaged openness.
The pattern is predictable. A high-openness person encounters a functioning process, sees its imperfections vividly, and starts optimizing. The optimization becomes a project. The project fractures an active scaling layer mid-quarter, and now the team is maintaining two systems instead of one. Nobody involved was being careless. The Discovery Drive was simply doing what it was built to do, without a container around it.
How to Work With It
If you manage a high-openness person, the worst thing you can say is some version of "stop trying to break things that already work fine, just follow the standard tracker." You haven't corrected a behavior. You've told their hardware it isn't welcome, and they will either disengage or leave.
The move that works is validation first, container second. Something like: "I love that you're looking at optimized tools for our workflow. Your discovery drive is exactly what keeps this team competitive. Let's time-box it: what are the three metrics we'd need to see in an isolated 30-day pilot before we touch the core system?"
Notice what that does. It honors the instinct as genuinely valuable, because it is. Then it gives the drive a sandbox with walls: a time limit, a success metric, and isolation from production. High-openness people don't resent containers. They resent being told to stop exploring.
If you're the high-openness person, the container is still the answer, you just have to build it yourself. Before you propose the overhaul, define the pilot, the metrics, and the boundary. You'll win far more of these conversations arriving with the sandbox already drawn.
The Two Sides of the Table
Most openness conflict is a collision between a Discovery Drive and a Process Architect, and neither of them is wrong. One protects the future, the other protects the present, and the team needs both protected. When you find yourself in that collision, resist the urge to make one setting right and the other defective. The productive question is never "who's correct?" It's "what does the experiment need to look like so we can both trust the result?"
If you're not sure where you sit on this spectrum, our free assessment maps you across all five OCEAN traits in about five minutes, superpowers and pitfalls included. Your setting isn't going anywhere. You might as well know what it's optimized for.
.svg)