What did I learn building an offshore and nearshore team?Wat heb ik geleerd door een offshore en nearshore team op te zetten?Vad lärde jag mig av att bygga upp ett offshore- och nearshore-team?Was hab ich beim Aufbau eines Offshore und Nearshore Teams gelernt?

A few weeks back I wrote an article about What makes global teamwork, offshoring, nearshoring and remote cooperations so interesting. I have a critical father in law who told me that I described some pitfalls that I walked into and asked me ‘but what did you learn from the mistakes you made?’ So I devote this article to that question, because I believe it could prevent others from making the same mistakes. I will go through the points that I described one by one (the italics are from my previous article)

Een aantal weken geleden heb ik een artikel geschreven over Wat maakt wereldwijd werken met teams, offshoring, nearshoring en samenwerken op afstand zo interessant?  Ik heb een kritische schoonvader die me vertelde dat ik een aantal valkuilen had beschreven waarin ik was gevallen en hij vroeg me ‘maar wat heb je geleerd van de fouten die gemaakt hebt?’ Aan deze vraag wil ik graag dit artikel wijden, want ik geloof dat het kan voorkomen dat anderen dezelfde fouten begaan. Ik zal stapsgewijs door de volgende beschreven punten heen gaan (de schuingedrukte tekst komt uit mijn vorige artikel)

Ik vond het niet leuk om zo veel fouten te moeten maken. De eerste jaren had ik geen idee over wat men moet doen om samen te werken met iemand in India of Oost-Europa. Ik maakte alle fouten die je maar kunt bedenken: het huren van de verkeerde mensen, het werken zonder proces, zonder hulp van een online project management tool werken, het communiceren via chat alleen, werken met leveranciers die niet betrouwbaar waren, vast komen te zitten tussen klant en leverancier, en niet in staat zij om een ​​project te leveren aan een klant. En dan nog een berg met fouten gepaard gaande met de opening van een kantoor in India zonder enige voorafgaande ervaring of Indiase contacten.

>Het huren van de verkeerde mensen
Hoewel het gemakkelijk leek om goede programmeurs te huren, je kunt immers objectief de kwaliteit van iemands code beoordelen en redelijkerwijs analytische skills beoordelen, maar dit bleek in werkelijkheid tegen te vallen. Voor het hebben van een goede samenwerking op afstand zijn technologische en analytische skills slechts deel van de vergelijking. Communicatie is het meest cruciale aspect en het is belangrijk om juist voor die skill te recruiten. Ik heb ook geleerd dat het huren van waarden belangrijk is. Twee van onze kernwaarden die de grootste impact hebben op het succes van ons persoonlijk werk met klanten zijn ‘openheid’ en ‘verantwoordelijkheid’. Ik heb daar eerder ook een artikel aan besteedt.

>Het werken zonder proces
De menselijke spirit is van ‘gewoon door blijven gaan’. We vinden een goede programmeur of team op afstand en sturen de eisen op en verwachten dat het op die manier goed uitpakt. Ik heb geleerd dat het cruciaal is wanneer je werkt met mensen op afstand, cultuurverschillen of een andere taal, dat je afspraken maakt over ‘hoe je te werk gaat’. Als je hier van te voren niet over nadenkt en mensen op dezelfde manier werken zoals ze gewend zijn, tenzij ze bij toeval de juiste routines hebben ontwikkeld, zal je offshore project falen.

>Zonder hulp van een online project management tool werken
Technologische ontwikkelingen hebben hierbij veel geholpen. Veel mensen gebruiken tools zoals Jira, pivotaltracker, github en bitbucket, maar 7-8 jaar geleden werd er vooral met email en skype gewerkt. Als je niet vanaf het begin een overzicht maakt, gebruik makende van een online tool dat communicatie, status, bugs, vragen, etc. bijhoudt; zal je project na de tijdje ontsporen.

> Alleen communiceren via chat
Het opvallende is dat deze methode absoluut kan werken, we hebben een aantal klanten die alleen via chat werken, die tevreden zijn. Maar wat dat je mist is de persoonlijke relatie en de verbale communicatie. Ook neemt het meer tijd in beslag dan praten. Het is veilig om achter je pc te zitten, dat geldt zeker voor programmeurs op afstand. Maar het is belangrijk dat je een relatie opbouwt en efficiënt kan werken daardoor. Scrum is een van de instrumenten die je helpt bij het werken op afstand. Scrum werkt alleen via praten en video en niet met chat.

> Werken met leveranciers die niet te vertrouwen zijn
Toen ik begonnen was met Bridge, werkte ik alleen maar met leveranciers. Degene waar ik mee werkte kregen problemen met het aantal programmeurs dat ze hadden om de hoeveelheden werk te verwerken. Waardoor je uitbreidt naar andere partners. Het is moeilijk om de juiste partner te vinden en dat kost ook tijd. Maar ik heb geleerd dat daar ook de tijd voor moet nemen. Ik heb ook geleerd dat het voor ons beter werkt om onze eigen mensen te hebben, want zo kunnen we zelf beslissen wie we aannemen. Gebaseerd op skills en kennis, maar ook op waarden, hoe ze werken, hoe we een team spirit op kunnen bouwen en hoe we comfort en geluk creëren in ons team. Daarover heb ik vorig jaar een artikel over geschreven.

> Noodgedwongen tussen klant en leverancier komen
Hier heb ik ook een belangrijke les geleerd: om offshore coöperaties succesvol te maken, moeten er zo min mogelijk managers tussen de klant, die vraagt om de creatie van een software programma, en de persoon die het programma creeert, zitten. We hebben projecten gehad waarin een eindklant een webshop wilde, hiervoor een uitgever inhuurde, die op hun beurt een web agency inhuurde, die vervolgens ons inhuurde, en wij huurden uiteindelijk een nearshore team. Vanuit ieder bedrijf was een project manager betrokken, dat betekent op zijn minst 5 project managers. Als één slaapt, faalt het project. Het beste scenario voor een succesvol project is wanneer de eindklant direct met de programmeur praat. Wanneer de skills hiervoor ontbreken, kan een web agentschap ingehuurd worden om op afstand te praten met de programmeur. Een positieve bijkomstigheid van deze methodiek is het besparen van kosten!

För ett par veckor sedan skrev jag en artikel om “Vad gör globala samarbeten, offshoring och nearshoring så intressant?” Jag har en kritisk svärfar som påpekade att jag beskrev en del fallgropar jag har ramlat i och frågade mig ”vad lärde du dig av de misstag du gjorde?”. Så jag tillägnar denna artikel åt den frågan, för jag tror att det skulle kunna förhindra att andra gör samma misstag. Jag ska gå igenom de huvudsakerna som jag beskrev, en efter en (kursiveringen är från min tidigare artikel).

Vor ein paar Wochen schrieb ich ein Artikel über „Was macht globales Teamworking, Offshoring, Nearshoring und Kooperationen aus der Ferne so interessant?“ Ich habe einen kritischen Schwiegervater, der mir sagte, ich hätte einige Fallstricke beschrieben, und er fragte mich „aber was hast du aus deinen Fehlern gelernt?“ Somit widme ich diesen Artikel genau dieser Frage, weil ich denke es kann anderen helfen nicht die gleichen Fehler zu begehen. Ich werde jeden Punkt einzeln durch gehen. (Das Kursive ist von meinen vorhergehenden Artikel)

Das was ich nicht mag, sind die vielen Fehler, die ich machen musste. In den ersten Jahren wusste ich nicht was man tun muss, um mit jemanden aus Osteuropa oder Indien zusammenzuarbeiten. Ich machte alle Fehler, die man sich vorstellen kann: Stelle die falschen Leute ein, arbeitete ohne Fortschritt, nutze gar keine Online-Projekt-Managment-Systeme, kommunizierte nur durch Chat, arbeitete mit Lieferanten, die nicht vertrauenswürdig waren, blieb in der Mitte zwischen Kunde und Lieferant stecken und war auch nicht in der Lage ein Projekt an einen Kunden zu liefern. Und dann noch einen Eimer voll Fehler bei der Eröffnung eines Büros in Indien ohne Vorkenntnisse und indische Kontakte.

Ø  Die falschen Leute einstellen

Obwohl es einfach scheint gute Programmierer einzustellen, weil man objektiv die Qualität eines Codes beurteilen kann und die analytischen Fähigkeiten vernünftigerweise beurteilen kann, ist es in der Realität nicht so leicht. Für eine Zusammenarbeit auf Distanz sind technologische oder analytische Fähigkeiten nur ein Teil der Gleichung. Kommunikation ist der wichtigste Aspekt dabei und nach dieser Fähigkeit sollte auch rekrutiert werden. Ich habe auch gelernt, dass es wichtig ist gemeinsame Werte bei der Auswahl zu berücksichtigen. Offenheiten und Verantwortung sind zwei unserer Unternehmenswerte, die den größten Einfluss auf den Erfolg bei unserer vertrauten Arbeit mit unseren Kunden haben. Ich habe einen früheren Artikel diesem Thema gewidmet.

Ø      Ohne einen Prozess zu arbeiten

Die menschliche Natur will immer „gleich loslegen“. Wir finden einen Programmier oder ein ganzes Team in der Ferne und schicken unsere Anforderungen und erwarten, dass einfach alles automatisch funktioniert. Ich habe gelernt, dass es bei der Arbeit auf Distanz und zwischen Kulturen und Sprachenräumen ein gemeinsames Verständnis wie gearbeitet wird sehr wichtig ist. Wenn man sich vorher nicht darauf verständigt und die Angestellten tun nur das wie sie es gewohnt sind, es sei denn, dass sie zufällig die richtigen Routinen herausbilden, entstehen falsche Routinen und das Offshore-Projekt wird scheitern.

Ø      Keine Online-Projekt-Managment-Systeme benutzen

Technologische Fortschritte haben hier viel geholfen. Heute benutzen die meisten Leute Jira, Pivotaltracker, Github und Bitbucket, aber sieben bis acht Jahre zuvor hat man gerade erst angefangen bei der Arbeit aus der Ferne mit E-Mails und Skype zu arbeiten. Wenn Sie sich keinen Überblick mittels Online-Anwendungen, die die Kommunikation, den Status, die Fehler und Fragen verfolgen verschaffen, wird Ihr Projekt im Laufe der Zeit entgleisen.

Ø      Kommunikation nur mittels Chat

Das Auffallende ist, dass es auch funktionieren kann. Wir haben einige Kunden die nur über Chat arbeiten und zufrieden sind. Aber was Sie vermissen ist die persönliche Beziehung und die verbale Kommunikation. Es braucht auch mehr Zeit als zu reden. Es ist sicher für den Programmier in der Ferne hinter dem PC zu sein. Aber es ist auch wichtig diese Beziehung aufzubauen und effizient zu arbeiten. Scrum ist eines der Instrumente, das der gemeinsamen Arbeit auf Distanz am meisten hilft. Und Scrum funktioniert nur mittels Audio und Video, nicht mit Chat.

Ø      Zusammenarbeit mit nicht vertrauenswürdigen Lieferanten

Als ich mit Bridge startete, hatte ich nur Zulieferer mit denen ich arbeitete. Diese haben sich jedoch schnell gezeigt, dass sie zu wenige Programmierer hatten um die Arbeit weiter auszuführen. Deshalb verzweigt man sich mit anderen Partnern. Es ist schwer den richtigen Partner zu finden und es braucht Zeit. Aber ich habe gelernt, dass man sich die Zeit nehmen sollte. Außerdem habe ich gelernt, dass es besser ist seine eigenen Leute zu haben, da wir selbst entscheiden können wen wir einstellen (bezüglich Fähigkeiten, Wissen aber auch in Bezug auf Werte), wie sie arbeiten, wie wir unseren Teamgeist aufbauen und wie wir Komfort und Freude unter unserem Team aufbauen. Ich schrieb im letzten Jahr einen Artikel über dieses Thema.

Ø      In der Mitte zwischen Kunde und Lieferant stecken zubleiben

Ich habe auch eine andere wichtige Lektion gelernt: Für erfolgreiche Offshore-Kooperationen sollten ein paar Manager zwischen dem Kunden und dem Programmierern geschalten sein. Wir sind es gewohnt Projekte zu haben bei denen ein Endkunde einen Webshop haben wollte und engagiert dafür eine Agentur. Die gibt den Auftrag an eine Webagentur weiter und diese wiederum gibt uns den Auftrag und wir stellen ein Nearshore-Team ein. In jeder Firma war ein Projektmanager involviert, das bedeutet mindestens fünf Projektmanager. Wenn einer dabei schläft, scheitert das Projekt. So die beste Version ist, wenn der Endkunde direkt mit dem Programmierer spricht und wenn er nicht die Fähigkeiten dazu mitbringt, kann er eine Web-Agentur engagieren, welche mit dem Programmier in der Ferne kommuniziert. Ein Nebeneffekt ist, dass man sich einige Kosten auf dem Weg sparen kann!

The thing I disliked was having to go through so many mistakes. The first years, I was in the dark as to what one needs to do in order to cooperate with someone in India or Eastern Europe. I made all the mistakes you can imagine: hire the wrong people, work without any process, not using any online project management tools, communicating through chat only, work with suppliers that were not trustworthy, get stuck in the middle between client and supplier, not being able to deliver a project to a customer. And then another bucket of mistakes opening an office in India without any prior experience or Indian contacts.

> Hiring the wrong people
Although it seems easy to hire good programmers, because you can objectively judge the quality of ones code and you can reasonably judge the analytical skills, it’s less easy in reality. For having good remote collaboration, technological or analytical skills are only part of the equation. Communication is the most crucial aspect and it’s important to recruit for that skill. I also learned that hiring for values is crucial. Two of our core values that have the biggest impact on the success of our intimate work with customers are ‘openness’ and ‘responsibility’. I have dedicated another article to these too earlier.

> Work without any process
The human spirit is to ‘just get going’. We find a good remote programmer or team and send requirements and expect it to work out just like that. I have learned that it’s crucial when you work across distance, cultures and language to have a common understanding of ‘how you are going to work’. If you don’t think about this upfront and people just do what they are used to, unless they by accident build the right routines, you’ll build the wrong ones and your offshore project will fail.

> Not using any online project management tools
Technological advancements have helped a lot here, most people use tools like Jira, pivotaltracker, github and bitbucket, but 7-8 years back most remote work was just started by email and skype. If you don’t create an overview from the beginning using some online tool that tracks communication, status, bugs, questions, etc; your project will over time derail.

> Communicating through chat only
The striking thing is that this can absolutely work, we have several clients that work only through chat and are satisfied. But what you miss is the personal relationship and the verbal communication. It also takes more time than talking. It’s safe to be behind the pc, certainly for remote programmers. But it’s also important to build that relationship and to work efficiently. Scrum is one of the instruments that helps remote work most and scrum goes with talking and video, not chat.

> Work with suppliers that were not trustworthy
When I started Bridge I had only suppliers to work with. The ones I worked with soon appeared to be having too little programmers to process the work. So you branch out to other partners. It is hard to find the right partner and it takes time. But I have learned that you should take the time. I have also learned that for us it works better to have our own people, because we can decide whom we hire (on skills and knowledge, but also on values), how they work, how we build a team spirit, how we create some comfort and happiness among our team. I wrote an article last year about this topic.

> Get stuck in the middle between client and supplier
Here I also learned an important lesson: for offshore cooperations to be successful, there should be as few managers in between the person asking to create a software application and the person building it. We used to have projects in which an end client wanted a webshop, hired a publishing agency for this, who hired a web agency, who hired us and we hired a nearshore team. In each company there was a project manager involved, which means at least 5 project managers. If one is sleeping, the project fails. So the best version is the end customer talking to the programmer and if he doesn’t possess the skills for that, he can hire a web agency who talks to the remote programmer. A side effect is that you save some extra costs along the way!

Det jag ogillade var att vara tvungen att gå igenom så många misstag. De första åren kunde jag inte se vad som behövdes göras för att möjliggöra samarbete med någon i Indien eller Östeuropa. Jag gjorde alla misstag du kan tänka dig: anställde fel människor, jobbade utan processer, använde inte några projektledningsverktyg online, kommunicerade enbart genom chat, jobbade med leverantörer som inte var pålitliga, blev fast mellan klienter och leverantörer och hamnade i situationer då jag inte kunde leverera projekt till kunderna. Och ovanpå det, en till lista med misstag då jag öppnade ett kontor i Indien utan några tidigare erfarenheter eller indiska kontakter.

> Anställa fel människor

Även om det verkar enkelt att anställa bra programmerare, för att du objektivt kan bedöma kvaliteten på kodningen och du kan rimligen bedöma den analytiska förmågan, så är det inte så enkelt i verkligheten. För att ha goda, distanserade samarbeten är teknologiska eller analytiska förmågor bara en del av ekvationen. Kommunikation är den viktigaste aspekten och det är viktigt att rekrytera utefter den förmågan. Jag lärde mig också att rekrytera efter värden är avgörande. Två av våra kärnvärden som har den största påverkan på framgången för våra intima arbeten med våra kunder är ”öppenhet” och ”ansvar”. Jag har dedikerat en annan artikel till dessa två tidigare.

> Arbete utan någon process

Den mänskliga andan är “fortsätt bara”. Vi hittar en bra, avlägsen programmerare eller team och skickar krav och förväntar oss att det ska fungera, bara sådär. Jag har lärt mig att det är avgörande när du jobbar på distans, mellan olika kulturer och språk, att ha en gemensam förståelse för ”hur det kommer att fungera”. Om du inte tänker på det här direkt och människor bara gör vad de är vana att göra, så kommer du att bygga upp fel rutiner och dina offshore-projekt kommer att misslyckas.

> Att inte använda några projektledningsverktyg online

Teknologiska framsteg har hjälpt till mycket här; de flesta människorna använder verktyg som Jira, pivotaltracker, github och bitbucket, men för 7-8 år sedan startade de flesta arbeten på distans endast med email och skype. Om du inte skapar en överblick ifrån början genom att använda några onlineverktyg som spårar kommunikation, status, buggar, frågor, etc., kommer ditt projekt med tiden att spåra ur.

> Att enbart kommunicera via chat

Den förvånansvärda saken är att det här absolut kan fungera; vi har flera klienter som jobbar enbart med chat och är nöjda. Men vad du missar är den personliga relationen och den verbala kommunikationen. Det krävs också mer tid än att prata. Det är tryggt bakom en dator, särskilt för distanserade programmerare. Men det är också viktigt att bygga upp en relation och att jobba effektivt. Scrum är ett av de instrumenten som hjälper avlägset arbete allra mest och scrum fungerar genom videosamtal, inte chatta.

> Jobba med leverantörer som inte är pålitliga

När jag startade Bridge hade jag bara leverantörer att jobba med. De jag jobbade med visade sig ha för få programmerare till att behandla arbetet. Så istället räcker du ut handen till andra partners. Det är svårt att hitta rätt partner och det tar tid. Men jag har lärt mig att man bör ta sig den tiden. Jag har också lärt mig att för oss så fungerar det bättre att ha våra egna personer, för att vi kan bestämma vem vi anställer (efter förmåga och kunskap, men också efter värderingar), hur de jobbar, hur vi bygger teamspirit, hur vi skapar komfort och lycka i teamet. Jag skrev en artikel om detta ämne, förra året.

>  Att fastna mittemellan klient och leverantör

Här har jag också lärt mig en viktig läxa: för att offshore-samarbeten ska bli lyckade, bör det vara så få ledare mellan personen som efterfrågat en programvara och personen som bygger den. Vi brukade ha projekt där klienten ville ha en webshop, anställde en publishing agency till detta, som i sin tur anställde en webagency, som anställde oss och vi anställde ett nearshore-team. I varje företag var en projektledare involverad, vilket betyder minst fem projektledare. Om en sover, misslyckas projektet. Så den bästa versionen är att kunden pratar med programmeraren och om han inte har kompetens att göra det, så kan han anställa en webagency som pratar med den avlägsna programmeraren. En sidoeffekt är att du kan spara ett par extrakostnader på vägen!