We’ve all been told the same thing:

Work smarter, not harder.

So we do.

We tighten agendas.
We batch tasks.
We use AI to summarize meetings and extract action items.
We automate the repetitive stuff.

We become efficient.

And yet…

We’re still busy.
The same issues resurface.
The same debates repeat.
The same friction returns next week.

The work got smarter.

The system didn’t get better.

Maybe smarter isn’t the upgrade we think it is.

Maybe the real shift is this:

Work Farther, Not Smarter (WFNS).

---

The Three Ways We Work

There are three modes of effort.

1. Work Harder

More hours. More intensity.
It works — until it doesn’t.
But energy is finite.

2. Work Smarter

Better tools. Better tactics.
Cleaner processes. AI summaries. Faster steps.

Smarter beats harder.

But it still optimizes the step.
It rarely questions the structure.

3. Work Farther

Farther is different.

Farther zooms out.
Farther asks uncomfortable questions.
Farther invests thinking before optimizing.

Smart people optimize for today.
Wise people optimize trajectory.

Leverage is what changes the slope.

---

A Familiar Example

Take the weekly meeting that drags.

Working smarter looks like this:

• Tighter agenda.
• Pre-reads sent ahead of time.
• AI summaries after the call.
• Cut from 90 minutes to 60.

It feels productive. Modern. Optimized.

And yet the same issues resurface.
The same decisions get revisited.
The same blockers reappear.

Smarter improved the ritual.

Farther questions the ritual.

Farther asks:

• Why does this meeting exist?
• Who actually owns the decision?
• Why do these issues keep recurring?
• What structure would make this discussion unnecessary?

Instead of perfecting the meeting, you:

• Clarify decision ownership.
• Define escalation rules.
• Create a simple dashboard that replaces in-person status updates.
• Track recurring friction at the root.

Eventually, something unexpected happens.

You don’t shorten the meeting.

You remove the need for it.

Smarter saved an hour.
Farther freed the organization.

That’s leverage.

---

What WFNS Really Means

Work Farther, Not Smarter isn’t about eliminating tasks.

It’s about building for the long haul.

It means:

• Don’t optimize broken workflows.
• Don’t speed up recurring problems.
• Invest in understanding the whole system.
• Think in years, not weeks.
• Design structures that survive change.
• Create processes that compound.

Smarter solves it faster.
Farther makes sure you don’t have to solve it again.

Farther isn’t subtraction.

It’s construction.

---

Why This Matters

Leverage is what turns effort into trajectory.

This applies to meetings.
It applies to hiring.
It applies to how you structure teams.
It applies to how you spend your time.

And it applies beyond work, too.

The question isn’t:

“How can I do this faster?”

The better question is:

“Should this exist in this form at all?”

Work Farther.

Most organizations don’t struggle because they lack smart people or modern tools. They struggle because they lack a shared understanding of what’s actually broken.

You’ve seen it:

• The dashboard says one thing, the team says another or simply ignore it.
• Projects “make progress” but don’t land.
• Meetings are sharp, follow-through is soft.
• A process “exists,” but everyone runs it differently.
• Someone says “we need tech to fix this”, but cant define what this is 

The problem is we use one word—maturity—to describe two different things.

This model is needed because it separates them.

---

The Organizational Maturity Model: Capability + Process

1) Capability Maturity (skills-first)

How well a person or team turns information into judgment and action. This applies to individuals and organizations. Tech may support it, but it’s not “a tech ladder.”

2) Process Maturity

How clearly the work is defined, repeatable, measurable, and improvable.

---

The Organizational Maturity Grid: Diagnosing Your Next Growth Move

Ladder 1: Capability Maturity C0 — Tribal memory Depends on what people remember. C1 — Capture Notes/emails/paper. Information exists but isn’t reusable. C2 — Organize Spreadsheets/docs/checklists. Structure appears. C3 — Standardize Shared definitions, consistent metrics, repeatable reporting. C4 — Explore People can ask “why?” and investigate without rebuilding everything. This typically includes tools like Interactive views, drilldowns, slicing by context. C5 — Execute Decisions translate into owners, next steps, routing, follow-ups. Insights turn into action: alerts, routing, checklists, workflows, ownership. This typically includes shared plans and task lists. C6 — Learning Loop System Improves Itself. Outcomes feed back to refine standards, playbooks, and tooling (AI?). The goal is faster, higher-quality decisions with less cognitive load.

Ladder 2: Process Maturity P0 — Ad hoc High variation. Lots of “it depends.” P1 — Repeatable There’s a usual way, but it’s not explicit. P2 — Defined Clear stages, handoffs, owners, and “done.” P3 — Measured Cycle time, aging, rework, defects, SLAs. P4 — Improved Experimentation and continuous improvement are normal.

Putting this together you get the Organizational Maturity Grid.

This grid gives you a targeted prescription:

• Hero-Driven / High-Variance– Stabilize the process: define stages, ownership, and handoffs (raise P).
• Bureaucratic Efficient– Invest in capability: definitions, analysis skills, and exploration habits (raise C).
• Immature / Fragile– Start with minimum viable clarity + basic capture/organization.
• High-Performing / Compounding– Strengthen the learning loop: measure outcomes, review exceptions, and improve continuously.

---

How this helps (practically)

1) It prevents the wrong fix

Teams often solve the wrong problem:

• They add process when the issue is capability (they create bureaucracy).
• They add tools/AI when the issue is process (they automate confusion).

The dual model points to the right lever.

2) It explains uneven maturity without drama

Organizations aren’t one maturity level. They’re a patchwork by workflow.

This model lets you say, calmly:

• “Admissions is strong capability, weak process.”
• “Billing is defined and measured, but needs stronger exploration skills.”

That’s a useful conversation, not a judgment.

3) It turns maturity into a roadmap you can execute

For any workflow (or any person), you can choose one next move:

• raise Capability (C)
• or raise Process (P)

That turns “we need to improve” into “here’s what we’re doing next.”

4) It also applies to individuals

This isn’t only an org model.

• A high performer might be high capability / low process personally: brilliant work, inconsistent follow-through, hard to delegate.
• Another might be high process / low capability: extremely reliable, but not yet strong at root-cause diagnosis or judgment calls.

This gives managers a respectful development language:

• “Let’s strengthen your decision-to-execution muscle (C5).”
• “Let’s define your handoffs and definitions (P2).”
• “Let’s build your learning loop (C7) using outcomes and retros.”

---

The takeaway

Maturity isn’t one ladder. It’s two.

• Capability is how well you think and decide.
• Process is how well work runs and improves.

Real maturity is when those ladders climb together.

After almost every interaction today, you get a survey.
Buy something—survey.
Call support—survey.
Quick chat—survey.

We get so many that most people ignore them unless something goes wrong. And when something does go wrong, the scores are harsh. That creates a built-in bias: feedback skews negative by default.

But volume isn’t the real problem. What we ask is.

---

There Are Two Problems Hiding Under “Customer Service”

Customer service is really two separate things:

1. The service representative
2. The product or process itself

Most surveys focus almost entirely on the first.

They ask whether the rep was polite, followed a script, or “resolved” the issue. Sometimes that’s fair—training and enablement matter. But in many cases, the rep is just the messenger.

The real issue is usually upstream.

---

Support Calls Are Signals—If You Listen Correctly

Customers don’t call because they want to. They call because something is broken, confusing, or poorly designed.

Every call is a data point pointing to:

• A flawed workflow
• A confusing feature
• A missing capability

Yet most surveys never capture this. Instead of learning why customers are frustrated, companies measure how well agents absorb that frustration.

That’s backwards.

Good customer service isn’t just handling problems well—it’s eliminating the reasons those problems exist.

---

Ask One Better Question

If you want useful feedback, stop asking ten shallow questions and ask one strong one.

Make it open-ended. Make it focused.

The question we use on our intranet is:

“What is the ONE thing that would most improve your experience with [Intranet Name]?”

The phrase “the ONE thing” forces clarity.
You get fewer answers—but better ones.
And they point directly to where time and energy should be spent.

Try it.

---

One Last Thing: Be Fair to Your Support Team

When customers do have a good interaction, reward it—clearly and consistently.

Service reps spend most of their time dealing with problems they didn’t create. They absorb frustration caused by broken products and bad processes, and they often get blamed for both.

If someone handled a bad situation well, give them a high grade.
They earned it.

Fix the system.
Listen better.
And don’t punish the people stuck holding the bag.

In today’s tech-driven world, design is no longer just a visual element. It’s a powerful force that can make or break a company. Look at the iPhone’s fusion of artistry and innovation or Elon Musk’s visionary ideas in electric cars. Both are testaments to the significance of design.

But what happens when design is overlooked?

Let’s explore the real-world implications of design neglect, where one company’s flawed design decisions reveal a harsh truth: bad design can be the silent killer of companies.

A few years ago, my company selected a prominent HR software provider, a name synonymous with NBA jerseys and women’s soccer. On the surface, they seemed poised for success, having recently merged two major companies and with plans for product enhancement and cross-selling.

However, the problem lay in their design philosophy.

Instead of crafting a thoughtful design, they opted to amalgamate the “best of” their two existing apps. This decision proved disastrous for this type of software. It was akin to forcibly marrying two mismatched puzzle pieces, resulting in a disjointed and ill-fitting solution.

The repercussions of this design choice were profound:

• Administrative Hassles: Managing two separate systems required administrators to learn and use both, introducing complexity and challenges during implementations.
• Duplication of Infrastructure: Each system had its distinct code base, leading to the replication of reporting tools and APIs. This substantially increased the workload for users attempting to learn and implement them.
• Support Challenges: Support personnel were restricted to working on one system, often leaving clients more knowledgeable than their own support staff. Resolving issues frequently necessitated the involvement of multiple personnel, resulting in extended response times.
• Data Synchronization Problems: Data needed to flow between these systems, but there was no seamless way to synchronize it. The absence of synchronization led to a cascade of downstream issues.

Within the software company, problems escalated. Protracted support queues, lingering software glitches, and a revolving door of employees became the norm.

Despite its subpar design, the company won’t vanish overnight due to legacy clients and the complexities of transitioning HR systems. Nonetheless, I foresee a gradual exodus of clients as competitors with superior design or fresh alternatives gain momentum. Someday, they’ll reflect on their downward spiral and wonder where they went astray.

The answer will be glaringly evident: they fell victim to bad design.

This real-world example underscores the profound impact of design on a company’s destiny. It is a stark reminder that design isn’t confined to aesthetics alone; it profoundly influences functionality, efficiency, and user experience. Businesses that disregard structure do so at their peril, often succumbing to a gradual decline driven by poor decisions.

A few years ago, Google conducted a survey of its employees to determine what’s the main contributor to a high performing team. As I saw the headline I was intrigued to find out the result. I was sure leadership was the number one reason for team success- mostly because I was a manager and I had read a lot about the impact of good leadership. I read eagerly hoping to learn some tips. I even anticipated secondary reasons like: talent, team composition. But when I read the results I was shocked and disappointed by their conclusion- it did not include any of my assumptions. The research claimed that the #1 factor for high performing teams was “Psychological Safety” aka trust. It didn’t make sense to me. In general, I think people are good- especially in a professional environment. I thought in any reasonable organization people dont lie to each other, and are going to get paid on time. I really didn’t understand what this was trying to say- was it just some new fad? 

A few months later I finally understood.

The company I worked for at the time had reorganized. Within a few weeks my team’s work quality started to suffer or so it seemed. Almost each time after we released a new update of the software to our operations team, there were issues. They were typically small and easy to fix but the issues escalated quickly. It went from the operations person who discovered the issue to their manager, to the VP, to the President of the company, to my boss (The CIO) and then it hit my desk as the VP in charge of that area. If you’re counting, that’s 7 steps. I knew where to go to get it fixed and involved an 8th person, Carla. She had recently switched from the operations department to my team in IT and understood the intersection between technology and operations well so was well suited for her new role. But it seems she started making a lot of mistakes all of a sudden. While the fixes were typically minor (e.g. change a number from 100 to 1000), each time I’d need to write up a full report on what happened, how it happened and how it was fixed etc and send it around the organization. It was very frustrating to say the least. Sometimes we needed to meet about it- wasting even more time. Of course I put in preventative steps to ensure that root cause wouldn’t happen again. I reviewed processes and put in more checks and balances. But the next time a different small issue would crop up and trigger a large chain of events. It was reflecting badly on the team, especially Carla as her mistakes came to light. As I worked to close gaps in the development/testing process, I tried to understand how quality tanked and so quickly. Finally in one discussion with Carla, she admitted that these mistakes were always happening. In the past her friend in the operations department would call her with the issue directly. They both came in early so they typically solved issues before others noticed. What had changed was that her friend moved to a different role. With new people in new roles in the organization no one reached across to solve issues and instead went up and down the chain. A small issue became a crisis.

When I rehashed this episode I realized that admitting mistakes early could have solved the issue early when Carla was starting out in her new role and saved countless hours of CYA emails and wasted meetings. Trust is important. Trust that a person won’t get in trouble for making a mistake. Trust to go across the organization. Trust that an issue is being taken care of appropriately. Trust that a manager will have appropriate solutions. 

I realized I needed to do two things: first I had to make her comfortable enough to admit mistakes and gaps in knowledge so we can learn from it and prevent it from happening again. I also needed to give Carla more training. The problems soon went away and Carla succeeded in her role, but first came trust.

As I build a new team I know what I need to start with- Trust me.

Isn’t it crazy that we spend about half our day with people but we don’t get to choose them? This article is your chance to find out a little about what working on our team will be like. 

The ideal teammate has good character, smarts, and initiative. We try not to get bogged down if a teammate shows up a little late sometimes or wants to leave early to go to their child’s game. Someone with good character would be courteous, communicate and not let it impact their work.

We try to add small twists to the mundane. When you’re asked if you have read this article, just tell us your favorite candy. Why do we care about your favorite treat? Because it’s the little things that make a work environment more interesting. If your favorite treat is waiting for you on your first day, that will get us started on the right foot.

We believe process and proper design are important. Henry Ford didn’t necessarily invent the best car- he invented the best process: the assembly line. Let’s work together to create the best plan to achieve the best results with the least effort.

We strive to create a culture of learning and hope that working together will be fulfilling. Lesson one: the secret to good communication is to get to the point and move on- Brevity.

Let’s make an impact! Join the team:

Consultants and people with big ideas

Heshy