Having a culture of individual feedback is an important part of growing awesome teams, yet for many teams I work with giving feedback is in the category of “something we want to get better at”. Speedbacking is a simple process to help people practice and nurture a culture of honest feedback.

I designed this process to help students at Dev Academy and have found it crucial to creating a high performance learning environment. I’ve run it with dozens of groups of 8 – 20 people and find it a crucial culture building tool, as well as good skills development in its own right.

Photo by rawpixel on Unsplash

Here’s how I host a Speedbacking session:

Setup (people) :

  • A group of 8 – 20 people
  • Usually the session is just promoted as ‘Feedback’ or sometimes ‘Speedbacking, getting better at feedback together’
  • The more the people have worked together the better but limited team experience works too. This could be long time team mates, students who have been studying together for a few weeks, or retreat participants who have gotten to know each other over a few days.
  • Each person will need some paper and something to write with
  • You will need a time keeping device

Setup (space):

  • Ideally I would start the group in a circle but it’s fine to start with a presentation layout and have everyone facing you
  • You want to have chairs that are easy to rearrange in to two rows with no tables or desks in the way


The main points that I hit to set the tone

* Feedback is a skill. The more you do it, the better you get. Today is a practice session to help us explore that skill while hopefully giving and receiving some useful feedback on the way

* In a few minutes you are going to give and receive feedback to everyone else in this room. You may be wishing you were somewhere else right now, and I can assure you that is a very common reaction. That’s one reason why we often don’t give or receive enough feedback, we have barriers where it seems easier to avoid it. I can also assure you that by the end of the session you will very likely feel differently than you do now. I find participates reactions vary from “that was much better than I expected” to “that was really awesome”.

* Before we jump in to the practice session, let’s go through some key ideas

Key Ideas

If we are short on time then I run through these pretty quickly, otherwise I like to leave space for questions and discussions as we go through the ideas.

Feedback is a skill, it takes practice

If I were to ask you to list your top 20 skills right now, do you think giving feedback would be on the list? What about receiving feedback? While it isn’t common for us to perceive them as skills they absolutely are. Especially receiving feedback, it takes skill to filter out your feedbackers biases, it takes skill to distract your ego to hear challenging feedback, it takes skill to ignore feedback that may be true but isn’t useful right now. The more you practice them and the more consciously you practice them, the better you will get.

[example of the worst feedback you ever gave / received] I often tell a story about one of my business partners who asked me for some feedback on working with him. I thought really hard about it and then mentioned that I hadn’t seen him actively keeping Xero (our accounting software) up to date or using it to generate many reports and he might want to upskill on financial management and using numbers to drive the business. He gently reminded me that he had an economics degree, was very comfortable with financial management and the only reason he hadn’t been updating Xero was because the business was so small he could keep it all in his head. I’d completely forgotten about his financial background! The worst feedback I’ve given, ever.

It’s ok to give feedback that’s off the mark, it’s ok to receive feedback that doesn’t feel right. Giving good feedback is a skill and we’re just practicing here.

Actionable, Specific, Kind

The best way to give good feedback is to make it Actionable, Specific and Kind. (I will often write these words up on a board).

Actionable : Feedback that you can do something about. You’re too short for the basketball team isn’t good feedback.

[Optional question to group: “what are some examples of feedback that is or isn’t actionable?”]

Specific : “The game you played was great” isn’t good feedback, it might make the feedbackee feel better but it won’t help them get better.

[Optional question to group: “what are some examples of feedback that is or isn’t specific?”]

Kind: The purpose of giving feedback is to help the feedbackee, it is an act of generosity. “Here is a list of 10 actionable and specific ways that you suck” isn’t a good approach to feedback.

[Optional question to group: “what are some examples of feedback that is or isn’t kind?”]

[Optional question 2: “what is the difference between kind and nice?”]

Here is where I would give some examples of different feedback and ask the group what they think about them.

Another good thing about ASK is that it is a reminder to checkin with someone before giving them feedback. “I have some feedback about the session you just ran, would you like to hear it”, and being completely ok if the answer is “not right now”. Remember that it takes energy to process feedback well and sometimes “surprise feedback” it isn’t setting your feedbackee for success. Ask first.

Photo by Robert Baker on Unsplash

Feedback difficulty levels

I find it useful to think of giving and receiving feedback as a game that you can play on multiple difficulty levels. When giving someone feedback in the category “here is something you are great at that you may not be aware of” you are playing at an easier skill level than “here is something I think you can get better at” which is easier than “here is something you did that hurt or disappointed me”.

When playing on harder difficulty levels realise you are getting in to it is a good idea to think carefully about the feedback before hand and realise you are getting in to difficult conversation territory which is another skill entirely.

Continuous Improvement

The reason we give feedback is to help people around us get better every day. It is an act of generosity and service that takes practice and skill. We don’t give feedback to make ourselves feel better, to demonstrate our ability or to make someone else do what we want. Sometimes giving public feedback in a group setting can be a good way to help lots of people learn faster, sometimes it is easier to give or receive feedback in private.


Step 1: prep

  1. Write up everyone’s name on a white board.
  2. Give the group 1 minute per person to come up with a piece of feedback for everybody on the list. So if there are 15 people give the group 15 minutes of prep.
    1. Mention that it can be hard to think of good feedback for people and that’s why we are practicing
    2. If you can’t think of any feedback you can share something you appreciate about that person
    3. Or you can share your experience of an interaction you recently had. “I don’t know if I have any feedback for you but my experience of the session you ran was…”
  3. Give them a few minutes notice before the time is up

Step 2: speedback

  1. Arrange all the chairs into two lines facing each other. I usually have to encourage people to move the chairs closer to the person opposite them.
    1. You will have 1 minute to give feedback to the person opposite you and then 1 minute for them give you feedback.
    2. When you’re time is up I’ll raise my hand, if you ever see anyone’s hand in the air, raise your hand and stop talking (my favourite social process for bringing a group to silence
    3. Everyone on this side (gesture to one row of chairs) go first.
    4. Time for 60 seconds and then switch pairs
    5. Time for 60 seconds and then first rotation
  2. First Rotation
    1. Get everyone to stand up
    2. If you have odd numbers then ask everyone to move to the chair to their left
    3. If there are even numbers ask one person to stay seated (they will stay in that chair for the whole process) and then ask everyone to move into the unoccupied chair to their left
  3. Repeat
    1. The rest of the session turns into a timekeeping game of ‘Everyone on the left feedback’, 60 seconds, hand up, ‘Switching’, 60 seconds, hand up, ‘Rotate’
    2. After 4 or 5 sessions I find it is good to give people a minute or two to digest and take any notes they wish to
    3. Keep going until everyone has speed backed with everyone else, or your time is up

Step 3: reflection

People are usually buzzing after the speedbacking round and I like to finish off with a circle. Give everyone 2-3 minutes to reflect on the session, make any notes they wish to and then rearrange the group into a circle.

There are two questions I finish with depending on the time remaining a) a tweet of advice to yourself (short version) b) any reflections on the process and a short summary of the feedback you want to action (long version)

I would love to hear your stories

This process is published as part of The Peer Garden learning community, feel free to take the ideas and do what you like with them.


Some learnings on resolving conflict on Loomio

I can’t imagine Enspiral working without Loomio. It’s not just a core part of our technical stack, it is a cornerstone of our social architecture and shapes how we deal with powerful human forces of belonging, trust and power.

On Loomio we are trying to make decisions about issues which a large number of different people care deeply about. Online. With asynchronous text.

I’m sure people from the future (or their emissaries) will laugh at us from their virtual reality playgrounds. Or they won’t even laugh, they will just smile and wonder at our naive fumbling as we try and evolve better ways of working together.

Either way, most of the conflict I’ve seen at Enspiral has surfaced on Loomio threads. It arises in other forums as well but I’ve found that Loomio can act like a magnet or a sieve which attracts and surfaces bad feelings in the community.


Over the years I’ve developed some informal practices for dealing with conflict on Loomio which might be useful for others.

Escalate the bandwidth

If you do only one thing do this. It’s my workhorse for resolving conflict.

Whenever misunderstanding or conflict arise escalate the bandwidth of the channel. If you’re on Loomio (asynchronous text) move to chat (synchronous text), chat to a voice call, voice call to video call, video call to in person meeting.

I first heard of this from an open source contributor dealing with disagreements online (@searls I think) and if I had to pick just one tool it would be this one.

Support Individuals

The thing about conflict on Loomio is that it is a symptom not a cause. When conflict emerges it is because individuals have needs which aren’t being met. Maybe they aren’t feeling trusted or trusting, maybe they have been triggered by something, maybe they feel like their belonging or livelihood is threatened.

One thing I have seen Enspiral do reasonably well is swarm individuals with support when they are involved in conflict online. It’s more of an ambulance at the bottom of the cliff strategy and the cost of the distributed emotional labour on the community is high (and disproportionately distributed).

Sometimes ambulances are really useful, especially when you’ve fallen off a cliff and this is why community size matters. People in small high trust groups can care for each other much better than large loose ones.

In an effort to provide more support to individuals we have recently expanded the peer to peer stewarding system that the Loomio team use to the core Enspiral membership of ~40 people.

Strong Teams

In the catalyst team Rich has been observing that the people who do the best in Enspiral are usually in one or more ‘affinity groups’ which have a name, a purpose, a consistent membership and a regular rhythm. This could be a venture like Loomio or a working group like the board. I agree and this is one reason the catalysts are investing our energy in helping to form working groups in the network.

Strong Teams
Image Credit – Vaibhav Sharan

Strong Communities

The root causes of conflict will never be resolved through an online forum. The right tools are human methods like one on one conversations, retreats, circles, listening and sharing stories together.

A robust rhythm of “support and grow the humans and the community” is essential to use Loomio in a high trust community in my opinion. Enspiral was born of the deep intersection between human methods and digital tools – we are here today due to the facilitators just as much as the programmers.

Collaboration is a skill

People often have strong opinions that differ from each other but it takes skill and practice to navigate those differences in an online forum.

We aren’t born knowing how to ride a bike, tie our shoes or make complex decisions in decentralised groups online. Using Loomio well as either a participant or facilitator is a skill and should be treated as such.

We need to learn to listen, to approach difference with curiosity, to express ourselves authentically and leave room for disagreement. We need to practice starting from a position of kindness and care for ourselves, for others and for the community as a whole. It doesn’t just happen, but when it does it is magic.

One strategy for acquiring skill is to just jump in and learn by doing which is what we’ve had to do. Find practices that work in related contexts and adapt them, try them out and see what works. It’s expensive and you’ll get a few bumps and bruises on the way, the trick is to approach Loomio as a skill and intentionally try to get better at using it.

Another strategy is to find people who have the skill and learn from them. The stories and guides on the Loomio blog are a great place to start. You can contact the Loomio team if you want to engage the growing pool of Loomio facilitators and consultants.

Neither strategy will work by itself and as an old martial arts teacher said to me the way to learn the fastest is to have someone you are teaching, someone you are learning along side, and someone you are learning from.

Martial Arts

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Some learnings on resolving conflict on Loomio

Loomio lessons – 90 day planning

Recently we had Richard Bartlett from the Loomio team pay a visit to Dev Academy and share some of the lessons they have learned around their 90 day planning cycle. The price of the workshop was a blog post and like Lannisters and Dev Academy graduates a developer always pays their debts.


it’s all about context

A lot of the context is held implicitly in the team and the quarterly planning cycle is an opportunity for the team to add to this context and create shared understanding. The 90 day plan is developed in the wider context of the teams direction which is articulated as purposestrategy and priorities.

Purpose (decades): your long term vision. For Loomio it is to
create a world where it’s easy for anyone to participate in decisions that affect them.”

Strategy (3 years): what are your strategic objectives over the next few years?
This is in flux at Loomio and a new iteration is currently being formulated. You can get a gist of it through these slides.

Priorities (3 months): the targets that the 90 day cycle sets.
The last priorities for the cycle that ended in June were

  • Capital: deliver US$250k in philanthropic funding by June 30
  • Revenue: generate US$2.5k in monthly recurring revenue for use of Loomio
  • Release: develop new interface to the point where all users can switch to it by May 15

Richard made the comment that the numbers in their targets were somewhat arbitrary and that regardless of whether they missed them, hit them or overshot them the value was in the focus it gave. For each new idea or task there was a very clear litmus test of is this a priority.


3 weeks before the end of the quarter the team starts gathering data and and sharing it with the members. There are two main inputs into the planning session: a survey and reports.

Team Survey

This was last quarters survey and it particular reflects the particular dynamics of team Loomio where roles can dramatically change each quarter.

The retreat cycle of Loomio is retreat, offsite, retreat, offsite – with the retreats being 3 days in summer and winter and the offsites being one day. Richard commented that the survey felt more useful for the offsite cycles as the extra time in the retreat created more space for creating shared context.

Another noticing about the survey is that it was a useful tool for some people to switch out of day to day mode and start thinking about the big picture instead of jumping straight in the deep end of strategic planning.


Overlapping the survey process there is also a culture of writing reports to share with the team.

The coordinators write a collective report focused on the priorities for the last quarter specifically addressing what did we do and what did we learn.

Individuals in the group also write up longer form reflections on the work they did and any opinions they have about future directions.

retreats and Off sites

The Loomio planning process culminates in their quarterly gatherings. Lots of work goes on here but one of the key outcomes is the skeleton of a plan for the next 90 days along with coordinators tasked with implementing that plan.

We have a strong retreat and facilitation culture at Enspiral and Loomio is a team with a high density of strong facilitators so this part of the process is under constant experimentation. This winter retreat marks their 7th retreat together and retreat cultural tech is a topic for several blog posts.


The Loomio team have gone through four iterations of their 90 day planning process and I am looking on with envy from an Enspiral Dev Academy point of view. We have just enough time to put together a 90 day plan for this cycle, though the boat has nearly sailed.

While the planning adds value to a single venture I think the real opportunity is when multiple ventures sync up with their context sharing. Add in some digital connecting during the retreat process from lots of teams reaching out of their bubbles and it would change the collaboration landscape at Enspiral dramatically.

For more information about Team Loomio be sure to checkout their blog and wiki.

Loomio lessons – 90 day planning

Self determined salaries

We have recently finalised a round of self determined salaries at Dev Academy and it was one of the most effective and powerful experiments in self management that I’ve experienced. 
freedom_2_by_sevCANNImage Credit

The Problem

The default setting in most organisations is that salaries are private and negotiated directly between an employee and a manager. The information asymmetry helps funnel power up the pyramid and this also results in people who are good at negotiating getting a better deal than those who aren’t.

Ever since first reading Maverick I have been struck with the idea of staff having the ability to set their own salaries. Stumbling across the The Morningstar Self Management Institute in the early days of Enspiral and reading about their work in the space locked in my commitment to self determined remuneration.

This was really easy when we were just a collective of contractors and everyone would set their own billable rates – if customers were happy to pay that rate then it must be good enough. Even when negotiating rates for internal work it was along the lines of “What do you think is fair? Well let’s do that then”.

But fast forward to the end of 2014, Dev Academy had just turned one and when I reflected on our remuneration process it was obvious we had unconsciously slipped back into old habits. Rohan (my co-founder) and I had agreed upon compensation levels with each new hire as they joined the company and traditional power structures and information asymmetries were starting to emerge.

This was yet another reminder for me that self-management processes need clear definitions and constant reinforcement.

For example, while everyone in the company was onboard with the idea of financial transparency we hadn’t put energy into making our remuneration data easily accessible so the only way for a new person joining the team to find out how much everyone was being paid was to ask each person individually or trawl through our xero account. As you can imagine this didn’t happen too much.

So we fixed things.

our Process

Getting started

The first step was writing up a document [extract below] outlining the thinking behind self directed salaries and passing a Loomio decision to try it out. We established a remuneration team to facilitate the process and act as an initial point of contact to help point people in the right direction.

Individual round

We each filled out a remuneration template and the REM team updated a central spreadsheet while acting as a sounding board when asked. For folks who needed extra support someone from the REM team would sit down and work through the details with them.


We collated the salary data and normalised it for time (e.g. how much would this person be paid if they worked full time for a year). This helped us compare apples with apples and made it easier to tackle the heart of the problem which was how much should we pay this person compared to everyone else.

This data formed the heart of an anonymous survey which we sent to everyone in the company with two questions for each person.

a) What do you think of this salary: too high, too low, just right or no opinion?
b) Comments?

We shared the responses with everyone the day before our weekly meeting the next day went through a facilitated session to collectively process the information. This took a fairly simple form of

  • Setting the tone for the session and emphasising the delicacy and importance of this work.
  • Going around the circle with each person talking through their thinking behind their suggested salary and their thoughts and feelings about the anonymous feedback.
    • The feedback for that person was projected on the wall before their checkin to provide a shared context
    • The person opposite in the circle was responsible for looping back what they had heard to shake out any initial clarifications
    • After the looping the circle was open for comments and responses from the whole group

This was an amazing session that helped clarify our understandings of each others roles and was a valuable part of building our culture.

Lock it in

After the “digesting feedback” session we had a few days for people to reflect further and then had a cut off point at the close of business on friday to lock in the compensation levels.

The main points of this were

  1. You were free to ignore or incorporate the feedback from the previous session as you liked.
  2. There was no one who would approve your salary, what you asked for is what you got.
  3. If there were any disagreements on monday it would be handled through our
    conflict resolution. (There weren’t any)

Those final two points where Salaries are approved by default and exceptions are managed by a peer initiating a conflict resolution process are the real magic in the system. It is stepping beyond a company where you have a lot of influence to a company which you actively control.

It’s all about the culture

I have tried lots of experiments over the years to help people realise a sense of ownership and empowerment and this was definitely one of the most powerful. At the end of the day setting salaries is pretty common sense stuff and when you give people all the information they will make common sense decisions.

It definitely requires a strong sense of trust amongst your team and a willingness to give and receive challenging feedback. But if your team isn’t up for that then helping them get into a position where they are should be your top priority.

[Extract from the initial document outlining the process]


Self Determination individuals set their own pay which colleagues provide feedback on but the ultimate remuneration decisions rest with the individual. Significant differences of opinion are resolved by our conflict resolution process.

Transparency – all compensation packages are visible to everyone in the company in a simple and accessible format.

Risk Adjusted – if a staff member puts some of their compensation at risk by deferring payments and accepting Fairy Gold instead of cash then they receive a fair compensation for that risk.

Intrinsic Motivation – we eschew individual performance bonuses and rely upon people’s intrinsic motivations to do a good job. Any performance bonuses are paid out across the whole company.

Adjustable – Individuals are free to adjust their remuneration at their discretion (e.g. if the type or amount of work they do changes) but are required to update their individual agreement at least once per year.

Trust & Integrity – are at the heart of Dev Academy but especially present in the work of setting compensation levels. We assume that each person is striving for the fairest outcome they can envision for themselves and their colleagues.

Self determined salaries