Working in distributed / remote environments 4: one on ones (1:1s)

An important part of any (people) manager’s work is to evaluate how things are going for your team members, the people under your responsibility. When managing distributed or remote teams, the one on ones (1:1) become even more relevant than in collocated environments. In extreme cases, they represent the only opportunity a manager to have an honest conversation with a member of your team.

The older I get, the more relevance I provide to 1:1s. I have found myself in several occasions feeling that my manager did not paid enough attention to me, to the problems myself or my department or team were going through, that affected my motivation, the project I was working on or the organization as a whole. If is not a fun feeling, specially in remote environments, where isolation plays against you. In all cases, there was a common factor: 1:1s did not work well.

Whenever I can, I like to have short but frequent 1:1 with my team members. My preferred option is a weekly 25 minutes meeting through video chat, at the beginning of the day. I try to avoid 1:1s late in the afternoons, depending on time zones. This is tough to achieve when working with Asians (I am located in CET/WET), but it is worth making the effort.

Why weekly 1:1s

A significant number of people tend to dislike such frequent meetings initially, specially when working remotely remote. In my experience, it is often underestimated how important it is to have a healthy channel with your manager, specially when times get rough for whatever reason: personal reasons, due to frictions with colleagues, workload peaks, changes within the organization, strategy shifts, etc.

If you experience such resistance, I recommend you to invest some time early on to justify why you will schedule these weekly 1:1s. Do not take for granted they will agree with them. I provide the following arguments:

  • If I am the new guy, I need to learn about how things work so I need help. Having frequent meetings the first couple of months will help me to shorten my on-boarding process.
  • If you are trying to push changes, you want your direct reports to participate in the decision making process. Use these meetings to get feedback from them.
  • If anybody under your direct responsibility just joined the team, you want to make sure their landing process is smooth, specially if they manage a team themselves.

There are two additional points that help to overcome significant resistance to have weekly 1:1s:

  1. When there is no relevant topic to talk about or the team is experiencing a working peak, the meeting can be skipped if there is a common agreement. I rarely skip two 1:1s in a row though.
  2. These meetings are primarily to deal with people management topics, not execution topics.

In most cases, if you have regular performance evaluations, there are always topics to go over during these 25 minutes slots, that might help to develop your colleagues professional career and performance. As a manager, it is a great learning experience too.

There is a special case I try to pay special attention to. There are times in which a member of your team is already overloaded with too many meetings. Your priority then is to offload that person and clear her agenda. 1:1s become then the desired useful tool. The same principle applies to you. If you perceive the 1:1 with your manager as inopportune, you might need to take a closer look at your agenda. They never are, or should be.

Ground rules on 1:1s

Before the first 1:1 with a member of my team, I prepare a shared document including the most important ground rules for the meeting. Most  ground rules are generic so I will focus on those influenced by the special nature of a distributed or remote environment (D.R.E.):

  • Meeting goal: write down clearly the meeting goals and priorities. I recommend to put people management topics first and, only when those are covered or there is none, move on onto other kind of topics. In the absence of face to face interactions with her colleagues, other managers or yourself, these kind of meetings might be the only chance to deal with people management topics a person might have in your organization.
  • Use corporate approved channels only: this might sound like an obvious advice but there are occasions where it might become a topic>
    • I have found many engineers, specially in the Open Source space, unhappy with using proprietary tools or tools that imply the installation of an application or a plug-in that track data from their machines. This specially sensitive for contractors. Be sensitive with this case if you can.
    • When working in Open Source projects, having a clear separation between what is or is not confidential might not be easy. Confidential information should flow in corporate approved channels only. 1:1s should be consider as such so the default video chat tool might not meet legal requirements in this regard.
  • Define the process to change the schedule of the meetings: the idea is to be flexible about when to meet but strict about how the process of changing the schedule of the meeting should be done, specially when it comes to notify changes in advance. Both parties need to consider how difficult it is to manage agendas when working in distributed environments where people is located in a a wide range of time zones.
  • Start on time: add this explicitly along with how to communicate that you will be late. Remember that if people around you systematically joins late, you will end up reproducing such behaviour. This is a hard personal battle to fight.
    • What has worked for me in the past with people that systematically joins late is to agree to make a note in the shared document when your counterpart or yourself arrive late. In the performance evaluation, when you find several of these notes, the point become a topic as something to pay attention to in the coming evaluation period.
    • The toughest situation comes when executives or customers are frequently late, specially when they are not remote. Do not let the situation get into a point in which you become passive aggressive about it. If you give up with them, you will end up giving up with your team too. Make it a point.
  • Describe what is the shared document for and how to use it: I will come to this later.
  • Add links to the description of key processes and HR documentation: mature companies in distributed environments tend to have well defined written processes. The escalation process is just an example. I like to explain it so the other person understand what will it happen when he request you to escalate a topic.
  • Add the contact information of the participants: I find it very handy.

The shared 1:1 document

The mission of this document is to track those conversation points that any of the participants consider relevant enough. Every time I make sure we both agree with the written text. This is extremely important to me. If there is no agreement, we work on the redaction of the text until we do. I there is no possibility to reach an agreement, both entries, mine and hers should be included.

In my experience, the shared document only works well if it is confidential.

The goal is to reflect when a common understanding has been reached and, if it hasn’t, where is the discrepancy. By default, I suggest to track at least the following topics in the shared document:

  • Agenda: during the week I introduce an entry in the document for every topic I want to raise in the meeting, if there is time. Sometimes there is no time so adding some description of the topic prevent you from having a additional meeting to deal with them. It also helps me as a self note. I tend to easily forget the topics I want to raise during these meetings, specially when I have several with different people during the week, or they are bi-weekly instead of weekly.
  • Escalations: when for whatever reason I have to escalate a point, I make sure it is written down in the document, in agreement the other person. This is very helpful when the escalation process or the resolution takes some time.
  • ToDos: sometimes the outcome of a conversation is a task. I keep track of them and who is assigned to.
  • Points related with the performance evaluation process: these points should only be written down under agreement.
  • Outcome of interesting conversations for one of both parties.

Any other topic can be translated to the document if any party wants to. My 1:1 shared documents frequently have the following sections:

  1. Document title: 1:1 (name surname):Agustín B.B. (this helps me to find the document easily.
  2. Contact info of both parties.
  3. Index
  4. Entry for each meeting with the following heading: Meeting #. Weekday YYYY/MM/DD
    1. Closed ToDos (on this week)
    2. Agenda items
    3. Open ToDos

Some other tips I recommend you to consider when it comes to using the document are:

  • Be short and accurate. This is not about tracking everything. It is not about taking minutes but about sharing a common understanding and agreeing on the outcomes.
  • Provide context. This document is meant to be consulted several times per year, like during performance reviews, for instance.
  • Although the document is confidential, write as if it is not. This is a general rule, in my opinion, to every communication.

Meeting how-to

I always start the meeting asking the person on the screen if there is any point she wants to raise. If an additional meeting is needed to go over the agenda, it should be because there was no chance to go over my points.

In my experience people with none or little experience in distributed or remote environments tend to avoid raising topics at the very beginning of the conversation. Being direct, adapted to the environment, takes some time. It is a learning process we all have gone through. If that is the case, I ask general questions about how is she doing. If nothing is raised, I like to check a couple more times during the meeting.

Only if there is time left after people management topics have been discussed, I introduce execution related topics. In any case, I like to dedicate some minutes to work unrelated topics, at the beginning or the end of the meeting depending on the agenda.

I like to configure the calendar to get a notification in my screen 5 and 1 min before the end of the meeting so I avoid cutting down the conversation abruptly. It is so easy to loose track of time…

Some additional points to consider

Do not forget about the intrinsic limitations of a communication through video chat, specially when feelings are involved. Compared to a face to face conversations, this is a serious handicap you will have to overcome as manager. Creating the right atmosphere during the good times will help you a lot when rougher times arrive, and they will.

These meetings might be the only chance for your counterpart to “talk to” or get “first hand information from” the organization. The impact of your words might get magnified by these two circumstances.

Since the nature of the relations between peers is different in remote environments than in collocated ones, managers has a higher chance to get “caught by surprise” during the one on ones by a problem, complain or a demand you had no previous information of.  If that is the case, be transparent about it and ask for some time to digest the information and provide a credible answer. Schedule another meeting if necessary. There is no award for providing a quick answer.

Do not underestimate the language barrier. It is already hard enough to talk with a manager openly through a screen about a sensitive topic. Add the fact that you have to do it in a language other than your mother tongue and you will soon realise that the shared document might work as a great ally. Cultural barriers are also higher to overcome in remote environments, as I have mentioned in previous posts of this series.

Conclusions

1:1 meetings are an essential “resource” for any manager. As expected, the remote or distributed nature of a working environment has a significant impact on this “tool” which makes it harder to master, at least in my opinion.

I prefer to have frequent and short check points than infrequent and long meetings. I also prefer to schedule an additional meeting than overrun the current one, since you loose very little time in joining/dropping from a meeting when working remotely. This might not be the case in distributed environments.

I like to create, pay attention to and put effort in translating the outcomes of interesting conversations into a shared and confidential document, keeping in mind that 1:1s are above all, about having an honest, transparent and direct conversations. Having them through internet makes the communication tougher which requires a higher doses of experience from any manager to make them meaningful, specially during stormy weather.

Dear software manager, working in the open for the very first time? Face the challenges (II)

This post is the continuation of the previous one, titled Dear software manager, working in the open for the very first time? Face the challenges (I)

Focus shift

I understand the transition that a front line manager needs to go through when moving to work in the open as a personal journey, mostly because the challenges described in the first post of this series, specially those related with personal values, have had a significant impact on who I am today.

I believe that working in the open long enough will charge not just the way you understand your work but other aspects like your personal relations, your view as a professional… you mindset. The key question to me is how to drive that change in a way that you do not use trial-error as the number one technique to learn, knowing that, unlike in the case of most developers, as a manager your mistakes have a significant impact on those around you.

I strongly believe that habits change mindsets, not the other way around. Which translated to a job means that in order to adapt to a new way of thinking it is required to work in a different way.

So in my opinion, in order to succeed faster as a front line project manager in the open you will need to embrace new habits as a manager. And I know by experience that the transformation process is faster when you realise that it is not just about changing the mechanics of your work but also about shifting your focus.

This is the core idea I want readers to take away. It is not just about adapting what you were doing already within your company, but also shifting the focus of your work to make a meaningful impact in a different area.

From autonomy to alignment

I created a model that helped me to understand where I was, what I needed to focus on in order to succeed as a manager, as a team, as an organization or project. I will provide some information about this model since so I can use it to describe that focus shits I mentioned before.

My personal model can be summarised in a cycle with four stages. I have written about this before, by the way:

toscalix management model
toscalix management model

I came to this model through a bottom-up approach, as a result of my experience working in open organizations. The structure in these four stages came from two key popular references:

  • The motivation model described by Daniel Pink in his famous book Drive.
  • The challenges described by Nilofer Merchant in her book The New How, when moving from strategy to execution in order to innovate. Those challenges many organizations go through led Nilofer to the description of the air sandwitch problem and how to approach it: alignment.

You can find references to both books in the Reads section of this site.

In corporate/in-house projects, front line managers mostly focus on what in the model refers to autonomy. They are perceived as successful when the people they manage are efficient which build trust on development teams, who get more room to work their way. Managers can then focus on effectiveness, risk evaluation, and mitigation activities, etc. increasing their impact and allowing them to help the engineering teams to a greater extend.

In my experience, the initial focus of most front line managers when working in the open is learning the new mechanics that would allow them to increase efficiency first and effectiveness later on of those around them. That might not be a bad approach since sometimes in Open Source projects, efficiency is a significant issue. At the very end, we all want to add value since day one, right?

But often this approach lead those managers to become the project escribe, doing  non-technical work with lower impact they are used to: driving meetings, documenting, etc. I have seen many people in Open Source, even other managers who went through the same process, justifying this approach as necessary to learn the new culture while adapting to the new environment. In other words, you play the role of a junior instead of a newcomer, living in first person a tough contrast when comparing the role you play in the open with the one you play within their companies.

When working in the open, I strongly believe that the key point to significantly shorten the time frame required for a front line manager to add real value to the project is to put emphasis from day one in alignment.

In most companies, this is the focus of more senior managers, so front line managers partially lack the skills and experience required to make a positive impact in alignment early on. At the same time, working in the open represents a unique opportunity to develop those skills and experience without many of the constrains and responsibilities associated to a senior management role.

Execution alignment based on the project goals (shared vision) represents one of the outstanding challenges in Open Source projects, so the main opportunity for a front line manager to add real value.

pjm_role_closed_vs_open_projects

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

Key habits to change

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

The first one is the management style. As a manager you will need to transit towards coaching as the main style. If directive is the default one in your organization, your journey will be longer and tougher than if your style can be identified already as affiliative. There is plenty of literature about management styles but sadly not much (for this context) about the next habit.

The second one is transparency, which has different requirements and implications for a manager than for a developer working in the open, since they hold a different responsibility within their organizations compared than in the Open Source projects towards their managees.

Let me clarify an interesting aspect of transparency.

There are restaurants where the kitchen is exposed to the customers. We all can see if it is clean, if there is a good working atmosphere, who is the chef and who clean the dishes, etc. Many people feel better in those restaurants because for them, selecting a restaurant is not just about getting tasty food at a reasonable price from a good service.

But is it exposing your kitchen being transparent?

Out of what the experience as a customer, an accountant can tell more meaningful information about that restaurant by looking at the numbers that somebody like me can tell by looking at the kitchen, since I have no clue about cooking. Transparency and exposure are not the same thing.

A key goal as a manager working in the open is to figure out how to drive a symbiotic relation between the organization the team belongs to and the Open Source project and their participants. Transparency at a personal, team and organization level is so important that should be practised since day one. Again, transparency and exposure are not synonyms.

Conclusion

Working in the open involve new challenges that requires a different mindset to be successfully faced by front line managers moving from corporate to Open Source projects. They will need to develop new habits and the most effective way to do so, in my view, is understanding since day one that your focus will need to move towards alignment instead of insisting in autonomy, according to my mental model. With that in mind, my advice is to pay special attention to those habits that will lead you to become a servant for your managees, promoting transparency by example…

…together with a good doses of patience and tolerance to public criticism. 🙂

Dear software manager, working in the open for the very first time? Challenges (I)

Warning: these two posts are a “Lessons Learnt” kind of post, so there is a grandpa kind of smell on it that I am not sure I am comfortable with so there is very little science.

I’ve got lately a few questions from managers about different aspects involved in the transition to working in the open when coming from a traditional corporate environment. This post and the next one are an attempt to answer some of those questions.

In this post I will focus on describing some of the challenges any manager will face and a second one will deal with how to face them.

I will constrain my comments to management aspects, ignoring as much as possible the leadership topic, although they are related. These two articles target what I call front line managers, not senior managers (managers of managers) nor executives. By front line managers I mean those that is in daily contact with developers and that represent, in a top down view of an organization chart, the lower management level. It is true though than many of the ideas you will read  might be valid to other profiles. You tell me.

Challenges

When moving from managing software projects/teams in classic corporate environments into Open Source  (FOSS) projects, there are several new challenges any front line manager will need to face. I group them here in four categories:

  • Challenges derived from the fact that Open Source projects are public and open.
  • Challenges related with the FOSS culture which has some unique characteristics.
  • Open Source has a project nature different in many aspects from the service/product nature most companies have.
  • Working in the open implies new challenges from a more personal point of view, involving values, motivations, etc.

Feel free to add more challenges that those named below. I would go over them.

Challenges: public and open

Some of the challenges corresponding to this category, in my opinion are:

  • In open environments like Open Source projects, no matter if they are community, company or consortium driven, technical leadership is as relevant (or even more relevant) than any other type of leadership, including business leadership.
  • Open Source development and delivery are all about distributed teams and, in most cases, about  multicultural teams.
  • Every aspect of the project needs to consider asynchrony by default. I find this challenge one of the most difficult to understand early on for those coming from corporate environments, even from big corporations, since managers tend to be familiar with concentrating specific roles and responsibilities per site/location, even when high availability is a business requirement.
  • When working in the open, you not just represent yourself, but also the organization you belong to. This is magnified when talking about managers because very frequently they are also perceived as the voice of the team they manage, which is not necessarily the case every time.
  • Front line managers are familiar with dealing with private and confidential information, but working in the open brings new challenges in this regard. This seems obvious. But what in my experience is not so obvious, because it is very often not part of front line manager’s responsibilities within their companies, is to deal with the preparation, communication and consequences of making corporate/internal information public, for instance. There are other interesting cases to consider in this regard.

Challenges: culture

  • In Open Source, openness is a given, although depending on the governance model of the project, there might be different degrees. The same applies to sharing.
  • One of the pillars that has made Open Source so successful is code ownership. If you develop it, you own it, which means that you are expected to maintain it. I have written several times before about how important this point is for the professional and personal growth of any developer. I know a few that, by the time they turned  20, they were already maintaining software used by thousands of people. That is something no college will teach them… nor most companies, sadly. There are still many so called senior engineers that haven’t dealt with the consequences of their own code or the one done by their teams for a few years. The agile movement, through promoting the micro-service architecture, has recognised how important this point is. Development teams are in charge of maintaining what they deploy in production. Still, Agile has not reached the level taken in this regard by Open Source.
  • Standardisation through adoption. This concept is significantly different in corporate environments. The success that Open Source is having though is slightly changing the approach to standardisation many corporations have. There is still a long way to go.
  • Consensus is as important as efficiency in Open Source projects. Some people talk about consensus driven development when referring to Open Source development to highlight how important this aspect is. Corporate managers and executives very often perceive Open Source development as significantly slower compared to developing in-house, which technically speaking might be true in some cases. They underestimate though the benefits that consensus has within a project overtime, specially when talking about the motivational aspects, when dealing with complex problems, interoperability, etc..
  • Documentation always beats meetings, always. I go even further. Meetings are so expensive and precious in highly distributed environments, that front line managers go through a lot of pain until they learn to focus meetings on discussing instead of reporting. This is a fundamental disagreement I have with the stand up concept, by the way. And I am not the only one. Reporting should not be part of any meeting. Period. Document and read reports up front.
  • Open Source is all about specialists (aka rock stars) instead of about teams. Front line managers have a particularly hard time dealing with “unique personalities” in the open. The tools they’ve learn to deal with them are very often not valid in the new environment. As I have written before, the team culture is one of the assets that corporations are bringing into Open Source.

Challenges: project nature

  • Open Source projects are mostly related with R&D, technology or tooling development and, in some cases, specially in company driven communities/projects, about pre-production (early productization stages). They are not about developing products or services which is what corporations are mostly about, even when dealing with R&D. This difference requires, for example, that front line managers pay constant attention to value-capture-and-return cycles between the project and the company.
  • Within Open Source projects, the relation among organizations is not common to many managers coming from corporate environments. Other organizations are treated as partners instead of customers, even if they are service providers or suppliers. In a similar way somebody you work with is a peer, even when talking about members of their teams (managee).
  • Looking at delivery, in Open Source is frequent to release features when ready, on a time based release cadence, which helps to coordinate many different parties. Within most organizations, not even R&D delivery is managed this way. Lately, rolling/continuous approaches are becoming popular among FOSS projects. This way of understanding delivery is very often tough for managers risen in the “deadline drama” culture.
  • When taking decisions in the open, front line managers need to adapt to the fact that developers think about the project as much as they think about the company they belong to. Sometimes even more. Who pays your salary and what for are common question among those managers who do not fully understand yet the environment they are working on. They get the perception that people tend to forget the corresponding  answers after a while working in the open.
  • I always ask managers working in the open about their definition of success for the teams they manage. By their answers I learn a lot about the transition stage they are in. Defining success, even in FOSS projects with a clear shared vision, might become tough. And it is so important to have an agreed definition by every team member…. In general, a definition of success for a team working in the open should consider at least these elements:
    • The project/community.
    • The company or organization that pays the check.
    • How is the value capture-return cycle defined for both, the company and the project.
    • Additional aspects that motivates the team.

Challenges: personal values

  • Front line managers, specially those with little exposure to customers, are not familiar with every aspect involved in professional reputation. It is a relevant concept when your work is public and can be directly associated to you. It is so powerful that it is easily mistaken with the most negative aspects of “ego”. Senior managers coming from corporate environments understand it better but still not fully. Reading or talking about it, listening to those who has been there, working with them, is not enough to get what is like to be on the other side. You need to cross the river to understand it.
  • Open Source was born out of strong ethical values. So strong that they are still relevant to many. FOSS is now mainstream so most think that those values are disappearing, being relevant only to the “senior geeks” working in some specific projects. I believe though that those ethical values still matter and, in my experience, the longer people is involved in Open Source, the more relevant they become for them, no matter where they come from. It takes time for anybody coming from corporate environments to fully understand the impact some of these values have and their implications in day to day activities. These values tend to to manifest vigorously when conflicts arise.
  • One of the things that everybody learn very soon when collaborating in Open Source projects is that people have “two different personalities” which in some cases diverge: the offline and the online personalities.

These challenges, and many others not mentioned above, will require different levels of attention at different stages of the adaptation/transition process to any manager. So in one way or the other, they will need to develop skills and accumulate experience to successfully face them.

A second post describes some ideas about how to approach these challenges when joining an Open Source project as a manager.