Tags: feedback

19

sparkline

Tuesday, April 3rd, 2018

Navigating Team Friction by Lara Hogan

It’s day two of An Event Apart Seattle (Special Edition). Lara is here to tell us about Navigating Team Friction. These are my notes…

Lara started as a developer, and then moved into management. Now she consults with other organisations. So she’s worked with teams of all sizes, and her conclusion is that humans are amazing. She has seen teams bring a site down; she has seen teams ship amazing features; she has seen teams fall apart because they had to move desks. But it’s magical that people can come together and build something.

Bruce Tuckman carried out research into the theory of group dynamics. He published stages of group development. The four common stages are:

  1. Forming. The group is coming together. There is excitement.
  2. Storming. This is when we start to see some friction. This is necessary.
  3. Norming. Things start to iron themselves out.
  4. Performing. Now you’re in the flow state and you’re shipping.

So if your team is storming (experiencing friction), that’s absolutely normal. It might be because of disagreement about processes. But you need to move past the friction. Team friction impacts your co-workers, company, and users.

An example. Two engineers passively-aggressively commenting each other’s code reviews; they feign surprise at the other’s technology choices; one rewrites the others code; one ships to production with code review; a senior team member or manager has to step in. But it costs a surprising amount of time and energy before a manager even notices to step in.

Brains

The Hulk gets angry. This is human. We transform into different versions of ourselves when we are overcome by our emotions.

Lara has learned a lot about management by reading about how our brains work. We have a rational part of our brain, the pre-frontal cortex. It’s very different to our amygdala, a much more primal part of our brain. It categorises input into either threat or reward. If a threat is dangerous enough, the amygdala takes over. The pre-frontal cortex is too slow to handle dangerous situations. So when you have a Hulk moment, that was probably an amygdala hijack.

We have six core needs that are open to being threatened (leading to an amygdala hijacking):

  1. Belonging. Community, connection; the need to belong to a tribe. From an evolutionary perspective, this makes sense—we are social animals.
  2. Improvement/Progress. Progress towards purpose, improving the lives of others. We need to feel that we do matters, and that we are learning.
  3. Choice. Flexibility, autonomy, decision-making. The power to make decisions over your own work.
  4. Equality/Fairness. Access to resources and information; equal reciprocity. We have an inherent desire for fairness.
  5. Predictability. Resources, time, direction future challenges. We don’t like too many surprises …but we don’t like too much routine either. We want a balance.
  6. Significance. Status, visibility, recognition. We want to feel important. Being assigned to a project you think is useless feels awful.

Those core needs are B.I.C.E.P.S. Thinking back to your own Hulk moment, which of those needs was threatened?

We value those needs differently. Knowing your core needs is valuable.

Desk Moves

Lara has seen the largest displays of human emotion during something as small as moving desks. When you’re asked to move your desk, your core need of “Belonging” may be threatened. Or it may be a surprise that disrupts the core need of “Improvement/Progress.” If a desk move is dictated to you, it feels like “Choice” is threatened. The move may feel like it favours some people over others, threatening “Equality/Fairness.” The “Predictability” core need may be threatened by an unexpected desk move. If the desk move feels like a demotion, your core need of “Significance” will be threatened.

We are not mind readers, so we can’t see when someone’s amygdala takes over. But we can look out for the signs. Forms of resistance can be interpreted as data. The most common responses when a threat is detected are:

  1. Doubt. People double-down on the status quo; they question the decision.
  2. Avoidance. Avoiding the problem; too busy to help with the situation.
  3. Fighting. People create arguments against the decision. They’ll use any logic they can. Or they simply refuse.
  4. Bonding. Finding someone else who is also threatened and grouping together.
  5. Escape-route. Avoiding the threat by leaving the company.

All of these signals are data. Rather than getting frustrated with these behaviours, use them as valuable data. Try not to feel threatened yourself by any of these behaviours.

Open questions are powerful tool in your toolbox. Asked from a place of genuine honesty and curiosity, open questions help people feel less threatened. Closed questions are questions that can be answered with “yes” or “no”. When you spot resistance, get some one-on-one time and try to ask open questions:

  • What do you think folks are liking or disliking about this so far?
  • I wanted to get your take on X. What might go wrong? What do you think might be good about it?
  • What feels most upsetting about this?

You can use open questions like these to map resistance to threatened core needs. Then you can address those core needs.

This is a good time to loop in your manager. It can be very helpful to bounce your data off someone else and get their help. De-escalating resistance is a team effort.

Communication ✨

Listen with compassion, kindness, and awareness.

  • Reflect on the dynamics in the room. Maybe somebody thinks a topic is very important to them. Be aware of your medium. Your body language; your tone of voice; being efficient with words could be interpreted as a threat. Consider the room’s power dynamics. Be aware of how influential your words could be. Is this person in a position to take the action I’m suggesting?
  • Elevate the conversation. Meet transparency with responsibility.
  • Assume best intentions. Remember the prime directive. Practice empathy. Ask yourself what else is going on for this person in their life.
  • Listen to learn. Stay genuinely curious. This is really hard. Remember your goal is to understand, not make judgement. Prepare to be surprised when you walk into a room. Operate under the assumption that you don’t have the whole story. Be willing to have your mind changed …no, be excited to have your mind changed!

This tips are part of mindful communication. amy.tech has some great advice for mindful communication in code reviews.

Feedback

Mindful communication won’t solve all your problems. There are times when you’ll have to give actionable feedback. The problem is that humans are bad at giving feedback, and we’re really bad at receiving feedback. We actively avoid feedback. Sometimes we try to give constructive feedback in a compliment sandwich—don’t do that.

We can get better at giving and receiving feedback.

Ever had someone say, “Hey, you’re doing a great job!” It feels good for a few minutes, but what we crave is feedback that addresses our core needs.

GeneralSpecific and Actionable
Positive Feedback
Negative Feedback

The feedback equation starts with an observation (“You’re emails are often short”)—it’s not how you feel about the behaviour. Next, describe the impact of the behaviour (“The terseness of your emails makes me confused”). Then pose a question or request (“Can you explain why you write your emails that way?”).

observation + impact + question/request

Ask people about their preferred feedback medium. Some people prefer to receive feedback right away. Others prefer to digest it. Ask people if it’s a good time to give them feedback. Pro tip: when you give feedback, ask people how they’d like to receive feedback in the future.

Prepare your brain to receive feedback. It takes six seconds for your amygdala to chill out. Take six seconds before responding. If you can’t de-escalate your amygdala, ask the person giving feedback to come back later.

Think about one piece of feedback you’ll ask for back at work. Write it down. When your back at work, ask about it.

You’ll start to notice when your amygdala or pre-frontal cortex is taking over.

Prevention

Talking one-on-one is the best way to avoid team friction.

Retrospectives are a great way of normalising of talking about Hard Things and team friction.

It can be helpful to have a living document that states team processes and expectations (how code reviews are done; how much time is expected for mentoring). Having it written down makes it a North star you can reference.

Mapping out roles and responsibilities is helpful. There will be overlaps in that Venn diagram. The edges will be fuzzy.

What if you disagree with what management says? The absence of trust is at the centre of most friction.

DisgreeAgree
CommitMature and TransparentEasiest
Don’t CommitAcceptable but ToughBad Things

Practice finding other ways to address B.I.C.E.P.S. You might not to be able to fix the problem directly—the desk move still has to happen.

But no matter how empathic or mindful you are, sometimes it will be necessary to bring in leadership or HR. Loop them in. Restate the observation + impact. State what’s been tried, and what you think could help now. Throughout this process, take care of yourself.

Remember, storming is natural. You are now well-equipped to weather that storm.

See also:

Wednesday, September 6th, 2017

Form Validation with Web Audio | CSS-Tricks

An interesting idea from Ruth—using subtle sounds to augment inline form validation.

There aren’t any extremely established best practices for this stuff. The best we can do is make tasteful choices and do user research. Which is to say, the examples in this post are ideas, not gospel.

Sunday, June 25th, 2017

Implementing a slider well

A look at the feedback needed for a slider control that feels “right”.

You can get most of the behavioural (though not styling) suggestions in HTML by doing this:

<form>
  <input type="range" min="0" max="100" value="50"
   onchange="amount.value=this.value"
   onmousemove="amount.value=this.value">
  <output name="amount">50</output>
</form>

Saturday, August 6th, 2016

Service worker meeting notes - JakeArchibald.com

Jake has written up the notes from the most recent gathering to discuss service workers. If you have any feedback on any of the proposed changes or additions to the spec, please add them. This proposal is the biggie:

We’re considering allowing the browser to run multiple concurrent instances of a service worker.

Wednesday, July 27th, 2016

A Code Review, Or Yet Another Reason to Love the Web | Brad Frost

I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:

  • I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
  • I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.

Tuesday, July 26th, 2016

Join Fractal on Slack!

If you’re planning on giving Fractal a test drive, jump into this Slack channel. Mark and others will be able to help you out with any questions that aren’t covered in the docs.

Wednesday, July 20th, 2016

Questions for our first 1:1 | Lara Hogan

Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.

Sunday, June 5th, 2016

Good intentions are not enough | silversuit.net

Online discourse:

Wouldn’t it be nice if we had an x-ray that could peer into the true intention behind words on a screen? Sadly we don’t have that x-ray yet (for most of humanity’s existence, we had body language to enrich our words and enhance understanding, but we live in interesting times where so much, perhaps even the majority, of our communication lacks body language) and so we have to be mindful of how our words might be perceived, and what the ramifications of publishing them might be. That’s not to say we should hold off completely, but it does mean we should be mindful if we’re to be most effective.

Wednesday, December 16th, 2015

Natural peer environment by Mikey Allan

‘Sfunny, I was just discussing this with Clare and Charlotte at work: how our office space (and culture) lends itself well to spontaneous exchanges of feedback and opinions.

Friday, March 7th, 2014

Making progress

When I was talking about Async, Ajax, and animation, I mentioned the little trick I’ve used of generating a progress element to indicate to the user that an Ajax request is underway.

I sometimes use the same technique even if Ajax isn’t involved. When a form is being submitted, I find it’s often good to provide explicit, immediate feedback that the submission is underway. Sure, the browser will do its own thing but a browser doesn’t differentiate between showing that a regular link has been clicked, and showing that all those important details you just entered into a form are on their way.

Here’s the JavaScript I use. It’s fairly simplistic, and I’m limiting it to POST requests only. At the moment that a form begins to submit, a progress element is inserted at the end of the form …which is usually right by the submit button that the user will have just pressed.

While I’m at it, I also set a variable to indicate that a POST submission is underway. So even if the user clicks on that submit button multiple times, only one request is set.

You’ll notice that I’m attaching an event to each form element, rather than using event delegation to listen for a click event on the parent document and then figuring out whether that click event was triggered by a submit button. Usually I’m a big fan of event delegation but in this case, it’s important that the event I’m listening to is the submit event. A form won’t fire that event unless the data is truly winging its way to the server. That means you can do all the client-side validation you want—making good use of the required attribute where appropriate—safe in the knowledge that the progess element won’t be generated until the form has passed its validation checks.

If you like this particular pattern, feel free to use the code. Better yet, improve upon it.

Friday, May 31st, 2013

Screenshots of Despair

The existential angst of unfeeling feedback.

Friday, September 28th, 2012

Monday, November 23rd, 2009

Adding “1UP notification” with jQuery - O! Mr Speaker!

A jQuery plug-in inspired by the interaction feedback on Huffduffer, which was in turn inspired by retro games.

Monday, October 15th, 2007

Humanized Messages for jQuery at Binary Bonsai

A nice little extension to jQuery from Michael Heilemann for displaying unobtrusive feedback messages.

Sunday, June 24th, 2007

Upcoming Suggestion Board

Search on Upcoming is borked. Here's my explanation why. I criticize because I care.

Friday, October 27th, 2006

Comments on comments

Right before I set off on my antipodean adventure, hell froze over and I opened up comments. There was a twist, of course. I wanted to solicit feedback but discourage conversation so, to foster independence of opinion, comments were not immediately published. Instead, all the comments were published together once the ability to add comments had been switched off. In this case, that was a period of one week.

The post received quite a few comments, some more interesting than others.

Quite a few people were sidetracked by the issue of spam and assumed that I would simply be inundated with comment spam. Spam was something I deliberately didn’t mention in the original post as it is tangential to the matter at hand. As it happens, the Akismet API — which I’m using to filter comments — does a great job of keeping comment spam out.

The original post was prompted by Mike mentioning the lack of comments on my site at the Future of Web Apps summit. The audio of Mike’s talk is now available and I highly recommend you listen to it. It’s an excellent presentation chock full of ideas about community, participation and social interaction. Mike also weighed in on my post, saying:

In my view, comments can significantly raise the quality of experience on most sites but cannot significantly lower it.

Now, this is interesting because I disagree almost 100%. In my experience, coming across pointless, lame, nasty or redundant comments attached to a blog post can lower the quality of the document as a whole. I think Mike has managed to crystalise why others are willing to put up with the downsides of comments, while I find the trade-off unacceptable.

Bradley Wright says:

I’m curious as to how comments that no one else can see will foster good feedback.

Well, that goes back to the whole wisdom of crowds thing I was talking about: independence is one of the defining factors.

He continues:

Sometimes the best leaps I’ve seen in online “conversations” come from the back and forth, which is helpful for some people to help crystallise their thoughts.

I agree. But I haven’t found those conversations happening very often in comments. Instead, I find them happening blog to blog. People tend to post more well-thought responses on their own blogs than they do in the comments to someone else’s blog post.

Guy Carberry brings up an important issue:

I have got some very useful information from the comments of a post.

This is true. This is also something that Andy said to me when we were discussing blogs and comments. Well, with my system of comments, this will still be true. Once comments are displayed, there is a greater chance that they will contain only useful information rather than a mixture of information and conversation. The google dance usually takes a while anyway, so if someone is looking for information on a topic and they end up at one of my blog posts, the ability to add comments will probably be disabled and all comments will be displayed. That person gets the information in the original post along with any feedback sent in via a comment. In fact, I would argue that my comment system will prove more valuable for long-term information search.

But how long is long? For how long should the ability to add a comment be available? For the inaugural post, I chose one week. I figured that would be a nice length of time to allow everyone to have their say. As it turned out, the vast majority of comments were submitted in the first few days. Clearly, a week is a long time on the web. I think two to four days might be a better length of time to keep the comment form available.

Pete Lambert commented on the need for some way of tracking when comments get published:

My only issue with it is that I would have to remember to come back and check the comments after whatever arbitrary quarantine period you define.

This is clearly something I need to work on. I still think some form of email notification would work best. Another option would be to actually publish the comments in my RSS feed as well as on the site. With a little jiggery-pokery, this could be flagged up as unread in most RSS readers. But this could just end up pissing off the people who don’t care when comments are published.

Here’s another point:

I suspect what you are going to wind up with is a long list of the same comment over and over again.

Surprisingly, this didn’t turn out to be the case. I actually received a fairly wide range of ideas from people.

That’s not crowd wisdom at all. If your blog was a multiple choice quiz, then fine, but it’s not.

That’s a good point: the wisdom of crowds does seem to work best with multiple choice questions (or “guess how much this weighs” questions). I opened up comments on another entry, where I was soliciting opinions on things to do in Melbourne. I personally thought that this would be a better test of my commenting system. The aggregate results should have given me a good independent overview of recommendations.

As is turned out, I shot myself in the foot by

  1. restricting the crowd to people who know anything about Melbourne and
  2. also encouraging feedback via my contact form.

Still, my point above about the added value of comments via findability still stands: somebody googling for restaurants in Melbourne will not just find my original post, but also the (one) useful comment about places to eat. The fact that the comments was originally hidden during the submission process doesn’t affect the long-term usefulness. I can see the commenting system working well for less tightly focused questions.

Based on the inaugural post with comments, I’m pretty pleased with the results. Clearly I need to work on a better notification system and I also need to figure out the sweet spot of how long to allow comments to be submitted but overall, this little experiment has yielded some pretty tasty fruit.

I was all set to start allowing more comments when I came across a post by Robert Nyman entitled A blog without comments isn’t really a blog.

Oh, brother! Here we go again.

After all these years of trying to define what a blog is, who knew that someone blogging for a year and a half would stumble upon the answer?

Forgive my sarcasm, but I get pretty fed up of being judged based on how I set up my personal site. I said as much in a comment on Robert’s post.

In his post, Robert has this advice for people who don’t have comments enabled:

Then you shouldn’t blog.

At the same time, he claims to love the openness of the web. I’m seeing a disconnect here. In his reply to my comment, Robert says:

I’m glad that I have comments here so everyone can read your and my opinions on this, and also have the possibility to contribute with what they think. That’s what I like about the web: the openness.

That’s a pretty narrow view of openness. I don’t think it’s very open to have all responses in a single document.

Here’s what I like about the web: openness through hypertext. I can link to any resource on the Web and comment on it here on my own website. Conversely, anyone is free to link to this document and comment on it on their own site (or a third-party site like Newsvine). That’s openness. Demanding that everyone post their thoughts together on the originating document is a closed system.

So, just as I was ready to start experimenting more with feedback mechanisms, I’m confronted with a “my way or the highway” ultimatum about what I’m allowed do on my own site. It’s enough to make me give up on the whole idea.

But I won’t. I’ll keep opening up the occasional post for comments, although I’m also really interest in using tags and pings for tracking responses, hence the Del.icio.us, Technorati, and Flickr links at the end of each post.

I was thinking of opening comments on this very post, but I think most of the salient points have been gathered from the initial post. If you would like to respond to this, you can write a blog post of your own and it will appear through the Technorati link (I really wish Trackback worked better but spam has effectively killed that off). If you have any feedback, there’s always email and IM.

Monday, July 24th, 2006

Fixtorati

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.

Friday, April 7th, 2006

Further comment

My thoughts on comments were cause for some debate in certain circles. I’m not the only one grappling with this issue.

I managed to lure Dunstan out of his self-imposed exile long enough for him to point to some ideas he had for a more heavily moderated commenting system where only useful additions appear with a post. This is somewhat along the lines of the BBC’s website where occasionally feedback is solicited but it’s more along the lines of letters to the editor: comments enter a queue and only representative selections are published.

For a very interesting take on the comments question, I highly recommend listening to this interview with David Sifry posted on the Podleaders podcast. Responding to the question of whether Technorati has any plans to begin indexing comments, he points out that whereas blog posts have a certain level of accountability, comments are more like the (often anonymous) throwaway remarks that polluted Usenet and chat rooms, preventing those technologies from scaling past a certain point:

One of the reasons I think blogging is very different from bulletin boards or chat rooms is that it fundamentally enforces a level of accountability.

I find that that level accountability tends to create, or enforce, a certain amount of thoughtfulness… a willingness to think twice before someone says nasty things.

The problem I have with many commenting systems on blogs [is that they] do not enforce any level of accountability.

That’s exactly what I was getting at in my original post when I said:

The best online conversations I’ve seen have been blog to blog: somebody posts something on their blog; somebody else feels compelled to respond on their own blog. The quality of such a response is nearly always better than a comment on the originating blog for the simple reason that people care more about what appears on their own site than on someone else’s.

Then the tricky bit is tracking those conversations. And that’s where services like Technorati come in.

Tuesday, October 11th, 2005

Conversation with Five Teenagers

Talking with the youth of today about how they spend their time online.