Productivity

It's About Goals, Not Office Hours

Andres Max

· 14 min read

When was the last time you were productive for 8 hours a day sitting in front of your computer?

Think about it. You can’t remember. I can’t either.

It just doesn’t happen, that’s now how our brains work.

Recently (and to my shock) I found a thread on Reddit about how some IT/Software related companies, are requiring remote work employees to be always-on (some even have to have their webcams on at all times), reporting in 8 hours of full-time work, and some even required to work additional hours because of the WFH flexibility.

Thankfully, this does not describe the majority of the industry. A company could quickly lose all of their team members and find it hard to hire if they have policies like these.

8 hour “clock-in, clock-out” workdays go back to 19th century socialism. And well, this is not the 19th century anymore. Between meetings, emails and Slack interruptions, how many hours are we really productive?

Companies should be thinking about their employees meeting goals, not office hours.

If the company’s goals and project objectives are clear, everyone can align and work at their rhythm while attaining them at a healthy rhythm. I’m talking about asynchronous, non-linear goals. This ties directly into measuring success through North Star metrics rather than time spent.

I live in Colombia, and for over 14 years I’ve worked as a consultant for remote/distributed companies around the world. We’ve met and connected through Skype, Slack, Gmeet, zoom, etc. Then twice a year we’ve met and connected. I’ve made lifelong business partners, mentors, and friends this way.

Of course, this requires the right culture to be in place, one of being dependable a team player, and respecting each other’s focus time. Especially not cramping everyone’s calendar with meetings.

When can you get actual, focused work done if all you ask your team is to be on Zoom meetings all day? One or two should suffice, with the rest being async communications.

Output over time.

We should focus on expertise and contribution, but not buying chair-hours. This outcome-focused mindset is especially critical when building product teams where results matter infinitely more than hours logged.

The Productivity Paradox: Why 8 Hours Doesn’t Mean 8 Hours

Let me share some data that will sound familiar:

A 2020 study by Vouchercloud found that in an 8-hour workday, the average employee is productive for only 2 hours and 53 minutes.

The rest of the time? Here’s where it goes:

Reading news websites: 1 hour 5 minutes
Social media: 44 minutes
Discussing non-work topics with colleagues: 40 minutes
Making hot drinks: 17 minutes
Smoke breaks: 23 minutes
Text/instant messaging: 14 minutes
Eating snacks: 8 minutes
Making food in office: 7 minutes

Now, before you judge: this isn’t laziness. This is how humans work.

Our brains aren’t designed for sustained focus on complex cognitive tasks for 8 straight hours. Study after study shows that:

Deep focus work happens in 90-120 minute cycles
We need breaks to maintain cognitive performance
Context switching from interruptions destroys productivity
Creativity often happens during “downtime”

Yet we’ve structured work around an arbitrary 8-hour day that made sense for factory workers in 1817, not knowledge workers in 2025.

The False Logic of Monitoring Hours

When companies monitor hours instead of outcomes, they’re optimizing for the wrong metric. Here’s what actually happens:

The Time-Tracking Death Spiral

Company implements time tracking to ensure people are “working”
Employees respond by appearing busy rather than being productive
Busy work increases, actual output decreases (more meetings, more status updates, less deep work)
Management sees low results despite “full time” logged and adds more monitoring
Best employees leave for companies that trust them
Remaining employees become increasingly disengaged
Company wonders why productivity is down despite everyone logging 8+ hours

I’ve seen this pattern destroy startups. The irony? The companies obsessed with monitoring hours get the least actual work done.

What You’re Actually Measuring

When you track hours, you’re measuring:

Time in seat (not output)
Ability to look busy (not actual productivity)
Compliance (not creativity or innovation)
Synchronous availability (not async collaboration skills)

What you’re NOT measuring:

Quality of work produced
Business impact of work completed
Customer value created
Problems solved
Innovation generated

One of my client companies tracked developers by lines of code written and hours logged. Their best developer was flagged as “low productivity” because he wrote elegant, simple solutions. Their worst developer looked amazing on paper—1,000 lines of buggy code per week.

They were rewarding the wrong behavior and would have lost their best engineer if I hadn’t intervened.

The Case for Outcome-Based Management

Here’s the alternative: manage outcomes, not hours.

What Outcome-Based Management Looks Like

Instead of: “You need to work 8 hours today” Try: “By Friday, we need the user authentication flow tested and deployed”

Instead of: “Why were you offline from 2-4pm?” Try: “Did you hit your weekly goals? Great. I don’t care when you worked.”

Instead of: “Everyone must be in this 9am standup” Try: “Post your update in Slack by 10am your timezone”

The shift is subtle but transformative. You’re defining success by what gets done, not when or how long it takes.

Real Example: From Time-Tracking to Outcome-Focus

At Ideaware, we made this transition in 2014. Here’s what changed:

Before (Hour-Based):

Required 8-hour workdays
Daily standups at 9am (painful for distributed team)
Time tracking software monitored activity
Developers stressed about taking long lunches or mid-day breaks
Average project completion: 6 weeks
Team satisfaction: 6/10

After (Outcome-Based):

No time tracking
Async updates in Slack (24-hour cycle)
Defined clear sprint goals and deliverables
Developers worked when they were most productive
Average project completion: 4 weeks (33% faster!)
Team satisfaction: 9/10

What explained the improvement?

Developers worked during their peak hours (some people are morning people, some are night owls)
Less context switching from mandatory meetings meant more deep focus time
Trust increased motivation - people wanted to prove they could deliver
Clear goals meant everyone knew what success looked like
Autonomy attracted better talent - A-players don’t want to be micromanaged

How to Implement Outcome-Based Work

Okay, philosophically you’re sold. But how do you actually do this? Here’s the framework I use:

Step 1: Define Clear Objectives and Key Results (OKRs)

You can’t manage outcomes if you haven’t defined what outcomes you want.

Bad objective: “Improve the product” Good objective: “Increase user activation from 40% to 60% by Q2”

Bad key result: “Ship new features” Good key result: “Launch onboarding tutorial that 80% of new users complete”

The more specific, the better. Every team member should be able to answer:

What am I trying to achieve this week/sprint/quarter?
How will we know if I succeeded?
What’s the business impact if I achieve this?

Step 2: Establish Async Communication Norms

If you’re not tracking hours, you need strong async practices:

Daily Updates: Instead of synchronous standups, use async updates in Slack/Notion:

What did you complete yesterday?
What are you working on today?
Any blockers?

Post these by a certain time (e.g., 10am your timezone) so the team has visibility.

Weekly Planning: 30-minute sync meeting (yes, just one!) to:

Review last week’s results
Set this week’s priorities
Unblock anything that needs real-time discussion

Everything else? Async via Slack, Notion, Linear, etc.

Documentation Over Meetings: Default to writing things down:

Product specs in Notion
Design decisions in Figma comments
Code reviews in GitHub
Updates in Slack threads

If someone can read it later instead of being in the meeting, don’t have the meeting.

Step 3: Create Accountability Through Results, Not Surveillance

Instead of monitoring time, track deliverables:

Use Project Management Tools:

Linear, Jira, Asana, or Notion for task tracking
Each task has clear acceptance criteria
Team members update status as they progress
Everyone can see what’s in progress vs. blocked vs. done

Weekly Results Review: Every Friday (or whatever cadence works), review:

What shipped this week?
Did we hit our goals?
If not, what blocked us?
What’s the plan for next week?

Notice: nowhere in this review is “how many hours did you work?”

Step 4: Measure What Matters

Define success metrics for your team’s work:

For Product/Engineering Teams:

Features shipped and adopted
Bug reduction and system stability
User satisfaction scores
Development velocity (story points, not hours)

For Design Teams:

User testing results and iterations
Design system adoption
Reduction in design-to-dev handoff time
User flow completion rates

For Marketing Teams:

Lead generation and conversion
Content engagement metrics
Campaign ROI
Brand awareness indicators

Then review these metrics regularly. Are they improving? If yes, your team is performing. If no, dig into why—but don’t default to “not enough hours worked.”

Step 5: Trust and Verify (But Mostly Trust)

Outcome-based management requires trust. But trust isn’t blind—it’s earned through demonstrated results.

Initial Trust Phase (First 30-60 Days):

Give autonomy but have frequent check-ins
Look for consistent delivery and communication
Identify any issues early

Sustained Trust Phase:

Reduce check-ins as patterns prove reliable
Focus on quarterly/monthly planning rather than weekly
Intervene only when results miss expectations

When Someone Isn’t Delivering: Don’t immediately blame “not working enough hours.” Investigate:

Are goals unclear?
Are they blocked by dependencies?
Do they have the skills needed?
Are they in the wrong role?
Is there a personal situation affecting work?

Often, “low productivity” has nothing to do with hours and everything to do with unclear expectations, poor tooling, or skills mismatches.

Tools and Practices for Async, Outcome-Focused Teams

Here are the tools and practices that make this work:

Communication:

Slack or Discord for async updates and quick questions
Loom for async video explanations (beats synchronous meetings)
Notion or Confluence for documentation and knowledge base
Threads and channels to keep conversations organized

Project Management:

Linear, Jira, or Asana for task tracking
GitHub Projects for engineering teams
Clear task statuses (To Do, In Progress, Blocked, Done)
Sprint planning and retrospectives (can be done async!)

Time Zone Management:

World Clock in Slack or dedicated app to see team timezones
Working hours in calendar/Slack profile so people know when you’re available
2-4 hour overlap for occasional sync meetings

Goal Setting:

OKR tracking in Notion, Lattice, or Perdoo
Quarterly goal setting with weekly progress updates
Public dashboards so everyone sees team progress

Culture and Trust:

Written values that explicitly mention autonomy and trust
Default to async as a core practice, not an exception
Results in reviews, not “time seen online”
Hire for outcomes, screen for self-direction in interviews

Addressing Common Objections

I’ve helped dozens of companies make this transition. Here are the most common pushbacks and my responses:

“But how do I know people are actually working?”

You don’t. And you never did.

Even with butts-in-seats and time tracking, you don’t know if someone is productively working or browsing Reddit. You only know they’re physically present or logged in.

Instead, ask: “Are they delivering results?” If yes, does it matter if they worked 4 hours or 8 hours? If no, is the problem hours worked or something else?

“Our clients expect 9-5 availability”

Two solutions:

Coverage model: Have team overlap hours for client communication, but individuals don’t work 9-5 straight
Expectation setting: Educate clients that async response (within SLA) often produces better results than immediate synchronous response

I’ve found clients actually prefer well-thought-out async responses over rushed “I’m available right now” responses.

“We tried this and people slacked off”

A few possibilities:

Goals weren’t clear enough: If people don’t know what success looks like, they can’t self-manage
Wrong people: Some people need structure and direction; hire for self-direction if you want autonomy
Trust wasn’t real: If you said “outcome-focused” but still checked if people were online, you weren’t actually trusting
No accountability: Outcome-based ≠ no accountability. You still need regular results reviews.

“What about collaboration and teamwork?”

Async doesn’t mean isolated. It means:

Scheduled collaboration time (e.g., weekly planning, design reviews)
Tools for async collaboration (Figma, GitHub, Google Docs with comments)
Cultural norms around responsiveness (e.g., respond to Slack within 4 hours during your workday)

Many teams find they collaborate better this way—less interruption, more thoughtful input.

The Business Case: Why This Makes Financial Sense

Beyond employee happiness, outcome-based management has hard business benefits:

1. Access to Global Talent

When you don’t care about time zones, you can hire the best person anywhere in the world. This:

Increases your talent pool 100x
Reduces salary costs (geographic arbitrage)
Enables 24-hour development cycles (someone is always working)

2. Reduced Real Estate Costs

No need for expensive office space if you’re not tracking office hours. Many companies have:

Eliminated offices entirely (GitLab, Zapier)
Moved to smaller spaces for occasional collaboration
Saved 30-50% on operational costs

3. Higher Employee Retention

Autonomy is one of the top drivers of employee satisfaction. When you trust people:

They stay longer (reducing recruiting costs)
They refer other A-players
They’re more engaged and productive

I’ve seen companies reduce turnover from 30% annually to under 10% with this shift.

4. Actual Productivity Improvements

When people work during their peak hours with minimal interruption:

Developers ship 30-50% more in the same “time”
Quality improves (fewer bugs, better design)
Innovation increases (people have space to think)

At Qrvey, when we shifted to outcome-based management for our product team:

Sprint velocity increased 40%
Bug rates decreased 25%
Employee satisfaction scores went from 7.2 to 9.1
We had zero attrition for 18 months

The business case is overwhelming.

Remote, Hybrid, or Office: This Works Everywhere

You might think this only works for fully remote teams. Not true.

Remote Teams: This is essential. You can’t monitor hours across timezones anyway.

Hybrid Teams: Define core collaboration hours (e.g., 10am-2pm local time) but make everything else flexible.

Office Teams: Even if people come to an office, measure outcomes not presence. Some of my most successful client implementations are office-based companies that stopped caring about 9-5 and started caring about results.

The key shift is mental: from “are you here?” to “did you deliver?”

How to Transition Your Team

If you’re currently hour-based and want to shift, here’s a 90-day transition plan:

Days 1-30: Education and Expectation Setting

Explain the new approach to the team
Define clear OKRs for the quarter
Set up async communication tools and norms
Start with one team/pod as a pilot

Days 31-60: Remove Time Tracking, Add Outcome Tracking

Turn off time tracking software
Implement weekly results reviews
Transition to async updates
Monitor what breaks and fix it

Days 61-90: Refine and Scale

Gather feedback from pilot team
Adjust processes based on what’s working/not working
Roll out to more teams
Document learnings for future teams

The Future of Work Is Outcome-Based

COVID accelerated remote work, but it also revealed something deeper: the old industrial-era model of “clock in, work 8 hours, clock out” was never suited for knowledge work.

The companies winning today are the ones that:

Trust their teams to manage their time
Define clear outcomes and success metrics
Enable async collaboration
Measure results, not hours
Hire self-directed people and empower them

This isn’t just “nice to have” culture fluff. It’s a competitive advantage.

When you let people work when they’re most productive, give them autonomy, and judge them on results:

You attract better talent
You get better work
You build a more sustainable company
You create a culture people don’t want to leave

Output over time.

We should focus on expertise and contribution, but not buying chair-hours.

Because at the end of the day, no customer cares how many hours your team worked. They care if you solved their problem. That’s the only metric that actually matters.

Frequently Asked Questions

How do I know if someone is actually working if I don’t track hours?

You don’t. But you never did, even with time tracking. Someone can be “online” for 8 hours and accomplish nothing. Instead, track deliverables and results. Set clear weekly goals, review what shipped, and measure business impact. If someone consistently hits goals, they’re working. If they don’t, investigate why—it’s rarely about hours.

What if my team takes advantage of flexible hours and doesn’t work enough?

This usually means one of three things: (1) Goals aren’t clear enough, (2) You hired the wrong people who need micromanagement, or (3) Trust wasn’t real and you’re still checking if people are online. Set clear expectations, hire self-directed people, and measure results weekly. If someone can’t deliver without supervision, they’re not a good fit for outcome-based work.

How do I transition from time-tracking to outcome-based management?

Start with a 90-day pilot: (1) Define clear OKRs and weekly goals, (2) Turn off time tracking software, (3) Implement async daily updates, (4) Hold weekly results reviews. Start with one team first. After 30 days, gather feedback and adjust. If results improve or stay the same with higher satisfaction, roll out to more teams.

What metrics should I track instead of hours worked?

For product teams: features shipped and adopted, sprint velocity, bug rates, user satisfaction. For design teams: design iterations, user testing results, time-to-handoff. For marketing: leads generated, conversion rates, campaign ROI. The key is measuring output and business impact, not input (time). Every role should have 2-3 clear metrics tied to business outcomes.

Does outcome-based management work for junior employees who need more guidance?

Yes, but they need more structure. Junior employees should have: (1) Very clear daily/weekly goals, (2) More frequent check-ins (daily vs weekly), (3) Pairing with senior team members, (4) Explicit expectations about what good work looks like. As they demonstrate consistency, reduce oversight. Outcome-based doesn’t mean zero guidance—it means measuring results, not hours.