Creating the scaffolding for teams to do their best work

Aly Blenkin
WeAreSnook
Published in
12 min readMar 11, 2021
Poetics of space book cover, illustrated by Nick Misani, a series of line drawings of three dimensional shapes with different areas filled in with colour
Poetics of Space book cover, illustrated by Nick Misani

Creating space for casual ‘water-cooler conversations’ is difficult in a remote setting. It often feels forced. It’s hard enough for established teams to find space to reflect and exchange stories, let alone for those who’ve never connected with their colleagues in real life because they’ve switched jobs during the pandemic.

Whether you’re setting up a new remote team or working within an existing one, it’s important to establish a structure to foster resilient and adaptable teams.

Over the past few months, I’ve been testing out some different ideas to create an environment or ‘scaffolding’ for teams to do their best work.

In this blog post, I’ll share what I’ve learned about setting up a team in a remote setting, highlighting what’s working and what’s been less successful:

  • Creating the scaffolding for teams
  • Establishing the team’s baseline and defining roles
  • How to intentionally create space to share work and feedback

Setting up a new team remotely

As you may have guessed, I’m one of those people that started at a new company during the pandemic. Towards the end of 2020, I joined Snook to set up the digital practice.

The team is still in its infancy, with a mixture of newish, and even newer, members. There are about 20 of us — made up of developers, product managers, interaction designers, content designers, accessibility experts, and delivery managers.

The digital team works closely with user researchers and service designers, to design and build products and services — predominantly for the public sector.

For a lot of the team, it’s their first time working with so many other disciplines on a project. To deliver meaningful work they need to feel aligned, comfortable collaborating and to trust each other. These things can be more challenging to establish when working remotely.

Illustration of fish swimming to a central point

I feel grateful that in my last job, co-directed a service that helps nonprofits design and build technology, I was working with teams in Europe and in the United States, so I already felt comfortable with remote working.

I thought: ‘I know how to spin up remote agile teams — no problem, I’ve got this.’ Of course, there isn’t ever going to be an exact recipe, but what I didn’t fully consider was how difficult it is when you're joining a new culture remotely, needing to quickly understand the ways of working, and react to things already in flight. It feels like you’re making decisions blindfolded because you don’t truly understand how the system operates or grasp the implications of certain decisions.

It became apparent soon into joining Snook that I would have to adapt and reevaluate as I went. But I still wanted to make sure that I was establishing a structure for the team as intentionally as possible.

Creating a community

I’m very inspired by Jamer Hunt’s research around how problems shift depending on the scale (from an individual/ family/ community/ city/ nation/ to a global level) and how resilient communities are formed.

He writes about how the ‘lattice’ or ‘scaffolding’ is the structure that allows collectives to thrive. In his book, Not to Scale: How the Small Becomes Large, the Large Becomes Unthinkable, and the Unthinkable Becomes Possible, he says

“If we were aiming to grow roses, to use an analogy, we might design and build a lattice so that the roses have an infrastructure for successful growing. The aim is for the roses to flourish and for the lattice, ultimately, to fade into the background…the intent is to design an intermediary framework that is not the thing itself (that is, the rosebush), but the means by which many different configurations (or roses) may emerge. The aim is not to create a single idea multiplied, but to nurture the conditions of possibility for diverse results to emerge.”

I have a theory that Jamer was testing this model on our master’s cohort, the Transdisciplinary Design MFA program that he founded. This brought together a diverse group of disciplines to address complex and systemic problems. I think a lot of us left the program trying to recreate those same conditions in our work.

Building scaffolding at the ‘mesolevel’

The first step for me to develop the scaffolding was to listen to the system (the organisation), to understand all the actors, powers of influence, and the rules of the organisation.

The goal was to understand the state of play and to empower people within the team to help shape the vision. In his book, Jamer advocates for not a top-down or bottom-up approach, but rather somewhere in the middle — the ‘Mesoscale’ layer, as he calls it.

Diagram showing the mesoscale — a midway between topdown and bottom-up approaches. From the book Not to Scale, by Jamer Hunt —
Diagram from Not to Scale, by Jamer Hunt

The way I’ve interpreted this is to design the scaffolding together as a team (from the bottom-up), whilst working closely with the other heads of teams to reinforce the structure and ensure a joined-up approach (top-down). This requires buy-in from the entire organisation. We all need to be aligned.

Just as there is risk in big bang releases in software development, the same is true in rolling out change within teams.

So where do you start without rushing things or not taking enough time to understand the system? Ella Fitzsimmons’ weeknotes about starting a new job at the Joseph Rowntree Foundation really resonated with me.

She writes about feeling the need to fix things right away, rather than spending time thinking and strategising. To avoid jumping to solutions, one of the first things we did as a team was to understand our baseline.

Establishing the team’s baseline and defining roles

A sreengrab of two spreadsheets showing a rubric of the Digital Team’s skills and the Software Development process
Screenshots of the digital team rubric. The development rubric was created with Toby Osbourn.

If you don’t know what your baseline is, you’ll never know if you’re making progress. Worse, you might be repeating the same mistakes over and over again. One of the first things I did on joining the team was to understand the current state, in order to start building from there.

This was a team effort, and we’ll continue to develop it based on shifting needs. In the spirit of not reinventing the wheel, we decided to use the Digital, Data and Technology (DDaT) framework as our foundation and then build on it.

The spreadsheets above defining the different roles and skills are not sexy, but it’s our first iteration — it’s lean and works for now. Each person on the digital team assessed their own skills and added comments on the skills they’d like to improve.

Our goal was to use this framework to help us establish our baseline and then adapt it for Snook. For example, for content design, we looked at all of the various skills that the GDS framework outlined, and then added in other attributes that we’ve adopted, like ‘respectful content’ championed by Nao Pattem.

The next stage we’re working on is getting feedback, and building up evidence, which will help us define a path for progression for each of the disciplines and how we want to set up our practice.

This isn’t a silver bullet solution — nothing ever is — but it helps us get something out there to build on. We also wrote little blurbs to define each of the disciplines in the digital team. Zeeshan Wali, our accessibility and inclusive design lead, and I outlined the following for the accessibility role:

Image of the role and responsibilities of an accessibility specialist.
Accessibility specialist role and responsibilities
  • What the role is about: Accessibility specialists champion inclusive design and accessibility across everything Snook does, from the products we build to the services we offer. They work with the team throughout the design and development process, from research to writing accessibility acceptance criteria.
  • What questions they ask: How might we make the user experience more inclusive for a range of abilities? Does the product meet accessibility standards, such as WCAG acceptance criteria? Does this feature work using assistive technology?
  • What their responsibilities are: Supporting teams on how to implement WCAG 2.1standards (on both legacy software and greenfield projects), being the first port of call for the interaction designers to understand accessibility issues around their early designs.

Having these definitions helps other disciplines understand what’s expected of the different roles and some of the things they will champion in the project work.

In addition to assessing our team’s baseline and defining the roles and responsibilities, we’re also mapping our skills and interests. This is designed to be a starting point for people to collaborate or reach out to others who might have particular experience — working in central government, for example.

The high-level things we’re capturing are:

  • Discipline
  • Experience and areas of expertise
  • Areas of interest
  • Topics that might be triggering

It’s early days and we’re still getting everyone to fill it out. Merging the digital team’s skills and experience with the other disciplines across Snook is the next task on our mission to create space for more cross-pollination in the company.

How to intentionally create space to share work and feedback

I’m a big fan of feedback and retrospection. I recently wrote about my personal process of adopting a reflective practice.

Having worked on remote teams before, I knew that frequent feedback and space for reflection was key. If the team isn’t continuously learning and growing, they can become stagnant and frustrated.

These feedback loops need to be adopted and reinforced throughout the organisation, from the way we do new business development to how we build product teams to deliver the work.

Making space for reflection is one thing, but how do you do that when everyone is on different teams moving at — what feels like — hyper speed? And more importantly, why does it matter?

Designing feedback loops is essential. It enables us to reinforce the things that work well and to call out the things that make it tough to do our best work.

You won’t move forward individually or as a team if you don’t make space to regularly take stock.

Feedback can be hard and can make people feel uncomfortable if it isn’t delivered as a gift. If there aren’t safe spaces for retrospection and feedback, things can fester and really throw the team off balance.

Three techniques for team retrospection

1. Speed dating style feedback

This is a favourite tool of mine, that I learnt about years ago at ThoughtWorks. I forget who taught me it, but I’m forever grateful! The idea is that you do one to one feedback with everyone on your project team in a rapid manner, just as if you were rotating around a table at a speed-dating event. When you first try this, it can feel too quick and unnatural, but the goal is that everyone gets into the regular habit of giving and receiving feedback that is both constructive and actionable.

I’ve adapted it to work in a remote setting. It does take a little prep for the first go, but it gets easier to run over time. You will need to:

a) Review the rules and establish how to give constructive feedback

The rules are pretty simple. The first step is to create a safe space. Ask the team how they feel before you run a session. This is a lifelong practice and everyone can use a refresher on how to give and receive feedback. There are great resources out there like the posters from GDS or these feedback cards for teams that Tash Willcocks, (our head of learning design), made.

I personally focus on: what to keep doing, what you want to learn from others, and what to start doing or improve.

b) Prep feedback for each of your team members in advance

Block off 30 minutes in your calendar to write bullet points about each of your team members in advance of the session. I usually leave it up to the team to find a time that works for them.

c) Set up breakout zoom rooms

Depending on how many people are on your team, you will need to set up rooms for people to rotate between. We usually do 4 minutes of paired feedback before rotating to the next person. For example, I’ll give feedback to Endy for 2 mins and then we switch, and Endy gives me 2 mins of feedback. After we are finished, we thank each other and then rotate to the next person.

The entire session takes about 45–60 minutes — depending on your team size. It can be helpful to draw out the pairing combinations for your first time.

Diagram by Tom Wicks

d) Run the session and check-in

Some people might forget to prepare and that’s fine. It won’t be as smooth, but it’s still possible. After the one to one sessions are finished, bring everyone back into the central room to discuss how it went. Talk about how people felt during it and how they’re feeling now. Iterate! Change based on what you’ve learnt. Most importantly, decide how to hold each other accountable and make space to help your colleagues achieve their personal goals.

2. Entire team feedback sessions

Miro board for running a team feedback session
Feedback board in Miro

Although I’m a huge fan of speedy feedback, slowing down and making the space to be more intentional and reflective about what’s been happening over the course of a month is a worthwhile investment.

Bayo Akomolafe, author of These Wilds Beyond our Fences: Letters to My Daughter on Humanity’s Search for Home, talks about “Becoming accountable to more than what rests on the surface” and “lingering in the places we are not used to.” It’s easier to get lost in the busyness (only connecting with our colleagues at the surface level), and avoiding digging deeper and intentionally reflecting on how we can grow as a team.

Instead of joining individual breakout rooms, the team spends 20 or 30 minutes writing feedback for everyone on the team in a central place — like Miro for example. When everyone’s ready, you have a discussion and get people to own the positive things people are saying about them.

For the best results, do this on a Friday. It will leave everyone feeling good going into the weekend and coming back on Monday feeling closer as a team.

3. Team office hours

Setting up team office hours was something new that I hadn’t done before. But I think this has been one of the most successful bits of scaffolding that we’ve created.

It started based on some of the feedback from our digital team retrospective. People wanted to pair more with those in other teams and know who to reach out to when they’re up against a particular challenge.

In the physical studio, this is pretty easy to do. You can simply ask someone to go for coffee to get their feedback on something, or you bump into someone in the kitchen and naturally start thinking through a problem together.

Matthew Trivett visually explaining how encryption works.

To recreate this ‘water-cooler type environment’ we host a virtual space each week to have informal chats (and no, I’m not talking about some sort of Clubhouse, the exclusive virtual hangout, which always reminds me of memories of being picked last on my middle school’s sports team).

‘Office hours’, for us, is an inclusive space for people to share ideas and get feedback.

A space where it’s encouraged to “look at everyone as a mentor and opportunity to grow from” as Julie Zhuo points out in her book, Making of a Manager.

This approach requires zero prep, in fact, I actively discourage people from bringing pixel perfect or polished ideas to the group. The entire dynamic switches when it’s a space to present ideas — it shifts power in the room.

The goal here is to actively break down hierarchy and create an equal playing field. Everyone brings a different perspective and questions that are valuable for product development and individual growth.

This is my favourite meeting of the week because it doesn’t feel like one. It’s a space to just chat and get to know your teammates better.

Keep on building…

The scaffolding isn’t anywhere near being finished, but the roses are starting to bud based on the foundation we’ve created. The hard work doesn’t stop here, we need to keep building and tending to the team as it grows. We need to continue learning and growing as a team before the latticework can disappear and allow for diverse possibilities to flourish.

I’m keen to hear how other people have set up remote teams! Please drop me a note on Twitter: @alyblenkin.

I really admire how open and transparent people are with weeknotes. I’m more of a ‘let me think on this for a long while before I have the courage to share my thoughts publicly’ type person. However, I’m actively trying to get better at this…here’s to me giving it a go.

I also want to give a massive shoutout to Melissa Gates for all her thoughtful suggestions to improve this blog post!

Resources and further reading:

--

--

Aly Blenkin
WeAreSnook

Writing about the intersection between design, technology, and impact.