A structure for effective teams

Written by Nik

Like any manager who is responsible for multiple teams, one of the jobs I often find myself doing is shaping how the teams work within each other and between each other.

In my head I often have a simple schematic view of the ideal setup. At one level there should be a good deal of freedom around how any group should work within itself. But when it comes to interactions between groups there should be simplicity and rigidity.

I should add that the reality is often very different to this ideal, and people who have worked with me will probably not recognise it. As I say—it’s an ideal to strive for, and it’s in my head. But it is based on an idea of two extremes.

At one extreme a small team that is stable and communicates continually can afford to have unique practices that it adjusts continually. The stabilty of the group make-up and the continuous communication allow for individuals’ to do things in a way that best suits their personal preferences, and for that to change often. (If a team isn’t stable and communicates continually I would wonder how much of a team it really is.)

At the other extreme, when there are people (or groups of people) that interact less frequently, and communication with them is less frequent, then much more reliance needs to be placed on processes that are easy to understand and change rarely.

The complications occur because people and information do move between teams often. Perhaps one team will review the code of another, or individuals will tend to move over to another team due to shifts in demand. In these cases having common processes and ways of working inside teams becomes much more important.

But in the end, where the bulk of work is what we call “knowledge work”, it’s preferable if we can structure things as much around the people, not put the people around the structure.

Photo by Rich Renomeron

5 thoughts on “A structure for effective teams”

  1. I don’t use a predetermined structure, I leave that to the people to do themselves. If they have to communicate with whoever in the team or between teams, that’s up to them to organize and do. All I ask is to plan what has to be achieved by the end of the week, and what every individual is going to do to contribute to successfully achieve that. If at the end of a week anyone has an excuse why things didn’t go as they should have, because bla, bla, bla, I use my Bullshit Stamp (underside of right-hand fist on flat left hand), see also http://www.malotaux.eu/excusesexcuses , and http://www.malotaux.eu/delay
    This way, within just a few weeks they make sure that they communicate as needed to be successful. They’re clever enough to figure out themselves how to do that.
    Once they get the hang of doing it weekly, we add using a TimeLine of several, usually 8 to 10 weeks, with what we aim to achieve during that period.
    Nobody likes bullshit. It works wonders.

  2. Yes, that’s the kind of thing I was trying to get across for an individual team – if they can work in the way that’s right for them, that’s ideal. But there are clear (and ideally simple) expectations about how they interact with others – in your case, with you.

    I wouldn’t want to be on the end of your Bullshit Stamp, though.

  3. I gave a talk a few years back Nik about automation. But, funnily enough, it was really about people structure and culture. One of the things I referenced in it was a great TED talk I’d watched by a chap named Yves Moreaux (easy enough to find on the YouTubes – “As work gets more complex, 6 rules to simplify”) His first point was one of my “anchors”, that being “understand what your colleagues actually do”. I think having tech underpin that can really help with communication, because if the tech means the communication happens automatically, then a culture of open communication can follow. In Rory Sutherland’s excellent book “Alchemy” he says “Conventional wisdom about human decision-making has always held that our attitudes drive our behaviour, but evidence strongly suggests that the process mostly works in reverse: the behaviours we adopt shape our attitudes”.

  4. “Understand what your colleagues actually do” is good rule. Without that, process (and tech) for working with them can really miss the mark.

Comments are closed.