Processes for Establishing Teams

Often when I am coming into a new team much of the work I am doing, while I get up to speed on the product and market, is helping the team focus and work together.  Over the years I have come across, modified, and developed several tools to help facilitate establishing teams, norms, and roles. As always, no tool is exactly right for all teams. Adapt and change for the nature of the team you are dealing with.

Norms

Goal

Establish a common set of team level rules for how we collaborate and interact.  This can be everything from SLAs around PRs to the number of meetings we have, from how we handle conflict to support rotations.

This process should be team led.  The team leader should be a participant in the discussion.  As such it can be very difficult for the team leader to also facilitate the discussion.  A team norms discussion also becomes a way the team actively works through their communication and conflict management style.  If possible, it is better to do this synchronously.  The conversation is part of the point.  Approximately an hour should suffice for this discussion.  Some teams can do multiple exercises (norms + mandate or norms + decision making) in one session.  Once norms are established, they should be updated over time.

Process

Let the team know you will be doing an exercise so they can think about it in advance.  The prompt is “Think about a team you worked on that was great.  What made it great?  Think about a team you worked on that was terrible.  What made it terrible?”  Capture one thought per sticky.

Then group stickies together into themes.  Talk through the stickies in each theme together as a group.  As a facilitator make sure that people are engaging in debate on whether that idea is important to them as a team or not.  This will allow you to come to a set of statements that basically boil down to “We believe…”

Examples

From a very mature team with a lot of baggage, this set of norms evolved over the 2 years the team existed. This example is only a subset of the total norms the team had. They did a remarkable job of holding each other accountable by simply saying “thank you for following our team norms”.

At a very different company, a very different result. This was a team coming out of a lot of process whiplash.  Also, they were globally distributed (designer in India, team lead in South Africa) so there was a lot of concern for async communication and clear hand offs.

Roles and Responsibilities

Goal

Clearly define who owns what part of a process or has decision making power is essential to clean hand offs and action.  While many activities fall clearly into one job title (HR is a great example of a job with clear boundaries) in the space between Product and Engineer, or between levels in an organization, things can be a lot murkier.

This process can either be leader with team or leaders among themselves depending on where you are seeing grey areas.  It is best that anyone who’s position is being defined is part of the process.  This process requires a willingness to engage in some difficult discussions about both skills and responsibilities and can become heated so it’s best to have someone with position power that can break an impasse.

This process should be done in conjunction with establishing a DACI process or establishing a 7 levels of authority so you can clearly talk about both the “owner” of a process and who should be involved in the decision and how involved.

Process

This is a classic card sort exercise focused on job responsibilities.  This should happen in two phases.

Phase 1: Collect responsibilities

Bring the affected group together to collect all the responsibilities that need to be defined and owned.  Working alone capture one responsibility per sticky.  This can be as simple as “review a PR”, as mundane as “schedule meetings”, or as complex as “architectural direction”.  Set a timer for the independent brainstorming.  At the end of that time, go through all the items and group them and chose a “winning” card to represent each group of ideas.  Take these cards to a new clean area.

Phase 2: Card sort

Have boxes for each of the roles you are trying to define.  Together as a team determine which box each sticky belongs in.  If the sticky belongs in multiple boxes, duplicate it.  If a sticky represents a “decision owner”

Example

Most of this kind of discussion I have done has been in person, so I don’t have a captured shot.  This is a heavily cleaned up example from our process of hiring a Head of Eng and establishing teams with a “pod captain” for each.

Decision making structure

Goal

Sometimes it is helpful to separate the Roles and Responsibilities discussion from the decision-making structure.  This can especially be true when there are a lot of people involved in decision making and it can be separate from the actual job responsibilities.  This has been the case for my current role as we have moved from a single Engineer team of 25 to 5 pods with pod captains.

Process

Same as ‘roles and responsibilities’ card sort with the initial part focused on decision making stages.  In our process we also added in the variable of where and how the decision should be made and SLA because of how async we are.

Example

Mental Model Minute: Intent Based Leadership

I have so many things to share with you but so many discussions I have been having keep leading me back to this Mental Model Moment I thought I would share. And it’s easy, because it’s the author and this great illustrator do so much of the work for me. On the other side I can share my take aways and how I have implemented this with teams before.

Start with Clarity

Intent based leadership is all about setting the distant island we are trying to reach via the ship, and then collaborating as a team for the best way to get there. Teams are formed with different skill sets and the ability to have hard conversations around both priorities and implementation.

I had one team that was building a Form Builder. This was a priority for the company because of some compliance issues with our existing solution (PCI security) and a potential untapped market. So for that team we had two clear goals:

  1. Migrate existing users off the existing solution
  2. Prepare a product for go to market

Every meeting we had, every planning, every time we discussed a feature, we asked if it met those two goals. To the point that my otherwise quiet UI/UX developer (the Sheriff) would interrupt me outlining a feature to say, “This doesn’t seem in line with our goals, why are we doing it?”

In other words, the team started to understand “Is it the right thing to do”.

Build Structures around Competence

Over time the “is it safe” questions become engrained in the conversation. Each time I work with a team on whether we would release something I would ask the same questions. To the point were one of my developers started to impersonate me. “Will it break production? Have we informed the users? Do we have documentation?” Questions like that. This, as well, becomes a pattern of how the team acts.

At my last gig, we had a system that was forklifted from a mainframe with no test environment. As a result, questions of release, between my delivery lead and myself, were always about how much certainty can we have that none of us will be working the weekend. Followed directly by questions of where are the opportunities to create unit tests, or small test environments around sections of the application even if end-to-end tests can’t be done.

Moral and Ethical Responsibility

As a leader, there will always be some tasks you must reserve for yourself because it is irresponsible to allow that to be a team decision. The key here is to be explicit (using those 7 levels of delegation perhaps) on when that is happening.

When I was a department head I reserved two things:
1) Starting the firing process with HR
2) Telling a customer “no”

Neither of those things where my team should have carried that burden. I explicitly told them this. My tech leads would reserve some very specific breaking technical changes. For example, only the tech lead of my dev/ops team could take our CI/CD system completely offline.

Remote Work is Here to Stay

As operations leaders across the world stumble and struggle to figure out their “return to work” strategies, I have been reflecting on the nature of the fundamentally collaborative work we do in software development and what it will look like in this new world.  I don’t know what the post-Covid world of work will look like.  But I do know that it will be different and leaders who just try to rest to how things were a year ago are going to be in shock as their employees chose to move to more flexible companies.  So, what do we need to think about as we balance collaboration with employee desire?

Remote work is a benefit, revoking it will have consequences.

While most companies didn’t move into remote work a year plus ago because they were trying to add an employee benefit, that is, in fact, what they did.  Now that employees have gotten an opportunity to work remotely, and for the most part successfully, many will view any change to the remote work policy as the removal of a benefit.  In a lot of workplaces, the right to work remotely was previously reserved for special situations where an employee may want to move across country and the employer desperately wanted to retain that employee.  Now you have the same situation but in reverse.  Employees that choice to make a blanket policy that requires all employees to return to the office, even if only a few days a week, will see turn over.  The presentation of how this return to the office is conducted, and how much agency the employees have in their return, will also affect retention.  As part of your plan, consider retention goals along side other goals like productivity, collaboration, and team unity.  Figure out what you want to measure and what your most important goals are.  For some employees, the ability for managers to be able to work with their staff in person may be a worthwhile tradeoff for significant turn over.  However, just as furloughs, pay reductions, or other benefit reductions will result in employee exits, the same will happen here.  Also remember that the employees that leave first are most often the most talented as they can most easily find other work.

Employee opinions matter

Along that same line, asking employees what they want should be part of your policy strategy.  Rolling out a new return to work policy without conducting a visible employee feedback process will result in lash back, no matter if the employees agree with the ultimate policy or not.  Especially coming at the end of a year where everyone has lost a sense of control in their own life, most people will not take kindly to being told what they will do instead of being consulted in their own destiny.

Also consider that each employee has different goals, work/life balance needs, and work styles that will contribute to their optimal workplace environment.  There is no one size fits all approach.  Policies that declare a certain job family or group of people based on location of their homes will be required to work in the office while giving blanket approval to continue remote work for another group will be seen as unfair or ill considered.  Yes, it is much easier to make policies that apply across the board.  However, leaving room for manager discretion, especially for high performing individuals, is essential.  This isn’t just a matter of retention; it is also a matter of inclusion and diversity.  Different people work, process information, have interactions in different ways.  There differences between people is part of what allows serendipity to happen, not just being in the same place at the same time.  Honor those differences by honoring individual needs.

Identify tradeoffs based on work style and actively mitigate

There are pros and cons to each interaction style.  Fully remote individuals need to work hard to collaborate and consciously build relationships that may naturally develop by bumping into someone at the watercooler.  In office individuals can find it harder to concentrate or to find quiet to work in and be easily distracted by the talk around the watercooler.  Everyone needs to find ways to balance between time at work and time at home regardless of if they are physically in the office or not.  It is overly simplistic to say that people in the office have better connections to their coworkers or people who work remotely focus better.  Everything takes work and it is up to both the individuals and the organization to help employees perform their best regardless of where they work.  Collaboration tools and video helps remote employees feel more engaged.  Sound buffeting and focused spaces help in office employees feel like they can get “heads down time”.

In addition, hiring a remote workforce allows you access to a larger pool of candidates, no matter where your office may be located.

Remote friendly is now the standard

Regardless of your return to the office plan, more likely than not you will now have employees who will remain full time remote.  There was a general trend towards remote friendliness before Covid and now, as with all things in the last year, that trend has accelerated.  This means that a remote friendly office is no longer an option.  You must put cameras in your conference rooms, include collaboration tools in your budget, and be prepared to help manager navigate productivity discussions with employees they can’t see typing on their computers.  However, remote friendliness is more than just how you make sure your remote team members can be part of conversations.  It is also making sure all employees, regardless of where they work, feel like they are part of the team.  Time has to be taken to think about these things.