In a world where major tech companies are pulling their teams back into offices and expressing growing skepticism about remote work, we at KOR are proving the opposite. Our fully remote engineering team doesn't just function well remotely. It thrives. And the reason comes down to something that might surprise you: we practice Extreme Programming (XP), and we believe remote actually makes it better.
Where It Started
Many of our engineers spent formative years at Pivotal Labs (later VMware Tanzu), widely regarded as the epicenter of applied XP practices. Pivotal was famous for its disciplined approach to pair programming, test-driven development, and continuous feedback. When we founded KOR to help financial institutions navigate the complex world of derivatives trade reporting, we knew we wanted to bring those same practices with us.
But we also knew we wanted to be remote-first. Not remote-tolerant. Not hybrid. Fully, intentionally remote.
That presented an interesting challenge. XP was born in physical spaces: people sitting side by side, rotating pairs at whiteboards, having spontaneous conversations in the hallway. Could we preserve the intensity and effectiveness of those practices without sharing a physical office?
The short answer is yes. The longer answer is what the rest of this post is about.
Building a Virtual Office That Actually Works
The foundation of our remote XP approach is what we call the virtual office. Rather than relying on scheduled meetings and Slack messages alone, we maintain a persistent, always-on space where engineers can see who is available, jump into a pairing session, or have the kind of quick, informal conversations that happen naturally in a physical office.
Everyone is just a click away. If you have a question for someone, you don't need to schedule a meeting, walk to a conference room, and then awkwardly try to fill the remaining 25 minutes with small talk once the actual topic is resolved in five. You just click into their room, ask your question, and click out when you're done. No calendar overhead, no wasted time, no friction.
Our virtual office has rooms for every occasion. There are focus rooms for deep work, meeting rooms with no size limit for when larger groups need to align, and then there are the rooms that give our space its personality: boiler rooms and even a rave cave for when you want some energy and company while working. The result is that people are genuinely approachable throughout the day, and collaboration happens as naturally as it would in a physical office, if not more so.
This matters more than most people realize. One of the biggest risks of remote work is isolation: the feeling that you're working in a vacuum, disconnected from the rhythm of the team. Our virtual office counters that by recreating the ambient awareness of a shared space. You know who's pairing with whom, who's taking a break, and who might be free to help you think through a tricky problem.
Remote Pairing: More Than Just Screen Sharing
We've written before about why we practice pair programming. The core arguments still hold: shared code ownership, real-time code review that replaces the overhead of pull request cycles, faster knowledge transfer, and a higher bus factor across the team. But remote pairing adds a few dimensions of its own.
When you pair in a physical office, you share a desk. One person drives, the other navigates, and you swap regularly. In a remote setting, the mechanics change slightly, but the principles stay the same. Both engineers share a screen, communicate continuously, and collaborate on the same piece of work in real time.
What we've found is that remote pairing can actually reduce some of the friction that exists in physical pairing. At Pivotal, the physical setup was already optimized: two screens, two keyboards, and two mice hooked up to the same computer, so fighting over the keyboard was never really a problem. But physical co-location brings its own friction. Open-plan offices, while great for visibility and spontaneous interaction, can get noisy. Conversations from neighboring pairs, impromptu discussions, and general office buzz all compete for your attention. In a remote setup, you control your own environment. You can be in a quiet room, wear noise-canceling headphones, or choose a virtual focus room when you need deep concentration.
That said, remote pairing demands something that physical pairing lets you take for granted: deliberate communication. You can't rely on body language or a quick glance at someone's screen to know what they're thinking. You have to verbalize your thought process, explain your reasoning, and actively invite input. This turns out to be a feature, not a bug. It forces a level of clarity and intentionality that makes the collaboration richer.
TDD as the Backbone
Pair programming doesn't exist in isolation at KOR. It's tightly woven together with test-driven development, and the two practices reinforce each other in powerful ways.
When you pair on a piece of work, TDD provides the rhythm. One person writes a failing test. The other makes it pass. Then you refactor together. This red-green-refactor cycle creates a shared cadence that keeps both engineers engaged and aligned. It's especially valuable in a remote context because it gives the pairing session a clear structure and measurable progress.
This practice has also shaped how we integrate AI into our workflow. Many teams that rely on AI-assisted coding end up shifting the bulk of their quality assurance to heavy code reviews on pull requests, where a single reviewer tries to verify what an AI generated in one large batch. With TDD and pairing, that dynamic is fundamentally different. Two people are looking at what the AI generates in a much more structured, stepped approach: test by test, small increment by small increment. Each generated piece of code is immediately validated against a clear expectation. It's a far more effective way to harness AI without sacrificing quality or understanding.
In regulated finance, where we operate, the stakes of getting things wrong are high. A duplicated transaction or an incorrectly reported trade can result in significant regulatory fines. TDD gives us the confidence to refactor aggressively, ship frequently, and adapt to ever-changing regulatory requirements without fear of regressions. That confidence compounds over time: the more disciplined the team is about writing tests first, the faster the team can move months and years down the road.
Trust, Respect, and Kindness
No amount of tooling or process can substitute for culture. The foundation of our remote XP practice is a combination of trust, mutual respect, and kindness.
Trust means we don't micromanage. We don't track how many hours someone spends in a particular virtual room, we don't require daily status reports, and we don't ask engineers to justify how they spent their afternoon. We believe that when you give a pair the right context, they will make the best decision within that pair and don't need to be managed. Engineers have the freedom to structure their day, take breaks when they need to, and choose when and how to pair.
To make this work at scale, we invest in lightweight structures that keep everyone aligned without top-down control. We use Architecture Decision Records (ADRs) so that decisions made within one pair are visible and understandable to the rest of the team. We run architecture circles where engineers come together to collaborate on cross-cutting architectural decisions. These mechanisms ensure that autonomy at the pair level doesn't come at the cost of coherence at the team level.
Mutual respect means valuing everyone's perspective. As we've shared before, pairing requires you to overcome your own ego. You have to be willing to make mistakes in front of your pair, to have your ideas challenged, and to change your mind. That's hard enough in person. Remotely, where miscommunication is easier and social cues are fewer, it requires even more intentional effort.
Kindness is the glue. It shows up in small things: being patient when someone is learning, giving feedback constructively, and recognizing that everyone has days when they're not at their best. In a remote environment, kindness also means being mindful of time zones, respecting people's personal boundaries, and creating space for connection beyond work.
Continuous Feedback, Continuous Improvement
XP is fundamentally about short feedback loops. Write a test, watch it fail, make it pass. Deploy, get user feedback, iterate. Pair, retro, adjust.
We apply this same principle not just to our code and product, but to how we work together as people. At the end of each pairing session, pairs take a moment to give each other feedback on the collaboration itself. What went well? What could be better? Was the communication clear? Did one person dominate the keyboard? These micro-feedback moments keep small issues from compounding into larger frustrations and help each engineer grow continuously.
Beyond pairing feedback, we invest in broader feedback culture through regular speedback sessions, where team members exchange rapid, focused feedback with multiple colleagues in quick succession. It's an intentional practice that normalizes giving and receiving feedback, making it feel like a natural part of how we work rather than something reserved for annual reviews or difficult conversations.
Regular retrospectives give the team a space to reflect on what's working and what isn't at a process level. And because we take those conversations seriously, our practices evolve continuously. The way we work today is noticeably different from how we worked two years ago, and it will be different again two years from now. That willingness to experiment and adapt is what keeps the approach fresh and effective.
Defying the Skeptics
We understand the skepticism around remote work. Some of it is well-founded: remote work done poorly, without intention or structure, can absolutely lead to isolation, miscommunication, and declining productivity. But the conclusion that the solution is to return everyone to an office misses the point. The problem isn't the location. The problem is the absence of deliberate practices that foster collaboration, accountability, and shared ownership.
XP gives us those practices. Remote gives us access to exceptional talent regardless of geography, the ability to work in deep focus without open-office interruptions, and the freedom and autonomy that attract engineers who take ownership of their work.
The result speaks for itself. Our platform processes complex, regulated financial data at scale using Apache Kafka and Kafka Streams, handling high-throughput, high-retention workflows with stringent accuracy requirements. We build and maintain this with a fully remote team, practicing XP every day.
The Kind of Team We're Building
If you've read this far, you might be the kind of engineer who cares deeply about how software is built, not just what it does. You might value craftsmanship, collaboration, and the kind of continuous learning that comes from working closely with talented peers. You might be looking for a place where pairing and TDD aren't aspirational posters on a wall but daily practice.
If that sounds like you, we'd love to hear from you. We're growing our engineering team, and we're looking for people who share our values and want to help shape the future of regulated financial technology.
