Even just a decade ago, working virtually with software developers seemed rather exotic. Today, it’s not only the new normal, it’s regarded as preferable to maintaining full-stack resources in-house. And here at Softjourn, we agree, because virtual software development is what we do for businesses located across the U.S. and throughout Europe and UK.
We’re a U.S.-based company with software development centers in Ukraine and Poland, and we’ve spent nearly two decades working virtually with our clients—delivering new software and systems and acting as a flexible extension of their in-house tech teams to bring deep domain knowledge in fintech, ticketing and media and entertainment.
Our CEO and COO Emmy Gengler and President Jeff Kreuser recently got together to chat about their combined 47-years’ experience working as both users of and providers of virtual software development services and reflecting on questions they’re asked about how Softjourn delivers on the potential of virtual software development.
Softjourn: Softjourn offers virtual software development services to businesses in the U.S., Europe and the UK. What does this mean and how important is “virtual” to your business model?
Emmy Gengler (EG): We’re a third-party software development resource that businesses use to develop new applications and systems from the ground up or to augment their in-house staffs when they need specialized expertise or additional resources during peak periods. We help businesses deal with the increased competition for developer talent and demand for highly specialized tech support on a long-term or short-term basis.
By “virtual,” we mean we’re generally not on site with our clients. In the early days of third-party software development, it was customary for contract developers to be resident at clients’ locations. Today, most companies don’t want the hassle of having outside parties on site. And, with ubiquitous electronic communication, an onsite presence isn’t necessary. Developers can literally work from anywhere in the world. Ours work from our software development hubs in Ukraine and Poland.
Although providing “virtual” support is key to our business model, clients don’t choose Softjourn because of our virtual status. They choose us because of our deep domain expertise, consultative approach to identifying challenges and crafting tech solutions, and the quality and timeliness of our work.
From our clients’ perspective, we hope being a virtual provider is something like the 25th most interesting thing about Softjourn.
Softjourn: Let’s start with the most obvious question, what’s the key to make a virtual software development relationship successful?
EG: It’s the same answer for any software development relationship—great communication between the client and the developer team. The more we understand our clients’ needs and the faster we can establish those communication pathways, the more successful the outcome will be. It’s fair to say, however, that in a virtual—vs. an onsite—relationship, everyone must be a bit more conscious of communication. Recognizing this, we define communication protocols at the start of each relationship or new project. It’s even possible that by being more aware of the need for communication, we do better on this front than if a third-party developer were resident with the client, where good communication is assumed, but sometimes not a priority.
Jeff Kreuser (JK): Emmy is spot on. Effective communication isn’t rocket science, but it requires discipline and proactivity. Our communication protocol starts with a kickoff meeting—which is probably the most important meeting we have with a client—and continues with daily standups and, at a minimum, a weekly meeting with stakeholders. In addition, every week we host a demonstration of what we’ve done and address what we’ll be doing in the coming week. We find these activities help clients and Softjourn developers to get to know each other, which helps them become comfortable with each other and promotes informal conversations that reduce the chance of issues falling through the cracks and missed communication.
You can’t take great communication for granted; you have to keep it top of mind and work on it every day.
Softjourn: Explain why the kickoff meeting is so important?
JK: As a technologist, saying this may be sacrilegious, but projects don’t fall apart because of technology. They fall apart because of lack of clarity about the challenge. The goal of this initial meeting is to achieve clarity regarding the challenge the client is facing and its expectations regarding the solution. Only then do we start thinking about the most appropriate technology.
And, it’s here where our domain knowledge becomes critical. Because we’ve worked on hundreds of related projects, we bring expertise generated by deep hands-on experience. Often, working consultatively, we can assist clients in defining the challenge and setting expectations for the solution. And, we provide insights and information the client might not have considered.
For me, that’s Softjourn’s greatest strength—understanding our clients’ needs and having the skills to address them.
EG: Every system is unique, but we come to that initial meeting with history and context in our client’s industry. We take time to review the specific application if we’re adding new functionality; then we dive deeper into the code to further our understanding. If we’re developing a system from scratch, we write detailed specs for the application, so we have a more detailed process for how to work. All this activity is handled easily in a virtual environment.
Softjourn: Your developers are in Ukraine and Poland. Why those countries?
EG: I developed an interest in Eastern Europe back in the ’90s. I don’t know what the lure was; I just knew I wanted to work there and learn the languages. (I now speak Russian and Ukrainian.) During years of working for Arkansas Systems in Russia and then heading Universal Business Systems in Ukraine and Moldova, I became familiar with the developer talent pool in that part of the world. And, when I say ‘familiar,” I mean I was actually hiring developers in the region and I was blown away by their technical capabilities.
When I founded Softjourn, I knew I wanted to draw on this rich and deep talent pool.
Ukraine and Poland have a deeply embedded culture of technical education, with a strong emphasis on software engineering and mathematics. And, the universities are among the strongest in the world in these fields. Many of our Ukraine- and Poland-based employees have not only bachelor’s degrees in technical fields, but hold Masters’ degrees and PhDs as well, with a good number continuing to teach—or having taught—technical subjects at local universities. And, English is the universal business language, so most of our employees speak and write English well when they join us, and we continue their English immersion at work.
More subjectively, another benefit of having our developer activity in this area is the loyalty and work ethic of the people. People in Ukraine and Poland aren’t job hoppers. I dare say, our developers have longer tenure with us than many of our clients’ in-house developers. This longevity builds our domain expertise.
Any issues that arise from our developers being in Ukraine and Poland are the same that arise in any third-party developer relationship.
Softjourn: But, still, for people who haven’t experienced working with developers in another country, there might be questions. Like, do Softjourn developers use the same developer frameworks and methodologies used in the U.S. and Western Europe.
JK: Absolutely, frameworks like Agile are taught and used universally. In fact, our developers support 23 development frameworks—including project management tools and source control—so they’re prepared to work with clients in the framework and methodologies with which they’re most comfortable.
Softjourn: Are time zones a challenge?
JK: They’re certainly not challenges for our European clients. Poland is in the same time zone as Germany and France, for example, and just an hour ahead of the UK. And, Ukraine is just an hour ahead of Germany and France, and two hours ahead of the UK. Those are less than the time differences between the East and West Coasts of the U.S.
For our U.S. clients, the time differences are more pronounced—between six to 10 hours, depending where you are in the U.S.—so clients and developers have a smaller window to speak directly within normal business hours.
But, by augmenting verbal communication with email, it works. It becomes a continuous development cycle, with clients in the U.S. reviewing our work throughout their workday and providing comments and updates that will be incorporated the following day by developers in Europe. Even if clients haven’t worked with developers outside their time zones before, everyone picks up on the cadence within about a week.
Softjourn: What about the differing regulatory environments?
EG: As a baseline, it’s important to recognize that Poland is a member of the European Union and Ukraine has established a strategic goal of becoming an EU member. So, the regulatory environment we’re talking about isn’t really different from Germany or France.
But the legal/regulatory question I’m asked most often concerns intellectual property protection. It’s a fair question, and I’d expect potential clients to ask me the same thing if our developers were in California or New York or located onsite in their offices. With any kind of software development, there’s always the theoretical concern about someone walking out the door with your code and starting a competing company.
My response is that Softjourn is a U.S.-based company and the agreements they sign with us are governed by U.S. law, which provides among the strongest IP protections in the world. In addition, we don’t maintain sole control of code at any point, we don’t have access to all the inputs and outputs in a live environment and we don’t have or want access to production information—which not only protects IP but is also a matter of data security. IP protection is a universal issue that pertains to software development—whether created in-house or by third parties working virtually or in your location.
Putting IP aside, if we’re ever in a situation where some aspect of legal or regulatory compliance must be baked into, say, an application we’re working on for a client, we consult with our client and engage appropriate legal and/or consulting resources to ensure we’re on the right track. We’d take that approach regardless of where our developers or client were located.
Softjourn: What’s an example of how a Softjourn team would typically be structured to work on a client’s project?
JK: As Emmy said earlier, every system is unique and that applies to projects, too. But, still, there are constants regarding the team we assign to every project. At a minimum, every project has a dedicated project manager and a staff member assigned to quality assurance, along with one or more developers, depending on the size, complexity and duration of the project. When a project requires multiple developers—as most do—we assign a mix of senior, mid-level and junior developers to ensure we’re encompassing different perspectives and skills.
If there’s ever a situation where a client’s solution requires developer expertise we don’t have in-house, we use our network of university contacts and recruiters to find the right talent. Similarly, if a developer ever leaves in the mid-project, we draw from our staff to replace that person.
The point is, developer staffing is seamless for our clients. They don’t have to worry about identifying, recruiting and retaining developer talent. Nor do they have to concern themselves with payroll, benefits or facilities. All they need to focus on is applying the solutions we generate to address their challenges.
Softjourn: How has your experience informed how you operate at Softjourn?
JK: In our prior work lives, Emmy and I both made extensive use of virtual developers. Some of those experiences were great and some not so great. Our goals at Softjourn are, first, to take the best aspects of our cumulative experiences and amplify those positives for our clients and, second, to develop deep domain expertise so we can provide a consultative aspect to our technical work.
EG: I’d add that we thrive on challenges and, from my experience, I know that not all software developers do. We love looking at existing processes and making suggestions to help our clients envision what the process looks like and moving our clients up the value chain.
If you have a challenge, we know how to apply the tech that will get you where you want to go—and to do that seamlessly.
