Remote software development center in Eastern Europe, Romania

This is a short summary of the inception of MWG’s distributed teams, and Ron Herman’s role in this capacity, first as an employee of MWG and later as an independent consultant at TeamFound. This case study is posted with permission by MyWebGrocer

Client: MyWebGrocer, a Vermont based high-growth industry leader in enterprise SaaS digital commerce solutions
Industry: U.S. Grocery Retail and CPG
Technology: Microsoft .NET, Mobile (iOS, Android), Java, DevOps
Remote Team: 80 People: Software Engineers, Testers, DB/IT Admins, PMs, BA’s, and UX/UI Designers
Location of remote team: Transylvania, Romania

MyWebGrocer: offers a complete Digital Experience Platform for grocers and CPG brands, powering every interaction to attract, engage, transact with and retain grocery shoppers through digital offerings, ranging from planning and shopping platforms to mobile and social tools. Founded in 1999, MyWebGrocer manages digital solutions for more than 130 retailers across the globe, representing more than 10,000 stores, and 500+ major CPG brands.

In 2008 while I was employed at MWG as Software Engineering Manager, our Engineering team was struggling to find qualified software developers.

MWG is located near Burlington, Vermont a region of 100,000 people where, in 2008, qualified software engineers were scarce and recruiting times were lengthy. We were recruiting locally, but the effort proved too slow and we were ultimately faced with a choice: either augment our staff elsewhere or suffer delays in releasing software to market.

We had plans for major innovations, including a first-ever iOS/Android mobile app for grocery chains, web service API’s, and platform modifications to make it all work together. Time was of the essence!

I was tasked by our CEO to lead the search for a new development partner.  I called upon long-time hardware and software engineering leaders in the Boston area about their experiences.  Eastern Europe, and particularly Romania came forth as an emerging high-tech region with a good balance of education, talent, and western culture. The Computer Science curriculum is rigorous and the standards of education are on par with U.S. engineering colleges. Developers are fluent in English, and are self-starting, proactive communicators.

A month later, MWG’s VP and I landed in Bucharest. We had 9 providers on our list, located across the country from the south (Bucharest) to the north (Cluj-Napoca, Transylvania). Being from Vermont, we found the Transylvanians in the north to be more our style: craftsman-like engineers, honest hard workers, with a warm personable character. Interestingly, they had decades of experience working mostly with German clients, and had developed rigorous engineering process skills. This was very promising.

We selected two providers in Cluj-Napoca and setup a small team in each, one to build the mobile apps, the other to develop our API’s.  That’s 3 teams involved in this project altogether, including our internal developers. It was my task to lead the project and forge into this new model of distributed development.

At the time, MWG’s engineering processes were still emerging. Both Romanian providers helped us strengthen our communications and processes to better organize our work together. We found their guidance useful and it later served as a foundation to further mature our internal processes.

The project was very successful. MWG deployed the first-ever iOS/Android mobile apps for the grocery market, and our newly developed API’s served as key innovations helping MWG acquire its largest enterprise customer to date.

Over the course of the next couple of years, we settled on one of the two providers, and grew our teams there to 45 people by 2011.

After 11-years with MWG, I left to pursue other growth opportunities. I was asked to return to MWG to expand the Romanian team, provide management support, and coach internal team leads on how to work effectively with remote developers.  This was the inception of my consulting work at TeamFound.  My work with MWG lasted through 2014, having facilitated the growth of the team to 120 people in Cluj-Napoca, Romania.

MWG teams were mostly structured as staff augmentation, except for Mobile and QA, which were running more independently.

  • Mobile (iOS, Android)
  • .NET web development
  • Java
  • DevOps
  • QA Manual and Automation
  • IT/System Administration

The staff also includes project managers, business analysts, UX/UI designers, and database administrators.

Continuing a partnership of over 8 years, MWG benefited from the stability of a dedicated remote team, in a seamless integration model. Instrumental in the success of the relationship were:

  • The provider’s strong management and technical capability, which enabled MWG to delegate HR activities, on-boarding, people management, in order to focus more on building software.
  • The particular region of Transylvania, which combines western culture, a large talented pool of well educated engineers, and an emerging high-tech community.
  • MWG and the provider’s focus on human relationships, which involved building a culture of open communication and regular in-person meetings to strengthen knowledge transfer and cohesion among the distributed team members.
  • The flexibility, trust and commitment from the management team, and throughout all levels of the organization.

Guide for Leads of Distributed Teams

About This Guide

Pictured above is Ron Herman running a “How to Manage Remote Teams” workshop for 16 engineering leads and managers.

Managing distributed developers is different than managing a co-located team. Recognizing this is the first step towards making the enterprise successful. At TeamFound we’ve worked with many software development teams, often teams who venture to work with remote engineers for the first time.  This guide summarizes some key points in running distributed teams successfully.

If you’re a manager or team lead, and you want to better prepare for expanding your team with remote developers, or if you want to improve your current distributed operations, this guide is for you.

Table of Contents

Software development processes are your foundations
Setting roles and expectations
Develop a culture of accountability
Encourage truth and problem solving in stand-ups
Ownership is not easily measured, but more valuable
Take opportunities to foster a collaborative atmosphere
Characteristics of an effective team leader
Conduct one-on-one’s
Attention is your greatest asset
Emails are lost to the team
For Pete’s sake, turn on your web cam!
Great performing teams are built on trust
Tell the story. Rally them behind a common goal

Software development processes are your foundations

Process is usually not a top-priority when a team is co-located. Teams that reside in one office, often get by with little to no process or standardized workflows or structured communications. If co-located teams take-on remote team members, and do not develop good processes, they will experience many frustrations and loss of performance. This alone may cause them to consider the collaboration a failure.

Therefore, one of the most important planning initiatives for organizations preparing to work with remote teams is designing robust processes, workflows, and structured communications – all of which I refer to as “process”.

Process is simply put a structure for working. When team members are dispersed, using a common process is essential to knowing how to work together: expectations of team members, when to perform key activities, and overall how to achieve good team performance.

Fostering good team collaboration begins with designing processes and workflows that encourage collaboration. Especially in a distributed team model, good collaboration needs to be “engineered” into the engineering process, and the day-to-day workflows of the team.

Software engineering and testing teams have significant advantages with distributed members, because for decades engineering teams became accustomed to process as a means of facilitating good software engineering. Today many teams use Scrum, a framework for managing agile processes. Scrum has gained so much favor in the software development world, that most engineers today have either worked in a Scrum process or can freely explain the key elements to Scrum.

The main advantages of Scrum from the perspective of managing remote or distributed teams are:

  1. Engineers can on-board quickly since they understand the general underpinnings of how to work in an Agile team.
  2. Managers can track and assess the performance of the team through the activities of the process, and by using metrics that are associated with an Agile process, without the need to “see” developers at their desks.

As far as process is concerned, the main difference between an agile co-located team and an agile distributed team, is how well the process it’s defined. With a distributed team, processes should be well documented and easily accessible for the team to read and follow and collaboratively adjust. A simple wiki serves this purpose. For example, one team we worked with who were implementing weekly sprints even posted a day-of-week schedule for the team to follow: activities for Monday, Tuesday, etc.

Processes should include communication protocols: team member contacts and their roles, when meetings occur, who is responsible to attend those meetings, and what tools are used. Protocols should also define off-hour or emergency communication procedures and phone numbers.

Think of workflows as more detailed expressions of your processes, similar to logical decision-making trees. In Git For Teams (O’Reilly), the author presents examples of very well defined workflows and processes using Git for Agile Scrum teams. The published chapter Workflows that Work is a great introduction. Use them as examples of how detailed and well-define your workflows can be.  Written workflows help team members place their task or problem in the right context, and understand what their options are for handling them.

Far beyond resolving loss of performance, robust processes can enable distributed teams to actually outperform collocated teams.  In a 2009 article titled How to Manage Virtual Teams, published by MIT Sloan Management Review, the authors write:

“Virtual teams that had processes that increased the levels of mutual support, member effort, work coordination, balance of member contributions and task-related communications consistently outperformed other teams with lower levels. Moreover, dispersed teams that had high levels of task-related processes were notably able to outperform co-located teams with similar levels of those same processes despite the physical separation of their members.”

I suggest making a best effort to design your processes up-front collaboratively among your team members, internal and remote.  Working together, your team will feel more ownership of the process, and it’s a good team building exercise.  It doesn’t need to be perfect. Refinements can be made iteratively.

Setting roles and expectations

Team members are more willing to trust and cooperate with other team members when they know what to expect from each other, especially in distributed teams where personal contact is limited.  Each team member should not only understand his or her role and responsibilities, but also that of their teammates.  By reducing the ambiguity of people’s roles, and sharing this information across the team, members gain confidence in communicating with each other and working together.

Roles are typically set from the start of the project. Expectations are determined mainly via the processes and workflows.  If you have no documented roles and expectations, consider assembling your team in a meeting where teammates list all critical decisions and activities that they anticipate or for which they are already accountable.  It’s easier, of course, when the team can reference a well defined process. These are then discussed and agreement is reached on who has which role and what is expected of them.  While this activity can take place over the course of the team’s collaboration, determining roles early in the team’s life cycle helps accelerate productivity.

Lastly, it’s incumbent upon leads to regularly who reinforce roles and expectations, as well as adjust them to meet the demands of projects.

Our research shows that… Collaboration improves when the roles of individual team members are clearly defined and well understood…”  Eight Ways to Build Collaborative Teams, Harvard Business Review, Nov. 2007

If you’d like to take inspiration from leading experts in setting goals, I recommend:

Develop a culture of accountability

Wade Foster, co-founder of Zapier, a company of 36 fully distributed members, in his Ultimate Guide to Remote Working said that running a fully remote team forces you to build more systems and processes, to grow up more quickly, to be more disciplined. One of these disciplines is evaluating performance. In distributed teams the “noise” of seeing co-workers show up to work, personality biases, etc. do not exist. Performance evaluations need to be based on metrics.

For example:

  • number of commits, pull requests
  • # bugs
  • # tickets/issues handled (with perhaps a weighting involved)
  • contribution to sprint reviews
  • participation in written forums

Managers worry: “if I let my team work remotely, how do I know they’re working?”  The answer is to setup reporting mechanisms. Then you know. When you assign work, that work needs to have a reporting mechanism attached to it, so you know it was done.

Developing a culture of accountability begins with processes. For example, Wade Foster explains that in Zapier, they have “Friday Updates”, where every person on the team posts an update about what they shipped. The idea is adapted from Scrum Sprint Reviews. In Agile, teams aim for a shippable product at the end of each sprint.

Encourage truth and problem solving in stand-ups

With remote teams, stand-ups may be the best opportunity for leads and members to understand potential technical or product conflicts, what is not headed in the right direction, challenges that need to be addressed. This often takes more than a quick 10 minute stand-up! Don’t fly through stand-ups like a process that you need to check-off.  Everyone’s busy and no one wants to waste time, but it’s better to assure development is headed in the right direction, than to write wrong code.

The key skill in stand-ups is attentiveness. This may sound simple, but remember, you’re inputs are fewer when communicating through voice or webcam. If you are attentive, you know when you have to intervene and ask more questions. Dig in. Doing so with the whole team helps you surface issues that the everyone can learn from. In remote teams this is especially needed because it gives team members the opportunity to reinforce their understanding and thinking processes, even to challenge their biases, and to learn from other teammates.

Chris Lema in Building & Managing Virtual Teams, warns you to be careful not to encourage responses from your team that they believe you want to hear. Instead, push for honest answers with all the bad news that may be hidden in there.

So how do you encourage truth? Simple. The next time you hear bad news, instead of getting upset, dig into it so you understand it. And then embrace it. Ask what alternatives have been considered and if it sounds like everyone is thinking about things correctly, adjust expectations and plan for the new reality that takes into account the bad news. Don’t lose your cool.

It’s not that anyone wants to lie. But the reality is that most cultural dynamics in teams land closer to telling each other what they want to hear instead of what they need to hear.

Ownership is not easily measured, but more valuable

Metrics that look good in a report may still leave stakeholders frustrated. Accountability refers to responsibility for a task. Ownership refers to responsibility for end-to-end delivery, which translates to a satisfied customer.

Chris Lema writes a humorous analogy: Have you heard the joke about the chicken and the pig? When it comes to a ham and egg breakfast, only one is committed, while the other is just involved. It’s the same distinction when it comes to accountability and ownership.

The challenge for managers is how to take someone who is accountable, and foster them to graduate to ownership. This begins by learning to delegate your “ownership” responsibilities, elements of your job that you think only you can or should do.

Gradually, give your most responsible teammates more to own. Help them by giving them a bigger stake, a bigger role, a bigger reason and need to be committed (rather than involved). Give them greater ownership over the whole, instead of just the parts.

Zapier sought-out a way to ground engineers in the needs of customers.  They want to assure feature building isn’t done in a vacuum. They do this by rotating engineers into bug fixing and customer support. This advances a culture where each person is not only accountable for his or her work, but also takes ownership for delivery and satisfied customers.

Take opportunities to foster a collaborative atmosphere

We’ve already discussed designing processes and workflows that encourage collaboration. It also helps to identify special opportunities that arise day-to-day to further foster collaboration.

For example, when a developer or tester is having difficulty in accomplishing a task, ask the team for a volunteer to assist him or her.  Solving problems collaboratively and voluntarily is a great way to strengthen the team.

Similarly, when research is needed into a particular technology, assign the task to more than one person. This not only encourages collaboration, but often results in better research.

What’s more, good collaboration involves healthy working relationships. Leads should ease into group meetings by taking a few minutes to ask members how they are doing, how their weekend was, for example. This “humanizes” what can otherwise be a task-based operation devoid of team atmosphere.

Characteristics of an effective team leader

In our experience, the following traits contribute to successfully managing remote teams. Team leadership can be a shared responsibility across different roles:

  • Can manage transitions in the objectives, people, and focus of the team.
  • Fosters an atmosphere of collaboration among team members
  • Clearly communicates team goals, and how they align with the broader organizational strategy
  • Has strong interpersonal communication skills
  • Enables members to feel engaged in the project.
  • Delegates responsibility effectively
  • Encourages team members to come up with creative ideas
  • Has the autonomy to iteratively evolve processes, workflows, and collaboration methods as needed, based upon project demands.

It takes strong communication skills by team leads to make sure people have the information they need to do their jobs, and to ensure team members feel “plugged-in” and engaged. Those who are naturally extroverts tend to more easily succeed in team leadership. However, even others with fewer “people skills” can learn.

  • It’s better to over-communicate than under-communicate
  • Be responsive. Follow-up promptly to requests from your team.
  • Encourage dialogue so members feel comfortable speaking their mind
  • Remember that a voice only discussion does not provide important visual cues. Learn to compensate by asking for clarity anytime an issue is not well understood.

Conduct one-on-one’s

Conduct one-on-one’s with all team members at least once per month.

Keeps the manager and team members on the same page, and great for informally letting team members know where they stand, and receiving feedback that they would otherwise not give. At Zapier, managers ask 4 questions: “what’s one thing you’re excited about, what’s one thing you’re worried about, what’s one thing I can do better to help you with your job, and what’s one thing you can do better to improve at your job.”

Attention is your greatest asset

You can’t know what the best course of action is, if you don’t know what’s really happening.

Everything that is normally communicated through speech, sight, whiteboards, hand gestures, body language, facial expressions must now fit into a pipe called “Skype” (or tools of choice). Your most valuable asset is your attention.

You have to work harder than before, because before you could afford to miss something, a gesture, a signal, a phrase. Not any more. Communication (hearing, seeing) is minimal, and you have to pay attention to every word, to read between the lines, to sense the signals that would otherwise be obvious to you. During your calls with remote members, attempt to reduce all potential distractions.

Emails are lost to the team

Email from one person to another is a private discussion, potentially about a component or business logic that other team members can benefit from understanding. It takes valuable time to write these emails. So why is the content lost in email?  Even in shared emails, the content is lost to future team members.

When migrating from co-located to remote or distributed teams, it’s not necessary to devote lots of time building new documentation. So much documentation is already being written every day in emails.  Shift that effort from email, to a repository available for the whole team to see.

Shift to transparent discussions visible to the whole team.

Successful remote teams all acknowledged that sharing information across teams is a huge element of their success. Visibility is key. Slack is a good solution.

For Pete’s sake, turn on your web cam!

Whatever your reason for keeping it off: bags under your eyes, bad hair day, etc,  pales in comparison to the good reasons for turning it on.  Seeing our colleagues face-to-face is critical to the psychological drivers of healthy team work. Every experienced lead or manager knows the importance of looking someone in the eye.

Even though your team members may be thousands of miles away, a web cam enables you to see them as though they were right there next to you.  No, it’s not the same, but it does go a long way towards building camaraderie, getting to know your co-workers, and improving the working relationship of the team.

Buying webcams for your team is a very small price to pay for the overwhelming benefits.  Not every conversation needs video.  I recommend using video at least twice each week. is an advanced team video collaboration tool. Skype is okay. Best are tools that your team can spontaneously use, without the need for an organizer. Think of it like walking over to your buddy’s desk.

Great performing teams are built on trust

It’s more difficult to establish trust when you’re working with a team member remotely, especially one whom you’ve never met. But teammates have to trust each other.

The most efficient approach to building trust is to bring teammates together in-person. There is no faster, more impactful way to build relationships, to get to know each other, than to meet face-to-face. Studies have shown that if a team meets in-person during the first 90 days of the collaboration, the project has a much better chance to succeed.

If your budget allows an early in-person visit, great. If not, consider scheduling an annual in-person meeting, rotating team members, one or two members at a time to visit the home office.

A more continuous approach that is also effective is scheduling weekly or bi-weekly hangouts to enable teams to virtually get together, and do lighting talks, demos, and otherwise share experiences.

Tell the story. Rally them behind a common goal

Team leads are responsible for rallying their team behind a common goal.  Spend time discussing the “why” of the project, providing context beyond the technical requirements. Remind the team periodically how the project, and specifically their efforts, impact the company’s business and its customers.  Furthermore, a consistent effort to communicate team goals and relay “the story” behind the project breaks many long-distance barriers.  Being rooted in a clear understanding of the big-picture objectives, a team member is likely to make better decisions and stay motivated when working alone.

Daniel Pink writes: “It’s often difficult to do something well if we don’t know the reasons we’re doing it to begin with. People at work are thirsting for context, yearning to know that their efforts contribute to a larger whole. And a powerful way to provide that context is to spend a little less time monitoring who, what, where, when and how – and little more time considering why.

More on story telling:

Remote Drupal Development Team For U.S. Digital Agency

Client: Digital Agency
Location: Boston, MA
Technology: Drupal 8, PHP, AWS, Acquia Cloud, Web services
Remote Team: 3 Drupal Developers, 1 Tester, 1 Project Manager
Location of remote team: Eastern Europe

Why did you choose to utilize a remote development team?

The projects we consult and provide strategy on are wide & diverse – from the tech stack through to the individual project requirements – from simple web sites to more complex CMS implementations. We needed a skilled & versatile development arm to produce web products. In addition, in the agency universe, we periodically burst our efforts depending on client needs and we needed the flexibility to scale up or down.

How skilled is your remote team?

The remote Drupal team includes all levels of development – junior, mid, & senior and brings in a tech lead as necessary. The quality of both back end and front end development is top notch, and the different experience levels selected for each task are mindfully selected to ensure quality is met at the right level of need. In addition, the project managers have a solid handle on the products we create and know when to make appropriate product ownership decisions without me in the room.

How would you describe your relationship with the remote development provider?

Excellent. I consider our relationship as more of a partnership. We continually work together to address any process snags or issues as they arise.

As a tech agency, does utilizing a remote team pay off? How?

Yes. The risk of hiring and managing a development team is greatly reduced. There’s no need to constantly worry about things like resource utilization or making sure we have the right skills for the project. We focus on our end of the services we provide and the remote agency focuses on their services – together we complement one another.

What is your daily engagement with the remote developers like?

We have daily standups with project managers and developers. Developers are brought on an as needed basis if either party needs to communicate more or ask questions. We stay in contact via Slack and manage tasks with a couple project management tools. We have weekly management and account meetings to ensure things are going smoothly.

What kind of guidance or support did TeamFound provide?

TeamFound introduced and matched me to the agency we work with based on our needs for a full service production arm. Ron coached me on the initial phases – how to engage and communicate effectively with a remote team. Once the honeymoon is over, you enter a new phase and encounter new pain points – Ron was there to listen and provide managerial guidance. His insights are spot on and his ability to home in on the problems and solution sets are remarkable. He traverses well past the team operations, and has become an indispensable business coach.

Magento 2 Enterprise Ecommerce Migration Team

Client: Vermont based computer hardware manufacturer
Industry: Computer Hardware
Technology: Magento 2 Enterprise Ecommerce, PHP, LAMP
Location of remote team: Eastern Europe

Our client designs and manufactures small, rugged computers engineered for reliability, even in the most challenging environments. In addition to their extensive product line, they offer custom development for both x86 and ARM-based systems, as well as an end-to-end OEM service program from its headquarters in the US and offices in both the EU and Taiwan. Their products and customized solutions are sold through a Magento 2 Enterprise Ecommerce deployment.

Having run its shop on a complex development of Magento 1 eCommerce platform, our client was interested in upgrading to the newest Magento 2 Enterprise Edition. They were seeking a focused, highly skilled Magento agency with extensive experience in Magento 2 migrations, to work along-side their team.

The first task was to build a fully responsive Magento 2 theme, followed by migration of all the modules and custom features to the new modern Magento 2 Enterprise. This was also the best moment to build some long awaited new modules.

Magento 2 is a very robust and advanced system, but it is technically complex and requires skill to make a good implementation. The complexity of the existing database and adaptation of the requirements to the new architecture was challenging, but by using a fully agile methodology, the team succeeded in providing the expected solution within the planned budget and time frame.

The Magento agency considered this project to be of medium complexity. Scrum methodologies were successfully applied and the result is a well built, robust Magento 2 Enterprise product that will be able to support numerous updates and new features in the years to come.

Our client found in the agency provider strong Magento domain knowledge, and reliable and trustworthy long term partner, capable of delivering the best eCommerce development services.  The agency also runs an annual country-wide Magento conference with 400+ attendees.

Technologies involved:
Nginx, Apache, Composer dependency package for PHP, MySQL, ElasticSearch,
HTML5/CCS3, Knockout.js, jQuery, RequireJS, PHPUnit and Selenium IDE

Remote Software Engineers AWS Amazon Web Services, Redshift, Data, PHP, Open-Source, Angular.js

Client: Software as a Service business
Industry: Digital Marketing
Technology: PHP, Open-source, Web services, AWS, Redshift, Angular.js
Remote Team: 3 Software Developers, 1 Tester, 2 Data Analysts/Developers
Location of remote team: Eastern Europe

Why did you launch a remote team?

We knew it was going to be a long haul hiring the right engineers locally. We couldn’t afford to wait that long. We needed to get our start-up idea out to market fast. A remote team offered a very fast ramp-up, with the talent-level we needed.

Secondly, because at this stage we’re quite a small management team, we don’t have the time to do HR management and performance reviews and all the things that hiring in-house would demand of us. We had to focus our efforts on delivering value to our customers, especially since we’re bootstrapping our startup.

How do you work with your remote team?

We use the agile scrum methodology, which works very well with a remote team setup. It provides a common workflow, consistency, and predictability. We run weekly sprints, daily stand-ups, and planning and review meetings. Our tools include JIRA, Slack, GoToMeeting, Google docs, and Asana.

What activities most contribute to making the remote team work for you?

One-on-one’s and weekly reviews. Most of the time we’re not present in the remote office, and so we rely on one-on-one’s to understand some of the difficulties our team is facing, as well as opportunities to professionally develop and inspire our team. We use weekly reviews to bring everyone together to demo their accomplishments, and have everyone be on the same page regarding the projects and current activities. It’s also a great way to share our vision with the team.

How did TeamFound help you ramp-up to the remote team?

TeamFound offered us the experience of having run remote teams many times before, which gave us confidence in utilizing remote developers. They also have long-running relationships with providers and connected us with one whom we found to be good managers with strength in attracting good talent.

Remote Software Developers Microsoft.NET, Team Foundation Server

Client: Chicago based software start-up
Industry: Advertising technology
Technology: Microsoft .NET, Team Foundation Server
Remote Team: 2 Software Developers
Location of remote team: Romania

What were the reasons you sought a remote team?

There’s a lot of competition in the marketplace for .NET developers, particularly front-end. We had time constraints and needed to hire more quickly. We understood that we had to look to other markets.

What are your impressions of the remote engineering resource provider?

TeamFound had vetted our provider on other projects, so we felt much more at ease working with them. One of their principals visited us in our Chicago office. Our feeling is that they were listening. They understood our challenges and were very capable in resourcing a talented team.

How much engagement do your remote developers have with your internal team?

In a startup, there can’t be a single point of contact. Multiple lines of communication are needed. The remote developers engage with all our engineering team members, as well as our customer success team. Essentially they function as an extension of our internal team.

Startups move quickly. How well is the remote team working in your fast-paced Agile workflow?

We have 1-week sprints, and daily scrums that include the whole engineering team, internal and remote. We feel they are part of our team. They engage with us very well, are proactive in asking questions and communicating with our staff. No one’s afraid of asking questions and speaking up when mistakes are made.

How well does the remote team fit into your culture?

There’s a good cultural fit. They’re comfortable with the informal and fun side of our culture. They work at the interpersonal relationships. This is important. We include them in our monthly company-wide meetings, so they understand the vision and bigger picture. And they also receive company updates from our business team. They loved receiving company t-shirts for Christmas!

I asked the remote team lead what he felt about the collaboration. Here’s what he said:

Communication is exceptional. Personally it’s been the best experience in remote work that I’ve had. Everyone is super friendly and have a great attitude in collaborating with us. Never felt like i was here and not there. We feel we are part of the team.

Team ENTy of Romania is Microsoft Imagine Cup Champion 2016

Team ENTy of Romania was crowned 2016 Imagine Cup World Champions, Microsoft’s global technology competition held at Seattle, Washington.

They used sensor fusion to detect and monitor if a patient is having balance and posture problems, visualized via an Azure cloud service in real-time. Normally it would take doctors months to see and diagnose related health issues.

The event featured John Boyega, lead actor from Star Wars: The Force Awakens, as one of the three judges.

Grand prize winners from Romania, Flavia Oprea, Iulian-Razvan Matesica and Cristian Alexandrescu of Team ENTy earned a mentoring session with CEO Satya Nadella.

Remote Software Developers SaaS, PHP, Open-Source, Web Services, DevOps

Client: Software as a Service business
Industry: Real Estate
Technology: PHP, Open-source, Web services, DevOps
Remote Team: 4 Software Developers, 1 Tester
Location of remote team: Eastern Europe

Why did you pursue a remote team?

Our company is located in a limited employee market with high competition for engineers. It was taking us too long to hire developers, and retention is a challenge when competing with much bigger employers.

How do you utilize your remote team?

We work in a staff augmentation model with remote engineers who are dedicated 100% to our company. We have two remote engineers who extend our core platform team, and two other engineers who extend our devops team. For software testing, we placed a tester with our remote team to leverage their domain knowledge and cycle faster among them.

What steps did you take to make the distributed model work?

We had experience with distributed U.S. developers, and so processes and tools were already in place. It wasn’t a big leap for us. However, we had no experience working with offshore engineers. TeamFound helped us extend our processes and communications to support a larger distributed team. We sought ways to on-board developers easily. The solution that made the most sense is having our remote team visit and work with us for a few weeks. That was a huge help: our local team enjoyed the close interaction, and getting to know them. Building those relationships in-person is a best practice, and makes working remotely much easier.

Can you describe your software development process?

Our engineering processes have to meet the challenge of a competitive fast moving marketplace. We run an Agile scrum process: daily stand-ups, backlog, two-week sprints, etc. Having remote engineers means we have to be more disciplined about our workflow, particularly communications. But the process remains the same.

How did TeamFound help you ramp-up to the remote team?

TeamFound identified a partner that matched our business and technology requirements, and whom we felt we can trust and grow with. That turned out to work quite well for us. We also asked Ron to help us adapt to working with the offshore team, especially in areas of communications and process. He worked directly with me, the Director of Engineering, providing support and guidance, until we were comfortable with the remote relationship.

Does running a remote team pay off?

We believe that it does, even with the added cost of bringing them to our offices a few weeks each year. When we calculated how much it cost us to hire a local developer, meaning the full HR cost, the local overhead, and the lost product development during those lengthy searches, we get a much more realistic picture.

Why distributed teams are a strategic advantage to technology companies

Software development teams who strengthen their work processes to enable remote developers offer their companies distinct advantages:

  1. New recruitment is focused on talent and fit, rather than an applicant’s geography.
  2. Leads can build teams more quickly.
  3. Onboarding team members is faster and more efficient, as a result of shifting from centralized dependencies to a de-centralized structured process.
  4. Executives gain the flexibility to utilize outsourced contractors, local or offshore, because there’s considerably less disruption to the team.
  5. As a result, products get launched faster

Companies such as Automattic, makers of WordPress, Zapier, Basecamp, Help Scout, WooThemes, GitHub, Treehouse, to name a few, have written extensively about their remote teams, some with a central office, others without. Software engineering being highly structured with patterns, practices, and mature processes is well suited for distributed work.

Co-located teams, where all members work from one office, need not pursue the fully distributed model. They can reap the same benefits by enabling remote engineers to be effective, along-side their co-located team. If teams are well versed in Scrum or have well defined processes, the transition is minimal. In cases where teams are less mature in software processes, some training is useful to help teams better structure their work. Here we are referring to standard Agile Scrum practices, for example. The overall effect of strengthening process is a higher performing team, whether they are co-located or mixed with remote members.

Engineering teams I’ve worked with who have matured their processes, have improved their products, increased quality, evolved their architecture, and are making better decisions.  Collaboration and decision-making improves, since teammates are more aware of what each is working on and can better participate in solving complex issues – the team no longer pushes the issue to “the only guy who understands it”.

We all know there’s real overhead in on-boarding and departing developers.  In a co-located team it can take 2 to 6 months for a new member to become efficient. During this ramp-up, he gains knowledge mainly through examining the code and questioning his teammates.  Yet when a team is skilled in working with remote members, it learns to develop repositories of conversations, requirements, business logic, and even designed software to be more easily understandable – because their peers need to understand it with less communication. There’s a fundamental peer incentive to depart from old practices of keeping knowledge locked up, to distributing knowledge and communicating more effectively.

The median tenure among even the most attractive tech companies such as Google and Amazon is 1.1 years. These numbers underscore the need to shorten on-boarding, distribute knowledge, and train in engineering practices that are more resilient to changing team members.

What we can learn about remote engineering from Zapier

You can hire the right people, even if they don’t live where you live.  Zapier publishes a guide to Remote Work, that is one of the most in-depth sources of honest information on remote working that I have found on the web. A must-read for development managers.  I’ve highlighted some important take-aways:

A focus on process

“Process, at a small company, is more about providing a feedback loop so that you can measure progress for both the company and the people in the company.”

Monthly One-on-Ones

Keeps the manager and team members on the same page, and great for informally letting employees know where they stand, and receiving feedback that they would otherwise not give. There are 4 questions the manager asks: “what’s one thing you’re excited about, what’s one thing you’re worried about, what’s one thing I can do better to help him with your job, and what’s one thing you can do better to improve at your job.”

A culture of accountability

They call it “Friday updates”, where every person on the team posts an update about what they shipped. The idea comes from Agile “Sprint Reviews”. In Agile, teams aim for a shippable product that is being built. Part of this is to demo the new features.

Building culture in-person

Zapier aims to bring the team together twice per year. Studies have shown that in-person meeting significantly improves the collaboration of remote teams.  TeamFound recommends one in-person meeting each year, rotating developers, so not the whole team, but one or two members at a time visit the home office.

Trust is the foundation

“Remote teams have to trust their teammates. There is simply no way around it.” Zapier facilitates building trust via a culture of accountability, a major component of which is “Friday Updates”, their version of Sprint Reviews. Also, each teammate shares weekly updates on their internal blog (P2).

“Everyone does support”

Zapier sought-out a way to ground engineers in the needs of customers.  They want to assure feature building isn’t done in a vacuum. They do this by rotating engineers into bug fixing and customer support.

Weekly Hangouts

Enable the team to virtually get together once per week, and do lighting talks, demos, and otherwise share experiences.

Great resources

Checkout the list of resources Zapier highlights from some of the more outspoken managers of remote teams (scroll to bottom).