Working in distributed / remote environments 3: weekly meetings (II)

This is the second and last post of the Weekly Meetings series. If you haven’t read the first one, I recommend you do before reading this one.

Where?

There is a very simple rule in distributed environments. If one of the participants in the weekly meeting is remote or at a different office, everybody is remote, or should be.

Take advantage of what the technology provides and participate in the meeting from your desk instead of from the meeting room together with part of the team. I pointed several reasons for this in a previous post. Let me develop further:

  • You do not have a white board to support your explanations. You will need a virtual one and its usage is more effective when everybody can collaborate, getting the same experience. There are plenty of tools nowadays for this purpose. Your screen is your projector. If you need to show something to others, sharing your screen becomes trivial compared to the set up required in a meeting room, no matter how prepared it is.
  • Let me insist on how important it is for building a healthy team that everybody lives the same experience at meetings. It is not just that participation and follow up is harder to those who are not present in the meeting room, it is that the meeting becomes less efficient because those joining remotely become listeners instead of active participants.
  • When teams are used to meetings at their desks, efficiency increases. It is easier to start on time, the sound quality is uniform, less time is wasted in moving to the meeting room, flexibility to organise meetings significantly increase, etc.

How many participants?

Since it is significantly easier to manage a meeting in person than remotely, I recommend to reduce the number of participants in these weekly meetings in distributed and/or remote environments.

It is a common mistake to assume that the ideal team size does not necessarily need to change when moving from collocated to remote. In my experience, distributed teams should be smaller than collocated teams. Remote ones should be even smaller.

Weekly meetings with 8 participants in a room are manageable if the team is disciplined. That is not the case, in my experience, with such meetings through video chat.

Meeting Length

I mentioned in the previous post that meetings in distributed and remote environments should be short. People gets tired of looking at a screen and talking through a mic. I also mentioned already that due to the need of talking once at a time, these meetings have a slower page, which bores people to death.

If you can, make them no longer than 30 minutes. Allow a little more for chit-chat if there are plenty of topics. but in general, avoid reaching the one hour mark. If you reach it on constant basis, analyse and distil the topics, try to preparation them better, send the descriptions in advance, promote offline discussions before bringing the topic to the meeting, control the time better, etc.

And if still is unavoidable, split the meeting in two 30 min meetings if your team can afford it in terms of agenda. Remember that for some, these meetings might require a personal sacrifice because they might need to happen very early or late at night. Two 30 min meetings are far more productive than an hour long meeting when managed correctly.

If any topic requires significantly more time than you can afford during the weekly meeting, propose an “ad hoc” meeting for it. Make sure though that the schedule of such future meeting becomes a a topic on the current meeting. Remember that schedule meetings for the whole team is hard, specially through asynchronous methods.

When?

Applications like Doodle or Pollunit (there are more) can help you and your team to decide in which time slots are better to schedule any meeting. The weekly team meeting is a good example. Every serious calendar has a free/busy time feature that allows you to avoid conflicts. Make sure you master them.

Ensure everybody adds in their calendars the working hours and you define yours so you get an alert when you are trying to schedule a meeting out of somebody’s working hours. I think I did not mention this on the post about the calendar tool. 😮

Serge Broslavsky showed my a trick I use ever since. In a sheet, he added the names of the team members (column B) and the UTC hours of the day (row 2). Then he marked in green, orange and red the times in which meetings were acceptable for each team member. When you have to manage a large number of people around the globe, that simple visualization makes scheduling meetings easier.

Avoid scheduling meetings out of green working hours. If you cannot, try at least to avoid putting any colleague in a position in which they cannot negotiate their own agenda in amber or red hours. In remote environments with different time zones involved, people need to be flexible about their availability, but being flexible does not mean there is no impact. Remember to promote the culture you would like to live in.

As mentioned previously, in DRE it is important to arrive to the meeting prepared so I tend to avoid “first time in the morning” meetings. Like everybody else, I hate interruptions so I tend to concentrate half hour meetings in 2 hours slots and have 1 or 2 hours slots free of meetings, at least a couple of days a week. Promote among participants to reserve a free slot before your team meeting starts.

If you are managing managers, it is extremely important to decide if you want to have your weekly team meeting before or after your colleagues (managers) have had their own weekly team meetings. By default I would prefer to have my weekly meeting after all my managers have had theirs but that depends on the type of job and how is it organised.

Roles

I like to pre-assign roles to avoid any discussion about who should play which role. I add to the meeting ground rules how the roles are selected. Pre-defined rotation is a system I have used. Let the team choose the one they prefer. The point is to start the meeting already knowing who does what. Start the meeting confirming who plays each role, after allowing one or two minutes for chitchatting. The roles are:

  • Scribe: everybody takes notes. Is one of the good things about having every participant in front of their laptops. But there is somebody responsible for completing the notes, record them and publish them.
  • Timer: this is critical since meetings needs to be short so participants need to be concise. The timer not just controls the time assigned to each topic but also that nobody goes off-topic or eat all the available time.
  • Topic lead: the meeting agenda should include a topic lead for each topic. That is the person in charge of making the discussion at the meeting worth it which frequently means that the right information has been sent in advance, questions has been asked and answered and that participants understand what is the expected outcome of the meeting. It will also ensure that the notes reflect the state of the art and will highlight if the topic needs a follow up in the next meeting, for instance. If there are actions points, the topic lead will ensure they have been recorded and/or properly tracked.
  • Meeting owner: I mentioned that you, as manager, should be the meeting owner which does not mean you manage the meeting. Make sure your role is clear, set the boundaries of such role and use your “power” wisely. Assign a person that will substitute you when you are absent.

You can add more roles but I only do in extraordinary occasions.

Some final tips

I will summarise some additional tips in no particular order:

  • Since the environment in these meetings is more hostile than face to face ones, making these weekly meetings short and to the point has to be an essential goal which requires more preparation in advance compared to face to face meetings.
  • Make sure the agenda is sent to participants in advance. Provide a time estimation to each topic, assign a person to lead each agenda topic and make sure you do not fill out the 30 min. I would recommend to not have a pre-defined agenda beyond 20 minutes. Meeting’s pace in DRE is slower than in face to face meetings. Include in the agenda time for AOB (Any Other Business) but be aware that this topic can be used to come to the meeting to discuss topics that has not been prepared in advance. Do not let anybody misuse AOB.
  • Every description, report, detailed opinion, statement or positioning should be sent in advance, as I have mentioned before, with enough time for others to read and answer in written form before the meeting. This saves long turns and explanations during the meeting.
  • When there are more topics than time, ensure those topics related with people management has preference. The others should wait until the next meeting or be a matter of a future “ad hoc” meeting. Since scheduling those topic-specific meetings is so complex, specially in remote environments, use the AOB section to schedule it or at least get a tentative date and time for it.
  • If part of the meeting deals with tasks, blockers etc., make sure the tickets have been updated in advanced so WIP (Work In Progress) can be clearly visualised by all participants. Provide the links to the dashboards to the participants in advance.
  • During the meeting, ensure that every time somebody makes a reference to a specific page, the link to that page, ticket, image, etc. is provided through chat to every participant.
  • I find slides very useful when describing a complex idea or when the amount of information to be provided is high. Screen-share is your friend here. I recommend though to make the slides available to everybody beyond that screen share. They will be easier to follow, participants can take notes, click on the links, etc..
  • I really like dashboards, specially kanban boards as a WIP visualization method (through tickets), even if you are not following the methodology. I use them during meetings to go through hot topics. When going over tickets, repeat the number and title of the ticket you are referring to more than once so everybody can follow you.
  • Predefine a way to communicate that somebody’s turn is taking way too long, or that the participant is repeating herself, that the information is irrelevant , etc. In summary, find a way for anybody to cut anybody politely. The timer role should be the default person for this, but everybody should participate on this tough task.
  • It is common that participants start talking while mute. It happens to me more often that I will ever recognise. There are video chat applications that has solutions for such cases like a notification, or the possibility for another participant to activate anybody’s mic. Try to use video chat apps with these features. If yours does not have it, use a keyword to notify to the person that she is talking while muted.
  • Since in a video conference only one person can talk at a time, muting participants should be a normal practice. Nobody should take offence. Sadly only most experienced people do not. Try to avoid muting people while speaking unless it is strictly necessary if your time has little or no prior experience working in distributed environments or remote. Assume by default that the muted person might have taken it as a rude gesture from you. Talk to the person offline to clarify the situation. Make it an acceptable practice (in specific circumstances) little by little.
  • When the connection of any participant introduces noise or is choppy, muting the affected participant is a must. Mention why you did it, and move on. You cannot afford stopping the meeting flow because of somebody’s bad connectivity. Participants should have alternatives for these cases. I usually have a 4G connection as secondary line in case my default internet connection fails. If the affected person is the topic leader, move on to the next topic. If it happens to a different pre-defined role, make the next person in the queue adopt the role. If it happens to you… well, use the opportunity to “lead by example”.
  • Do not join team meetings through wifi. Do not underestimate the amount of bandwidth that several participants require, even with the best video chat app or plug-in. No, shutting down your video camera is not ok. Take the meeting as seriously as everybody else.
  • Do not close the video chat room once the meeting ends. Allow some minutes for off-topic chatting. Stay once in a while a few extra minutes yourself to participate in those off-topic conversations.

It takes time for any team working in DRE to have smooth and productive team meetings. Keep pushing and do not accommodate, tendencies are usually perverse when it comes to meetings dynamics.

I would like to finish pointing that weekly team meetings for groups that work in distributed or remote environments (DRE) might be the only time where they get together during the week. It is essential to keep in mind how hard it is to generate a sense of team work when there is little or no face to face interaction. This action, the weekly team meeting, represent the best opportunity generate a team spirit, which is a fundamental mission for every manager.

I am sure I have left behind important tips or you might not agree with some of the above. Please let me know. This is not a science.

Working in distributed / remote environments 3: weekly meetings (I)

This is the first out of two parts dedicated to share my experience around weekly meetings in distributed and/or remote environments (DRE).

Introduction

As a manager I cannot tell you how many times I have listened colleagues of mine complaining about having too many meetings, but specially about too many unproductive meetings. Sadly, they are frequently right. And you know what, for every meeting any engineer I have worked with usually have, I have three. And no, attending to meetings is not my job either. It has never been, thanks God. And yes, they usually are at least as unproductive as those the engineers complain about.

I wrote in a previous article that in person meetings are expensive, hard to manage and exhausting. I also mentioned that, in distributed or remote environments (DRE), meetings are even more expensive, harder to manage and far more exhausting.

You will find very few people who dislikes unproductive meetings more than I do. I am not a fan of long meetings either. The best way to avoid unproductive long meetings is to have a real purpose for them. And that purpose has its reflection on an agenda. In short, no agenda, no meeting.

So my first point is, if you are a manager, reserve a slot for a weekly meeting so everybody takes it in consideration in their agendas. But the meeting will only take place if there is an agenda. If your team is healthy, there will most likely be topics to discuss every time.

This principle applies to any professional environment, but due to the nature of DRE, unproductive meetings have a higher impact on participants. Keep that in mind specially when coming from co-located environments.

Who owns the weekly meeting?

I enjoy working in organizations where technical leadership roles are separated from other management roles like product or line management. I definitely recommend to have at least a clear separation between technical and people (organizational) leadership roles. When the tech lead is the line manager….

These weekly meetings can and should serve the team. At the same time, as a line manager, there are occasions in which you need the flexibility to modify the agenda or even own the meeting entirely.

So answering the question, you as manager own the meeting, which does not mean that you manage it, conduct it or even play an active role on it by default. In fact, I recommend not to. Just be clear about the possibility for you to change the agenda in short notice. Be wise about this power though. It might have some negative impact on your colleagues if it is abused.

Weekly meeting main goals

In my opinion, the weekly meeting has the following key goals in DRE:

Alignment

Autonomy is widely perceived as beneficial and a necessary step towards reaching mastery. But autonomy does not come for free, it is associated to a risk, specially as teams/ departments grow: that risk is called alignment.

As a manager in DRE, your number one goal is to promote alignment across the organization and specially across those under your responsibility. I explained this focus shift that any manager should face, referred to working in the open, which is a specific case of DRE, a few months ago.

So my recommendation is to focus these weekly meetings in improving alignment.

Discussions

There are times in which discussions through mailing lists or chat become so complex that the right approach is to discuss the topic in a meeting. There are other occasions in which the topic under discussion is sensitive to one or more team members. Those implicated in such discussions might benefit from a chat through video, experiencing the advantages that some body language and bigger doses of empathy might bring.

Call the attention of your colleagues when overdoing the discussions or when they reflect frustration and invite them to move the conversation to the coming weekly meeting.

Consensus

Alignment frequently requires consensus. Reaching  consensus through mailing lists or chats might be extremely hard, specially the last mile. One or more discussions through video chat might help.

Take some time during weekly meetings to work towards reaching consensus on key topics, instead of having one “ad hoc”meeting to solve it, at least until the discussion is mature enough. Remember that alignment is your outstanding challenge. Work on it on regular basis.

Conflict resolution

In order to understand how important team meetings are in DRE you need first to be aware of the strengths and weaknesses that remote communication has.

Strengths:

  • Direct
  • Aseptic
  • Accurate
  • Easily traceable and recordable.
  • Higher latency, which sometimes help.

There are also weaknesses:

  • Lack of body language which represent a significant decrement on the amount of information transmitted.
  • Requires experience to do it right.
  • Latency: sometimes plays against you.
  • Irony, humour, passion… hard to transmit emotions. So aseptic communication channels might play against you and your colleagues many times.
  • DRE communication is not taught at school. It takes time to master it. It is one of the great advantages of participating early on in your career in Open Source projects. You learn to communicate in DRE.

Back to the conflict resolution point, supporting written communications with conversations through video chat are extremely important in DRE to solve or contain all kind of conflicts, before they escalate.

Use weekly meetings to solve simple conflicts or to expose them. Take a deeper evaluation and potential solutions offline and come back to the team meeting with the result and evaluation. The message is that, when problems or conflicts affect the team, weekly meetings are a better forum to expose them than mails or chats.

More serious conflicts require a different approach. Using the weekly meeting to fully identify them, evaluate them or attempt to solve them might not be a good approach.

Hot topics

In DRE, it is significantly harder to schedule meetings in short notice than in collocated environments. It might also have a higher impact in people personal life.  I always recommend to reduce the drama associated to meetings announced in short notice. Having a scheduled weekly team meeting will significantly reduce that drama while having a positive impact on any team dynamics.

Most hot topics…. can wait one or two days for the weekly team meeting.

Learn about the state of art.

As a manager, you get a significant amount of information about how things are going for your co-workers,team, department or organization in front of the coffee machine, at lunch or at the hall, listening and talking to those you work with. You do not have such luxury in DRE so weekly team meetings represent a unique opportunity to understand how things are going, beyond tickets, merge requests, reports, chat channels and mailing lists.

Following the same argument, employees get fewer information about how is the company doing when working remote. Weekly team meetings become an outstanding opportunity for them to ask you and comment about corporate related topics.

Escalations

In the same way that in DRE, you have limited opportunities to “talk to the team”, they have the same number of opportunities to “talk to the company”. As a manager, it is your responsibility to create the environment in which escalations are properly communicated, discussed, tracked and managed.

Team meetings, together with 1:1, become the default forum where to define and trigger escalations. No matter how flat your organization is, you need to define a clear escalation process that works for both, the company and the employees. This is specially true when you are, de facto, the default company interface because you are the line manager.

Participation.

In organizations or teams where people is spread in different time zones, joining a weekly meeting might involve sacrifices. Now imagine a colleague of yours joining a meeting at 22:00 to realise that 75% of the time has been consumed by a colleague describing a topic, summarising what she did about X or reporting about what somebody else did with Y.

Do you really expect that person to pay full attention?

In order to “encourage” participants to remain connected to the meeting, many managers and teams developed techniques that frequently do not apply to on line meetings. I love the “no laptops allowed” one.

But even face to face meetings, many of them does not work. The human brain have an outstanding capacity to take us somewhere else without others noticing. I developed such skill at college. The normal outcome in an online meeting where reporting is the norm and not the exception, is that participants listen while doing something else.

A waste of time and passion.

It is well known that the key to successful meetings is active participation. This is specially true in DRE. Looking into a screen and listening others through speakers is hard enough already. Add to it lack of participation and you will end in a set up for failure. Descriptions, reports, etc. should be provided to participants in advance. They should read them and come to the meeting ready to participate. Dependencies, blockers, feedback, etc. should be the meat of these weekly meetings.

It is amazing how effective meetings might become in DRE when participants develop the habit of sending and reading reports and descriptions in advance. Promote preparation in advance over longer meetings.

Participation comes with a challenge. Managing fluid conversations through video chat is hard. Experience and simple tips, like something that is equivalent to raise the hand (ask for turn) or a nice way to make somebody aware she is talking for too long, etc.  help a lot. Try some. Some video tools provide some nice solutions to mitigate this challenge.

Stay tuned for the second part of the post.

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.