Three frameworks to get stuff done more easily with your team
Ask a person about their productivity, and they’ll tell you about using specific note taking techniques, time management or focusing on specific goals.
Ask a business about their organization’s productivity, and they will talk about efficiency, collaboration, the importance of meetings or the value of async work.
The truth is, everyone has their own insights and frameworks around what makes them and their organizations productive. Sometimes it’s a really straightforward process. But most of the time, projects get bigger, teams get larger, and challenges get trickier.
The higher the complexity, the harder it is to define that thing we call ‘being productive’.
How to actually be productive when working in a team — the secret ingredients
If productivity is something you’re spending time thinking about, there’s probably a couple of things you’d like to see change. Things like:
- How do you make team members collaborate in a positive way, day in and day out?
- How do you facilitate productive conversations to figure things out, rather than let talks turn into endless circles?
- How do you make the small things no longer become big issues? Minor errors, things falling through the cracks — can you handle all the things that end up chipping away at team morale?
I’m going to assume you’ve already went through the steps of defining what you want to achieve, and your specific goals. You’ve probably already gotten strategies in place, and project plans written down. So I’m not going to talk about that part.
What I am going to talk about is the day-to-day stuff. The ‘I hate talking to [colleague name] because it’s always exhausting’. The ‘things fall through the cracks and we keep making mistakes’ part. The ‘why are we spending so much time on this uselessly’ part.
I don’t think sorting out these kinds of problems is hard, but it is dependent on two things:
- You’re commited to not overcomplicating things, whether it’s processes, discussions, or project work. Say what you mean, and mean what you say.
- You’ve got someone on the team willing to play the facilitator. In can be the team manager, it can be the project driver. It can even be that colleague that is good at summarizing talks and keeping things organized (no, it’s not the loudest, most extroverted person in the meeting. It’s usually the one who says ‘What I’m hearing is…’ and ‘Let’s agree on our next steps…’ ).
So, here are the 3 frameworks to make the day-to-day work less bumpy to get through
I’ve selected them after reflecting a bit on what are the most frequent tools I’m reaching for mentally, when organizing a group of people working on a specific project.
Here’s how to look at tasks, set up collaborations, and figure out what’s important.
1. Learn to think in flowcharts
You can use flowcharts to map pretty much anything you can break up into steps. You’ll usually find a flowchart when discussing user flows (how do I make a new feature for my SaaS product), process steps (how does an article get published on the blog) or sitemaps (how are all the pages connected).
Why learn this: it helps you break down anything into the specific steps to get from point A to point B.
Where is it useful: when you need to map application and site flows, process flows, information flows. When it’s important to not skip any steps (especially if you’re more of an intuitive worker and tend to do mental shortcuts). UX people are very good at this, go learn it from them.
When do you need it: when you get annoyed on the colleagues who worked on something before you because some point wasn’t covered or included. When things fall through the cracks and you can’t tell where.
Resources:
- https://www.nngroup.com/articles/wireflows/
- https://www.figma.com/resource-library/how-to-create-a-flow-chart/
2. Define roles with the RACI matrix
The RACI model — or the responsibility-assignment matrix is like a cheat sheet that tells everyone who’s doing what. It outlines the roles and responsibilities of team members based on their expertise, but also spells out the rules of engagement between team members.
- R — Responsible is the person (or multiple people) doing the work.
- A — Accountable is the person making the decisions, whether it’s about the direction you’re going in or signing off on deliverables. It’s healthy to have one person be accountable for one project, so things don’t get stuck in decision limbo.
- C — Consulted is how you define the stakeholders that have an impact on the project and their opinion needs to be taken into account.
- I — Informed is how you define the stakeholders that don’t have an influence on the running of the project, but who need to be informed of the going-ons to keep everything on track and avoid surprises.
In other words, when it comes to tasks, activities, or creating deliverables, the RACI matrix spells out what the team member’s jobs are, how to engage with each other and what expectations is realistic to have from each other.
Why learn this:
- it clarifies out loud who does what and who is responsible for what (from work to decisions).
- it’s a safe setup to difuse potential conflicts and have the difficult conversations around responsibilities and professional boundaries.
- It’s an elegant approach to let people bow out of responsibilies or communication flows where they can’t contribute much or which are not part of their scope.
Where is it useful: pretty much during any project kick-off discussion.
Teams that keep their members format will do this more formally a couple of times in the beginning, but soon enough the roles will become common knowledge and habit. It does help to do the occasional check-in, especially if the shape of projects change or new team members are joining.
Newly established teams or collaborations should always have this discussion.
When do you need it:
- when people feel they’ve been left out or brought in too late.
- when different people’s scopes overlap, and it creates friction.
- when you’re setting up a project with a large group and you need to clarify responsibilities and ‘rules of engagement’.
Resources:
- https://www.teamgantt.com/blog/raci-chart-definition-tips-and-example
- https://www.forbes.com/advisor/business/raci-chart/
3. Prioritize with the RICE model
Borrowed from product management, the RICE model helps you gauge how important it is to get something done and where it sits in your (probably endless) to-do list.
Let’s break it down:
- Reach: Imagine how many people will see your project within a specific time frame.
- Impact: Estimate the expected impact on your business. Think about both the cool numbers (like conversions) and the more fluffy parts (like customer happiness).
- Confidence: This one can be tricky: rate how sure you are that your project will have the expected reach and impact. You can base this on your experience, or on insights from what your competitors are doing.
- Effort: Eyeball how much elbow grease it’ll take to make the project happen. This in hours of people working on this and money being spent.
Why learn this: while you don’t need to always apply clear numerical values to what you’re comparing, it’s a useful shorthand to prioritise tasks and focus change requests or feedback on what’s most likely to affect impact and reach.
It can be important to do the actual calculations, to keep you grounded and make good assessments. For example, in situations like: how much money to invest in promoting each of your services, or how much budget to give to specific marketing tactics.
My rule of thumb is: Do actual calculations when getting it wrong carries great risk (for example, when you’re deciding budgets). Eyeball it if the risk is low (like when discussing feedback on a content asset).
Where it’s useful: whenever you need to prioritise a list of options. It can be the items on your to-do list, the choice of your marketing tactics, the next feature or service you’re releasing.
When do you need it:
- When conversations on tactics are stuck in decision limbo.
- When feedback sessions become an endless loop of comments and change requests.
Resources:
There you go, three frameworks to help you and your team be more productive.
Full disclosure: you don’t have to call out the framework you’re applying in a given moment. You don’t have to make it a formal discussion.
If you want to map a process, say ‘Let’s use stickers for what the specific steps are and how the project changes along the way. We can color code it for each team’s input.’
If you’re dividing responsibilities on a project, ask: ‘Who is the decision maker here? Who does what? Who gives what kind of feedback? Who do we need to keep updated on this topic?’
Don’t say ‘Let’s make a spreadsheet with a scoring system for each tactic’. Say ‘Let’s compare budgets and effort to outcomes from the past six months and prioritize from there.’
Does this really work?
You tell me.
Think back on experiences from your life, when projects and collaboration weren’t working out how you expected them. If you apply now one of these three frameworks to your situation, would it have gone differently?
Here’s what I’ve learned after 10 years of working in teams, in all kinds of different setups and companies.
Build the habit of covering the basics.
The more responsibilities we get assigned, the more we rise in the ranks, the more we tend to think that it’s the complexity that needs most of our attention. But it’s the basics that keep the wheels turning.
