Close the Office

The communication problems in a hybrid setup are not always obvious because they are structural, not personal. No individual is doing anything wrong. The structure itself creates the gaps.

What in-office communication does to remote team members

In-office conversations - in the kitchen, at someone's desk, in the hallway - contain decisions, context, and updates that remote team members never receive. A quick conversation between two developers in the office can change the direction of a ticket.

A manager mentioning something during lunch becomes the unofficial brief for a feature, and none of that gets documented because it did not feel like a meeting.

Remote team members are left with incomplete information and no way to know what they missed.

What happens to the team culture

In-office employees assumed remote employees had less visibility and sometimes resented them for it. Remote employees assumed in-office employees had more access to decisions and sometimes felt excluded. Both groups were partly right because neither could actually see the full picture.

When I transitioned to fully remote, I pushed one rule immediately: all work communication happens in public Slack channels, not private DMs (this was not immediately adopted of course).

Team members were used to resolving things quietly… and that habit had to be broken deliberately.

The fix for the communication problem was not better tools - it was removing the situation that created invisible conversations in the first place.

When I decided to close the OmniStreak office, I did not announce it on a Monday and hand people boxes on Friday. The transition had two steps and took several weeks.

Step 1: Communicate the plan in advance

I told the team we were planning to go fully remote, and why. Not a consultation - a clear direction, explained honestly. Several weeks before the switch, not the week of.

Step 2: Run test days before committing

Before the full switch, team members worked from home on Thursdays and Fridays while the office was still available. This was not optional - it was how the team operated during that period.

By the time we made the switch permanent, in-office team members had been working remotely for two days a week for several weeks. The adjustment was much smaller than it would have been without that preparation.

What this approach does: it removes the shock of the change by making remote work a practiced reality before it becomes the only option.

• People know what their home setup needs.
• They have experienced the standup bot, the Slack channels, the ticket workflow.
• The switch from partial to full is much less disruptive than switching cold from office to remote.

Two things made the transition hold after it happened:

First, maintaining communication discipline without crossing into micromanagement - this is the ongoing challenge of remote, not the transition itself.

Second, centralizing everything in Slack and Google Meet so there was one place for all team communication.

The transition is not the hard part. The operating model that runs after it is.

Going fully remote does not solve everything... it removes one layer of complexity and replaces it with a different set of requirements.

From my experience, going fully remote solves:

• One onboarding process instead of two
• One contract structure instead of split contracts by worker type
• No office compliance overhead - rest areas, fire safety, infrastructure
• No gas reimbursements, no late arrivals from commutes
• No bandwidth degrading as headcount grows
• No power outages affecting in-office capacity

When I sold the office equipment and cancelled the lease, that operational overhead disappeared immediately. That freed up attention for what actually matters: the quality of the work, the reliability of the team, the consistency of delivery.

What going fully remote does not solve:

• Visibility into what the team is working on
• Accountability when someone goes quiet
• Communication discipline
• Capacity planning

These problems do not come from having an office. They come from not having the right systems.

A remote team without a structured standup, without public channels, without ticket status automation has every problem a hybrid team has - plus none of the in-person context that sometimes compensates.

In an office, you get some visibility for free because you can see people working. Remotely, visibility has to be built deliberately. That is not harder - it is different. And once it is built, it is more reliable than proximity-based visibility because it is documented and consistent rather than dependent on who happened to be in the room.

What I built at OmniStreak after going remote was not a replacement for the office.

It was an operating model that never needed one. Each stage of this course covers one of the systems that makes that possible.

Most standups produce noise. The question is whether yours produces signal.

At OmniStreak, the daily standup runs through a Slack bot. Every morning it pings each team member with two questions: what did you work on yesterday, and what are you working on today. The response goes into a shared channel the whole team can see.

What a good standup response looks like:

• Previous workday: one sentence or a list of Jira task references
• Plans for today: one sentence or a list of Jira task references
• Blockers: specific description, or none

It is specific, traceable and takes about two minutes to write.

What a bad standup response looks like:

• No response at all
• "Working on my tickets"
• "Same as yesterday"
• Vague language with no task references

That response tells you nothing, basically it's like the written equivalent of a blank stare.

The distinction matters because the standup is not "status theater". It is the primary mechanism for early-signal visibility on the team. A developer who has been writing good standups for two weeks and then suddenly writes nothing useful is flagging something - a blocker, a motivation issue, a personal problem.

That signal needs to be caught the same day, not at the end of the sprint when the missed work is already a problem.

The protocol at OmniStreak: a bad standup response is flagged the same day to the operations manager, who pings the team member privately. Not in public. Not in a group setting. A private check-in, the same day, every time.

Before I introduced structured question windows at OmniStreak, the lead developer was being interrupted throughout the day. Developers would message him directly whenever something came up. He would stop what he was doing to respond. Then the next developer would do the same thing an hour later.

The result was predictable:

• The lead developer's own work moved slowly
• Questions got different response times depending on when they landed
• The same question was answered multiple times in private DMs nobody else could read
• Blockers surfaced ad hoc with no structured resolution process

The fix

I defined a time window - for example, 9am to 11am - where developers post technical questions to the lead developer in a shared Slack channel. One window, one channel, visible to everyone.

Outside that window, developers keep working on what they can move forward on, document their blockers, and bring them to the question window.

Production blockers that cannot wait are handled separately - but a clarifying question about a ticket specification is not a production blocker.

What this achieves:

• The lead developer has protected time outside the window for focused work
• During the window, they batch responses instead of context-switching continuously
• Answers land in a public channel every developer can read - the same question never needs to be asked twice
• Developers prepare better questions because they know they are going into a public channel at a set time

The default at OmniStreak is async. A meeting is not scheduled unless something cannot be resolved by written communication in a reasonable time.

This is not a philosophical position about meetings... it is a practical decision about where attention goes. Every meeting on a remote team requires everyone in it to stop what they are doing, shift context, and participate in real time.

When a call is worth scheduling:

• Alignment on something complex where written communication has already stalled
• Feedback conversations involving tone or nuance that text handles poorly
• Escalations where a decision needs to be made in real time

When async is the right answer:

• Status updates
• Blockers that can wait for the question window
• Decisions where one person can make the call and document it
• Information that needs to reach the whole team at once

The meetings at OmniStreak are structured and recurring: a daily standup through Slack (async, not a call), a Friday engineering review with me and managers, a Monday HR call. Each has a defined purpose and a defined audience. None exist to share information that could be shared in writing.

The failure mode I see most often in remote teams is meetings scheduled as a substitute for the written communication discipline that async requires. If your team cannot communicate clearly in writing, adding more calls does not fix the problem. It defers it.

Before I set up Jira automation at OmniStreak, tracking ticket status was a manual process. Managers would ping developers on Slack or ask in standup: what is the status of this ticket, is it in QA, has it been tested?

The developers were not being deliberately unhelpful… they were focused on the work and the status update felt like overhead.

The result of that was that the ticket board was always partially out of date, which meant planning was always working from incomplete information.

Two changes made the difference:

1. A bot pings the assigned developer when their ticket status needs to be updated. It is not a manager chasing them - it is a system prompt that keeps the board current without anyone having to remember to ask.
2. Guardrails prevent moving a ticket to "Ready for QA" - which auto-notifies the QA team - unless the developer has tested it themselves first. This eliminated a whole category of problem where half-finished work landed with QA, who then sent it back, creating rework and frustration on both sides.

The ticket status flow at OmniStreak:

In Progress → Ready for QA → Stakeholder QA → Prepared for RC → Published to Production

Each transition has defined criteria. The guardrail on "Ready for QA" is the most important - it is the gate that enforces quality before the next person's time is spent on the work.

One important note: Even after the automation was in place, manual follow-up was needed for the first few weeks. Automation changes the system. It does not immediately change the habit.

The combination of the bot prompt and a manager reinforcing the expectation in the first weeks was what made the behavior stick.

At OmniStreak, every team member sets their own delivery ETA for each assigned task. This is a deliberate choice and it proved (in practice) that the accountability dynamic changed completely.

Why self-set ETAs work

When I set the deadline and it is missed, the conversation is about why someone did not meet my expectation. That conversation often goes in circles.

When the developer sets the deadline and misses it, the conversation starts differently:

• What did you estimate?
• What did you actually find when you started the work?
• What do we need to adjust for next time?

That conversation produces useful information - about scoping, about complexity, about dependencies that were not visible upfront.

What self-set ETAs reveal

A developer who consistently sets deadlines they cannot meet is not unreliable - they are bad at scoping. That is a skill gap with a specific fix. You cannot identify it if you are setting the deadlines yourself.

The discipline required to make this work:

• ETAs must be set before work starts, not after
• "End of sprint" is not an ETA - it is a deferral. The ETA should be a specific day
• When an ETA is missed, it is addressed the same day - not at the end of the sprint, not in the retrospective

The standup and the ticket board make missed ETAs visible in real time. That visibility only matters if something is done with it promptly.

In a remote team, silence is always a signal. The question is what kind. At OmniStreak, silence shows up in three forms - and each means something different.

Silence type 1: Missing standup response

A developer who has been writing consistent standups for weeks and then goes quiet has flagged something - a blocker, a personal situation, disengagement, or something in between. This gets addressed the same day. The operations manager sends a private message that day - not at the next standup, not at the end of the week.

Silence type 2: A ticket that stops moving

A task in "In Progress" for three days with no status update and no question in the question window means the developer is either stuck and not saying so, or the task has been deprioritized for a reason nobody knows about. Both need to surface before the sprint ends.

Silence type 3: Minimal participation

A developer who participates but only minimally - one-word standup answers, tickets updated only when prompted, no questions in the question window - is harder to detect than outright silence but equally telling. It often precedes either a request to leave or a drop in quality.

How to respond to silence

The response is not confrontation and it is not surveillance. It is a private, direct conversation: something seems different lately, is everything okay, is there anything blocking your work?

Most of the time, the answer is either a practical problem that can be solved - unclear requirements, a dependency they were waiting on - or a personal situation where acknowledging it and adjusting temporarily is the right call.

The goal is not to catch people doing something wrong. It is to catch problems early enough that they are still solvable.

Every new hire at OmniStreak goes through a 10-day paid trial on a fixed sum, working on a real task/project.

The creation of this trial process was triggered because of a specific experience: a remote hire who was not a fit refused to return a laptop until paid out (in hindsight this was a process error on our end). The resolution took more than 20 emails. The lesson was not about that individual - it was about the structure.

Evaluating fit before any equipment investment, before any onboarding commitment, before any longer-term arrangement is the only model that protects both parties.

What the 10 days actually evaluates:

Signal 1: Local environment setup

This is not a technical test. It is a signal about self-direction. Someone who works through it methodically, asks specific questions when stuck, and gets it running within a reasonable time is operating like a professional. Someone who waits for hand-holding at every step is not.

Signal 2: Questions before starting work

The instinct to start immediately - before fully understanding the requirements - is the most common source of rework in engineering. A developer who reads a ticket, identifies what they do not understand, and asks about it before writing a single line of code will waste less of everyone's time.

Signal 3: Communication behavior on Slack

Silence is the biggest flag. A developer who is not sure what to do and says nothing is a liability on a remote team. The right behavior is to surface uncertainty - in the question channel, in the standup, in a message to the relevant person. The wrong behavior is to go quiet and hope the problem resolves itself.

Technical ability is necessary. It is not sufficient, and from my experience it is not what "breaks" most remote hires.

The failures I have seen - and the patterns visible across agencies using remote contractors - almost always trace back to communication, not code quality:

• The developer who goes quiet for three days when blocked
• The person who submits work that fails QA and does not explain what they tested
• The hire who answers standup questions with one-word responses and never surfaces a blocker until it has already missed a deadline
• The contractor who works for two weeks, delivers tickets, and then disappears when a client question needs answering

None of those failures are technical. All of them are communication.

This is why the 10-day trial is evaluated primarily on communication behavior, not on code quality alone. I can review code and identify whether it is good. I can also see when a developer tests their own work before submitting, when they ask questions before getting stuck, when they update their ticket status without being prompted.

Those behaviors are the actual job in a remote engineering team. Writing good code is part of the job. But a developer who writes good code and communicates poorly in a remote context creates more problems than a slightly weaker developer who communicates well.

The screening sequence that works:

1. Application form filters for communication quality first
2. Trial confirms the behavior under real work conditions
3. Technical depth is assessed across the full month that follows

By the time you are assessing technical fit in depth, you should already have confirmed the person can communicate in the way your team operates.

At day 10, the decision is binary: end the engagement or proceed. There is no extending the trial indefinitely.

End the engagement if:

• The developer went silent on Slack more than once without explanation
• They failed to ask questions before getting stuck, consistently
• Standup responses were vague or missing on more than two occasions
• Work was submitted without testing
• They showed no initiative in setting up their environment

Extending a trial for someone who has not shown the right behaviors in 10 days usually produces 20 days of the same behaviors, followed by the same outcome.

Proceed if:

• Standup responses were consistent and specific
• Questions were asked before starting work, not after getting stuck
• Ticket statuses were being updated without prompting by day five or six
• When feedback was given, they corrected quickly and asked what to watch for

The month that follows

Proceeding does not mean committing. It means moving to the next stage: one full month of collaboration covering two complete sprints.

The sprint cadence over that month is where real assessment happens. Is the developer estimating accurately? Are their standups consistent? Are they asking fewer process questions as they settle in - without going quiet on blockers?

Two full sprints also reveal how a developer responds to feedback. Everyone makes mistakes in a new environment.

What distinguishes someone who will work well long-term is how they respond when their work is returned by QA. A defensive response is a signal. A quick correction and a question about what to watch for next time is a green flag.

Missed delivery timelines usually have one of three causes: the work was scoped incorrectly, something unexpected blocked progress, or the team did not have the capacity that was assumed. The first two are engineering problems. The third is a planning problem - and it is the most preventable.

The three inputs to capacity planning at OmniStreak:

1. Story point targets per team member per sprint - this is the baseline for what each person can deliver in a two-week window under normal conditions
2. The monthly PTO declaration - entered by the 5th of each month, factored into the capacity calculation before any client commitments are made
3. The Monday HR call - where the operations manager flags any team members at reduced capacity for personal or health reasons that would not appear on the PTO calendar

Together, these three inputs give me a real number for available delivery capacity each month - not a headcount-based estimate, but an actual hours-available figure.

How this changes client conversations

When we are discussing a start date with a client, I am working from that real number - not from optimism. It is tempting to say yes to a start date because the client wants it or because saying no feels like losing the work.

The capacity model creates a factual basis for those conversations instead.

A client who is given an accurate start date and hits it trusts your agency more than a client who is given an optimistic start date and waits. Predictability is the product, not just the code.

Numbers tell you what has happened. The Monday HR call tells me what is about to happen. Every Monday morning, I have a 20-minute call with the operations manager. The agenda is the same each week:

• How is the team doing generally?
• Are people following processes?
• Any team members who have asked about a pay rise recently - and is there a viable reason?
• Who are the top performers this week?
• Who showed self-initiative last week?

Why the last question matters most

In a remote team, self-initiative is one of the clearest leading indicators of an engaged, growing team member versus one who is going through the motions.

A developer who flagged a risk before it became a problem, improved documentation on their own, or suggested a process change is someone to develop.

A developer producing the minimum required for several weeks running is someone to pay attention to.

What the call catches that the numbers miss:

• A team member dealing with something personal that will affect capacity before it shows in sprint delivery
• A tension between two people playing out in ticket comments
• A pattern of behavior the operations manager has been watching but has not yet escalated
• Early signals of someone considering leaving

These conversations are not investigations. They are pulse checks. The goal is not to catch problems but to hear about them before they compound.

The capacity model handles the numbers. The Monday call handles the context the numbers cannot capture.

At OmniStreak, the same four levels apply across every department - Engineering, Operations, Project Delivery, Business Development, and QA. One framework, consistently applied, regardless of what someone does.

The four levels:

Delivery: You reliably execute assigned work. You are focused on building skills, collaborating with your team, and contributing to outcomes.

• Core question: Can I be counted on to deliver what I am asked to deliver?

Ownership: You own features, projects, or processes end-to-end. You anticipate risks, manage dependencies, and ensure delivery succeeds without needing constant direction.

• Core question: Can I take something from start to done without being managed through it?

Strategy: You guide initiatives across teams. You align work with business goals, coach others, and improve how the organization delivers.

• Core question: Am I making the people and processes around me more effective?

Vision: You define long-term direction in your area of expertise. You act as a trusted partner to leadership, represent the organization externally, and shape how it grows.

• Core question: Am I building something that outlasts my direct involvement?

Why this framework works across all roles

The levels are descriptions of how someone operates - not rungs on a ladder you climb by waiting long enough. Progression is based on demonstrated readiness: consistently operating at the next level before being recognized for it.

This gives team members a clear picture of what growth looks like without requiring a different answer for every role. It also creates a shared language for performance conversations across the whole agency.

At OmniStreak, salary is independent of level. The two operate on separate tracks.

The pay structure:

Pay increases on a transparent, predictable cycle: 5% every six months, conditional on:

• Demonstrated reliability in delivery
• Consistent communication quality
• Openness to new technologies and self-improvement

The criteria are known and the cadence is known.

What level brings instead of pay:

• Ownership of larger and more complex initiatives
• Opportunity to mentor and lead
• More influence over product, technical, or business direction
• Greater scope of responsibility and visibility

Why the separation works

It removes the incentive to chase titles for financial reasons. If level does not drive pay, the only reason to pursue a higher level is because you want the expanded responsibility that comes with it. That filters for the right motivation.

It also removes ambiguity from pay conversations. Team members do not need to campaign for a raise, time a conversation correctly, or worry about whether they are being paid fairly relative to someone with a different title. The cycle is transparent and the process is predictable.

When I first introduced the conditional 5% increase, some team members assumed it was automatic.

They were surprised to learn criteria were attached. My response was direct: the criteria are reliability, communication, and willingness to grow. If someone is not meeting those, a pay increase would send the wrong signal about what the agency values.

The criteria exist because the increase should mean something.

The most important principle in the OmniStreak career framework is this: progression is not automatic. It is based on consistently operating at the next level before being recognized for it.

That distinction matters. Most career ladders reward time served:

• Stay long enough
• Do your job adequately
• Get the next title

The problem is that this creates an expectation of progression as a default - and makes it feel like a demotion when it does not happen on schedule, even if the person is not ready.

Demonstrated readiness works differently

The question is not "have you been here long enough?" The question is "are you already doing what the next level requires?"

If a developer is consistently taking ownership of complete features without needing direction, proactively identifying risks, and supporting their teammates - then recognizing that level is acknowledging what is already true.

An honest note on where OmniStreak is with this

The framework exists and the team understands it. The formal process for who makes the progression call and exactly how it is evaluated is still being developed - there is no dedicated HR team member to own it, and the review cadence is not yet systematized. I am documenting that as a gap rather than presenting it as solved.

What is working: the team has a shared language for growth conversations, the title-for-pay dynamic has been removed, and progression is understood to be based on impact rather than tenure.

What the progression conversation looks like in practice:

• What has this person delivered in the last quarter?
• Are they operating with the independence the next level requires?
• Are they actively developing the skills associated with it?
• Can you point to specific examples of next-level behavior - not impressions?

Evidence is what makes a progression conversation productive. Without it, the conversation defaults to impressions, tenure, and comparison - exactly what the framework is designed to avoid.