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.

 

Advertisements

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.

Kim Scott on Feedback, Candor, and Gender Bias Bingo

LOVED this article by Kim Scott on First Round Review about how gender bias relates to ongoing workplace struggles with candor. She’s doing this incredible project called Radical Candor to build tools to help people be candid at work. She defines radical candor as “the ability to give both praise and criticism in a way that challenges people directly and shows you care about them personally” and breaks communication styles down via this great visual:

radicalcandor

She goes on to explain why candor is difficult: we’re trained NOT to do it!

Most people have been told since they learned to talk some version of “if you don’t have anything nice to say, don’t say it at all.” When they become a boss, the very thing they have been taught not to do since they were 18 months old is suddenly their job.

Cue Maya Angelou:

angelou

Scott’s piece links to this terrific education project about gender bias that fills my heart with both sadness and joy (yes! we know enough about gender bias to be pithy! ugh, there’s enough gender bias to make a bingo card). There’s a clickable link on the site to enter your experiences and a printable format as well.

benderbiasbingo

Related to the notion of communicating with candor is this post about giving feedback, which summarizes some key points from a few leadership and management books, specifically about making sure you know what you’re trying to accomplish by giving feedback, and lists out three kinds of feedback to be aware of:

  • APPRECIATION is expression of gratitude or approval of another’s effort. It is an expression of emotion, designed to meet an emotional need.
  • ADVICE (or COACHING) consists of suggestions about particular behavior that should be repeated or changed. It focuses on the performance, rather than judging the person.
  • EVALUATION is ranking the subject’s performance in relation to that of others or against an explicit or implicit set of standards.

 

The end of that post recommends Getting to Yes, the negotiation book by William Ury, whose Creative Mornings talk I just linked.

Related: Link: Feedback

 

 

Asana blog on feedback

There’s some good advice in this Asana blog post about giving feedback on creative work. It’s largely rooted in the tenets of facilitation and expectation-setting:

“Ideally, you spent some time clarifying the objectives and nailing down the requirements—target audience, channel, timeline, etc.—of your project before your creative team started executing on designs and copy. So when it’s time to give feedback, you’ll have something to refer back to.”

There’s another facet in this piece that I really appreciated, which is about making sure to be clear about whether your feedback must be incorporated or whether it’s just a recommendation:

“It’s important to distinguish between blocking feedback and advisory feedback. The former are changes that must be addressed before something goes out the door. This might be a design interaction that doesn’t align with your goals or written content that doesn’t meet legal guidelines. The latter kind of feedback includes things that would be nice to have, but aren’t critical to the success of the project.”

Being clear about this is so important — not only for the person giving feedback, but for the person receiving it. If there’s any doubt, clarify!

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.