Dave Murphy and I decided to record a short video on what we have learned and the best practices that we have distilled over the years on how to manage remote teams.

We have a lot of leads at Ebury that are suddenly looking after remote teams, with this video we hope we can help you during this transition.

Hope you enjoy our video!

(Thanks to Nikki Heald and Dave Murphy for their contributions)

For about 7 years, I worked from home participating in a very large Open Source project  (Ubuntu Linux). Since then, I have continued setting up and advising companies on how to work remotely.

While you might be struggling with setting up on short notice your working environment at home, soon you will find your groove, and then the next big thing will hit you: Your usual ways of accessing information and the tools you use to communicate have suddenly, drastically changed.

When you were working in an office, you used Instant Messaging (IM) to communicate with people in other offices every now and then, but you largely relied on face to face conversations or office meetings. Now EVERYTHING seems to happen in IM.

Instant Messaging (IM) is a great tool for remote working but also has massive pitfalls. This is not just your problem but something remote organisations have been struggling with for years. Here are some key best practices:

Keep communication in the open. Set up team chats and invite people from other teams to ask questions in public channels, avoid as much as possible starting conversations on direct and private messages.

It is extremely easy to misinterpret and get frustrated using instant messaging. Keeping conversations in the open makes people think twice about the language they use. It also increases the possibility of someone from the group chat replying to your urgent message faster.

Be kind and patient.  Written communications are always easier for non-native speakers, but it can also make us overestimate the language skills of our colleagues and read too much into what they write. It might be that something you feel is aggressive or even offensive is just a side effect of this. At this point, take a breath, be polite and ask to have a video call.

Move detailed conversations to private messages and then to video call.  The recommended communication flow is to start in an open forum (group chat) , then if the conversation gets into details and it is clogging the channel, ask for it to be moved to a thread or private direct message, finally if still taking too long, set up a video call to address the issue at hand.

IM is asynchronous, really!. Instant messaging gives us the false sense that we have the full attention of our colleague, and that they are going to reply straight away. This is nothing further from the truth! Work or personal life can be interrupting and stressing out the person you are talking to, leading to long pauses or terse replies. Do not get frustrated, relax, they will get back to you as soon as they can.

IM is disruptive. Constant direct IM interruptions can lead to low productivity, this is another reason to use group chats. One good tip for teams is to designate a person (maybe rotate it daily) responsible for answering questions from other teams in your group chat. This means only one of you is getting distracted, but also gives a better responsiveness to the person asking the question.

Document decision outside IM. Instant messaging is ephemeral, even if it is in written form. If you take a decision in a group or private chat, follow it up with an email, a gdoc or whatever else your team uses to share documentation.

Don’t try to read everything. Very quickly IM proliferates and becomes an avalanche of information. Don’t have fear of missing out, you shouldn’t expect to read everyone’s messages AND don’t expect everyone to read your messages. If there is something that you really need people to read, use an email or arrange a meeting.

IM is not that social. Although it is a great tool for GIFs and Memes, it is not going to replace the social interaction that you are used to in the office. Instead, try leaving a video call, such as hangouts, open with the rest of your team members while you work on your tasks, just for chit-chat.

If you have any other questions or you are struggling with managing your team communications while working remotely, don’t hesitate to reach out to me!

One of the key things that motivate me every day to work at Ebury is the company’s passion to invest in its people. This comes directly from Juan and Salva (our founders) and it is lived by all of us in management positions.

But what does it mean for our Tech teams? Originally, when we were 10-20 people in Tech, this happened organically, but over time and with growth, it is important that career development also scales up and it is consistent across teams. 

During the last year and a half, I have been working with the team to define a framework that allows people to plan their development and have meaningful conversations with their leads.

At Ebury Tech, your career can take several paths, but it all starts with mapping what are 6 competencies that we really care about.

6 Competencies and 4 Levels

We have summarised our cultural values into 6 competencies, each of them with 4 levels. Leve 1,2 tent to focus on you, as an individual, while the others focus on your impact in your team(3) and the wider tech organisation(4):

• Domain Mastery: How good are you in your domain and do others agree? 
• Team Work: Do you help to achieve others’ objectives? 
• Continuously Improves: Do you improve and help others improve?
• Problem Solving: Can you resolve real-life issues with a simple solution?
• Business Impact: Deliver value, not just code
• Leadership: Do you set an example to others and take responsibility?

Not everyone  follows the same path

Although it might sound like something that you get from a fortune cookie, it really applies to personal development. At Ebury, we have define 3 loose paths to guide your development in Technology:

People Leadership – This is the path I chose, while still technical, my passion is to help others develop and work with team to achieve high performance

Technical Leadership (Architecture) – Another available path is to focus on your ability to design systems that deliver customer value and to work with others across the organisation to hone the best solutions for our clients.

Technical Leadership (Hands on) – Finally, there is also a path to lead by example, to bring change and best practices from within a squad. 

Putting it all together

Each step in a development path is defined by a set of behavioral and observable expectations. These are a level within each of the 6 competencies.

Note, that I have said observable. This is important because, in order to move from one step to another, your team lead will put you forward a case with examples to a panel of peers that will support your change based on observable facts.  Not everyone will move to the next step at the first try, but you will receive tangible feedback on how to achieve it next time. 

Digg deep, let me know what you think

There is no secret sauce to what we do to invest in our people, hence I am sharing with you and I look forward to your feedback. Hit me up in Linkedin

Why Tui?

At Bitnami, we have a bunch of useful command line tools that can be used to operate our stacks. I wanted to build a basic menu for the most used, so I didn’t have to remember each command and each argument. Then I thought It would be great to have a library that would work a bit like the cli go libraries, you can define the inputs and the function to handle the command and the user experience ‘just happens’. So that is why I created TUI

What is Tui?

This is a Basic Implementation of a text ui D.O.S style, that can be used to run CLI commands or you can define your own HandlerCommand to run Go functions. You can find it in my Github repo: https://github.com/vtuson/tui

Basic Structure is:

• Menu
• Commands – Each menu can have a set of commands to present
• Args – Each command can have a set of arguments that get passed

The idea behing TUI is provide a simple library similar to the cli libs like https://github.com/urfave/cli that allows you to build a menu based application for terminal users.

By default a CLI command handler is provided that is able to pass parameters as flag, options or Enviroment variables You can find an example app in the /sampleapp folder

Sample app

The project comes with a sample app under the folder /sampleapp

 cd sampleapp
 godep get
 go run app.go

Getting started with tui

A basic shell

Lets write a small application, You need to import the package, and create a basic menu with no option:

package main

import (
   "github.com/vtuson/tui"
)

func main() {
   menu := tui.NewMenu(tui.DefaultStyle())
   menu.Title = "Test"
   menu.Description = "Test app"
   menu.Show()

// This function handles input events like key strokes
   go menu.EventManager()

//Menu contains a channel that lets you know when the user has exited it
   <-menu.Wait

//Quits the menu, and cleans the screen
   menu.Quit()
}

Adding a command without arguments

Now lets add a small OS command that will run without need for arguments.

package main

import (
	"github.com/vtuson/tui"
)

func main() {
	menu := tui.NewMenu(tui.DefaultStyle())
	menu.Title = "Test"
	menu.Description = "Test app"

	menu.Commands = []tui.Command{
		tui.Command{
			Title:       "No Args",
			Cli:         "echo hello!",
			Description: "just being polite",
			Success:     "Yey it works",
			PrintOut:    true,
		},
	}

	menu.Show()
	go menu.EventManager()
	<-menu.Wait
	menu.Quit()
}

The option Printout allows for the output of the command to be shown to the user. The Description and Success are strings that will be use to add more context to the command execution. They are optional and dont need to be set if you don’t want to.

Commands with arguments

You can also add argument to command that a user can input

package main

import (
	"github.com/vtuson/tui"
)

func main() {
	menu := tui.NewMenu(tui.DefaultStyle())
	menu.Title = "Test"
	menu.Description = "Test app"

	menu.Commands = []tui.Command{
		tui.Command{
			Title:       "Args CLI",
			Cli:         "echo",
			PrintOut:    true,
			Description: "test of running a tui.Command with arguments",
			Args: []tui.Argument{
				tui.Argument{
					Title: "Please say hi",
				},
			},
		},
	}

	menu.Show()
	go menu.EventManager()
	<-menu.Wait
	menu.Quit()
}

Arguments can also be boolean flags, they can have a name (which can be passed as input to the command) or can be set as environment variables.

Adding your own handler

The library assumes that the command is an OS command to be executed using the provided OSCmdHandler function if the Execute is nil. If another handler is passed by setting the Excute value, then it will be called when the users selects that command.

Here is a simple echo example:

package main

import (
	"github.com/vtuson/tui"
	"errors"
)

//This is the customer handler c is the command object 
//for the command to be executed. 
//ch is the channel that can be used to return text to be displayed back to the user.
//The handler is executed async from the main program, 
//so you must close the channel when completed or the menu will hang 
//waiting for your command to complete.

func CustomHandler(c *tui.Command, ch chan string) {
	//defer close to make sure when you exit the menu knows to continue giving user the output
	defer close(ch)
	for _, a := range c.Args {
		ch <- a.Value
	}
	//if you want the command to fail set Error in the command variable
	c.Error=errors.New("It failed!")
}

func main() {
	menu := tui.NewMenu(tui.DefaultStyle())
	menu.Title = "Test"
	menu.Description = "Test app"

	menu.Commands = []tui.Command{
		tui.Command{
			Execute:     CustomHandler,
			Title:       "Args CLI",
			Cli:         "echo",
			PrintOut:    true,
			Description: "test of running a tui.Command with arguments",
			Args: []tui.Argument{
				tui.Argument{
					Title: "Please say hi",
				},
			},
		},
	}

	menu.Show()
	go menu.EventManager()
	<-menu.Wait
	menu.Quit()
}