I am a manager, coach, speaker with more than 15 years in business mostly in IT, Advertising and Training industry working on Agile leadership and project management challenges with such companies as Cisco, Intel, or Unilever. I use my creativity in everything from running workshops to facilitating teams and fostering change. I am responsible for Selleo’s awarded recruitment process.

Dariusz Wylon

Grzegorz supports smart technically-minded people as a business consultant and COO.

Grzegorz Rduch

Selleo Developers

Tomasz is a Tech Expert with an enormous experience in both back-end and front-end solutions. He ensures that quality processes and automations are carried out through the whole software development cycle.

Tomasz Bąk

Nowadays, working with remote teams is often a necessity and although it is a great option to access talented engineers from all around the world, many leaders are scared to take the full advantage of such a solution. The lack of knowledge on how to manage those collaborations is what discourages them and ultimately stops from working with remote teams. In this article, I will present essential tips on how to work and manage remote teams.

### 1. Set clear expectations and explain the process

Before you start the development it is crucial to **set clear expectations** and **explain the full product vision**. The developers you hire should be aware of the final goal and the direction towards they will be heading. This will ensure your team knows what success looks like to you and rule out most of the misunderstandings.

It is important to have the process you follow **well-documented** and send out during onboarding. It should include your expectations for availability, tools they will be working with as well as work expectations.  General words like ‘well’, ‘qucikly’ or ‘done’ can be ambiguous and misleading, so keep in mind to express yourself clearly and precisely.

**Set core values and distribute goals** into smaller time frames eg. present monthly or quarterly goal expectations to keep the team on track and allow further adjustments.

### 2. Communicate often

The most important factor of a successful remote collaboration is **communication**. Since the team you are working with is not physically present in your office, you do not have the opportunity to talk face-to-face on a daily basis. This is why a regular, often scheduled communication is crucial to outsourcing success. Plan short **daily standups, weekly plannings, and scrum, team building, meetings**. 

Your responsibility is to respond to messages as quickly as possible to avoid breaks in production. Be accessible and open to feedback. Value your and other’s time.

Make use of various channels to communicate: **use chat and video**. A written form of communication will ensure that everything discussed is documented and available for future reference while video helps to build a more intimate relationship.\
Do not be afraid to use emoticons or gifs to strengthen your reaction and introduce a more relaxed atmosphere - non-verbal communication is as important as verbal communication.

Try not to overlook company-wide communication. **Provide frequent updates** to the on-site team, so they also know how the work is going.

When communicating, take time to get to know your remote team. Do not forget about small talks, ask about their hobbies or families. This will demonstrate you care about them and their well being, which will have a positive influence on your relationship.

### 3. Make time for one-on-one and face-to-face meetings

When working with remote teams it is important to make time for **one-on-one meetings**, preferably through a video chat. This will give you an opportunity to have an honest conversation with each team member which will further influence the overall level of happiness. Frequent chats will ensure you stay on top of things.

Try to arrange at least once a year an in-person meeting with the entire team - fly them over or, if possible, visit their offices. This will give you the opportunity to spend time together outside the work environment.

### 4. Choose the right tools

Ensuring that your team is working with the same tools as you are is an inherent step. At the very beginning of the project, you should choose the tools which you will be using to communicate, document progress, track time etc.

Project management tools like [Trello](https://trello.com) or [Jira](https://www.atlassian.com/pl/software/jira) will help to organize work and distribute tasks. By using that, everybody on the team will know **who is currently working on which task**, which ones were finished or need to be reviewed. Weekly plannings and reviews based on those ticketing systems will give you information on the progress, which tasks need more time to be completed or which ones you can get rid off. Trello and Jira are also a great place to **document ideas and future functions**.

[Slack](https://slack.com/intl/en-pl/) is probably one of the most popular chat and video solutions. It allows sending private messages, making calls, creating public or private channels dedicated to various topics eg. a channel with important company-wide announcements or one for the off-shore team only. It supports emoji and gifs as well as file sharing.

Google also gives you a great variety of tools that you can make use. [Google Calendar](https://calendar.google.com/calendar/r) will help you schedule calls and meetings while keeping you up-to-date with time zone differences and possible public holidays. [Google Drive](https://drive.google.com) is a great cloud environment to store all the important files on. It gives you the ability to create and share documents, presentations, spreadsheets as well as keep your documentation or framework guides handy.

### 5. Balance schedule

Timezones are tricky. Especially if you and your team are on the complete opposite sides of the world. This, however, does not make the collaboration impossible, just trickier. When planning meetings it is important to **take into consideration the time differences**, national holidays etc. Aim to find a time that works for both of the sides, but if that is impossible be the side who wakes up earlier or stays up late in order to take the inconvenience off of your partners. Here, make use of already mentioned Google Calendar - it will ensure everybody knows the schedule, send notifications when before a meeting and help to overcome time differences.

### 6. Track performance

When handling remote teams it is important to keep track of the progress they are making. Make use of **productivity tracking software** in order to ensure your employees stay focused and on the right track. Those tools can also aid in performance reviews and help to set clear objectives within specified time frames. There are many goal tracking and OKR tools you can use.

Before implementing such tools remember to properly introduce the technology to the entire team. They should understand it is not a way of controlling them, just helping them to manage their time, fight distractions and improve concentration.

Those tools will also come in handy when **calculating payrolls.**

### Summary

A well managed remote team is what stands behind a successful outsourced project. \
**Clear expectations, good communication and proper tools are the key elements of an amazing collaboration**.

Nowadays, working with remote teams is often a necessity and although it is a great option to access talented engineers from all around the world, many leaders are scared to take the full advantage of such a solution. 

How To Manage Remote Teams

In the dynamic business environment companies are adjusting their management model or business processes to gain competitive advantage, suite best their clients, reach company’s goals or just adapt working environment to the employees needs. And all these reasons are about introducing, adopting and sustaining some kind of change. So there’s no secret that also agile organizations are in the need of change. 

A change can be challenging, sudden, painful or it can be welcomed and planned. We want to be more agile or maybe some of us realized that apart from our wishful thinking that we are the followers of Agile Manifesto we’ve honestly used it just to software development but not to the entire process of running a company. As we’ve implemented agile techniques to speed up development time and reduce risks involved while on the other hand became more responsive to customers needs we have to stop for a while and answer one simple question.

> Are we able to apply agility to the change management process?

If you are looking for some tips how to spark a change that engages people hearts as well as minds I would highly recommend you an amazing book by [Jurgen Appelo](https://medium.com/u/79df0d151f0e) – [How to change the world](https://www.amazon.com/How-Change-World-Management-3-0/dp/9081905112). On the 60 pages you will find a kind of framework to implement an organizational change in a way that everyone’s talents and creativity can be sparkled.

Jurgen’s Change Management 3.0 process is a mixture of well-known tools (he calls it the Mojito Method) which he combines with the four aspects of change management. With his guide you are not alone and if you just know your goal, team and organization you can get through the step by step process and make people more agile, better educated, more cooperative and more willing to adopt the change.

In the dynamic business environment companies are adjusting their management model or business processes to gain competitive advantage, suite best their clients, reach company’s goals or just adapt working environment to the employees needs.

Responding To Change - The Change Management 3.0 Process

[Stoos Connect](https://stoosconnect.nl/) was the event launched in January 2013 in Amsterdam in celebration of World Stoos Day by Stoos Satellite Netherlands. Unlike the Stampede event, the special feature of the Conference was that it could be audienced globally thanks to live multimedia streaming so that anyone, anywhere could watch the sessions.  

Behind the event stands a group of senior executives, business strategists, managers, academics and lean/agile development practitioners who first met in Stoos, Switzerland in January 2012. They endeavour to uncover a better way for leadership in contemporary organizations which are still relying on linear, mechanistic thinking which is reflected in the current economic crisis, increased inequity, bankruptcies and general disillusionment.  

A brief review of the topics of the conference, divided into one-hour-sessions, proves the innovative activity carried out by Stoos Network.  Among others, there were presentations on employee motivation, common mistakes companies make when managing their business culture or misconceptions in thinking about sales. To enlist the most prominent speakers, let us mention such names as [Daniel Pink](https://www.danpink.com/about), [Jurgen Appelo](https://www.jurgenappelo.com/), [Dawna Jones](https://www.frominsighttoaction.com/default.aspx) and Lisa [Earle Macleod](https://www.mcleodandmore.com/).  

[Selleo actively participated in the event](https://mikstura.it/stoos-connect/) setting up one of the three streaming locations in Poland as well as inviting and hosting the people involved in the management of software development houses from the south of Poland.

Among the presentations we liked most, there was the one by Daniel Pink, who dealt with the issue of motivation.

<YouTube id="cIdbq6nnY4U" />

He started with a seemingly trivial question, namely: “If you reward something, do you get more of the behaviour you want?” He shared the results of the survey conducted at the Massachusetts Institute of Technology (MIT). The findings were quite surprising:  in case of simple, mechanical tasks, a typical motivation scheme, (better performance = higher reward), common within organizations, actually worked. This turned out not to be like that in the case of tasks aiming at rudimentary cognitive  skills where larger rewards led to poorer performance. \
The phenomenon is known to psychologists, sociologists and economists and still business practitioners notoriously disregard the findings when designing and implementing remuneration policies. The conclusion is that when a task requires some conceptual, creative thinking, people will be no longer motivated by financial rewards. It could thus be perfect to pay them enough to take the issue of money off the table. According to Pink, there are three factors that affect not only better performance but also stimulate personal satisfaction. These are: autonomy (the desire to be self-directed), mastery (the urge to get better) and the sense of purpose. It might be a good idea to find enough room for them in your company.

The presentation by [Jurgen Appelo](https://www.jurgenappelo.com/) (the author of already well-known book [Management 3.0 – Leading Agile Developers, Developing Agile Leaders](https://www.management30.com/product/management30/) as well as a popular blog [NOOP.NL](https://www.noop.nl/) ) was linked to the previous one. He reflected on how to develop a bonus programme without destroying intrinsic motivation. As he says: “Paying people for work, without destroying their motivation, is one of the most difficult challenges for management. Regrettably, most compensation systems are unfair and unscientific”. He pointed out the common misconceptions of paying bonuses as something expected, relying on employees’ individual achievements, not depending on co-workers’ opinions and lacking the element of randomness.

<YouTube id="PVqcQ8GBFkM" />

Among the worth mentioning there was  certainly the presentation given by Dawna Jones entitled: [“3 Mistakes Companies Make When Changing the Business Culture.”](https://www.slideshare.net/EvolProvocDawna/3-mistakes-companies-make-when-managing-their-business-culture)

She enlisted:

1. Failing to manage the corporate culture,
2. Trying to change behaviours,
3. Underestimating the power of human spirit: vision-creativity.  

According to Jones: “The same principles Nature uses to keep a complex system stable we can use to dynamically adapt business cultures”. As well as this, she also stressed the importance of self-organizing by means of cleaning barriers to collaboration / innovation which brings about creating  high performance workplaces and achieving personal fulfillment. In summary she pointed out at “enormous possibilities which will appear when we replace force and struggle to survive with intelligence and creativity”.  

As well as the already mentioned, we should not overlook the speech by Lisa Earle Macleod which referred to an original philosophy of selling. The speaker is the author of a highly praised book entitled [“Selling with Noble Purposes – How to Drive Revenue and Do Work That Makes You Proud.”](https://www.mcleodandmore.com/what-is-selling-with-noble-purpose/) Macleod takes issue with the common belief that money is the primary motivator for top salespeople. She discovered that selling with some noble purpose is bound to outbalance that aiming entirely at sales goals and money. Behind such a statement there are 10.000 hours spent with top sales performers and the findings reveal that the Noble Sales Purpose (NIP) has proved to be a truly effective and generally outstanding option.

<YouTube id="sWaTtG1N1wI" />  

The next insightful presentation was that by Arjan Polhuijs whose area of interest embraces the impact of innovation. The speaker pointed at three worlds that need to interlink in order to assure truly robust and sustainable growth. These worlds are: a) the Imagined with such ingredients as vision, creativity, ambition, single-mindedness and the truly differentiated concepts; b) the Real which tests the practicability of the Imagined and c) the Human, which includes the set of qualities like ownership, passion, alignment and permission, without which even the perfect theories will never work in practice. By combining these three worlds with one simple, insights-led approach, Polhuijs produces a matrix which contains everything necessary to produce impactful innovations.  

We also liked [Steve Denning](https://www.stevedenning.com/site/Default.aspx)’s,”Towards the Tipping Point in Leadership and Management”. Apart from those there was a number of other interesting presentations; to mention a few, there were those by[ Niels Pflaeging](https://www.metamanagementgroup.com/), [Joe Justice](https://www.linkedin.com/in/jojustice/), [Olav Maassen](https://decision-coach.com/about/) and [Claudio Perrone](https://agilesensei.com/).  

The heated debate that followed, focused on both the presentations and the possible improvements that might be introduced in the future conferences. From our perspective, there might be fewer presentations with longer breaks in between, which would certainly facilitate longer and more fruitful discussions. We had one longer debate during the dinner break which was cool, taking into account that we were honoured to host managers from a few software development houses who rarely have an opportunities to meet their counterparts from other companies.There is quite apparent need for such contacts and events that help to foster them.  

![](https://2018.selleo.com/wp-content/uploads/2013/06/20130125_185325.jpg)\
The attention was also drawn to the varied quality of presentations which, perhaps, calls for pre-selection / pre-qualification procedures in the future.It might also be a good idea to consider organizing some such events with an industry focus.  

We would like to express our gratitude to both the organizers and the guests who came to share their management experiences.  

P.S.

For those trying to redefine their management and/or leadership approach it might be a good idea to probe deeper into the variety of topics which have been only briefly outlined above. The Stoos movement is not alone in pushing for a shift in the leadership and management paradigm. Some other movements that are genuinely dedicated to achieving a paradigm shift in leadership and management include the[ Management Innovation Exchange](https://www.managementexchange.com/), the[ Drucker Society Global Network](https://www.druckerinstitute.com/what-we-do/volunteer-network/), the[ Beyond Budgeting Roundtable](https://www.bbrt.org/beyond-budgeting/beybud.html), the[ Scrum Alliance](https://scrumalliance.org/welcome_to_scrum_alliance), the[ Agile Alliance](https://www.agilealliance.org/), the[Society for Organisational Learning](https://www.solonline.org/) and the[ Daedalus Trust](https://www.daedalustrust.org.uk/).

Stoos Connect was the event launched in January 2013 in Amsterdam in celebration of World Stoos Day by Stoos Satellite Netherlands.

In Search For Better Management Leadership

**In** [Innovation and Entrepreneurship](https://www.amazon.com/Innovation-Entrepreneurship-Peter-F-Drucker/dp/0060851139/ref=sr_1_1?ie=UTF8&qid=1325063740&sr=8-1)**, Peter Drucker discusses the various sources of innovation. One of them is technical knowledge, which is often the foundation of ventures set up by tech entrepreneurs. Drucker notes that science-based / technology-based innovation is loaded with extremely high risks. The window of opportunity is often very narrow and heavily congested, with large numbers of entrepreneurs and enterprises trying to exploit it. Under such circumstances, the** cost of delay (COD) is particularly high. In simple words, it is a question of how much revenue you will lose by delaying the product market launch. How much will you need to lower the price if your competitor manages to enter the market before you do?

**Paradoxically, even under such circumstances, many product developers act as though time was not money.** When building their products, they see the revenue potential introduced by new features, the associated development expense and even – though much more rarely – the increasing cost of product support and maintenance. Hardly do they quantify and consider the loss they may incur due to being late with the product launch. If they did, they would be able to make much better decisions when managing their project scope.

### **Capturing COD in the project’s economic framework**

**Don Reinertsen** [@DReinertsen](https://twitter.com/#!/DReinertsen) has offered a way to view the timeline within an financial framework, rather than just temporally,  for product development projects. The figure below presents his framework that has been modified in a way to better match the context of web / mobile projects we develop with our clients at Selleo. It was adapted from Reinertsen’s *[The Principles of Product Development Flow](https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009)__.*

By converting schedule / cycle time into cost of delay ($),  you arrive at a common denominator for all the dimensions involved and are thus better equipped to make more fully-informed economic decisions. In product development you are very often confronted with **trade-off decisions**, i.e., you cannot optimize one dimension without affecting the others. To cite an example, a Product Owner decides to add a new feature (and thus increase the scope of the solution implemented) hoping it will allow them to capture more customers or charge a higher price for the product. In doing so, however, they **simultaneously** increase the development expense as well as the support and maintenance cost. More importantly, with a fixed capacity of the development team, they often postpone the launch of their product, which means they incur a cost of delay and increase the market and technology risks involved. As another example, Product Owners may be tempted to speed up feature implementation at the expense of QA measures, e.g. tests, refactoring, etc. In doing so, they:

* reduce the scope and the associated workload (in the short run),
* reduce the development expense (in the short run),
* significantly increase the support and maintenance cost,
* reduce the cost of delay,
* affect risks in multiple ways.

Should they do so? It depends. Their decisions should be made upon considering their overall impact on the **product life-cycle profit**. Since COD has an impact on the latter, it should be part of the equation. It was already in the early 80s that Reinertsen published an insightful article that first quantified the value of speed, indicating that a 6-month delay can deplete 33% of lifecycle profits. In *The Principles of Product Development Flow*, published in 2009, he maintains 85% of companies still do not quantify the impact of COD on their projects and he comes up with a bold suggestion: *if you only quantify one thing, quantify the cost of delay*.

### **What happens when the cost of delay is ignored?**

Since schedule is usually expressed in time rather than monetary units, Product Owners may easily ignore the impact of COD on the economics of their projects. They may, for instance, increase their project scope AND lower / eliminate the product’s revenue potential. In practice, scope is often bloated – the products developed get loaded with a number of features which – from an economic point of view – should never have been implemented. Blindness to COD may very well be one of the main factors behind[ ](https://en.wikipedia.org/wiki/Scope_creep)**[scope creep](https://en.wikipedia.org/wiki/Scope_creep)** –  uncontrolled growth in a project’s scope. All in all, Product Owners often make decisions as though time was not money. Well, in fact, it IS.

### **What if you take COD into account?**

You may choose to remain blissfully ignorant of what it costs you to delay the product launch and increase some of the risks described above. There is an alternative, though. Convert the timeline into monetary units and **estimate** – however roughly – what it may cost you per day / week to delay. Is it $100, $1000 or $10.000 per week? **It will obviously be very project-specific.** Next time you come up with an idea for a new feature to enhance your product, you will need to make sure the expected value exceeds a much higher cost hurdle which includes not only development expense and support/maintenance cost but also the cost of delay. When it is fed into the economic equation, you will find it much harder to justify any new features, which will in turn reduce the risk of scope creep on your project. **If such a rigid economic approach was applied to manage the product backlog, many features would not pass the cost-benefit test. Scope creep could be more effectively constrained.**

### **A note on the fully loaded cost**

To make matters worse, the note and the figure above do not capture the whole intricacy of costs encountered in product development projects. It is often assumed that development and support/maintenance costs increase linearly as new features are added to the system. The assumption is very often false. Each feature added to the system introduces more complexity. **Complexity has got its own cost**, and it is exponential rather than linear in nature. Each feature added, makes it harder and more expensive to develop and integrate subsequent features and maintain the whole system. In other words, the cost of adding one and the same feature varies depending on when it is added. Viewed from a different perspective, given a fixed development velocity, you will implement ever smaller portions of scope as you progress through the iterations. Consequently, cost estimates should be adjusted for complexity if we are to make optimal economic decisions. It is only when we are sure that the **fully loaded cost** exceeds the expected value that we should allow a new feature to enter the project scope. Taking the above into account, it is only too reasonable to implement high-value features first and thus avoid littering the system with trivia which may block the way for important enhancements later on in the development process. **With COD quantified in the economic equation, you are much more likely to reduce the complexity of the system developed and thus lower the associated complexity costs.**

### **A note on risks**

A careful look at the diagram in Figure 1, offers another insight. When you delay the product launch in a competitive environment – for instance, in the market type with a first-mover advantage, you significantly increase the **market risk** of a competitor preempting the market space before you launch your solution. With delayed feedback, you are at least less likely to detect and respond to changes in customer preferences and risk no / poor product market fit. In both cases, you decrease the likelihood of ever materialising the expected revenue. You may also unnecessarily expose your product to **technological risks**, e.g. changes in the underlying technology. Again being fully aware of COD and accounting for it in your decisions on project scope may help reduce such risks.

### **Conclusion**

All in all, if you are a tech entrepreneur, as Drucker pointed out – your window of opportunity may be very narrow and congested. **Be fully aware of the cost of delay on your project, quantify it and treat it as an important factor to consider when managing your product scope.** It is yet another constraint to manage. Still it may be an eye-opener with a potential to help you build a better solution and a viable business venture.

### ***Post Scriptum***

Paradoxically, if you enter the market too early, the cost of delay can actually be positive, i.e., it can have a positive impact on revenue. In such cases though, it may simply be reasonable to wait rather than implement a product the market is not ready for.

Be fully aware of the cost of delay on your project, quantify it and treat it as an important factor to consider when managing your product scope.

Read our articles on Selleo Blog

Business

Technology

How To Manage Remote Teams

Responding To Change - The Change Management 3.0 Process

In Search For Better Management Leadership

Cost Of Delay Insights For Better Product Scope Management

Tell us about your project