There are two modes of operating. Most people mix them up. Strong operators don’t.
Doing things is activity. Getting it done is outcome.
They look similar on the surface. They are not the same game.
⸻
1. What each mode actually means
Doing things
You execute inside a defined frame. The task is clear. The path mostly exists. Progress is measured by effort and completion of steps.
Getting it done
You own the outcome. The goal is clear. The path is not. Progress is measured only by whether the end state is achieved.
This is not a spectrum. It is a clean switch in mindset.
⸻
2. Skills required
Doing things (Execution skills)
- Strong functional skills
- Discipline and repeatability
- Speed with acceptable accuracy
- Ability to follow instructions well
- Focus on local optimisation
This mode rewards reliability.
Getting it done (Outcome skills)
- Framing the problem correctly
- Making decisions with incomplete data
- Orchestrating people, time, and resources
- Designing trade-offs, not avoiding them
- Aligning stakeholders
- Holding the line till closure
This mode rewards ownership.
A simple test: If work stops when instructions stop → it was doing.
If work continues until the outcome → it is getting it done.
⸻
3. Value share in the system
Most organisations overvalue “doing things.” Because it is visible. It is easy to measure.
But value does not follow effort.
- Doing things: high effort, lower value
- Getting it done: lower effort, higher value
A rough split:
- Doing → ~70% effort, ~30% value
- Getting it done → ~30% effort, ~70% value
Execution creates output. Ownership decides if that output matters.
Teams rarely fail because people are not working. They fail because no one owns the final outcome.
⸻
4. Value chain view
Think in a simple chain:
Problem → Design → Plan → Execute → Integrate → Deliver
- “Doing things” sits mostly in Execute
- “Getting it done” sits in Problem, Design, Integrate, Deliver
Most failures happen at the edges:
- Wrong problem → perfect execution, useless result
- Poor integration → many parts done, system broken
- Weak delivery → solution built, no real impact
“Doing” optimises pieces. “Getting it done” optimises the full chain.
⸻
5. When to use each
Use “doing things” when:
- The problem is well defined
- The process is stable
- Variability must be low
- Scale and efficiency matter
Examples: Routine ops, manufacturing, reporting, standard builds
Use “getting it done” when:
- The problem is unclear or evolving
- Many teams or dependencies are involved
- Trade-offs are unavoidable
- The outcome matters more than the process
Examples: New launches, cross-functional programs, crisis situations, supply issues
⸻
6. The common mistake
Most teams do this wrong.
They take a “getting it done” problem And assign it to “doing things” people.
Then they add:
- more trackers
- more meetings
- more escalation
Activity goes up. Outcome does not.
Correct structure is simple:
- One clear owner for the outcome
- Multiple executors for parts of the work
One person owns closure. Others support execution.
⸻
7. Mode switching
The best operators can switch cleanly.
They start in getting it done: Define the problem. Set direction.
They move into doing: Unblock key tasks. Drive execution where needed.
They return to getting it done: Integrate. Push to closure.
Staying too long in one mode breaks the system:
- Too much doing → busy, but no result
- Too much getting it done → thinking, but no movement
You need both. But not at the same time.
⸻
8. Quick diagnostic
Ask three questions: 1. Who owns the outcome end-to-end? 2. Where does work break between teams? 3. Are we tracking activity or actual closure?
If these are unclear, you are not getting it done.
You are just doing things.
⸻
Conclusion
Execution is necessary. Ownership is decisive.
Visible effort gets rewarded in organisations. Finished outcomes win in reality.
Choose your mode deliberately.