There is a quote often attributed to Eleanor Roosevelt that has stuck with me throughout my career:
Small minds discuss people. Good minds discuss events. Great minds discuss ideas.
The longer I work in technology, the more I see this pattern play out — in meetings, in Slack channels, in architecture decisions, and in how organizations succeed or fail.
Small Minds Discuss People
We have all been in these meetings. Instead of solving the problem, the conversation drifts to who caused it. Who wrote the bad code. Who missed the deadline. Who made the wrong call.
This is the lowest form of professional discourse, and it is toxic.
In engineering teams, it sounds like:
- “Who approved this pull request?”
- “That team never delivers on time”
- “The previous architect made terrible decisions”
None of these statements solve anything. They assign blame, create defensiveness, and destroy psychological safety. The engineer who is afraid of being blamed stops taking risks. The team that is always criticized stops sharing information. Innovation dies.
I have seen brilliant engineers leave organizations not because of the technology or the pay, but because the culture was stuck at this level. Every retrospective became a blame session. Every incident review became a trial.
Good Minds Discuss Events
A step up is discussing events — what happened, when, and how. This is where most competent teams operate. Post-incident reviews, sprint retrospectives, market analysis.
In engineering, it sounds like:
- “The deployment failed at 14:32 because the database migration timed out”
- “Our competitor launched a new feature last week”
- “The cloud costs increased 40% this quarter”
This is useful. It is factual. It drives accountability without blame. Blameless post-mortems are a perfect example of event-level thinking: we focus on what happened, not who did it.
But event-level thinking has a limitation. It is reactive. You are always responding to what already occurred. You understand the past but you do not shape the future.
Great Minds Discuss Ideas
The highest level is ideas. Not what happened, but what could be. Not who failed, but what we should build. Not the event, but the principle behind it.
In engineering and technology leadership, it sounds like:
- “What if we designed our platform so this category of failure becomes impossible?”
- “How should we think about AI workloads in our architecture for the next five years?”
- “What would our developer experience look like if we eliminated all friction?”
This is where real value is created.
When a CTO asks “Should we adopt Kubernetes?” they are discussing an event — a technology choice. When they ask “How do we build a platform that gives our teams autonomy while maintaining governance?” they are discussing an idea. The first leads to a tool selection. The second leads to a platform strategy that transforms how the organization works.
How This Shows Up in Practice
Architecture Decisions
- People level: “The last architect was terrible, we need to rewrite everything”
- Event level: “Our monolith cannot scale to handle the traffic increase from last quarter”
- Idea level: “What principles should guide how we decompose our system so it scales with our business?”
Incident Response
- People level: “Who pushed this broken code to production?”
- Event level: “The deployment at 14:32 caused a 23-minute outage due to a missing database index”
- Idea level: “How do we design our deployment pipeline so that performance regressions are caught before they reach production?”
Team Building
- People level: “We need to hire someone from Google or Meta”
- Event level: “We lost three engineers this quarter and need to backfill”
- Idea level: “What kind of engineering culture attracts and retains people who want to do their best work?”
The Trap of Staying Comfortable
Most of us default to the level that feels safe. Discussing people feels powerful — you are the judge. Discussing events feels productive — you are dealing with facts. Discussing ideas feels risky — you might be wrong.
But being wrong about an idea is how progress happens. Every significant advancement in technology started as an idea that most people thought was wrong or impractical.
Container orchestration was an idea before it was Kubernetes. Infrastructure as code was an idea before it was Terraform and Ansible. The entire cloud-native movement started as a set of ideas about how software should be built and operated.
Building Idea-Level Teams
If you lead a team or an organization, you can actively shift the conversation upward:
In retrospectives, ban blame. When someone starts with “who,” redirect to “what” and then to “how might we.”
In architecture reviews, start with principles before technologies. Define what you believe about your system before selecting tools.
In one-on-ones, ask your engineers what ideas they are excited about. Not what tasks they completed — what possibilities they see.
In hiring, look for people who think in ideas. The engineer who asks “Why are we building this?” is more valuable than the one who asks “What framework should I use?”
In meetings, notice the level of conversation. If it has been thirty minutes of discussing people or events, pause and ask: “What is the idea we are trying to get to?”
The Meta-Idea
Here is the thing about this framework: it is itself an idea. You can discuss it at any of the three levels.
You could gossip about who in your organization operates at which level (people). You could observe that your last all-hands meeting stayed at the event level for two hours (events). Or you could ask: how do we build an organization where idea-level thinking is the default? (ideas).
That last question is worth more than the other two combined.
Final Thoughts
The best leaders I have worked with spend most of their time at the idea level. They do not ignore people or events — they use events as data and treat people with respect. But their energy goes toward ideas: what should we build, how should we think, what principles guide our decisions.
Small minds discuss people. Good minds discuss events. Great minds discuss ideas.
Which conversations are you having this week?
