A few months ago, I was interviewing a candidate for a senior engineering role. Strong resume. Solid certifications. Good technical depth. Halfway through the conversation, I asked a question I always ask: “Tell me about a time you had to throw away your own work because the team found a better approach.”
The silence lasted longer than it should have.
It wasn’t that he couldn’t think of an example. It was that the question didn’t compute. His career had been built around individual output: lines of code, features shipped, problems solved alone. The idea that discarding your own work could be a sign of strength, not failure, was foreign to him.
He was technically excellent. I didn’t hire him.
That decision would have been hard to explain to someone who evaluates talent by resume and certifications alone. But after nearly three decades of building, leading, and scaling technical teams, I’ve learned that the qualities that make someone effective on a team are not the ones that show up on a CV. And in the AI era, where individual technical output is increasingly augmented by machines, those qualities matter more than ever.
There are four that I look for in every person I work with: excellence, teamwork, adaptability, and empowerment. They were non-negotiable before AI. They are even more non-negotiable now.
Technical skills get people through the door. But the long-term success of a team depends less on what individuals can produce and more on how they think, interact, and grow together. These four qualities consistently predict that success.
Excellence Is Not Perfection
The first thing I look for is a commitment to excellence, and I need to be precise about what I mean, because excellence is one of the most misused words in corporate language.
Excellence is not perfection. Perfection is paralyzing. Excellence is the discipline of doing your best work within real constraints: time, budget, information, team capacity. It means caring about quality not because someone is watching, but because you cannot bring yourself to ship something you know is incomplete or fragile.
In practice, I recognize excellence in small signals. The engineer who writes a clear commit message when nobody requires it. The architect who documents a decision not because there’s a template, but because she knows someone will need to understand it six months from now. The consultant who pushes back on a customer’s request, not to be difficult, but because the request would create a problem the customer hasn’t anticipated.
AI amplifies this distinction. When AI can generate code, documentation, and architecture proposals in minutes, the person who accepts mediocre output because “the AI wrote it” becomes a liability. The person who holds AI-generated work to the same standard they hold their own becomes invaluable. Excellence in the AI era is not about producing more. It is about refusing to let the standard drop just because production got easier.
At Clouxter, we’ve built a culture where excellence is recognized and expected, not through rigid processes, but through a shared understanding that the work we deliver represents who we are. That culture happened because we hired for it.
Teamwork Is Not Collaboration
Everyone claims to be a team player. Very few actually are.
Collaboration is working alongside others. Teamwork is something deeper: it is subordinating your individual preferences to the team’s outcome. It is the developer who abandons his elegant solution because the team agreed on a simpler one that’s easier to maintain. It is the architect who lets a junior team member present the design she helped shape, because the team’s growth matters more than her visibility.
I’ve built teams across consulting and managed services where the work is inherently collaborative: multiple people, multiple disciplines, shared accountability for delivery. In that environment, someone who optimizes for individual recognition creates friction that no process can absorb. The best technical skill in the world doesn’t compensate for a person who makes the team slower.
This matters more in the AI era because of how AI-driven development actually works. In methodologies like AI-DLC, the rituals are collaborative by design. Mob Elaboration and Mob Construction put the entire team in one room, validating AI output together. A person who needs to be the smartest one in the room, who can’t build on someone else’s idea, who treats every discussion as a debate to win, breaks the dynamic that makes these rituals work.
The question I’ve started asking in interviews is not “tell me about a successful project” but “tell me about a time the team succeeded and your individual contribution was invisible.” The answers reveal everything.
Adaptability Is Not Flexibility
Flexibility is adjusting your schedule. Adaptability is adjusting your mental model.
Technology changes constantly. That’s obvious. What’s less obvious is how differently people respond to that change. Some professionals learn new tools but keep the same assumptions. They adopt a new framework but apply old patterns. They use AI coding assistants but don’t rethink how they plan, review, or validate work.
Adaptability is the willingness to question your own assumptions when the context changes. It is the Scrum Master who recognizes that her ceremonies need to evolve when AI compresses the work that used to fill a sprint. It is the architect who accepts that his design review process, the one he built and is proud of, might be creating a bottleneck instead of protecting quality. It is the senior developer who acknowledges that a junior colleague with strong domain curiosity might be a better validator of AI output than he is.
I wrote about this dynamic in the developer’s evolving role: seniority is being reshuffled, and the people who adapt are the ones who thrive. The ones who cling to “how we’ve always done it” become the bottleneck, regardless of their technical depth.
In my experience, adaptability correlates more with curiosity than with experience. The most adaptable people I’ve worked with are the ones who ask “why” before “how.” They don’t just learn the new tool. They ask why the old approach no longer works. That question, genuinely asked, is the starting point of real adaptation.
Empowerment Is Not Delegation
The last quality is the one that separates good professionals from leaders, regardless of their title.
Delegation is assigning tasks. Empowerment is creating the conditions for someone else to grow. It is the tech lead who gives a junior developer ownership of a component, not because she doesn’t have time, but because she knows that ownership is how people develop judgment. It is the consultant who teaches the customer’s team to operate the solution instead of creating dependency. It is the manager who shares context, not just instructions, so that the team can make decisions without waiting for approval.
Empowerment requires a specific kind of confidence: the confidence that making others better does not make you less relevant. In organizations where knowledge is hoarded and visibility is competed for, empowerment is rare. In organizations where it’s practiced, teams scale in ways that no hiring plan can replicate.
AI makes empowerment even more critical. When AI handles the mechanical work, the human differentiator becomes judgment, and judgment develops through ownership, not through following instructions. A team where only the senior members make decisions and everyone else executes is a team that will not scale in the AI era. A team where everyone is empowered to validate, challenge, and decide is a team that compounds its capability with every project.
At Clouxter, I’ve seen this play out directly. The teams that grow fastest are not the ones with the most senior people. They are the ones where senior people actively invest in making others capable of doing what they do. That investment is empowerment, and it is a choice, not a personality trait.
Why These Four, and Why Now
Someone might read this and think: these are generic leadership values. Every company’s wall has a poster with words like these.
The difference is whether you hire for them, or just talk about them.
I hire for them. I evaluate for them. I build teams around them. Not because they sound good in a culture deck, but because these are the four qualities that consistently separate teams that deliver from teams that struggle, regardless of the technology stack, the industry, or the methodology.
And the AI era makes them more important, not less. When AI can generate code, write documentation, propose architectures, and even facilitate planning, the human contribution shifts from production to judgment. I explored this shift as a leadership challenge in the conversation this book is really about: the gap between what metrics say and what teams experience. And judgment is shaped by excellence (the standard you hold), teamwork (the ability to integrate perspectives), adaptability (the willingness to update your assumptions), and empowerment (the commitment to develop others).
AI is raising the floor of what any individual can produce. These four values are what raise the ceiling of what a team can achieve.
The Hiring Question
If you lead a technical team, here’s a question worth sitting with:
When you evaluate candidates, are you measuring what they can do alone, or what they will make possible for the team?
The answer to that question shapes everything that follows.
Ricardo
