A former developer that turned rogue

Magnus Eriksson

Scaling and building performing teams

I am not an expert in creating performing teams, there is not really any doubt about that but i have been in teams since i started working in IT-industry 15 years ago.

I have seen different teams, team members and leaders, different ways of building teams, both from within a team and from the outside of creating & changing them. I can say that i have seen quite a lot, and one thing is certain, the process looks different everywhere.

The common denominator between all is the word “resources” and what it means, in other words people. A resource is something that is available to use, like wood when building a house, the problem with the word resource when talking about the people, is that people are more complex. The complex part you tend to forget when talking about the resources because the word resource is a simplification over that complexity to just be about time or availability, this why this is word is so easy to use but also very destructive. A human is something changeable, people can be trained, thought, people also get experience and constantly improve, which means that they evolve, but if you only think of people about resources this will probably never happen because of not leaving enough room to grow.

Companies tend to assign resources to projects, instead of assigning projects to resources, and this i think is all wrong and something i try to remove wherever i see it. This is because people tend to believe that projects is the value and not the people that work on them but this is untrue, people are those that produce the value that later turn into money, money comes when the project is delivered not before, this is why i say that we should stop talking about resources and start to talk about the people instead. Remove the resource word completely and lets focus on those people some more.

How can we evolve our staff, how can we make them better and faster? There is no easy way but i know one thing will help, let the people be in a fixed environment and let them stay there for a while. Let them have the time to evolve together, learn from each other, let them have time to become this unit called team, give them time to become a stronger team, a performing team.

If you think about resources you never think about the human, you think of now and not on the future.

This is sort of the basics for this entire post to look at everything from team perspective.

Building a team takes time, in short term it will be hard to see all the benefits but in the long term they will be more efficient than you previously seen, they will complete the projects better and faster and just because they do not have to go through the team building process over and over again, you might even start to see a performing and self-organising team where team members take on roles where it is needed

The stages of group performance

The way a team is ramping up is always basically the same, it is a little bit dependent of the persons within the team but every team go though “Tuckmans stages of group performance” [1] and i think this is extremely good to know about, because it tells you something about the importance of having teams that are together longer than a project.


“In the first stage of team building, the forming of the team takes place. The individual’s behaviour is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organisation, who does what, when to meet each other, etc. Individuals are also gathering information and impressions – about each other, and about the scope of the task and how to approach it. This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done. The team meets and learns about the opportunities and challenges, and then agrees on goals and begins to tackle the tasks. Team members tend to behave quite independently. They may be motivated but are usually relatively uninformed of the issues and objectives of the team. Team members are usually on their best behaviour but very focused on themselves. Mature team members begin to model appropriate behaviour even at this early phase.The forming stage of any team is important because the members of the team get to know one another, exchange some personal information, and make new friends. This is also a good opportunity to see how each member of the team works as an individual and how they respond to pressure.”


Every group will next enter the storming stage in which different ideas compete for consideration. The team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept. Team members open up to each other and confront each other’s ideas and perspectives. In some cases storming can be resolved quickly. In others, the team never leaves this stage. The maturity of some team members usually determines whether the team will ever move out of this stage. Some team members will focus on minutiae to evade real issues.The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences should be emphasised. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control. Some teams will never develop past this stage.Supervisors of the team during this phase may be more accessible, but tend to remain directive in their guidance of decision-making and professional behaviour. The team members will therefore resolve their differences and members will be able to participate with one another more comfortably. The ideal is that they will not feel that they are being judged, and will therefore share their opinions and views. Normally tension, struggle and sometimes arguments occur. This stage can also be upsetting.”


 “The team manages to have one goal and come to a mutual plan for the team at this stage. Some may have to give up their own ideas and agree with others to make the team function. In this stage, all team members take the responsibility and have the ambition to work for the success of the team’s goals. The danger here is that members may be so focused on preventing conflict that they are reluctant to share controversial ideas.”


 “It is possible for some teams to reach the performing stage. These high-performing teams can function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. By this time, they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channelled through means acceptable to the team.Supervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions. Even the most high-performing teams will revert to earlier stages in certain circumstances. Many long-standing teams go through these cycles many times as they react to changing circumstances. For example, a change in leadership may cause the team to revert to storming as the new people challenge the existing norms and dynamics of the team.”

Some teams might never get to a performing stage or start to self-organise, and if see tendencies of this never happening then you should evaluate the team composition and maybe change it around a bit, look for clues and try to figure out the problem.

One valuable advice is to try to get the teams as even as possible, teams form greater when the individuals are on a equal level because there is no goto guys within the team, the knowledge is equal so you cant turn to to someone for help or it is at least harder and therefor forcing the team to come together and start to form. It is like having only one good tire on formula one car, it doesn’t really help car performance and probably hurting it more.

How do you scale?

When companies are growing they need to changes in teams more frequently than others, and frankly new employees suck, not because they are bad just because they are not familiar with the company processes, tools and culture, they might not know anything about the product you are selling, and this is a real problem. So what can you do?

So what can you do to keep the teams momentum and still change team compositions as you grow or get new projects that also needs to get taken care of.

Basically you cant take on more job and create new teams without enough employees. If you have a big team you might be able to split a team but a normal team size is around 3-10 people dependent on what kind of work you do, i usually tend to say that the magic number is 5, at least for our projects. 4 developers and 1 tester. The bigger team you got the more waste time you produce so try to keep the number at an good level.

Find people who fit the team.

Getting the wrong person in a team can be really bad, Is he the right fit for the team? Is the team lacking in some area that we can fil? Is the team members on a equal experience level? and so forth are all good questions to try to answer before assigning a new team member to a team. A great fit will increase the output from the team, a bad fit will do vice versa.

Leverage on existing knowledge

When hiring new employee there is always a hurdle starting a new team, the knowledge about your processes, culture or tools at your company is not there yet, and one way of making this transition smoother is to move one existing into the new team and replace him with a new guy in the old, this way you can start a team with some knowledge and don´t disturb the old to much. You can move more than one developers as well but try to limit the number less than 30% of the total team size.
Don´t ever assemble a team with only fresh hires, not only will they spend at lot of time in learning but they wont get any help on regular basis, they need to look for answer outside the team which is probably fine but not fast enough, and not only this, this will set the team away on a clash with the company culture. Culture is important keep although it will be changing as the company grow or change.

Keep the natural leaders

Natural leaders are hard to come by so try to not move them (if you have one) when creating new teams, if you move them then the previous team can become weaker but it can also create opportunities within the group to step up so it is a gamble, so try to keep them, if you leverage existing knowledge as above it can create this opportunities as well.

Limit distribution

Distributed teams is a complex thing in it self and usually only tend to work great when there is a lot experience amongst the team members, this way the team can still form by it self because the normal questions are already answered, But if you still want distributed teams see to it that no team member is ever on its own, otherwise the waste product will be even bigger in terms of communication time and so, the lonely developer might also feel a bit left out and we are all human and have feelings. Minimum i would say that 2 in each office is a good thing because then you can leverage on each other and get all those benefits.

To get to a point of time when a team can call it self performing takes a while if we are talking about less experienced developers, and can be quite short if they all have a lot of experience. There are no fixed timelines on this, they will come the performing stage at some point, and then they need to be able to stay there as well, any little disturbance can get the team of balance, and it our job to see to it that never happens.

So my advice when it comes to building team while scaling is that it is really hard but you should always try think long term as possible and let it take some time to form, it will be worth it in the end. Let the load of the teams decide if they can pick another project, don´t let the project decide that you need another team, you will actually lose both time and money by doing so.



[1] http://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development

Middle management – death of creativity?

I have worked as developer for over 15 years, and roughly one and half year ago i moved over to becoming a development manager. I like the role but it is not even close to what i liked being a developer and that might be expected but what i miss is to be in charge of my own creativity and i think this comes from not really being in the driver seat anymore. What i mean is, as developer i had all the experience, skills and tools to do whatever i wanted, i was not limited by anything, i was in total control. Now days my experience is low, my skill set is limited and i know very little about good or bad tools and i am in need of others, i have limited control, i still perform good towards the developers but upwards i am lacking a bit. This is surely something that will come but it is quite frustrating to not be in charge over yourself in a sense.

As developer i always had personal projects and even if i probably never finished half of them, i had them, and worked on them from time to time but when i started as a manager they stopped, naturally the focus area shifted from being code to people and teams and it was not as easy to do this any longer, the time was all occupied by other things like learning the new role, meetings or reporting, but after a couple of months when the worst had settled and i more understood how everyone and everything worked i started to feel an urge again to have projects, of course there is less code involved but management comes with a lot of bugs, glitches and is in constant need of improvement in almost all areas, especially when are a growing company (from 3 to 109, and i was nr 20) Now a couple months later i have done a lot, some are work in progress and some are finished but i have the same feeling again, the DIY feeling.

To give some examples of what i have accomplished or is currently working on:

  • Removed some of our reporting needs
  • Started creating a developer career program (huge!, i know)
  • A tool for running CasperJS automatically (code, yes!)
  • and some more…

The conclusion is that management is probably death to your development creativity but not to creativity in general, and that might not be such a bad thing, and a good thing is that we can still apply principles that we have learned as developers in your creativity as a manager as well.

Keep it simple, stupid.

Magnus Eriksson

Hammarby Alle 120
SE-120 65 Stockholm