Edmonton Founders: Stop Hiring Local, Start Building Across Timezones

I remember a founder in Edmonton, let's call him "Mark," telling me he was struggling to find senior backend engineers. He'd spent months interviewing locally, burning through thousands in recruitment fees, and still felt like he was settling. The irony? He was sitting on a goldmine of talent just a few flights (or a VPN connection) away.

Why this matters in 2026

Edmonton's tech scene is growing, but the demand for experienced engineers, especially in specialized fields, often outstrips local supply. Founders trying to build complex products like SaaS platforms or AI-driven applications face a bottleneck. The global talent pool isn't just an option anymore; for many, it's the only realistic path to building a strong, competitive engineering team.

Three things I learned shipping this

1. Timezones are a Feature, Not a Bug (When You Plan For It)

When we were rebuilding Tokkatok's V2, we had a core team in Manila and a product lead in Canada. My initial thought was, "This is going to be a nightmare for communication." I was wrong. We structured our sprints so that the Manila team would finish their work day, push code, and the Canadian team would pick it up first thing in their morning. Code reviews happened overnight for one team and during their day for the other. It wasn't about synchronous meetings; it was about asynchronous handoffs and clear documentation.

We used Jira religiously, not for the sake of it, but to ensure every task had a clear description, acceptance criteria, and any necessary context. When a developer in Manila would push a feature, they'd leave detailed notes for the Canadian team about what to test and what to look for. This forced clarity reduced bugs and sped up our release cycles. We shipped the entire V2 rebuild in 8 months, a feat that would have taken us longer with a purely co-located team due to scheduling meetings and the inevitable "quick chat" that turns into an hour.

Here's a snippet of how we’d structure a ticket for that handoff:

// In Jira ticket description
/*
 * Feature: User Profile Update API Endpoint
 *
 * Status: Ready for QA/Review by Canadian Team
 *
 * Description:
 * Implemented PUT /api/v2/users/{userId}/profile endpoint.
 * Handles validation for email, name, and bio fields.
 * Includes error handling for invalid input and non-existent user.
 *
 * Code changes:
 * - src/api/users/profile.js
 * - src/services/userProfileService.js
 *
 * Testing Notes:
 * - Test with valid data.
 * - Test with invalid email format.
 * - Test updating a non-existent user ID.
 * - Ensure response codes are correct (200, 400, 404).
 *
 * Next Steps:
 * - Awaiting review and deployment to staging.
 */

2. Invest in Asynchronous Communication Tools (and Train Your Team)

This is where most companies trip up. They hire across timezones and then expect everyone to be in Slack at the same time, or to jump on a Zoom call on short notice. That's a recipe for burnout and resentment. For LaundryIT, our remote team was split between the Philippines and Australia. We learned to rely heavily on tools that supported asynchronous work.

We used Loom extensively for demos and explanations. Instead of typing out a lengthy email about a bug, a developer would record a quick 2-minute video showing the issue and narrating their thought process. This was far more effective and saved countless hours. For documentation, Confluence was our go-to, but the key was making it a habit for everyone to update it. If you fix a bug, document the fix. If you implement a feature, document how it works. This created a living knowledge base that reduced reliance on synchronous Q&A.

We also implemented a "no meeting before 10 AM and after 4 PM" policy for our core overlap hours, which was usually 2-3 hours. This gave people their mornings and evenings back. The result? Higher morale and more focused work. We shipped LaundryIT, a complex inventory and logistics system for laundromats, in 10 months, and the remote team was crucial to that speed.

3. Embrace the "Follow the Sun" Model for Support and Ops

When I was leading the engineering for EngagePOS, a point-of-sale system, we had support staff and critical on-call engineers spread across the US West Coast, the Philippines, and the UK. This was a deliberate strategy to provide near 24/7 coverage. A critical bug reported in the US evening would be picked up by the Philippines team first thing their morning, and by the time they were signing off, the UK team would be starting their day.

This "follow the sun" model for support and incident response significantly reduced our mean time to resolution (MTTR). We were able to address critical issues within hours, not days. The cost savings were also substantial; we didn't need to hire a massive, expensive late-night US support team. Instead, we built a distributed, highly skilled team. For example, a major outage on a Friday night in the US could be fully resolved by Saturday morning Manila time, meaning our US customers woke up to a fixed system without any extra overnight costs for us. We used PagerDuty for on-call scheduling and alerting, and Slack for immediate team communication during incidents, but the planning and handoffs were key.

What I would skip if I started today

I would skip the initial hesitation to hire senior talent purely based on geography. For years, I've seen founders in places like Edmonton default to local hiring because it feels "safer" or "easier." It's neither. The perceived risk of managing a remote team is often outweighed by the sheer availability of top-tier talent elsewhere. You don't need to reinvent the wheel; there are proven frameworks and tools for building successful distributed teams. The real risk is not tapping into that global talent pool and being outpaced by competitors who are.

What this looks like for your team

1. Define your communication protocols: Before you hire your next remote engineer, decide how your team will communicate asynchronously. What tools will you use? What are the expectations for documentation and status updates? Make this explicit. 2. Invest in asynchronous tooling: If you’re not already, start using Loom for demos, ensure your documentation platform (Confluence, Notion, etc.) is well-maintained, and train your team on effective asynchronous writing. 3. Structure your sprints for timezones: Plan your sprint ceremonies and handoffs to accommodate different timezones. Don't force everyone into a single 9-to-5. Think about how work can flow across your team’s days.

I write about engineering leadership and building with Filipino dev teams at devwithzach.com — drop me a line if any of this rings true.