“This is rainbows, butterflies, and unicorns.”

That was my manager’s response when I tried to explain my ideas about leading a team of software developers. He said it with enough certainty that there wasn’t much room for debate. Most managers have been less blunt over the years, but the sentiment has often been the same. The things I believed about people, about trust and motivation and team work, sounded too idealistic to be practical.

Eventually, I stopped trying to persuade anyone. It was easier to implement the idea and let the results make the argument for me.

The reactions that followed were memorable.

After a particularly dramatic improvement in team morale, one manager asked, “Are you putting cocaine in your team’s morning coffee?”

Following a round of enthusiastic praise from a client, another wondered, “Are you bribing the client?”

And when the employee survey results came back month after month with unusually high scores, someone looked at the report and asked, “How did you hack into the survey’s database?”

They were all joking, of course. But jokes have a way of revealing what people find difficult to believe.

What struck me was not that the results were good, but that they seemed improbable. The idea that a team could be highly motivated, deeply engaged, and genuinely happy in their work appeared, to some observers, less plausible than coffee laced with narcotics, bribery, or cybercrime.

I’ve always found that reaction interesting. We are often willing to believe in complicated explanations before we consider a simple one: that people do remarkable things when they feel trusted, valued, and understood.

The success of my approach has occasionally inspired the faint suspicion that I must be doing something illicit. I take that, oddly enough, as a compliment. It suggests that what should have been ordinary, a healthy team doing excellent work, has become rare enough to seem almost impossible.

Before I go any further, I should introduce myself.

I am from Iraq, where the human story first learned to write itself down. Before the world knew itself as a collection of nations, it was gathering its first thoughts in Mesopotamia, the cradle of civilization. I grew up with the understanding that some of the oldest human stories began in the land my ancestors called home. Among those stories is one of humanity’s most important inventions: the wheel.

Seven thousand years ago, in the ancient civilization of Sumer, someone was faced with a perfectly ordinary problem. There was something heavy that needed moving and a considerable distance over which to move it. Dragging it required strength, time, grit and character building patience. Then came a simple observation, the kind that changes history only because someone bothered to notice it. A rounded object could be rolled. What had been a struggle became substantially easier.

The wheel feels inevitable now. It is difficult to imagine a world without it. Yet every great innovation becomes obvious only after someone has thought of it.

I mention this story for a reason. It may seem like a historical detour, but I ask you to keep it in mind. We’ll come back to it later, because it turns out the lesson hidden inside that ancient invention has a surprising amount to do with the way we work today.

My path into people management was less a carefully planned career move than a consequence of circumstance. I had built a proof of concept, and when the proposal was approved for implementation, my manager decided I should lead the team responsible for delivering it.

“You know what needs to be done better than anyone,” he told me.

He was right, of course. I understood the technology. I understood the problem we were trying to solve. What neither of us considered was that knowing what needed to be done and knowing how to lead a group of people are two entirely different skills. I had never managed anyone before, and it showed.

I made nearly every mistake available to a first-time manager. I hovered over people when I should have trusted them. I failed to communicate clearly and then felt frustrated when the results did not match the vision in my head. I paid little attention to the relationships within the team, assuming that intelligent people with a common goal would naturally work well together.

At first, I wanted to be everyone’s friend. I imagined myself as the cool manager, the one people liked. When that failed to produce the results I wanted, I swung in the opposite direction. I became demanding, harsh, and far more forceful than I needed to be. Neither approach worked particularly well.

Day after day, managing a team felt remarkably similar to the problem faced by that ancient Sumerian who first looked at a heavy rock and wondered how to move it. Every task seemed to require tremendous effort. Every setback demanded rock dragging character building patience. Progress happened slowly accompanied with massive effort.

What made the experience especially humbling was the persistent suspicion that there had to be an easier way. More than once, after a long day of meetings, misunderstandings, and course corrections, I found myself thinking that the work would move faster if I simply did it all myself.

No team. No coordination. No difficult conversations. Just me and the work.

Over the years, many of the experiences I had navigating the technology industry found their way into my novel All the Shoes. Fiction gave me a place to explore some of the questions I carried with me and some of the lessons I learned the long way around. If you are looking for a little encouragement, or simply the company of someone who has wrestled with similar challenges, I hope you will give it a read.

Sometimes, when you’re struggling to solve a problem, the answer arrives from a place you would never think to look.

That’s exactly what happened to me.

The breakthrough had nothing to do with software development, project management, or work. It came from political activism and, through a chain of events I could never have predicted, a community theatre workshop.

The premise was deceptively simple. A group of strangers would spend six days together and, by the end of the workshop, create a play. Not perform an existing play. Create one. From scratch and then perform it in front of an audience.

Before we began, the director, David Diamond, explained how the process would work. The play, he told us, would come from the group. No one person would write it. No single voice would take charge. Through a series of exercises, the story would emerge collectively from the people in the room.

I was deeply skeptical.

It seemed like one of those ideas that sounded beautiful in theory and impossible in practice. Surely, I thought, someone would eventually take over. Someone would have to make the decisions, shape the narrative, and tell everyone else what to do. That was how things got done, wasn’t it? Every project needed a driving force, a person at the center pulling the rest of the work forward.

I nodded politely while privately waiting for reality to assert itself.

To my surprise, it never did.

What happened instead was exactly what David had described.

The workshop was led by David Diamond, a theatre director with ability to make people see things they had overlooked. Rather than beginning with scripts or dialogue, he began with people. The first few days were spend in trust building exercises. We spent hours doing exercises that felt, at least to me, entirely disconnected from anything practical.

When I raised my concern that we were no where near creating a play, David answered me with: “Just trust the process.”

It was only on the third day we proceeded to engage in exercises at least relevant to the issue at hand. In one of such exercises we used our bodies to create images related to the political issue we were exploring. Working in silence, we arranged ourselves into tableaux: frozen scenes composed of human beings instead of paint and canvas.

No one was allowed to explain what they meant. No one was permitted to negotiate. The image had to emerge from observation, intuition, and a willingness to respond to one another.

Once the image was complete, David would walk around us.

“When I touch you,” he would say, “I want you to speak a sentence that begins with the words I want.”

Then he would touch a shoulder or an arm.

“I want to be heard.”

“I want to belong.”

“I want to stop being afraid.”

The frozen image began to reveal an inner life.

Then came the next instruction.

“When I clap my hands, I want you to make a single movement in the direction of getting what you want.”

A person would shrink.

A hand would reach out.

Someone would turn away.

Another would stand taller.

The image, which was static only moments earlier, suddenly became a story. The desires hidden beneath the surface became visible through movement.

Over time, the scenes grew more complex. The movements became conversations. A play emerged.

There were other exercises as well, some of them surprisingly uncomfortable. David would ask us to voice the thoughts we normally keep to ourselves, the private commentary that rarely survives the journey from mind to mouth.

The exercise felt unnatural at first. We spend much of our lives learning which thoughts should remain hidden. Yet those unspoken thoughts often turned out to be the most important part of the room. They explained motivations, fears, and behaviors that otherwise made little sense.

Looking back, what strikes me is how much attention was paid to things that are usually invisible. Not just what people were doing, but what they wanted. The secret fears and desires. Not just their actions, but the stories they were telling themselves.

Let me be clear. The theater workshop exercises are completely inappropriate for work environment.

If someone had suggested that I run a software development team the way David ran a community theatre workshop, I would have dismissed the idea immediately. The workshop lasted six days. Software projects can last years. Participants volunteered to be there. Employees have deadlines, budgets, clients, performance reviews, and mortgages. The stakes are entirely different.

No, I was not about to start asking developers to arrange themselves into frozen sculptures in the middle of a sprint planning meeting.

Yet I couldn’t shake the feeling that I had witnessed something important that I could be inspired by.

A group of people had accomplished something I was convinced could not be done. They had created a coherent piece of work without a single person taking over. More importantly, they had done so while remaining highly engaged in the process. No one had been dragged along. No one had been ordered into compliance. The energy came from within the group itself.

The experience lingered in the back of my mind.

As I reflected on it, I realized that the workshop’s success had very little to do with theatre. The exercises, the stage, the eventual play, those were merely vehicles. Underneath them, were a set of principles about how human beings work together. The more I thought about those principles, the more they seemed applicable to the challenges I was facing as a manager.

I began to study the workshop the way an engineer studies a software. What were its moving parts? What exactly had caused it to work? Why did a room full of strangers become so invested in a shared outcome?

I made a few observations:

People wanted to be heard.

When a group of people trust each other a whole load of friction disappears.

People revealed valuable information when it was safe to do so.

A managers job is to create a process that allows ideas, all ideas including bad ones, to be expressed.

And perhaps most importantly, people were often willing to support an idea they had not originally proposed, provided they genuinely felt included in the process that produced it.

None of these observations were revolutionary on their own. Yet the process of applying them produced radically different result.

Back at work team discussions became more participatory. Decision-making became more transparent. I spent less time telling people what to think and more time helping them think together. Instead of treating disagreements as obstacles, I started treating them as information. Instead of assuming resistance was a problem to be overcome, I became curious about what that resistance was trying to tell me.

Gradually, something changed.

Meetings became shorter and more productive.

People began solving problems without waiting for permission.

Team members started helping one another in ways I had never explicitly requested.

Morale improved.

Clients became happier.

Delivery improved.

And, somewhat unexpectedly, my job became easier.

This was my equivalent of discovering the wheel.

For years I had been dragging the rock. Whenever progress slowed, my instinct was to push harder. Supervise more closely. Intervene more aggressively. What I failed to understand was that the problem was not a lack of effort. The problem was the method. Once the method changed, the amount of force required changed as well.

Over time, I refined these ideas into a structured approach that I came to call the Consensus Building Framework. I can boil it down to four principles:

1. People Before Technology

Software is built by people.Tools, processes, architectures, and plans matter, but none can compensate for an environment in which people feel ignored, mistrusted, or afraid to speak.

People do their best work when they feel seen, heard, and respected. In an environment built on trust, they share unfinished ideas, admit mistakes sooner, ask for help, challenge assumptions, and take responsibility for outcomes.

The leader’s first responsibility is not to manage the work. It is to create an environment in which people can do their best work together.

2. Discovery Through Play

At work, we often try to think our way to the perfect answer. We sit around tables discussing possibilities, defending opinions, and identifying everything that might go wrong. The conversation becomes increasingly intellectual while the problem itself remains untouched.

The theatre workshop worked differently. We did not begin by discussing the play. We stood up and made something.

One person created an image with their body. Another responded to it. A third added something new. No contribution was complete on its own, but each contained a fragment of truth upon which the next person could build.

We had to be present because there was no script to follow. We had to be spontaneous because we could not plan our response before seeing what another person offered. We had to be playful because play gave us permission to experiment without knowing where the experiment would lead.

This did not make the work frivolous. It made discovery possible.

Play loosens our attachment to being right. It allows us to offer unfinished ideas, experiment without certainty, and treat failure as information rather than embarrassment. Instead of debating whether something will work, we try it. Instead of protecting our own ideas, we build on the truth in what someone else has offered.

Sometimes the fastest way to understand an idea is not to discuss it further. It is to make something and see what happens. I always strive to add element of fun and playfulness into any project I am part of.

3. Create the Conditions for Collective Intelligence

No single participant in the workshop could have created the play we eventually produced. Each person could see only part of it. The story emerged through the interaction of different experiences, instincts, and points of view.

The same is true of software teams.

No manager, regardless of experience or intelligence, can possess all the knowledge held by the group. Collective intelligence does not happen simply because several people are in the same room. The loudest voice can easily become the group’s voice. Authority, confidence, seniority, and speed of speech can determine which ideas survive.

The leader must create conditions in which people can genuinely think together. Where every person has an opportunity to contribute, ideas can remain unfinished long enough to evolve, and the group can create something none of its members could have produced independently.

The goal is not to select the best individual idea. It is to allow the group to build a better one.

4. Design the Process, Don’t Force the Outcome

For years, I approached leadership the way my ancient Sumerian ancestor approached the heavy rock: by applying more force.

If a project stalled, I pushed harder. If performance slipped, I supervised more closely. If alignment was lacking, I communicated more aggressively.

The workshop taught me a different lesson.

The theater workshop did not force us to produce a play. It followed a process that allowed a play to emerge. It created the conditions in which people could respond to one another.

Leadership is less about controlling people and more about designing the conditions in which people can succeed together.

What This Looked Like in Practice

Principles are easy to admire in the abstract. I want to give you a taste of what this looks like in practice.

I once inherited a team of nine developers working on a project that was already in serious trouble. Everything that can possibly be wrong was happening on this project. The feedback from the engineering manager of the client was so negative that I told my manager: “Reading the feedback reports is hurting my ego, and I’m not even on the team yet.”

My first meeting with the client’s engineering manager was thirty minutes of him just yelling at me in frustration.

We began by rebuilding trust within the team and with the client. Together, we raised our standards for coding, testing, and communication. We clarified expectations, listened directly to users, and developed the domain knowledge needed to propose solutions rather than wait for instructions.

Within two months, the project had moved from crisis to stability. Two months later, the client’s feedback was glowing.

During a subsequent visit, the same engineering manager who spent thirty minutes yelling at me told us he felt lucky to have been assigned a talented team of developers who had become the key to the project’s success. Here is a case where everything was the same. Same people, client and technical challenges. The only thing that changed was the manager.

At another company, I inherited a team of fifteen developers whose morale scores had remained near the bottom of the organization for eighteen months.

Within two months, the team rose to the top, becoming the highest-scoring software development team in the whole company.

We did not get there through motivational speeches or forced fun. We examined every part of how we worked: coding, testing, releases, monitoring, project management, and communication. And then we collaboratively created the changes necessary to make us proud of our own work.

In both cases, the people had not suddenly become more talented. They had been given the trust, clarity, and ownership needed to use the talent they already possessed.

I admit that I feel slightly embarrassed writing all of this down. The principles seem so obvious: trust people, listen to them, invite them into the process, and create the conditions in which they can succeed. I can see you rolling your eyes.

I feel like an ancient Sumerian who has time travelled to the modern world and is now enthusiastically explaining the wheel.

Look, I want to say. It rolls. You don’t have to drag the rock anymore.

The discovery is ancient. The need for it, is not.