Reading a piece in the NY Times in which Adam Bryant interviews Karen May, Google’s vice president for people development, nominally about the fears that people have about giving feedback. I actually found that initial topic sort of tepid. Yes, employees are nervous about giving feedback, for potentially a gazillion reasons, and in particular when the feedback is negative, as in telling people they aren’t meeting expectations, their work isn’t up to standards, or they are rubbing people the wrong way.
I found myself frustrated, because it seemed to be one of those discussions where the implicit cultural rules of the enterprise are completely unstated. May states that training is a viable respond for a worker falling short of expectations because they lack a specific skill, knowledge or skill. But all other reasons for falling short? It’s on the employee’s head:
May: Don’t use training to fix performance problems. If you’ve got a performance problem, there is a process to go through to figure out what’s causing it. Maybe the person doesn’t have the knowledge or skill or capability. Or is it motivation, or something about relationships within the work environment? Or lack of clarity about expectations? Training is the right solution only if the person doesn’t have the capability. But what I have seen in other places is sort of a knee-jerk reaction by managers to put someone in a training class if somebody isn’t performing well.
The obvious conclusion is that the employee that lacks motivation, or doesn’t ‘get’ how relationships in the workplace are supposed to be managed is on their own: it’s not the company’s place to pass that understanding along, or impart motivation through training. Training is just about technical skills: we don’t train people to work well together, to find purpose, or to understand the company culture.
Needless to say, I think this is massively wrong. And the best companies will figure out ways — either by explicit training or other more subtle techniques, but equally intentional — to get those ideas and connections in the heads of their people. It won’t be sufficient any more to simply just hire the best and the brightest and assume that they share premises about interpersonal interaction, the meaning of life, and the relationship of the company to its workforce.
Yes, she suggests there are potentially other avenues — unnamed — to deal with motivation or relationship issues: but why aren’t those considered training? What are those recourses, anyway? I had a feeling they were punitive, in some way. You know, ‘straighten up and fly right’ sorts of management intercession.
I was about to close the article, and dismiss it as facile and unhelpful, when I hit a snippet that made it worthwhile to wade through everything else to get there:
Karen May of Google, on Conquering Fears of Giving Feedback – Adam Bryant via NYTimes.com
Q. Other insights about giving feedback?
A. We do something in some learning programs with our leaders where we’ll put them in a fast-paced exercise and ask them to give feedback to each other, spur of the moment, based on the experience they’ve had together during the day that they’ve been together. I actually named it “speed-back” instead of “feedback.”
We have people sit in chairs and they’re knee to knee. Then we start the speed-back and say, “You have three minutes to answer the question, ‘How have you experienced me during this learning program?’ ” Then the bell rings and the person giving feedback hears how the other perceived them. Many people say it’s some of the best feedback they’d ever received. We’ve experimented with different questions, like, “What advice would you give me based on the experience that you’ve had with me here?”
You pull people from their usual world, out of their everyday setting, with others similarly yanked out of their networks of commitments and position. You put those people in a context where it is understood to be a short-term exercise — a training session — and all involved are — temporarily — stepping outside the hierarchy: just a bunch of people doing something unusual together, led by a trusted expert, the trainer.
A ‘fast and loose’ context rather than the normal ‘slow and tight’ model of interaction.
Then, as one aspect of the exercise, and based solely (in principle) on what has occurred in that separate and temporary shared context, they share feedback. And based on that brief time, together — as individuals, not as nodes in a network of relationships, processes, projects, and long-term meaning — here’s feedback on you: your style, your thinking, your humor, your sensitivity and sensibilities.
I am totally unsurprised that ‘speedback’ leads to great insights and easily assimilated feedback. Why? I think the reason for speedback’s success is almost identical to that underlying Swift Trust:
The Rise Of Rōnin and The Liquid Economy, Stowe Boyd
Companies can avoid the high and seemingly inescapable costs of internal politics with permanent employees struggling for power and autonomy as soon as a hierarchy is created. Networked rōnin operate completely differently. [...] Impermanent teams operate as well as they do because of a well-researched — and profoundly important — social phenomenon, called swift trust, first detailed by Debra Meyerson and colleagues (see Swift Trust and Temporary Groups).
I’ve written about this recently, building on Myerson’s explanation, that impermanent teams can come together and accomplish projects with the least amount of politics, because
a/ the participants are all aware that the project is of limited duration,
b/ the team members are able to assume functional roles based on their previous experience with a minimum — or zero — training,
c/ the project is based on distributed, complex, non-trivial tasks that require deep expertise, and ongoing coordination of work activities, and
d/ people can suspend their need to build deep trust because it is a project composed of other rōnin.
These techniques that resemble deep trust, but are lighter-weight and faster to adopt, can be used to quickly get down to business in an ad hoc team, and focus on doing what is needed to get done; instead of getting bogged down in actual trust development, which can take weeks or months to build.
I believe that swift trust is becoming the default for creative work, and that we are all increasingly operating as if every activity we are involved in is impermanent. Increasingly, at least for most creatives, that is the case anyway. But some people, like me, are intentionally adopting the ad hoc project team as the form factor for all creative work.
Partly this is to take advantage of swift trust — where deep trust activities are deferred or completely put aside — and the team members operate in a social demilitarized zone, putting aside long-term obligations and politically negotiated power arrangements. Instead, we join such teams and rapidly assume the role that fits us, people interact based on the nature of the roles that all members play. We suspend our disbelief and agree to trust within the confines of the groups narrowly defined goals.
And just as important, as a consequence of deferring the complex and involved discussions of personal purpose, every ad hoc team member can cast the project in terms of how it lines up with their personal meaning for work. The members do not need to collectively agree to a single shared reason for existence. That is shelved, since the team members will be going forward on their own life paths, as soon as the project is completed.
This last point is where the liquid economy is most central to the discussion. The rōnin does not have to be 100% committed to the long-range strategic plans of the company behind a short-term project: his goals are his own. The company and the rōnin are just walking down this next few miles of road together, and after that, they will part ways.
So, getting back to May’s Speedback, my argument is that the training context for Google’s leaders breaks them so far out of their normal milieux that it almost indistinguishable from the swift trust context of short-term ad hoc projects made up of freelance professionals, like Broadway productions.
And I’ll make a general observation: the degree to which you can make the typical workforce operate around the principles of swift trust — with short project time frames, shifting teams, and feedback limited to work performance limited to the context of the project, and the interactions with members of the project team, exclusively in that context — the better and easier the feedback will be. Turn it around: it’s not that speedback trumps feedback, per se. There are great benefits that come from constraining the context of performance to something as limited as possible, like projects that are driven by the principles of swift trust, and moving it away from nebulous cultural norms and expectations. In that context feedback becomes speedback, and seems a natural and obvious thing, not something awkward and painful.