João Cavalheiro was brought to my attention due to a talk he gave at a local engineering management group.

We can see the talk’s slides at Totally Networked Team.

Managing a remote team is starting to become a common thing, so I was very interested in understanding how João works and what are the pros and cons of managing a remote team.

Hello João, can you introduce yourself and talk a bit about your background and what you do?

Hello Pedro, thank you for the invitation!

I am an Engineering Manager, working for SUSE. I am interested in topics like decision making, strategy, and philosophy, and importantly, a good work-life balance with time to have fun.

My background is software engineering and I have been working in this area for over 15 years. I started as a developer, wrote thousands of lines of code in multiple languages, and moved to management 5 years ago. Leading teams is something I am very happy doing, and I strongly believe that making great people work well together is challenging, and a key factor in the success of any project. Nevertheless, I keep writing code - I like to keep my mind fit, and I am constantly looking for ways to test my ideas.

At SUSE, I am working on a product called SUSE Manager, as a remote manager of a remote team. I have now more than 10 direct reports, working from 6 different locations. The SUSE ecosystem is all about Open Source, with many public projects and hundreds of contributors world wide.

In your opinion, what would you say that represents “working well together” and what do you do to achieve it?

Working well together can be seen as the ability to achieve an informed consensus and long periods of focus. In its ideal state, people’s strengths are combined in a way that maximizes team output.

There is no “silver bullet”. There are however a few practices that can help. First and foremost, you need to know yourself and your team. This means understanding the personality of each team member and how well people work together on a certain context. This is not straight forward, as for example, two colleagues may be very productive on debugging and bug fixing sessions, but have a hard time cooperating in more open-ended topics where creative opinions and ideology play a stronger role.

As a manager, you must be aware that people and ecosystems change over time, and continuously adjust your vision. It is very easy to get trapped into cognitive biases, and you should be at least aware of which ones exist and how they can affect you. A common one is confirmation bias, where we tend to interpret evidence in ways that are aligned with our existing beliefs and expectations.

Having that well balanced ecosystem is indeed complex but yields great results. An easy way to disturb the ecosystem is when we have a new developer on the team. How do you onboard new people and make sure that a newcomer is up to speed efficiently?

Growing a team while minimizing the disturbance in the ecosystem should always start with a very careful hiring process, done at the right pace. Going too fast, without a proper structure, will certainly yield chaos. In my perspective, the personal side of on-boarding can be compared to integrating someone new on a circle of friends - it’s a lot about caring and sharing.

On the process itself, there are some rituals than can help creating a good experience:

  • Prepare everything beforehand (hardware, welcome kit) so that the first day can be stress-free
  • Have an on-boarding guide (wiki, Trello, your favorite platform) with good introduction materials about the team, the product, how to access tools and platforms, and answers for frequently asked questions
  • Always assign a mentor to the new developer. The personality fit is more important than the mentor’s tech background
  • Start with short term goals that provide short feedback loops
  • Reserve dedicated time for pair-programming and knowledge sharing sessions
  • Do all the above with a personal touch!

You talked about two typed of tasks: bug fixing and creative tasks. If you have someone that prefers bug fixing, what do you think of making them leave their comfort zone for creative tasks? And what if you only have tasks that they don’t like that much? How do you manage that?

I previously talked about those two types of tasks in the context of cooperation. In how, for example, pair-programming outcomes can depend on people / context / environment. In general, I find creative tasks being more popular. Bug fixing is usually not preferred, although it’s a great way to learn the code base of a product.

Having someone leaving their comfort zone requires psychological safety - an environment where experimentation (and eventual failure) are encouraged - and the right incentives. One of the most important ones in my opinion is proper support from colleagues so that the feedback loop is short. Every product / project has its unpopular tasks, and there will be less fun moments. Managers should ensure those tasks are distributed in a fair and balanced way.

All these things contribute to good team healthiness. How do you track that the team is healthy? And how do you detect issues that may impact it’s healthiness?

There are two main moments that are essential to track health: 1:1 meetings and team retrospectives. They serve different purposes, and should be used together. Both should happen on regular intervals - at least twice per month.

On 1:1 meetings, I focus on understanding each one at a personal level and on fostering friendship and trust. I prepare my meetings based on news to share, questions to ask, and ideas to brainstorm. I keep notes in a journal format where among other things I track individual happiness and motivation levels over time. Consistent and structured note taking can help to minimize misunderstandings and loss of important information.

The retrospectives on the other hand are useful to understand one to many relationships, in the sense of how each one integrates the group. In those sessions, everyone should focus on understanding if the overall process, rituals and tools suit the team. I believe in no definitive solutions - what works today can go wrong tomorrow. Factors such as the work environment, pressure levels and people themselves change over time. Frequent adjustments and a growth mindset can help to avoid many problems in the long run.

And how about performance evaluations? Do you do them? What’s your process? And if you don’t do them, what’s your opinion on them?

We certainly need a way to understand when something is going wrong with someone on the team. This is not easy, as evaluating software engineering work is quite subjective, prone to error, and the cost of being wrong and unfair to someone can have a huge impact on motivation. Actually, I believe this is one of the hardest parts of management work.

In my opinion, goal setting and performance appraisals should be used to measure each one against him/herself over time, to create motivation, and to bring people out of their comfort zone. When hiring someone, I pay attention to strengths / weaknesses and define an individual long term plan based on that. But, it is never that simple! People change over time, motivation has ups and downs, conflicts happen, and some traits only become visible after a certain time. Early warning signs will not be visible in a process that happens once or twice in a year, and real performance is hard to measure with standard PMP processes that focus mainly on the quantity / quality of deliverables. This is one of the areas where I prefer a less formal process, based on observation of daily work and discussions during 1:1 meetings. I do performance evaluations, and think they are important when used in the right way, but they should definitely not be a second order solution for hiring processes that are not well tuned or done in a hurry.

And in your current scenario you also have remote team members. How does being remote affect most of the processes we’ve talked about? What are the pros and cons from your point of view?

Remote-first communication principles are the most important aspect to take into account in your processes, even when only part of the team is working remotely. Personal communication between people that are together in an office is unavoidable and part of a healthy environment, so managers should focus on creating a culture where important discussions are always documented, no matter where/how they start. In my case, I am a remote manager of a remote team, being that the “local” part of the team has its own manager. I believe this split makes a lot of sense, as a remote manager will tend to feel the pain points of remote team members more accurately - a local manager with some remote team members would have to divide its attention between what happens in the office and what happens “online”. To have a functional team, local and remote managers should coordinate and promote some rituals that create an efficient and healthy environment for everyone:

  • Meetings should always happen on the same place, at the same time
  • No shared camera: everyone who is in the office connects from his/her laptop
  • Encourage frequent team conversations and knowledge sharing
  • Involve the whole team when on-boarding a new member
  • Promote get-together moments as frequently as possible

My mantra for remote teams is: “What is not written does not exist”.

Working remotely surely has some cons: on-boarding is harder, communication is harder, especially for people that are used to an office environment, and the sense of belonging can be affected. It is also harder for companies to deal with hardware logistics, HR processes and some aspects of operations. There are however very positive aspects: It is easier to get long periods of focus without interruptions, more freedom in time management, no commuting stress, and the possibility of having a personal, custom work environment. You can play loud music if you feel like it, and be completely in silence when you want. You can also work from different locations: home, co-working space, coffee shops, whatever other place where you feel productive. Not everyone will feel comfortable working remotely, so it is quite important to understand each candidate’s aptitude with as much detail as possible during recruitment process and ensure potential hires are aware of downsides and challenges.

Could you do an overview of your development process? Imagine that there is something for the team to build. What’s the common process going from the idea to a deliverable?

For all the non-small things, we start with an RFC process: One or more people on the team write a proposal on both the problem and ideas about the implementation. This document (written in Markdown) is the starting point of a discussion that usually happens around a GitHub pull-request, where all the team is encouraged to participate. The “RFC” (request for comments) process is intended to provide a consistent and controlled path for new features to enter the product while not limiting agility, and is a great opportunity to get more eyeballs on each design proposal. Quite often, ideas can be significantly improved once a wider group of interested people have a chance to contribute.

Since the team is big, we have it divided in squads, that have their own local lead and work on a per-mission basis. Once we get to a final version of a RFC, the implementation work is assigned to a squad. Very often the management team will define beforehand what is the right squad to work on a given feature, based on skill-set and available capacity. Usually, we prefer that the RFC authors are part of the squad that will develop the feature, to minimize overhead in knowledge transfer. Squads works together with the product owner in splitting the design document into smaller units of work and prioritizing those in the squad backlog. Not everything must go through the RFC process. For example, bug fixes or performance improvements that don’t change any core behavior can be submitted directly. Each squad is an independent unit of 4-6 people, including someone dedicated to testing and automation. Bugs are managed centrally by a “bug guy”, which is a rotating position, and then assigned to squads, with a preference for the squad where the feature was developed. On retrospectives, we evaluate each squad’s health, and make adjustments on team composition whenever needed.

Per-mission basis? Can you tell us how the missions work and how do you plan for mid-long term?

I mentioned mission as something to the effect of a large deliverable or epic story, in the sense that a squad is responsible for designing, implementing and maintaining a certain feature. There is also mid-long term planning, sure. On the product I am working on, there is typically one major release per year, with a defined deadline. The team works in a fully agile way while keeping a strong alignment with the goals defined for the release, having a lot of freedom in defining the best way to achieve them. Stories are maintained in a central backlog that is owned by the product team and kept in order of priority.

Thanks for participating and sharing your opinions and best practices. I learned a lot. To close the interview, would you suggest some topics that you’d like to see covered on an engineering management blog? And do you have someone to suggest for me to interview next?

Thank you again for the invitation. It was a pleasure to participate, and I hope the ideas we discussed here are helpful to other engineering managers. Some topics I would like to see discussed:

  • Are estimations evil?
  • Career paths and the role of individual contributors - how can companies promote growth outside management?
  • Common cognitive biases in management and how to overcome them
  • Devops / SRE - when to use each of them
  • Manager lessons to yourself when you were starting your career as a developer

Some suggestions about who to interview: