Building trust, building teams

Who doesn’t want to be part of a team like this?

How do you build a team that’s so supportive and so invested in each other’s success?

First is creating an environment of psychological safety, so that the individuals (and the group) are willing and able to take risks.  Being vulnerable is critical to learning and growth and cooperation, and you just can’t do that in an environment that is not psychologically safe. Here’s the essential Brene Brown on connection, conversation, and constructive feedback.

 

“If you’re not in the arena also getting your ass kicked, I’m not interested in your feedback.” – Brene Brown


That’s impossible without a means of giving and receiving high-quality and valuable feedback. This Asana blog post about how they’ve worked to make the company an organization focused on learning and growth discusses how they’ve built feedback into their regular working rhythm. One of the central concepts is that feedback is necessary:

It’s also important to provide a climate that tolerates mistakes and lets people take chances. This means being mindful about the kind of feedback you provide. This is particularly relevant for creative feedback, since the best output often requires extra experimentation or taking risks.

The critical aspect here is to make feedback valuable and not just stressful or anxiety-inducing or causing someone to armor up.

I’m really excited about Kim Scott’s work on Radical Candor. I’ve talked previously about her work on gender bias impacting feedback. Here’s a wonderful update, expanding on how to receive feedback. It includes a lot of examples of ways managers have successfully solicited feedback:

“There’s this rule we’ve all accepted that you must criticize in private, but when you’re the boss, you’re the exception to the rule. You want people to see how you’ll react — that you can take it and will appreciate it.”

[Kim Scott, h/t First Round Review]

All of that is just lip service unless you are committing to living it, to being the change you want to see. Nobody’s going to magically make the culture you want to live in. It’s about knowing and deciding how you want to live, how you want to engage with the world, and then living that way. Cap Watkins does a terrific job of addressing how to build a culture of empowerment (Treat Your Life Like a User Experience Problem).

He touches on giving and receiving feedback, not just on the work itself, but on the processes and methods by which work is done. His advice for people in teams that don’t collaborate is to behave as though the problem isn’t there — to just begin collaborating, to begin to live in the new framework you want to exist in, as you build it.

“It doesn’t matter what level you are. It doesn’t matter what team you’re on. It turns out that leadership is not a role. Leader is not a title that anybody has at any company I’ve ever been at. You can always be an advocate. You can be a collaborator. You can be an idealist. You can create change locally.” – Cap Watkins

This article about Girls Rock! Pittsburgh includes some beautiful commentary from volunteer Tilley Hawk about how to create this change and build the environment you want to work and live in:

“When looking at large problems within societal structures, it is very difficult to figure out solutions while looking at such a large system that is in place. In playing by their rules, it is difficult to find change, and you often find yourself back in their pocket. GR!P plays by its own rules and thus finds itself outside of these structures. It uses music and puts the power directly in the hands of those who want to use it. GR!P creates its own space, occupies its own space outside of the box, and refuses to play by [their] rules. This is proof that direct action has an effect.”

Ryan Carson’s powerful and moving 99U talk (Begin With the End in Mind) takes a broader view (or maybe a more singular view, depending on how you’re thinking about it) of the idea of building the life you want to be living by prioritizing the things that are important to you, and saying no to everything else.

 

Katia Verresen on mindfulness at work

This interview with executive coach Katia Verresen does a beautiful, cussing-riddled job of linking up how self-care, self-compassion, gratitude, empathy, and mindfulness are critical for business.

Verresen’s approach is at the intersection of basic mindfulness skills and Brene Brown’s work on vulnerability.  For a little background, here’s a Q&A with Brene Brown on the TED blog, in which she discusses the concept of scarcity thinking, and the idea of not being enough:

Well, the idea of “I’m never enough” — beautiful enough, successful enough, thin enough, popular enough, loved enough, worthy enough — that’s shame and scarcity, and I’ve seen people overcome that every single day. I’ve gone through the process myself. I’ve interviewed people over the course of four years who’ve done a lot of this work. You have to understand shame. You have to understand where the message comes from, what drove it, how has it protected you in the past, and are you willing to look it in the eye and say, “Thanks, I appreciate it, but I’m not subscribing anymore. I’ve got a new way of doing things, and maybe you kept me safe and small in the past, but I’m not doing that.” The answer is absolutely that I’m not enough. You can overcome that, but you can’t overcome it without an understanding of shame. If you are not willing to have that conversation, there’s no way to the other side of it. You have to know what shame is.

Verresen approaches this from another angle, with what she calls abundance thinking: the idea that you have to take care of yourself, see what’s around you, see the resources and choices you have ahead of you, so that you can actively chart your course:

“You’re not going to build a billion dollar business on a string of bad days. It has to be a sequence of your very best days. Your performance is tied 100% to your attitude.”

The goal is to be in a non-reactive position (see also mindfulness teacher Tara Brach: Learning to Respond Not React). The example Verresen gives is about the moments when you need everybody to drop what they’re working on and jam out a huge and focused project:

When you’re building something new, you’ll inevitably run into 11th hour, all-hands-on-deck, crunch-mode situations — all the time. When you lead teams, you’re never out of the woods. In these cases, it’s so easy to tell your team, “Keep cranking, we’ll breathe when we’re done!” It’s easy to let all the habits enumerated above fall by the wayside because you believe you have no time or room.

But this is exactly when they’re needed the most. Every tool mentioned here takes less than 5 minutes to perform, enabling you to be at your best — which is also the way to ensure your team is at its best. At the times that matter most, you can’t accept less. That’s not going to happen if you’re pushing through exhaustion.

Cue up the classic Zen adage:

meditation

She goes on to discuss how essential feedback is for healthy teams (I wrote a bit about feedback here and here), and focuses primarily on appreciation-based feedback:

“When you look at healthy teams, unbridled, uninhibited appreciation is always a key ingredient. It’s the No. 1 retention tool in the world.”

Verresen offers a handful of tools for getting unstuck, for finding support, for busting yourself out of a rut, for approaching projects with neutrality. One I really love is the idea of forming a “giving circle” — a group of friends or colleagues where everybody is working on something unrelated (see Heidi Grant Halvorson’s work about competition as it relates to communication for more on the importance of projects not overlapping in this context) — to offer support, guidance, brainstorming, and resource-finding help to each other.

It seems so obvious to suggest putting together a network of people you trust, for ongoing collaboration, but how rarely do we offer up our struggles for others to look at? Our default answer is “I’m fine” when in truth we need some help. If we can be vulnerable and open, we can accomplish so much more with so much less suffering.

Bridge-building case study (“Factory Fridays”)

In early 2013, I was working as a technical writer and a facilitator for a startup company on the precipice of its commercial launch. The company had found a site for its factory and had begun to build it out, and the manufacturing team was gunning to spec, buy, and install equipment in time to hit the production launch date. Trouble was, the product was still very early in its development stage and thus not fully defined. This of course led to big frustrations between the teams:

“Can’t you just tell me what material you need this equipment to be able to make?”

and

“I cannot believe you’re considering buying that piece of equipment. It’s not what we need at all!”

I was in a really interesting position to tackle this communication gap, because I worked directly with almost every single person in the company at that time, and thus had a very high level of influence, even though I had no direct authority or power by title.

This case study steps through the scenario, my assessment of the problems, the planning work I did to bridge the gap, and how I evaluated the success of the project. It’s an interesting case, because there’s truly only one major deliverable: transferring enough knowledge to build out and standup a manufacturing plant (I’ll spoil it for you: the company did open a factory). But there were lots of interim projects, successes, and realignments, and I step through those as well.

One of the biggest realignments, which I reference in the case study, is that initially the two teams were operating in different working structures and methods. The development team had been using Scrum to great effect and was feeling really good about it (I was that team’s Scrum Master), and part-way through the knowledge transfer project, the manufacturing team switched to using Scrum as well. Here’s a short Scrum 101 post, which includes the presentation I made for the manufacturing team, to explain to them how the development team was using Scrum. It’s an interesting way to manage work in that context — it’s a framework designed for software development, which has no lead times, but product and equipment design can involve very long lead times — and requires a bit of adjustment.

This case study also looks a bit at why the approach was successful, which was matching the method to the situation. I talk a lot more about knowing which are tools and skills are necessary for which project, product, and company stage in this post about transitions.

Scrum 101: Using Scrum outside of software development

Scrum is a working method designed for software development. The Scrum Alliance published a quick but comprehensive summary of what Scrum is, and what its goals are, and that page includes this very condensed outline:

The Scrum framework in 30 seconds

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.
  • At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review and retrospective.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

When I got my Scrum Master training, I was the only person in the room who wasn’t working in software development. That meant that I couldn’t use Scrum exactly as it’s intended to be used: It’s not designed for projects that have lead-times. Software doesn’t really have waiting periods, where you’re waiting for a manufacturer to make a tool for a part, or where you’re waiting on 12 weeks of cycle testing, for instance.

When you’re working in hard goods, you aren’t talking about a potentially shippable product at the end of a sprint, but you are still talking about the work being ready to show to a stakeholder. But once you wrap your head around how you need to scope out the work and break up the tasks, it’s a really useful framework. What you wind up doing is breaking up tasks into smaller pieces that are less time-dependent. For instance, the task isn’t “make parts” — it winds up being several smaller tasks, that can be divvied up into various sprints (“finalize tool design” and “submit purchase order for tool” and “complete first article inspection on parts made with new tool,” for instance).

We used the Scrum framework to organize the development and manufacturing teams’ work to build out and stand up a manufacturing plant. The development team had been using the scrum framework for about a year by that point. I was the team’s Scrum Master. (I wrote a bit about my thinking on the Scrum Master role as a Facilitator role.) During the knowledge transfer process, when the development team and manufacturing team were working very intensively together, the manufacturing team switched to using Scrum as well. One of the engineers got Scrum Master training as well, and I showed the manufacturing team how the development team had been using this slightly-modified version of Scrum. Here’s the quick presentation I made for introducing the method to the whole team:

I did some training with the manufacturing team to help them get up to speed (how to estimate effort for chunks of work, how to get unit-of-measure-loving engineers comfortable with the idea of completely subjective point values for effort, how to build a backlog spreadsheet with a burndown chart — straightforward stuff, but practical examples based on how the company was already using these tools).

Working as two aligned scrum teams had two really valuable impacts. One was that it became much easier to schedule work that involved both teams, because there was a lot more visibility into work scope and schedule. The other was that folks were able to support each other: folks regularly attended the other team’s sprint reviews to see the presented completed work, and celebrate each other’s accomplishments.

How to make a process from nothing

You can’t worry about change management until you’ve got something to change.

And you can’t worry about process improvement until you’ve built a process.

So how do you build a process when there isn’t one at all? How do you know you need a process?

When I was a technical writer, I was asked to write a form that people would fill out to request resources to run a trial. The person asking knew what the output of a business process would be, but didn’t know how to ask for a process to be built. I could have just written a form, but that wouldn’t have gotten us what we actually needed.

Most of the work of process development is in talking to people. It’s interviewing. It’s asking people what they mean, what they want, what they need. But the key is understanding that it’s often hard for people to ask for what they need, because they don’t know yet that they need it. That sounds condescending, and I bring it up because it’s so crucial to not be condescending when you realize that what somebody is asking for is only the part above water, the part they can see. It’s so important to not be dismissive or to say it’s that what they’re asking for is too hard, especially when you haven’t walked through your thought process together. You risk not being able to get any more information from that person, which pretty much guarantees that you won’t be able to give them what they need.

In short, this approach does not help anybody:
whatyouthinkitmeans

The root of it is helping folks come to the understanding on their own that they’re asking for a whole iceberg. Then, once you’ve set some expectations (for example, no, I really do honestly only want the tip of the iceberg to be delivered, or yes, I guess I do actually want a whole iceberg!), then you can begin to think about resourcing the work.

Here’s a short case study about developing a business process where there was nothing in place at all, focusing on how I determined what was needed (versus what was asked for), with a good look at what kind of deliverables were part of the package. Click on the arrows or on the slide itself to advance the deck..

Management (oh, and conflict, diversity, transparency, and efficiency)

A frequently (but often only partially) quoted segment of the Tao te Ching  describes the idea of invisible leadership. Let’s take a moment here to recall that this text is estimated to have been written in the sixth century BC. Despite hundreds and hundreds of years passing since then, the best managers I have known are described here:

A leader is best when people barely know that he exists, not so good when people obey and acclaim him, worst when they despise him. Fail to honor people, They fail to honor you. But of a good leader, who talks little, when his work is done, his aims fulfilled, they will all say, “We did this ourselves.”

There’s so much to consider in management (of both people and projects), but I think a fundamental is that good management takes time. It’s work that is often unaccounted for, but supports teams, builds healthy organizational dynamics, empowers people, and removes obstacles from the team’s way, like the sweeper in curling. But learning how to be a good manager takes time as well. Learning isn’t efficient. It takes time and practice.

While we’re on the topic of efficiency, this is a great article about organizational efficiency, and what it’s tied to. The notion is that we are all living and working in systems, and you can’t flip one switch and expect it to work (“look, we’re efficient now!”). You have to understand first what the switches are, and then how they relate to each other.  The article includes a visual to explain the idea that they’re sliders rather than switches:

oLO070F1TPmvobj0cF2n_responsiveness

“The three sliders aren’t sequential; they’re deeply interrelated,” he says. When companies try to move just one, it almost always fails. “Let’s say your company is all the way on the left, totally efficient, and one day you decide to make things totally transparent. You push that slider all the way to the right — but only that one. Well, now everyone in the company can see all the problems, but they have no power or resources to fix them,” Pisoni says.

Here’s another one Pisoni sees a lot: A company resolves to experiment more, but doesn’t touch the other sliders. Now you have a situation where team members are asked to innovate, but can’t really take risks — in fact, they’re punished when experiments fail. “And with secrecy all the way to the left, nobody knows what experiments are happening, and they’re not armed with best practices,” he says. “Everyone is going off in different directions, with no communication.”

Nothing happens in isolation — no one person will save (or tank) a company in just the same way that no amount of planning will make an organization more responsive. Everything happens in relation to something else.

This is true in team dynamics as well, of course. Most of the time, individuals aren’t working alone, beside each other but not interacting. We’re collaborating, which means we’re sometimes in conflict. But just like happiness being rooted in process and growth, creativity is rooted in conflict.

Here’s a terrific piece about how important it is to accept conflict as not a necessary evil but as something valuable and useful in organizations. My favorite part is this, about the role of the leadership and hiring in creative conflict:

“With teams, the leader’s role is to channel conflict to fuel the journey. Seek to resolve but do not restrain conflict. The tensions are the magic touch. They force us to question ourselves and explore the full terrain of possibility. The tensions keep us uncomfortable enough to keep trying. Hire people that are willing to fight, and fight apathy ruthlessly.”

Building diverse teams is crucial for building enough conflict and tension to be productive and creative. That includes diversity of work experience, and diversity of background. I am never going to stop linking this article about Location Labs’ hiring and retention approach — they aim to hire people with differing backgrounds, focus on creating a work environment where people are engaged and empowered and feel appreciated, and they recognize that innovation and conflict go hand-in-hand.  COO Joel Grossman is quoted: “A healthy environment has disagreements, but they’re vigorous and healthy. Communication is open and ideas are debated.” It’s crucial to build an environment where it is safe to disagree, and that is largely the responsibility of management.

This Asana blog post by Rachel Miller is a great look at why diversity in organizations and building inclusive work environments is good for business. “I’ve found that making business cases for diversity have let me become a vocal advocate. Without that shift, it’s unclear how diversity should be prioritized inside a company when other social justice issues aren’t. I went from thinking that diversity was something I wanted from the workplace, but couldn’t necessarily expect, to realizing that investing in diversity is part of investing in a company built to last.” Miller lists several clear business reasons to support a diverse organization, including one related to conflict and creativity: diverse teams are coming with different perspectives and  are “less likely to practice groupthink.”

This joyful, pop-culture-gif-littered piece from the iDoneThis blog addresses tension and anxiety in teams, and how uncomfortable it can be to manage. It offers some very solid, very practical, and very applicable guidance to new managers, starting with how to provide feedback that will empower your team and help build their confidence, leading them to be able to be more autonomous:

Both novices and experts respond well to feedback given on a job that they feel is “finished,” rather than having a manager hover over them and interrupt their process.

Value their autonomy by giving feedback on finished projects, rather than interrupting employees at work.

The article goes on to talk about feedback loops ON feedback — doing retrospectives to see how your feedback is working, if it’s effective.

Practice makes practice.

 

Scrum Master as Facilitator

Facilitation is rarely discussed outside the context of having meetings, but there are a lot of kinds of facilitation. Teaching is facilitating learning. Project management is facilitating work.

I’m a trained Scrum Master, which is another name for a facilitator within the Agile working framework of Scrum. (Scrum 101: scrum teams work together in a defined span of time called a sprint to complete a discrete and deliverable part of a bigger project. Then they review their working methods in an event called a Retrospective, adjust their process, and then in their next Sprint Planning meeting, they break off another chunk of work to be completed in the next sprint. The fundamental difference between traditional project management and the Agile/Scrum framework is the frequency of review and iteration on smaller, discrete portions of a project vs a focus on delivering an entire complete project all at once).

Scrum Master is an interesting role, rooted in removing obstacles from the working team, but also working to provide a supportive environment in which the team can work.  One of my favorite scrum tools is the daily standup, a meeting not owned by any one person but by the team, in which everybody is asked three questions:

  • What did you do since we last met?
  • What will you do before we meet next?
  • What roadblocks are in your way?

In a true scrum setup, the Scrum Master is the sweeper: removing the roadblocks and making the path smooth!
curlingsweep
But that framework is really useful in non-scrum settings, too. I’ve adopted it for use in most projects I’ve worked on, regardless of team type. It makes the most basic and useful meeting agenda format there ever was!

The part of the sprint where the team pauses and reflects is my favorite part of scrum, because the best work happens when you look at your own process and methods. What disrupts your ability to get work done? What disrupts the team’s trust in each other? It’s so important to stop and look honestly and openly at how the team is working together. It requires the team to be vulnerable with each other, to be able to receive and give criticism in a safe and productive way, and to think honestly about how the team is working.

A retrospective will not be productive if you haven’t made  space for people to be vulnerable, and there are a lot of tools and techniques you can use to help create that environment. Here’s an example of a retrospective agenda I’ve used:

  1. Reminder of the goals/objectives of the retrospective
    All team members reflect on the past sprint and make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
  2. Check-in
    “How did the sprint go for you?” in only two words. Each person writes their two words on the board.
  3. Happiness Histogram (see below for examples)
    a) Review the burndown chart and sprint calendar to remember what happened during the sprint.
    b) Draw a graph with time on the x and happiness on the y axis, (Happy is above the axis, Sad is below, and neutral is the X axis). Label significant events e.g. planning, sprint review, and backlog reviews, important meetings, environment failures, branch merges etc. on the x axis.
    c) Everyone draws a line representing how they felt throughout the sprint.
  4. Gather data and generate insight
    Prepare sheets of paper for each team member each with one question:
    In this sprint, what things happened that were unusual?
    In this sprint, what things did we do well?
    In this sprint, what did we do that we should avoid doing in the future?
    Distribute the sheets. Each person writes something, then passes the sheet to their left, then writes something on the next sheet, in response to what has previously been written. Give 3-5 minutes for each round, then instruct the team to pass the paper to their left. Stop when participants have the sheet they started with.
  5. Decide what to do
    Ask people to read their sheets and write the main points on post-its, on the board. Ask people to read the post-its aloud. Distribute 5 dots per person. Each person votes by post-it (however they like). The goal is to select one or two things to actively work on in the next sprint.
  6. Close out (Return On Time Invested)
    (See Facilitation 105 for more info on how to use the ROTI tool.)

I love happiness charts. When we use these, we decide up front that we’ll use them, so we can define our rating system (-3 to 3, for instance, where 0 is neutral) and set up a table to track ratings. Every day during our morning standup meeting, each person gives a number ranking to how they felt about the previous day, the scrum master writes it down, and we map it out as we go (in a spreadsheet, or on a whiteboard, or on paper).

Here are some examples. You can see really readily when the team is in total alignment. Note the huge tank from everyone on the team at the same time, early in the sprint here: IMG_20130403_102712_958.jpg

It also reveals when the team is way out of alignment. Look how everybody’s lines are all over the place in this sprint:

sprint5.jpg

The real value of happiness charts though, is going back through and identifying WHY folks felt great or terrible. Folks often feel more at ease talking about emotion when it’s rooted in “data” (as much as a gut-take feeling on a made-up scale is data) so it can be a lot easier to identify from a graph, rather than from conversation alone,  what the team is struggling with, and thus what you as the facilitator or scrum master may need to focus on. And it also provides a framework for people to point jubilantly at a peak and say what happened that made things go well. I’ve gotten to hear some really lovely and supportive commentary from the team about each other. In one of my favorite retrospectives, we learned that the highest points on the happiness chart were when the team was really struggling, but felt supported by each other and able to work through the struggle.