Tech Lead Tips and Tricks: Easier Transfer of Developers Between Projects

Let’s talk about tech lead tips and tricks for the transfer of developers between projects. We all know there is no easy way to switch developers between projects quickly. Especially if you need to do it often as we do in the Q Client Support.

Each developer needs some time to get to know the code and the project. I’m not giving any magic tricks here. But I can share some tips and tricks that I discovered working as a tech lead in the Q Client Support department.

In the Q Client Support department, the developers transfer from project to project happens several times a month. In the beginning, Q Client Support looked like a company department that could easily get messy and developers avoid working there.

But we love challenges :).

How to reduce stress

The most important part was to reduce stress for developers.

When developers come to work for the Q Client Support department they usually get max 4 projects to handle.

They need to make changes to the project they know almost nothing about.

Most of the time there is no QA or another developer working by their side.

People that were working on the project before, QA, PM, BE, and FE… work on other projects now and the developer needs to schedule a meeting just to ask a few questions, help or review. Or even worse, several people working on that project already left the company.

Here is what worked for us:

 

Casual daily meetings 15 to 30min long

 

We have so much fun and fulfilled time on our daily calls that one colleague said that we actually have small team buildings. The important thing is to talk with people and make fun.

In Q Client Support, developers are working on multiple different projects. When someone talks on a daily sync, others don’t fully understand what the other developer is talking about. But there is so much we can learn from each other anyway. Also, it is good to know that you are not the only one in this situation and have a group of people who understand and support you.

 

Lower your expectations

 

In Q Client Support we have lowered our expectations. It is not the same working with a great team that has PM, BA, QA, minimum 2 BE, and 2 FE on the project using the Agile principle and working mostly alone on a finished project without detailed documentation with a limited amount of hours a month.

A developer gets in direct contact with a client more often on a solo basis. A developer is in the open. Sometimes the client thinks that the developer is a “one-man show” and asks questions like “Can you make me a one-page microsite with just several links, products, and categories?” :D.

You can’t wait to share that on daily calls in the Client support :D.

You should:

Lower down criteria for bonuses.

Give more time to a developer to get the know the project.

Give kudos when someone earns it.

 

Record all relevant meetings

 

If you have demo meetings, handover meetings, and meetings with clients where you get some important information, ask participants if you can record the meeting.

If one developer was at that meeting and tomorrow some other developer must take over the project (or the task) you don’t have to spend additional time to demo and transfer important information.

Create an example of a project handbook

 

Create an example of a project Handbook that will represent what you expect of a Handbook when you are taking over some project.

Communicate clearly what your expectations are from the project coming into your department. For example:

• Finished open tasks (you can’t transfer something that was in the “Client Review” column in one department into the “To Do” column to another department)


• Helpful README documentation in the repository


• Clean repository (main branches in sync, no leftovers like unresolved Merge requests)


• Clean backlog (removed what is deprecated, left only what needs to be done)


• Demo


• Project handbook (documentation of all important details, flows, setups, environments, and project-specific stuff – necessary for the new developer to quickly start working on the project)

Review the projects

 

It is helpful to track what kind of projects are coming to your department. To be able to do that ask developers and DevOps to review the project.

Document issues that developers encountered and share them with the team.

Talk with sales to adjust packages and contracts with clients to help you cover real issues and customer needs.

Use virtual desktops like Amazon WorkSpaces

 

This might not work for mobile development. But for most of the backend and frontend, we use Amazon WorkSpaces.

If you like to try how it works here is the quick setup guide:

 

1. Launch Quick Setup Guide

2. Create directory

2.1 Be sure that you are in the correct region. Select the directory type “AWS Managed Microsoft AD”.

2.2 Choose a Small AD Connector. AD Connector is a proxy to your existing Microsoft Active Directory.

2.3 Enter directory information. Select Edition that matches your business.

2.4 Choose VPC and subnets

2.5 Review and create

3. Launch WorkSpaces

When you have the directory ready you can launch WorkSpaces.

3.1 First select Directory.

3.2 Create different users for each WorkSpace; you can use the same email. This is important later to track the usage of a single WorkSpace.

3.3 Select bundle and storage sizes. Standard with Amazon Linux 2 is a free tier. You can increase storage size later, but not decrease it after you launch a WorkSpace.

3.4 Choose AutoStop mode to reduce the cost of developers who are not working full-time on WorkSpaces.

3.5 Review and launch WorkSpace and you are done!

When you launch your WorkSpace you will see your new WorkSpace under WorkSpaces. At first, it will have the status Pending, but that will change quickly.

Amazon allows 4 WorkSpaces per region by default. But you can ask them to increase that limit.

To start using Send developers an invite. Select WorkSpace you like and under Actions click Invite users.

This image shows what an invitation looks like. You can just c/p and send it to the developer as an email or via some messaging app.

The invitation contains the link for the WorkSpaces Client installation. It is important to have a stable internet connection to be able to use it.

The invitation also contains a registration code. The registration code is the same for WorkSpaces in the same region and directory, so it will not ask them again when they enter this code. But if they need to, they can change it.

The login screen has a link to change a registration code.

There is also Forgot Password link that you should use when the password expires.

It is not possible to work on the same WorkSpace from multiple WorkSpace clients at the same time. Only one user can be logged in at the same time. If another user logs in another will be disconnected.

Setup local environment and write a guide for developers on how to work with virtual desktops

 

Install the tools that developers in your team usually use on their machines like JetBrains tools, Visual Studio, Slack, Google Chrome, DBeaver… and give open hands for the rest.

Even simple things can slow developers down. If they don’t know how to structure local folders and files, where to put materials or temporary dumps and other stuff.

If they are not sure what is installed and what is not they need to check first. So it is best to have all that info in one document that is easy to read.

Especially if there are some known issues, document them too. Don’t let developers bump into them each time by them selves.

For example:

Known issues

• AWS WorkSpace Client application requires outbound access to 443 port (TCP). This means that we can’t expose Nginx on port 443. If your docker-compose up is failing because of this comment out in the docker-compose file, the part that exposes nginx to 443.


• If curl from the docker container is not working, try adding this into the /etc/docker/daemon.json file. Create a file if it doesn’t exist.

{ 

    "debug": true, 

    "experimental": false, 

    "dns": ["8.8.8.8"] 

}

After that flush changes and restart Docker

$ sudo systemctl daemon-reload

$ sudo systemctl restart docker

 

Have a calendar to track who works on virtual desktops

 

You don’t wish to interrupt the developer and give access to another developer to the same WorkSpace at the same time. It is best to have a calendar to check who was the last working on some WS and communicate the switch.

Document changes made on AWS WorkSpaces

 

Document each project setup or software installation made on AWS WorkSpaces. This should be done by the tech lead or team lead. Every time you need to switch developers just check AWS WS setups and you know which one you need to hand over to another person.

 

Setup budget and alerts

 

Amazon gives you the option to set up a budget and get an alert when the budget is almost used.

You can easily track and manage your costs in AWS Cost Management.

You can set up an S3 bucket to get detailed, hourly, cost, and usage reports.

Control WorkSpace usage with cron job

Sometimes people forget things. The developer can forget to disconnect from the WorkSpace client. Putting the device in sleep mode will not always trigger AutoStop. To keep the price under control, shout down WorkSpaces automatically after working hours. You can set up a local cron job for this if you install AWS CLI locally.

For example

#!/bin/bash



aws workspaces stop-workspaces \

--stop-workspace-requests WorkspaceId=ws-88aBa33ttl

Conclusion

 

You can laugh, you can cry, you can leave it or you can try. You can also do everything with supportive colleagues and a shared local environment. Good luck!