how we work

Author: Ivan Kovpak, CEO & Co-founder

Most remote companies are remote by accident. They hired someone in a different city, then another, and suddenly they're "distributed."

We're remote by design. Not because it's a perk. Because it's the only way to build what we're building.

Remote-first is a diversity requirement, not a benefit

Here's something most companies miss: you can't actually build a diverse team without being remote-first.

If you're hiring in San Francisco, your talent pool is San Francisco. That's 1 timezone, 1 dominant culture, 1 cost of living, 1 set of perspectives.

We operate across 12+ timezones. North and South America. Europe. Asia. Different cultures, different languages, different lived experiences.

This isn't about checking diversity boxes. It's about accessing perspectives we'd never find in a single geography.

When someone from Eastern Europe suggests a GTM tactic that worked in their market, it's often invisible to someone who's only worked in the US. When someone from South America points out a cultural nuance in messaging, it changes how we communicate globally.

Remote-first doesn't guarantee diversity. But diversity is impossible without it.

The trade-off? Coordination gets harder. You can't just walk to someone's desk. You can't do daily standups when half the team is asleep.

So we built systems that work async. Not as a compromise - as the default.

Small teams that own outcomes, not products

We structure work around small teams - 2 to 4 people maximum.

It starts with 2. One person working alone hits walls. Two people solve problems faster, catch each other's mistakes, compound learning.

As work scales, the team grows to 3, sometimes 4. The moment you add that third person, something shifts - a leader emerges. Not because we assigned the role, but because 3 people need coordination that 2 don't.

We don't force leadership. We watch who steps up.

These small teams own outcomes, not products. We have 1 product - Unstuck Engine. But we have multiple outcomes: outbound campaigns that convert, demos that educate, onboarding that activates, content that teaches.

Each small team owns 1 outcome fully. They decide what to build, how to build it, when to ship it. No approvals needed beyond the team itself.

Why small teams?

Speed. A 2-person team ships faster than a 10-person team because there's no coordination overhead. No alignment meetings. No waiting for consensus. Just build and ship.

Ownership. When 2-4 people own an outcome, responsibility is clear. There's nowhere to hide. If it fails, the team knows. If it succeeds, the team celebrates.

Minimal hierarchy. Small teams create flat structure. You don't need managers when teams are self-sufficient. You don't need approval chains when teams own decisions.

We keep executive leadership deliberately small. Their job: set direction, decide which products to build, make key people decisions, ensure cross-team initiatives run smoothly.

For everything else, small teams operate autonomously. If you need something from another team, you talk to them directly. You don't go up the chain to leadership, then down to the other team. You just talk to the team.

90% of the time this works perfectly. 10% of the time it creates minor confusion when priorities don't align. We'll take that trade-off.

Linear as operating system

Everything runs through Linear. Not because we love project management tools, but because Linear enforces the thinking we want.

We organize work across 3 strategic initiatives:

1. Product-Market Fit (PMF)
Are we building what the market needs? Discovery, validation, proving value through customer activation, retention, conversion.

2. GTM Excellence
Can we sell and communicate this effectively? Scaling demand through channels, messaging, distribution systems.

3. Operational Scale
Can we do this systematically, not heroically? Building infrastructure, processes, automation for sustainable growth.

Every project maps to 1 of these 3 initiatives. Every task maps to a project. Teams work on projects. This creates clarity - you always know which strategic objective your work serves.

Within projects, we have 2 types of tasks: Bounty and Standard.

Bounty tasks are experiments. We don't know if this will work. We're placing a bet. Speed matters more than perfection. Fail fast, learn faster.

In agile terms, Bounties get the big Fibonacci numbers - 8, 13, 21. Because they're uncertain, complex, exploratory.

Standard tasks are proven processes. Someone already figured this out. Now we're executing at scale using a template.

Standards get small numbers - 1, 2, 3. Because the path is clear.

The distinction matters because expectations are different.

Standard task fails? Something went wrong - either the template was bad or execution was off. Fix it.

Bounty task fails? That's fine - as long as we learned something and documented it.

The lifecycle: Bounty (experiment) → Standard (proven process).

When a Bounty succeeds, we don't just celebrate. We extract the learning and convert it into a Standard task template. Now anyone can execute it without reinventing.

This is where Strategic Leverage comes in.

After completing significant work - a demo, a campaign, a feature - we create a Strategic Leverage Review. It's a template that forces us to ask: "What compound value can we extract from this?"

Not all leverage opportunities get executed. That's the point. We identify them, then choose which ones create the most value.

Example: We build an interactive demo for Unstuck Engine. Strategic Leverage Review asks:

Can we turn this into a YouTube tutorial?

Can we extract the demo script into handbook documentation?

Can we use screenshots for social media content?

Can we repurpose the demo flow for onboarding emails?

Some of those make sense. Some don't. But we don't leave value on the table by accident - we consciously choose what to pursue.

This compounds. Every piece of work becomes a foundation for future work. Nothing is single-use.

Async > Sync

We don't do daily standups. Can't - half the team is asleep when the other half is working.

Instead: Standupbot.

Every day, team members post async updates in Slack:

What I did yesterday

What I'm doing today

Any blockers

Everyone sees what everyone else is working on. If there's overlap, people coordinate directly. If someone's blocked, others jump in. If someone's going dark on priorities, it's visible immediately.

This gives us transparency without synchronous overhead. People post when convenient for their timezone. People read when convenient for theirs.

Same logic for most communication. We bias toward async.

Loom for anything that needs visual explanation. Record a 3-minute video walking through the problem instead of scheduling a 30-minute call.

Slack threads for discussions that need context. DMs for quick questions. Channels for transparency.

Google Docs for collaborative writing and strategy documents. Real-time collaboration when timezones overlap, async comments when they don't.

Linear for execution. Every task, every experiment, every template lives there.

Gmail and Google Calendar for external communication and scheduling. Meet for the rare synchronous calls we actually need.

The rule: don't ping people at 2am their time unless it's actually urgent. Urgent means "the product is down" or "we're losing a customer." It doesn't mean "I need this answer today."

Async doesn't mean slow. It means respectful of time and timezone.

Meetings that actually matter

We have 2 recurring meetings. That's it.

Tuesday 9am PST: Full team meeting.

The whole team. Every week. This time isn't perfect for anyone - Europe joins late, Asia joins very late - but it's tolerable for everyone.

Here's what makes it work: rotating moderators.

Every week, a different team member moderates. Not leadership. A regular team member.

This does something unexpected: it reveals different leadership styles.

Some moderators are energizers - they get people excited, they create momentum. Some are structural thinkers - they organize discussions clearly, they keep time tight. Some are supportive facilitators - they make sure quiet people speak, they create psychological safety.

All 3 styles are valuable. By rotating, everyone discovers their leadership type. And the team sees each other in new ways.

What we DON'T do in Tuesday meetings:

Status updates (that's what Standupbot is for)

Tactical planning (that happens in Linear)

Approvals (teams make their own decisions)

What we DO:

Share context about what's happening in the market

Debate strategic priorities

Align on what success looks like this month

Surface blockers that affect multiple teams

Then people go execute independently.

Thursday: 1:1s with leadership.

Every Thursday, leadership meets with team members. Not just direct reports - everyone.

These aren't performance reviews. They're not status updates. They're context exchanges.

Leadership shares: "Here's what I'm seeing in the business. Here's why we made this decision. Here's what I need from your function."

Team member shares: "Here's what I'm stuck on. Here's where I need help. Here's what I think we're doing wrong."

It goes both ways. If someone thinks a leadership decision is wrong, they say it. If leadership thinks someone's approach is flawed, they say it.

This only works because Total Feedback is cultural norm. If people are afraid to criticize leadership, 1:1s become performative.

Tools you earn, not inherit

Not everyone gets every tool on day 1.

Tier 1 (everyone, immediately): Slack, Linear, Gmail, Google Calendar, Google Docs

Tier 2 (earned after demonstrating need): Claude.ai (after hitting usage limits for 2 days), Google Meet recording

Tier 3 (role-specific): Prosp.ai and Supergrow (outbound only), analytics tools (data only)

Why tier it?

Because Freedom & Responsibility means you earn tools by demonstrating you'll use them well.

Claude.ai costs money. It's also powerful and easy to misuse. If someone's using it to write generic LinkedIn posts, they're wasting money and not learning.

So we start everyone with basic tools. When they hit the ceiling - "I need Claude because I'm processing 50 pages of competitor documentation for analysis" - we grant access.

This isn't about being cheap. It's about ensuring people understand why they need a tool before they have it.

Documentation or it didn't happen

If it's not written down, it doesn't exist.

Linear for tasks and execution. Every experiment, every template, every outcome.

Google Docs for strategy and documentation. Why we're doing this, how we think about it, what we've learned.

Handbook for principles and culture. Lives publicly on our website. Everything from why we exist to how we hire.

Slack for communication. But important decisions get moved to Linear or Docs. Slack is ephemeral - if it matters, document it permanently.

This creates a compound effect: new people ramp faster because they can read instead of ask. Veteran people don't become bottlenecks because knowledge isn't locked in their heads.

When someone joins, they don't need to schedule 10 "pick your brain" calls. They read the handbook, watch the Loom videos, review the Linear templates, and start executing.

Questions still happen. But they're higher-level questions, not "how do I do this basic thing."

Sales-Assisted PLG in practice

Our GTM is Sales-Assisted Product-Led Growth.

Here's how it works:

7-day free trial, no credit card required. Sign up, configure ICPs, start seeing results in 15 minutes.

$25/month entry point after trial. No sales call required. No demo request. No qualification. Just activate and pay.

Product educates. The interface teaches you how multi-dimensional scoring works. The interactive demo shows you functionality before you commit. The help center answers questions before you ask them.

Sales enters when you're ready. By the time someone needs enterprise features ($12K+/year), they've been using the product for months. They know it works. Sales conversations aren't pitches - they're negotiations about volume discounts, custom SLAs, dedicated support.

We do run outbound. But it's not spray-and-pray.

We use our own product to score prospects. High ICP fit + right persona + meaningful signal = outreach. Everyone else gets nurtured or ignored.

The result? 40% reply rate on cold outreach. Not because our copy is magic. Because we only reach out to people who actually fit.

First 2 weeks: real work immediately

New hires get real work on day 1.

Day 1: Tool access, read the handbook, watch onboarding Loom videos.

Day 2-3: Join a small team, start contributing to actual work. Not training exercises. Real impact.

You might pair with someone experienced. You might pair with someone who joined 2 days before you - we've hired 2 recruiters with a 2-day gap. What matters isn't tenure, it's collaboration.

Week 1: Execute first real task.

Week 2: Run first small experiment independently.

We don't do training wheels. We do scaffolding.

Work alongside someone. See how decisions get made, how problems get solved, how we actually operate. Questions get answered in real-time: "Why did you choose that approach?" "What are we optimizing for here?" "How do you know when this is done?"

By week 3, the new person is operating semi-independently. By week 6, fully independently.

This only works because of comprehensive documentation and small team ownership. The new person isn't figuring everything out alone. They're operating in a system with clear context and tight feedback loops.

What we're building toward

We don't have sprint planning yet. Not because we're against it - we just don't have enough data to plan sprints effectively.

As teams mature and work becomes more predictable, we'll introduce sprint planning where it makes sense. Not simultaneously across the whole company. Where teams are ready.

Same with other agile practices. We're not ideologically opposed. We're just recognizing where we are: early-stage, high-uncertainty, rapid iteration.

Bounty tasks dominate right now. Over time, more work converts to Standard. When that happens, sprint planning creates value. Until then, it's overhead.

Why this all works together

You can't copy individual pieces of this and expect results.

Async communication only works when you have comprehensive documentation. Otherwise people are constantly blocked waiting for answers.

Small teams only work when you have minimal hierarchy. Otherwise they're waiting for approval.

Bounty → Standard only works when you have Total Feedback. Otherwise people hide failed experiments instead of learning from them.

Remote-first only works when you have strong async systems. Otherwise coordination overhead kills speed.

Sales-Assisted PLG only works when your product actually educates. Otherwise you need heavy sales involvement.

The 3 strategic initiatives (PMF, GTM Excellence, Operational Scale) only work when teams understand which one their work serves. Otherwise prioritization is arbitrary.

It's a system. Every piece reinforces every other piece.

That's why culture shapes operations. The 9 principles aren't separate from how we work. They are how we work.

Remove the principles and the operations fall apart. Remove the operations and the principles become empty slogans.

They only work together.

Next: Building a diverse team - How we hire for learning velocity, why interns matter, and what the first 90 days actually look like.

Foundation: Our culture: The real engine - The 9 principles that make these operations possible.

See it applied: How culture shapes everything - How principles become product, GTM, and daily decisions.