When I started leading a team, I defined what I expect from each software developer and how I see the role of a team lead. At that point, I did not know about Engineering Ladders yet, otherwise I would have build upon that framework. Instead I created this diagram.
The diagram shows the three areas I expect every software developer on the team to put work in. Of course the bar is set a bit lower for trainees. As a bare minimum, I expect a trainee (after the onboarding phase) to deploy working code to production.
I’ll explain every area and the effects remote work can have on them.
System Integrity
- Clean code and easy-to-understand solutions which enable frequent refactoring
- Every committed code contains corresponding unit tests (new tests / adaption of existing tests). Go for the highest viable code coverage and ensure to test corner cases as well. For systems communicating with others, include pact tests or other relevant tests. Ensure that test data sets are up-to-date. Test data should be both varied and realistic enough to be helpful for presentations, exploratory tests, etc.
- „Nitpicking“ in pull requests is encouraged. Always strive for a better variable/method name. Have fruitful discussions in the PRs. When Pair Programming happens, I still expect a PR at the end.
- Maintain and improve development and production infrastructure
- Keep the overall system in mind and use similar agreed-upon patterns in every project. Especially in a microservice setting, it may happen that services are written in different languages, with different frameworks or at least different versions of those. There is still room for consistency. E.g. you could agree on a domain-based folder structure instead of one for technical layers. This will help when switching from one code base to another.
- Don’t introduce breaking changes to other/external systems or processes.
Remote work is beneficial for system integrity. The asynchronous workflows ensures attention to detail in ticket descriptions, comments and pull requests.
Team Velocity
- Onboard, teach, mentor team members and help them out if you can
- Define processes (e.g. regarding ticket system usage) and remind others of them
- Research & present new technology that may bring value to the team or business. If you’re an expert in something already in use, consider a workshop for those who are not as well-versed.
- Prioritize unblocking others (e.g. Pull Request reviews) over own projects
- Automate manual steps wherever possible (e.g CI pipelines, ticket system)
- Minimize downtime to team infrastructure and communicate it beforehand
- Find the right balance of communication with other developers. Don’t disturb them when they are in „the zone“ but don’t wait forever when you are stuck either.
Leading a team: Mentoring remotely
Remotely, I found that mentoring team members has become much harder. New or junior team members ask a lot more questions. They get stuck once in a while and they benefit from having the same working hours as their mentor.
I always tell new team members: “As soon as you figure something out, document it immediately. The next newbie will otherwise probably be stuck at the same point”. This is great – for the next newbie – but won’t help the person in struggle at all.
A valuable tool is a good integrated video call solution like Google Meet. It allows video meetings and screen shares, but also to create a “Jam” which is a virtual whiteboard and helps visualizing concepts. It may help to keep the video call running on mute while the mentee is working so s*he can unmute at the next blocker instead of having to schedule calls several times a day. Both for mentoring and for classical pair programming, you’ll need remote pair programming plugins for your IDE. The most mature one seems to be “Code with me” for IntelliJ, which works very well. In case every team member uses a different IDE you may need something like “Code together” (which I haven’t tried out yet).
Leading a team: Team communication
Getting the balance of communication right is also hard. Chat etiquette (read this!) becomes much more important in a remote context. As the volume of chat messages increases due to remote work, some team members, in an attempt to unblock others, may be very eager to respond to every chat message immediately. They won’t find time to do their own work anymore! A pomodoro timer may help. Use a physical device from your kitchen over an online solution when you work from home. The ringing won’t disturb anyone and you don’t have to switch tabs all the time, aren’t affected from poorly programmed pages or network issues.
Domain Expertise
- Become knowledgeable in the domain of your project (e.g. Accounting, Legal, …)
- Lead projects and own them, including planning and communication with domain experts, PMs, stakeholders. Conduct meetings with external partners if necessary.
- Document and/or present what you have learned
- Understand every requirement and anticipate business needs
- Be aware of the financial implications of your work and make cost-efficient decisions
Leading a team as tech lead
From a tech lead – no matter how many of these are present within an organization – I would expect the highest possible level of all of the above (system integrity, team velocity, domain expertise), plus:
- Remove blockers from the team. Monitor frequency and category of blockers and provide solutions to avoid as many of them altogether
- Find and move bottlenecks out of your team. Facilitate optimization, coordination, collaboration and curation. If that is still not enough, try to acquire necessary resources (infrastructure, team members, money)
- Ensure well-being of the team. Frequently check with every team member, hear their worries and provide solutions if necessary.
- Analyze shortcomings, offer training, offer growth paths. Some team members need a little push.
- Communicate frequently and clearly in all directions: With your team members, your superiors and other team leads. Ensure that everyone has all information present that they need for their tasks
- Drive and encourage large-scale innovation
If you are in a position to shape the entire department, read my previous article about how to build and hire for an awesome team.
In my opinion, these leadership tasks have become much harder due to remote work.
I used to „feel the room“ and immediately spot struggling co-workers. Now I have to more actively seek out for them. While there are signals that can be monitored, like lower participation in team chats, it is still harder than it used to be.
It’s not possible to have lunch together or to go on team events. Virtual team events still seem forced and strange.
Leading a team: Innovate and inspire
Innovation and starting a new project has become a lot harder. In the office, we could draw on a whiteboard together, then sit down for pair programming, jump up to the whiteboard again when a bright idea hit us, some more coding and “while you research this, I think I have some notes on the topic from a conference on my desk, I’ll get them”. Afterwards maybe add a few post-its to the whiteboard, then it hit us that we need a certain technology and a co-worker is an expert on that, so let’s go over to his desk and ask him about it.
With the right tools all of this is still possible remotely, but the latency alone for switching between tools – even if they are integrated – (e.g. creating a Jam from a running Google Meet call) slows down the process significantly and prevents inspiration.
The best tool for kickstarting a project and innovating in a remote environment is, in my opinion, Mozilla Hubs. It offers a room-like atmosphere where you can walk around with your avatar (like in a 3D game). You can add pictures to the walls, draw notes, move objects, and voice chat with others.
What tools and techniques do you use? Feel free to tell me in the comments!