In the last few years, I’ve been fortunate enough to have been involved in dozens and dozens of really interesting projects in the software and design industry working at Mäd.
From redesigning the booking systems of a national transportation company to launching eCommerce websites with tens of thousands of products, rebranding a major Microsoft partner, all the way to redefining how consumers pay for the goods and services they buy by launching a well-known mobile money payment application that took the market by storm.
All of this has been great, I’ve learnt a huge amount and had a lot of fun.
However, I’ve also experienced a lot of frustration.
Missed deadlines, broken promises, miscommunications, times when legal teams got involved, and, generally speaking, a feeling that deep-down, we were only doing about 10% to 30% of what we could have done on these projects, and there wasn’t really any single reason or person that could be blamed.
It just happened.
I began to suspect that there was some type of complete systemic failure in the way we worked, and that teamwork in the modern age is actually getting more difficult, not less.
Teamwork is getting harder.
At times, there were isolated working sessions or small projects where things just seemed to go just completely right, and I’ve tried to understand what was in common with all these successes.
My initial (re)discovery, is that small teams with full responsibility and ownership outperform larger teams that don’t include stakeholders that are empowered to make affirmative decisions, by a factor of 2x to 10x.
Then, I decided to dig a little deeper.
- Why is it that these teams work better?
- What are the common working practices of small teams with ownership that seem to work so well?
- Is there any possible way to systemize or automate it so it can scale?
As I studied this, it became clear that small teams do many things better, and the main things are:
- Having a clear idea of what needs to get done, when it needs to get done, and by who.
- Receiving and communicating the project status.
- Having one version of the truth.
- Identifying project risks as early as possible.
- Taking Ownership.
And generally speaking, they can do this with simple tools like a whiteboard or a few post it notes and be more effective that larger teams using something like Microsoft Projects (yuck!).
Communication at scale is difficult.
So, clearly, the tools themselves are not that important, it is just a fact that as you scale past a non-trivial number of people (say, 10), teamwork becomes increasingly more difficult.
That’s because team communication does not scale in a linear fashion compared to the number of people on the team.
For instance, if you have a team of 2 people, there is one communication thread (between the two individuals). Throw another person into the mix, and now you have three communication threads. So, while the team size has increased by 50%, the communication threads have increased by 300%.
Let’s see how this grows:
- 2 team members = 1 communication thread
- 3 team members = 3 communication threads
- 5 team members = 10 communication threads
- 8 team members = 28 communication threads
- 10 team members = 45 communication threads
- 15 team members = 105 communication threads
- 20 team members = 190 communication threads
- 30 team members = 435 communication threads
- 50 team members = 1,225 communication threads
- 100 team members = 4,950 communication threads
This can actually be expressed by the following equation:
Where “n” is the number of people that need to be involved in the project.
It gets worse.
However, this is actually a complete oversimplification of the problem, because it assumes that there is only one method of communication, which in the modern world is pretty much a fallacy.
To give you an example, in a large project that I am involved in, information and communication can be found in the following places:
- Asana — the official project management system for the project
- Google Docs — where the specifications are kept
- **WhatsApp Group **— where chit-chat with project members happens
- WeChat — where anyone that happens to be Chinese lives.
- **Our own custom chat application **— because that is actually part of what we’re building.
- Slack — where senior executives and board members reside for the occasional suggestion and discussions
- Skype — where calls are made with various vendors in other countries are made.
- Email — Emails fly in and out with various comments, suggestions, and tasks.
- Meeting Minutes — normally also recorded by hand and either emailed or placed into a document.
- Photos of Whiteboards — yes, this does indeed happen.
- **Informal conversation in hallways and dark corners **— we all do it.
Now, you can see how a project of this nature, with 50+ people directly involved can quickly degenerate into a nightmare scenario, unless everyone has an ungodly amount of discipline in using the right tools for each type of work, and that everything is recorded correctly.
Querying the project managers, they are spending 40%+ of their time shuffling around information, keeping everyone up to date, and chasing up for project status.
So things are getting more and more complex, and the trend is towards distributed flash-teams, that come together for one project, and then dissolve, never to work together again.
However, things are still getting done all over the world, so why bother trying to reinvent the way people work?
Well, it’s because those teams that do decide to take a new approach, that prioritizes transparency, deep work, and thoughtful communication, tend to win —* big time.*
People tend to enjoy working at these organizations for more, and, ironically, the organizations move forward at a much faster pace by slowing down and consciously making important structural decisions on how people should work.
What Does Great Teamwork Look Like?
Perhaps a better question is what it *doesn’t *look like. I’ve noticed that great communication is something that I am not actually aware of when it happens, I just have the feeling that things are going well, and that I am working with a team that actually cares about the final result.
However, we can definitely identify some traits of great teamwork:
- It’s fun — you actually enjoy working on the project.
- It’s fast — you often end up ahead of the project schedule, and it feels like the whole project was overestimated.
- Real-time information — you normally end up with real-time, or near real-time information, and it’s easily accessible.
- Not many meetings — and the ones you go to feel useful, productive, and decisive.
So, like any good entrepreneur, I decided I should build something to scratch my own itch, and create a way to solve the common issues that happen when projects involve a non-trivial number of team members.
Essentially, allowing large teams to work as effectively as small teams.
The tagline for Bloo is Teamwork, made simple.
The core underlining principle is simplicity, and the idea that anyone should be able to use it, without having to (re)learn anything, so they can start being productive from Day One.
The current concept of Bloo is split up into a number tools, that aim to make project successful, and team members happy.
At the most basic level, it’s about getting the three basics right:
- A list of things that need to get done, with the supporting information required.
- People assigned to each thing.
- Timelines for each thing.
In our long term vision, we want to provide:
- Discussions — This is a forum-like experience, where general ideas and information is shared. This can be both long-form and also short-form (i.e. chat style) discussions.
- Process Board — This is the to-do management part of the application, which is great to use to build your team and business process into, and it’s dead easy to use.
- Updates — This is where people go to update other team members on what they’ve been up to.
- Newsfeed/Inbox — This is available both on a global (i.e.everything) view, and also as a personalized view, where we show you what’s happening that is relevant for you.
- Notes — This is where you can collaborate on documents. There are no complex options for formatting (so it always looks great regardless of the user's skillset), but it’s a nice way to ensure that you can hash things out together, and that everyone has the latest document available, with all the historical changes saved into the document.
- Projects — All of these tools are then wrapped together in separate projects, which allows team size to stay small. Discussions, Tasks, Notes, and Updates are able to live in multiple projects, which is pretty useful because really large projects will often need to be split up into smaller sub-projects.
Another thing worth mentioning, is the ability to have third parties (i.e. Clients or Vendors) join you on Bloo. They get a much simpler experience of the platform, especially if they only have one project on your Bloo account, which in our experience is almost always the case.
As exciting as all of this sounds, right now, we've just released a v0.1 version to the team at Mäd. We don’t expect a customer-facing version until some point in late 2018.
However, feel free to sign up for the beta, and we’ll be in touch when we are ready for you.
In the long term, we’re going to be doubling down on the concept of simplicity, and spend far more time building technologies that act behind the scenes to ensure that the user’s experience in seamless.
Things like making search smart, so it understands what you’re looking for, based on your involvement in the projects, and being able to build an understanding of the relationships between users based on job titles, general activity, and activity between users.
To me, that is something that as a human being I understand intuitively, but the tools that I have at my disposal don’t really help.
So, let’s try and build something that has a strong opinion on how people should work together, and see if we can make work more enjoyable and effective for the world.