5 tools to manage complexity across teams

We’ve all heard it — “teams that work together, win”. Simple, not easy.

Most of the work we do (that’s important), both with our teams but also across the organisation, can be boiled down to emotional humans solving complex problems. And when we work together to achieve bigger results, it turns out how we work together is actually a complex problem and a rather complicated one as well.

This post is about some of the tools & tactics we use at Flyt to try and solve some of these problems — let’s take a look.

5 tactics we use to deal with complexity across teams:

  1. Rhythm
  2. Plays
  3. Checklists
  4. Boards
  5. Watchers

  • Rhythm. Having rhythm means having a routine. When you don’t have rhythm everything needs a meeting to happen. No rhythm means anyone can interrupt, everything’s urgent, and the deadline is always set to yesterday. If you’re finding that things seem a bit ad-hoc, you’re probably not managing complexity by establishing a sense of rhythm around you, your team, other teams or what you do. No rhythm means everyone has their own expectation of when to participate and when it’s ok to expect results. When you setup rhythm, teams know when it’s time to provide input, and also when to expect outcomes from you. Once you’ve setup a rhythm around the work you’ll do, communicate that clearly to everyone involved. Development sprints are rhythm, monthly releases are rhythm, next 90 day goals are rhythm, and more.
E.g. If you’re a data analyst and constantly get requests for help over slack, over e-mail etc., establish a weekly rhythm of results. Say you’ll setup office hours for general Q&A on Thursdays 14–16h (outside of that you may not answer), big reports need to be discussed by the analytics team during your weekly’s which happen on Mondays at 10h (or they won’t get scheduled), and that everyone should expect a newsletter with the most important metrics and learnings to be distributed on the last day of every month).
Photo by Jo Jo on Unsplash
  • Plays. Plays are documented standard operating procedures based on lessons learned. At Flyt we encourage folks to move from E > P. From Entrepreneurial to Purposeful. From winging things as they go, to becoming purposeful about getting better at them. It’s the big difference between Amateurs and Pros (Amateurs value isolated performance, Pros value consistent results). To get consistent results, we coach teams to document “how they do what they do” in a Playbook. Similar to the football analogy, a Playbook has a list of Plays that can be done at any given time and describe “how we do things around here”. These are not long descriptions of how to go about the work but simple bullet points about what’s important to get done by everyone that’s involved. Plays do two things. 1) Because we give plays names, everyone starts to talk about them as “things we do” and we start to see alignment around what we mean when we say “we’re running the X play”. Play names get used in conversations, and to discuss if we did or did not run it at a certain time (or worse, if we kind of ran it, but didn’t fully commit). 2) Plays allow us to have something to update when we do retrospectives with the teams and try to learn how to do them better. This is how we move from E->P. We have plays around communication, hiring, most stages of our product lifecycle, customer requests, dedicated teams and more. At Flyt all our plays are put together in a Playbook that’s available to everyone in the company.
E.g. We have a play for “Pull the Chain”. The description says that anyone can run this play and that it should be run if something is wrong and requires the immediate attention of one of the teams. It also sets expectations of what we intend to achieve with running the play (have clarity about who is participating, update everyone regularly about it, and provide what was the resolution). The play also outlines responsibilities of everyone involved (from driving, communicating, resolving and closing). At Flyt, everyone knows what we mean by “Pulling the chain”, and it’s not panic or drama, it’s consistent and reliable collaboration across the company to resolve something on behalf of a customer
Image from the Atlassian Team Playbook
  • Checklists. You can’t read off a checklist and fly a plane. Checklists are not tools to get things done — they’re tools to manage complexity. How many items do you think a surgery checklist has? Most people think it has 100s. Most people are very surprised to hear it only has 22 (link). You can’t read off a checklist and operate on a human being. That’s not what that checklist is about. The surgery checklist is meant to manage the quirky things that happen when a team of professionals that are busy doing their normal everyday jobs, have to come work together on something critical that involves their full attention. The checklist should be understood not merely as a list of items to be checked off, but as an instrument for the improvement of communication, teamwork, and safety culture in the operating room. Has everyone introduced themselves to the surgery team? are we operating on the right person ? can everyone confirm it’s the left arm and mark that? does anyone have any concerns before we start? how long is the operation meant to take? how much blood loss is expected?. Start treating checklists less as todo-lists for everyone involved and more as templates for the working agreements and communication rituals that different teams need to do so they all do a great job.
E.g. For new employee onboarding at Flyt, there’s 5 teams that need to come together so the new joiner has a fantastic first month. Everyone meets for a 15 minute stand-up (we call it a “check-in”) on the Monday before the new-joiner joins. During check-in, folks verbally introduce themselves, commit to the group to do the onboarding tasks assigned to them and mention any concerns they have to get things done. At the end of the week before the new employee joins, we get together for another quick 15 minutes (we call this one the “time-out”) for a last chance discussion of anything missing and to confirm everything is ready. Finally, by the end of the first week of the new employee, we all gather one last time in what we call the “check-out” to verbally discuss if everything went ok, and document any lessons learned.
  • Boards. When a group of really smart people find themselves discussing abstract yet hard to connect ideas, our experience is you can make everything simpler/better by using sharpies, post-its and a wall. Write down one idea per post-it, in big legible letters and stick each post-it on the table in front of you. This will get the team pointing at them as if they’re pointing at the actual idea. Try laying the same post-its out in a wall / board, left to right, top to bottom or however they make sense “in a visual space”. Folks will leap off their chairs and go straight into collaboration mode, eagerly debating the right order of things, the connections between them and the relative importance to each other. All of it from visualising ideas, one by one, in a physical space. (watch this: How to make toast).
Photo by Daria Nepriakhina on Unsplash
  • Task Watchers. Any task tracking system (Jira, Asana) has the functionality of informing a select list of people of every update you or others make to that task. Our software engineering friends have figured this one out a long time ago. But it works for other business teams as well. If what you’re doing is going to take more than a 2–3 days to complete, and/or it involves a bunch of people to do well, then inevitably you’re going to benefit from tracking your work. Log the request straight away in a task manager, add everyone that wants to be involved as a watcher or follower of that task and share the link. Everyone can work confidently knowing that they’ll get updated when dates change, blockers arise or when the work is finally done. No more tapping on the shoulder for status updates.
How to add a watcher to a task, from the Asana guides

And that’s it! As it relates to tools we use Notion.so, Asana, Slack and Jira to get it all done (which I’ll cover in a future post).

Hope this was helpful! ☀️

PS: What are your favourite tactics for managing cross team complexity? Let me know via the comments or by following me at @rcclerigo on twitter