One of the challenges in running a remote team is finding ways to enable and encourage team bonding. With employees across the globe, it is hard to get everyone together regularly. If you do not encourage the team to interact socially then it is easy for team members to feel isolated.
Up to 65% of remote employees report that their teams only discuss project work.
These activities should not be mandatory as not all employees find them appealing. You should aim to run a few in parallel to cater to as many employees as possible. There is no limit on what you could try especially with the magic of video calls and Slack.
There are a lot of ideas on the internet such as:
Virtual Coffee Break. Arrange a time for a virtual call where team members connect from their local coffee shops. The aim is to discuss their personal lives, sport, entertainment or professional topics. You discuss anything but your project over your favourite brew.
Knowledge Sharing. Start a book club or arrange lightening talks to teach your team about new tools or libraries. These shouldn’t be about things directly relating to your project.
Fun Slack Channels. Pictures of your pets, film quotes, Dad jokes or selfie channels.
Board Games. You can arrange leagues and tournaments for games such as Chess, Drafts or Monopoly.
Team Lunches. Like the Virtual Coffee Breaks but you arrange to all meet up while eating lunch together. You can take this further with sharing recipes and agreeing to try each others.
When Ben, our new Head of Product joined Open Energy Market he suggested a music sharing exercise to bond with the team. On a Friday each team member gets to submit 2 music tracks on our team Slack channel. Once all the submissions are in then the team votes for a winner and Ben adds the winners to a Youtube playlist. There are no prizes. It can get quite competitive with some team members (in a fun way). It has become a staple of our week and for a music lover, it’s a great way to discover some new artists. There is a suprising mix of artists and genres for such a small team.
For anyone interested I have created a Spotify playlist of the submissions which I update each week.
I’d love to hear about your team’s approach to team building and bonding so please share them with me via twitter or email.
This week my family and I booked a holiday. After much discussion, research and reading Tripadvisor, we are off to Mexico. As it is 2018 you might think that I booked the trip online. You’d be wrong. We ended up booking with a travel agent. This was due to some additions that we wanted to make and a room we wanted that wasn’t offered by a UK online company.
In the UK there are becoming fewer and fewer actual travel agents to go and book a holiday with. I am not going to name and shame the company that I booked with. They offered mediocre customer service. But, the thing that stood out as I endured a near 90-minute booking experience was the poor use of technology.
When we arrived we sat down with the agent. The first thing they did was to bring up the holiday in one browser that we had found on their online site. In another browser, they then logged into an internal version of the company website. They then pulled out a paper notepad and started to scribble various references down. They started to write down the online and in-store prices. Then, on paper, they started to work out any discounts they would be able to offer. Their internal site was pricing the holiday at over £1000 more.
It then descended to a point where they had to log in to over 6 online systems. These covered the online and in-store versions of the company website, insurance website, payment system, airport parking and excursion websites. The thing that really stood out was that as the agent logged into more systems the use of the paper notepad grew. Each piece of data required by the payment system was written on the pad before manual entry. When various product shortcodes were required they were obtained from a printed sheet.
Security was worrying. On a couple of occasions, they shouted out to a colleague for a password. The response was then written on the notepad. It would seem that for at least one system there was a shared login. The scariest thing of all was the notepad paper being scrunched up at the end of the process and being thrown in a trash bin.
There was so much that made me take note. Why does this company have an internal and external website for their holidays? Why not have one that lists both prices. Why make the agents calculate the discounts when you have the data sitting on a server? Why is the payment system separate from the holiday data? Why is there no integration? Why not integrate with your partner’s for insurance and extras? So many why’s.
The agent took 90 minutes to book the holiday for a few hundred pounds more than the online price. In the time we sat there the staff lost 4 potential customers because all the agents were busy. What could the impact be on that business if they integrated their systems? How much quicker could they book a trip for a customer if there was no writing prices and references down? What if they could halve the time it takes to book a trip and match the online price? I am guessing fewer mistakes, happier staff, much happier customers and more revenue. By allowing their technology to remain so disjointed they are harming their business.
Have you worked for a company that does not realise the danger of disjointed technology or seen it in action recently? Message me via twitter or email.
When starting any coding project you should use Version Control software. Used to track changes to your code this software also allows for many people to work on the code at once. It may seem overkill but these systems provide a safety net for even the smallest shell script.
While there are many options out there, the most popular option is Git. Originally developed by Linus Torvalds the software quickly gained fans in the Linux Kernel community. Open sourced and released under a GNU licence, a community of developers and tools grew around the software. Github, a service designed to simplify the process of working with Git has also helped its growth.
There are many good tutorials for learning how to use Git such as:
The issue I want to address is when you start a project that has the potential to grow fluently. It is easy to work with Git by branching off of master and doing some work and then merging it back in. In fact, there are a lot of very large companies that do just that. But, if you’re a small company with limited resources it is hard to track release and development branches. If you use a centralised service such as Github or Bitbucket they offer integrations. For example, these integrations will allow you to automate your deployments via Git. They may also hook into your work management software such as Jira. Given that complexity grows in line with the number of branches, what you need is a workflow that brings some order.
Enter Gitflow.
Gitflow is not new. In fact, the article referenced above dates back to 2010. Gitflow specifies a way of setting up your Git repo and working with the branches. Its aim is to segment working code from development code. It allows developers to isolate features in development away from testing. Once tested the code can then be pushed to Production.
Within the workflow there are 4 main branches:
Master - This is your production code. The code on this branch should always be working, tested and deployable. No development changes should never be merged here directly.
Develop - This is your developers currently building code. Think of it as the master branch for development. Feature branches are pulled and merged to develop.
Release - The release branches are pulled from your develop branch and merged into the master and develop branches. The branches live for as long as you need to test the code/features within them.
Hotfix - These branches are pulled and merged from the master branch and are used for performing small bug fixes in your production code.
This set up gives you a lot of flexibility. You can have a team of developers working through your features for a sprint at the end of which you create a release branch. That branch is released to your staging site. While being tested your developers move on to their next work. Oh, wait, someone found a bug in the release branch and one of your developers fixed it. That fix lives in the release branch until the testing is complete. A couple of days later the testing is completed and the release branch is merged back to the develop branch. This means that the fix that was made is retained. The release branch is also merged to master and pushed to your production site. All the while this was happening multiple feature branches have been created, reviewed and merged by the developers. But, it is easy to track what is going on, which is the power of the workflow.
Gitflow is adaptable to your DevOps workflow as well. For example, at Open Energy Market we have Azure hooked up to our master branch. We have a Staging branch set up which our Azure Staging environment connects to. When commits are pushed to either branch it triggers an automatic build and deployment. Due to some of the bigger features, we have been working on of late, we have been able to manage many release branches with ease.
Gitflow’s popularity has lead to its adoption in many tools such as the Source Tree and Git Kraken GUI’s. There are also many console-based implementations, the best of which is nvie/gitflow.
There are other workflows available for Git. From my experience, Gitflow is ideally suited to small teams with limited resources. Once you have your development process then Gitflow is a great supporting process.
Have you used Gitflow for a major project? Are there better workflows for your usage? Message me via twitter or email.
About 9 months ago I wrote some advice for candidates based on reading a lot of CV’s. We are hiring again at Open Energy Market and I have carried out many interviews over the last month. A couple of stand out candidates made the process engaging and fun. Most didn’t for a variety of reasons. So I thought I would share, publicly, some feedback.
Research the company
When interviewing for a company it is rude to know nothing about it. Every company has a website, files accounts or registers with professional bodies. The information available varies. But, you should be able to answer the question “What do you know about our company?” The answer should also be better than “You work in industry x” and should prove effort on your part. You should be able to provide evidence that you have done your research in your answer. Who does the company work with, what is the company vision, how are they different from their competitors.
Just to be clear “Not a lot really” or “Nothing” are unacceptable answers. (Both of which were provided during the latest interviews).
Research the role
You will have a job description for the role. Use it to prepare.
Prepare to answer questions about the technology stack used. Your knowledge of that technology will be interrogated. Brush up on any parts you use less often. Prepare to answer questions about the technology’s ecosystem and architecture pro’s and con’s.
Have examples of how you have solved problems using the technology stack. It can sometimes be useful to have code snippets. These can act as conversation starters. I expect candidates to explain how their experience is relevant to my role. Be honest. If you have tried solutions that haven’t worked as expected, share and be clear on how you overcome the issues.
There is nothing worse than asking a candidate a question and getting yes/no answers. A good candidate will engage in a conversation about technology and share opinions.
You are not an island
When discussing a technology or library, the answer “I have my own version that is better than x” is usually a red flag.
Why do you think your framework is better than Bootstrap? Why is your ORM better than EF or Dapper? What makes you better than an open source community or a corporate development team. Obviously, this should be applied on a case by case basis. But, it tells a lot about a developer who makes that kind of statement.
(FYI if you are Linus Torvalds, Guido Van Rossum, John Resig or DHH this section probably doesn’t apply to you.)
Take breath
For a recent role, we interviewed two candidates at the polar ends of a long spectrum. One candidate took 22 minutes to introduce themselves and provide a “brief” career history. They literally didn’t take a breath. The very next candidate was the opposite. They said nothing more than the very least they could get away with.
There is a middle ground. Answer questions in a considered and detailed manner but do not bore people. Remember that the interviewer will want to know how relevant you are to the role. Being told about your paper round is of no value. If you do not know an answer then be honest and do not stumble to a bad answer.
No Arguments
Developers like flamewars and arguments. They are by nature opinionated people with strong views about everything technical.
Be flexible in the discussion. Don’t forget that interviews should be a two-way process. If you disagree with a statement or opinion of the interviewer, then counter. Do so in an educated manner and provide context for your opinion. The interviewer may even throw a curve ball question in to see how you react.
If something is a deal breaker for you then wrap the interview up there and then in a professional manner.
Keep it calm and polite.
Have a working environment
At Open Energy Market we carry out interviews via Hangouts. The main reason we do this is that our development team is fully remote. That means that candidates should be comfortable with video calls. It is the main method of daily communication. Doing interviews this way proves a candidate can be comfortable working in this way.
If a candidate takes 15 minutes to sort out their sound or video issues it’s a black mark. Hangouts is not a cutting-edge new technology. It is extremely easy to set up and if you are attending an interview using it you should be tested and ready to go.
A recent candidate was unable to operate Hangouts at all. Instead, they invited us to use their existing employers Skype for Business service. Not a good impression.
So, that is a brief summary of advice from 20 or so interviews. Every interviewer is different and the approach taken varies on the role. However, if you are prepared and can calmly and clearly explain how your skills and experience fit the role requirements you will standard a fair chance.
If you have any comments or would like to discuss this topic further then please message me via twitter or email.
This is a great validation of the work we have done at Open Energy Market over the last 5 years. The technology we have built has already changed the corporate energy market. Using the investment to enhance our technology further we have some exciting plans for both buyers and suppliers. I am looking forward to the next phase for Open Energy Market.
Welcome to my site and blog. You can find out about me and read my thoughts on code and technology, start-ups and building things.
