The First Question to Ask When Building Teams – Is This Really a Team?

Note: This article is co-written by Viktor Cessan and I. You can also find this article on his blog.

posts/2018-10-08-is-this-really-a-team/team.png

Have you ever wondered why so many organizations fail at building effective and high performing teams despite offering so much support in different ways e.g. by managing people, by managing the environment, and by coaching teams? You’re not alone. This is often something that frustrates teams, coaches, and managers.

You’d think that given all the support that teams receive, they would have great chances for becoming high performing. What our experience shows us, and research, is that it’s more uncommon than common for teams to get to a high performing state. While there are many reasons to why this happen, in this article we’re going to look at one often overlooked aspect of coaching teams. That is, whether the team in fact is a team or not.

Teams, Pseudo-Teams, Temporary Alliances, and Co-workers.

You might assume that if you put together a bunch of people and give them a goal, they’re a team. But that’s not how it works. While all constellations are working groups of some sort, in order for a working group to be considered a team two criteria need to be met.

First they need to have a common/shared goal and second they need to truly need each other to reach that goal. The need can be objective, e.g. that someone has accesses or a necessary skill-set I lack, or the need can be subjective, e.g. I’ve come to prefer a collaborative way of working such as pair or mob programming. But only when these two criteria are met, a working group can be considered a team.

posts/2018-10-08-is-this-really-a-team/working-groups-team.png

Pseudo-teams

Teams where the members do not necessarily need each other to reach their goal, despite the goal being shared, are merely Pseudo-Teams. In Pseudo-teams members often, but not always, report to a manager who assigns goals to the members individually or they do it in pairs. Sales teams, Customer Service Teams, Component teams, Channel teams (e.g. iOS, Android) are some examples where members from an objective standpoint often can accomplish their work and reach their goal without needing the help of other people in the working group.

posts/2018-10-08-is-this-really-a-team/working-groups-pseudo-team.png

Temporary Alliances

When co-workers need each other for something specific but they don’t share a common goal they form Temporary Alliances. Examples of this are team members that embed perhaps to help a team adopt a new technology. Alternatively if I need to get help from IT-support, or a new entry card to the building and I ask office management for help, I have formed Temporary Alliances. Knowledge sharing guilds are also examples of Temporary Alliances. A Temporary Alliance can last anywhere from minutes to months.

posts/2018-10-08-is-this-really-a-team/working-groups-temporary-alliance.png

Co-Workers

When team members don’t share their daily goals and they don’t need each other to achieve them, they’re just co-workers.

posts/2018-10-08-is-this-really-a-team/working-groups-co-workers.png

Common goal is both objective and subjective.

While the need for each other can be either subjective or objective, having a common goal needs to be both subjective and objective. If a common goal is shared by the people in the team but the rest of the company doesn’t believe that’s the right goal, those forces will work to disband the team.

If the company has a shared view of what the goal should be but only a few in the team share that view, sub groups will form. And of course most work can be linked towards the company’s overarching vision but that’s not what we’re talking about. We’re talking about goals as in daily work, monthly goals, quarterly goals, a year or years-long specific missions.

So whatever the goal for the working group is, it has to be both objectively and subjectively shared.

posts/2018-10-08-is-this-really-a-team/working-groups.png

Knowing your type of working group

It’s crucial to pay attention to whether or not a working group is a team because it dictates what kind of structures to build and how to support the team. We see organizations spend tremendous amounts of energy in trying to coach Temporary Alliances and Pseudo-Teams as if they were teams, when in fact the kind of support those working groups needs is very different from what a team needs.

Not only is this a wasted effort it’s also highly demotivating for the members to engage in activities that attempt to foster collaboration when it’s not necessary. Examples of this are daily stand-ups with people who don’t have any real reason to sync other than to possibly keep their manager updated (it’s really common still) – ever heard standups like this: “Yesterday I went to these meetings, today I may think about this and attend these workshops, and I don’t have any impediments” or “What are you going to do today”?

Frequent offsites with Temporary Alliances aimed at team building with extensive getting to know each other exercises or talking about roles and responsibilities are also examples of misdirected efforts.

Only teams need to stick through the rough times

Different working groups are affected by group dynamics in different ways. A team has to get through the rough times because they do need each other. A Temporary Alliance will often never work together long enough to get to the storming phase (see Tuckman’s stages of group development) or they may change or disband the alliance because they don’t really share a common goal and they don’t need to stick through difficult times. They can only fake it until they don’t need to.

The same goes for a Pseudo-team. When the times get tough, the team members can either try to work their way through the difficult times or they can just stop showing up to meetings, work from home, etc. They simply don’t actually need each other.

Would you like to learn more about to manage group dynamics?

Viktor and I hold training courses about building teams and managing group dynamics. We have versions tailored for managers, agile coaches, scrum masters, product owners, and entire teams and will also adapt for mixed groups. Reach out to either of us to find out more.

The biggest lessons from a successful software project

In my years of working with software projects the one thing I have learned is that doing software projects is really hard. Probably zero projects I have been part of or heard of has delivered their value, kept the quality to a standard everyone is proud of, launched on time and had a team of happy people through all of it. Recently, though, I was part of project that did just that. An actual real life professional software project that was deemed successful by both the team and the stakeholders.

I work at Swedish real estate site Hemnet. We are a company of about 50 people with about 15 people working in product development — mostly developers plus a few designers. Being a small company means we are close to management and all fill a bit wider roles than in larger companies. The biggest challenges in our organization has been making priorities and following them through. This heavily influences where we have put most of our effort and where we have made the biggest lessons making, though I think most of it can be pretty broadly generalized.

The team consisted of one UX designer, one graphics designer, one business analyst, one dedicated developer and me as team lead and part time developer. With the team of 5, we switched map providers, created a solution to render 100 000 hits on a map simultaneously and designed and implemented an all-new view for searching on maps. We did this in just 6 months and, from the release date set in the beginning of the project, slipped only one week with being fully rolled out.

Before we get in to what did matter, let me point out that you can Scrum, Kanban or Scrummerfall all you want without getting much of results. It’s easy to try to change the internal methodologies of a team because that’s something you’ve got complete control over. The biggest challenges though, are in getting the right conditions for the team and within the organization. Only after that is settled does methodologies begin to provide real value.

Here are the biggest things that made the project succeed.

A team with power to do its job

This is where everything begins. Way too often, projects are spread out over departments and even split in sub-projects over different departments. The business side is done in one project, handed over to a design project and then handed over to a development project. And even if that is not the case, people are still spread out without good means to focus and communicate on the project. This completely kills the common understanding and collaboration within a project.

Our team was created with exactly one premise: the goal of the project. We were to create the new map search experience on Hemnet. How would it look? Find out. How would it work? Find out. What would it even do exactly? Find out. This was absolutely crucial in enabling us to do our work — we are product developers and excel in solving problems. Based on the goal, the team formed the plan to do it, the concrete requirements and features and did all the design. Except for getting the rest of the company to buy in on our plan, we were never in need of someone else’s decision.

This of course requires the team to have all the competencies needed to get the job done. Having a team with a common understanding from start to end has incredible value in ensuring everyone works on the same thing and towards the same goal to create a cohesive product. In our team, having our business analyst from start to end allowed us to not stray away from business goals, and having everyone with from the beginning ensured we all really understood why the heck we were in this to begin with.

One of the factors we all appreciated the most was being all together in a room dedicated for the team and the project. If you are in an office, the change from being just one room apart is a huge boost to the social aspects of the team and the collaboration made possible by putting sketches up on the wall and just leaning over to talk about something is invaluable.

Making sure of a stable team with the right conditions is where everything begins.

Awareness of what could go wrong and preparation for it

Things always go wrong. The problem is that we more often than not ignore this and just plan for the best. This results in everything going to pieces when an assumption turned out to be wrong or an unforeseen problem arises. As a result, projects usually hit a point where everyone gets uncomfortable over something that went wrong and starts arguing over how to proceed — a situation where exactly nobody has their best ideas.

We spent a lot of time in the beginning of the project trying to figure out where things could go wrong. Being aware of the risks is key to being able to react in an intelligent way when something eventually goes wrong. In our case, we identified where users were most likely to have a hard time with the change and what business related key measurements we were most likely to impact. We completely shaped the project around the risks and made sure everyone understood and were prepared for the things that could go wrong. This helped us adapt continuously and completely avoid disasters, both in the product itself and among people in the company.

The plan we made focused on the key features that would be realized in the project on a higher level. This allowed us to cut the right corners in times when time started getting sparse while still delivering the value promised. We also spent time discovering where scope creep would most likely pop up and discussed these points beforehand. The things we agreed on not doing were then part of the plan. Designing the plan in terms of general features and including the things we would not do was a key tool for us in delivering the project on time.

Plan as much for the risks and the things you won’t do as the things you will do.

Collaboration outside of the team

All developers have been in projects where requirements and conditions change over their heads. A manager changes his or her mind on something too late in the project or another project gets important and starts snatching people. This is one of the most effective ways to demoralize a team trying to make something great and is probably also the most common way I have seen projects go out of control. The problem here is that managers often have no ability to make sense of cryptic scrum points, refactorings and vague descriptions of what is done and what isn’t, which forces them to make decisions with effectively no information on what they are deciding on.

First off, we put a lot of effort in communicating the plans for the project. We made sure everyone with the power to change our faith were fully aware of the plan, including what we would do, what we would not do and what we needed to complete the project. We did this early enough that we still could change everything and made sure that all stakeholders had their say before nailing it.

During the project, we continuously discussed any change that would affect stakeholders with them and held recurring demos open to anyone in the company. This allowed us to work without dropping anyone’s perspective. We had a number of small changes come out of this that would have gotten into big problems if they wouldn’t have been revealed until the end of the project.

Keeping managers and stakeholders in the loop is key to having the project stay it’s course.


There isn’t ever a silver bullet with these things. These were the biggest contributors to this specific project being a success. Even though I have reason to believe they would help significantly in many situations, a project always have to start with the people and environment where it will live.

We have the brilliant Thomas Lindquist as our full time coach working on process and people since two years. This project is the result of those two years of experimentation and much of the reasons why it succeeded are the brainchildren of Thomas’ continued thinking on the matter. This may seem too obvious, but the best way to get better at process is to spend time thinking about it and improving it.

If you are interested in more on this particular project, Thomas has written on the “post-mortem” retro we held with the team, our graphics designer Daniel Feldt has written on his perspective of the project and our UX designer Magnus Burell had a talk on the UX side of things. And for the more technical side, our map-oriented developer Igor Tihonov will talk on this year’s FOSS4G in September.

Riding the ages

Technical revolutions such as the Industrial Revolution are periods where the whole world gets revolutionized one area at a time by big contemporary technical breakthroughs. The breakthrough isn’t of any value by itself, but by revolutionizing a large amount of areas we care about, the technology becomes the largest driver of its time.

A revolution runs until the contribution of its values on the world has stagnated. We can no longer make a new machine that halves travel times or frees up as much time for people as the dishwasher does, and so the Industrial Revolution has peaked and room for the next revolution appears.

We’re now living in the ages of the Information Revolution. The driver this time around is the ability to process and communicate information at an ever increasing pace. Just as the goal of the Industrial Revolution turned out to be making manufacturing ubiquitous, the goal of our time must be to make information ubiquitous.

There is still the challenge of creating something of actual value for people — because without actual value that something will not gain momentum enough to move the world forward — but the path forward is clear: getting better information into people’s hands.

Someday this revolution will be replaced by one of another age, but for that to happen, we first all have to move the world there using our time’s biggest breakthrough; by creating valuable ways for people to use information in all the different areas we care about.

Creating experiences

You could create something that delivers an account balance to its account owner, something that helps visualize spendings, or something that helps people create perfect savings budgets. Or you could take on the problem in its entirety and combine all of those things to create something that is far greater than the sums of its parts.

In the first example you’re just giving people tools and leaving them with the challenge of figuring out how to make sense out of their economy. In the second you’ve got the potential of creating an experience that solves managing money without forcing someone into copying and pasting numbers into giant spreadsheets.

People with a specific interest in the subject will still want their tools, but people usually only have a few of those special interests. All the rest of the problems we’re facing every day are things we want to hassle as little as possible with in order to be able to focus on the things we really care about.

There’s enormous room for making great experiences out of all those problems people are faced with every day. Our world may be driven by increasingly complex problems, but that doesn’t mean we couldn’t solve those problems with wonderful experiences and at the same time allow ourselves to live simpler lives.

The curse of the social Internet

I have been social on the Internet ever since I can remember – I’m young enough to have grown up with instant messaging and online communities. It’s a wonderful thing to be able to communicate so easily with people. It has gained me both stronger relationships with existing friends as well as new friends. But as being online has transformed from something people sometimes do into something almost everyone always is it contributes more to me being less social than the other way around.

Here’s the thing. It’s ever easier to get a quick dose of social on the Internet. Share something and get instant feedback from a number of people, or just message any of the number of friends that probably are online some way or another. This makes a situation where, if you want to, you can always “be social” in some way. When this works well enough and go on long enough you develop, as Paul Miller put it, an itch to always be checking to see if someone misses you.

And when you’re increasingly interested in what happens on the Internet your attention on reality slowly fades away. You check Facebook in the middle of a movie and you check Twitter at a party, or even in the middle of conversations. Every one of these quick glances takes focus away from the thing you’re supposedly doing and, essentially, makes that thing less valuable.

Also, with the promise of always being social online there seems never be any time spent alone. You’re always an arms-length away from all the tasty socialness online and suddenly a night alone becomes seemingly not so alone. Enough of this and you start doing a lot less of the precious real things you otherwise would do.

Ultimately, social aspects of the Internet has made me less social. I’ve come to appreciate the things I do less and even do less of the things I like and love to do. The promise of social ubiquity turned out to be a curse for real life.

Going forward, all feeds, contact lists and notifications except for select direct messages will be completely hidden from my devices and I’ll constrain my checking of feeds to when there’s natural breaks in the things I’m actually doing. It’s time to focus on and enjoy one thing at a time for a change.