Thinking about networks
My formative years in technology and delivery were spent in the telecoms industry. I have learned a lot about how networks work, how they are controlled, managed and planned, and the strategies involved to deliver certain qualities of service to customers. In fact, at one point in my career I was responsible for designing and delivering all of the systems that planned, designed and stored most of the network assets and services within BT. I spend most of my time now considering how enterprises deliver value through projects, programmes, products and services and I find there are many overlaps between the two worlds. I have been re-reading Don Reinertsen’s ‘The Principles of Product Development Flow‘ recently and it brought me back again how telecoms theory can influence the delivery of value in an enterprise.
A past experience
The last major programme I worked on in BT before leaving was designed to introduce a 24MB broadband service to large parts of the UK. There were many firsts in technology underpinning this programme in creating a ubiquitous IP core network and how that would be planned, managed and controlled, but the key element that would enable the faster (and I know other technologies are faster, but not as available) speed to customers was based on a technology called DSL Max which had previously been used in the rollout of 8MB broadband. This technology was designed to enable any copper line carrying broadband to an end customer’s house to be as quick as it can physically be.
DSL Max is an example of a ‘Rate-adaptive service’. Wikipedia describes it as ‘… intended to offer the best possible speed attainable, which may vary over time. The maximum speed permitted is determined both by current line conditions and the level of noise, and also by recent history based on factors including the rate of communications errors and the best and worst DSL modem sync speeds achieved during some recent period of time …Customers with long lines or poor quality lines or who experience high levels of noise or interference will be limited to much slower transfer rates, and some customers whose lines are very poor or who are affected by high levels of noise may be unable to obtain service at all.Interestingly, when launched, this technology created a little bit of contention in the marketplace because customers wanted to know the exact speed that they are going to get from their broadband provider, but this technology says (at least in the copper network) that you will receive the fastest possible speed. It reminds me of the need from enterprises to know exactly how each team compare to one another and how fast they will go in the next 6 months – it kind of misses the point!
The technology does not necessarily dictate the ultimate end-to-end service speed because of the different aspects of how the core network and internet operate, but it has a major influence as to what the end-to-end speed can be. The interesting points, for me, from the excerpt above is the there are a number of factors that can influence speed – the end points or Interfaces (DSL Modems), Distance (from the Controlling elements), Noise and Interference – and it may vary over time. In some ways the things that impact network speed are similar to those that can impact speed-to-market for companies.
What does this mean for teams?
The team is an interesting construct because different people look at different parts of groups as teams. Agile folks generally consider a team to be a small (7 +/- 2) cross-functional unit of people delivering valuable features. But for something like the programme delivering 24MB across the UK, the ‘team’ spanned hundreds (and maybe) thousands of people. I was part of an IT leadership team tasked to deliver the overall programme that needed to operate as a team, and I also had around 300 people who were part of teams actually building features internal to my department and across other departments through integrated systems and technology. In this sort of environment it is very difficult to define what a team should look like or how small value units might operate within this context to a shared goal for the organisation. That is where project management has a role to play.
In Management 3.0, Jurgen Appelo covers structures and teams really well, and discusses the principles about the size of teams, the structure of teams and their interactions. I liked his approach to the topic, because I have always found the rhetoric from the Agile community a little disconcerting and not too achievable in the context of massive programmes of work. One of his points is the idea that the project managers role is to manage a project and not the people, which is counter to how most project managers and organisations behave. For us though, it really made sense and that was the approach we had taken within the programme – we created networks of teams that came together to deliver value for the customer and disbanded to work with other teams. That is to say, we allowed the teams doing the real work of developing solutions to be small enough so that they could self-organise around their own technologies, domains and features, but created some more ‘functional’ teams to act as nodes of understanding, communication and alignment between teams. Our goal was to align all the different teams up-and-down the programme in order to deliver incremental business scenarios. To start off with, we needed to give it a little nudge in the right direction as self-organisation wasn’t going to work across the different suppliers, organisational units and technologies.
My job as a manager was to help make all of my team units as effective and valuable as they could be across the wider programme. In short, my focus was to manage and deal with the Interfaces, Distance, Noise and Interference impacting my teams so I could enable them to go as fast as we could go.As a side note, this was for the good of the overall programme: the area I had inherited to ‘fix’ were already identified as the bottleneck for the overall delivery and a certain pressure came with that ‘gift’.
The definition of noise is: it can block, distort, change or interfere with the meaning of a message in human, animal and electronic communication.
I think anyone who has worked in any organisation can recognise noise. The world is full of things that can distract you from the task at hand. One of the roles of a manager is to limit unhelpful noise. There have been many times in organisations I have worked in that I have witnessed people creating noise for the sake of wanting to be heard. Throwing rocks from the sidelines. Passing judgement on the work of others. Often, this noise is like ‘anti-value’ for a team. Noise can come from many directions when delivering complicated, integrated technology solutions for complex businesses. It can come from the technology itself (especially if the technology chosen is new to a team – or just new). It can come from centralised groups who are not focused on the flow of value and are part of ‘economy of scale’ thinking. It can come from people who don’t really understand what a team is doing. It can come from project managers who feel that they need to control activities because ‘that’s their job’. It can come from people who are detailing the requirements if they don’t understand their own business. In short, as a manager, you need to have eyes in the back of your head, but more importantly you have to be available to reduce the noise affecting a team. Being there to breakdown organisational roadblocks and issues is an extremely valuable role when done well.
Interference is anything which alters, modifies, or disrupts a signal as it travels along a channel between a source and a receiver. The term typically refers to the addition of unwanted signals to a useful signal.
Similar to noise, Interference can come from many angles in an organisation. In telecoms their are a couple of common Interference types such as Cross Talk and Adjacent Channel Interference that can have a major impact on the performance of a circuit. The weather can sometimes make things worse too. I think there are a couple of common interference personas in organisations:
- The Bulldozer – a more senior person who wants to come in and set direction. Someone who generally bullies a team into doing what they want them to do without understand the full context.
- The Know-It-All – someone who solves the problems for the teams. This person can take away any accountability and responsibility for a team and leave them headless when they are not around. They can all set direction that often tries to solve the future and complicates the immediate task.
- The Seagull – we have all had senior managers and advisors who take a peek at a situation, swoops in, makes some snap decisions and swoops out again. They don’t take the time to understand what is really going on and help the team. Seagulls can sometimes be Know-it-alls.
- The Jobsworth – the homework checker who doesn’t like what they are seeing and have other goals to deliver that are not necessarily in support of the project being delivered. I do have some sympathy for this role as everyone has their job to be done… it would just be nice for people to be able to apply some judgement to a situation. These may well be the people who would want to compare one team against another.
- The Person-who-has-something-to-prove – people act from their own perspectives, and people’s goals don’t always align to the goals of the team. This might be someone who wants to make a name for themselves, or someone who wants to exert their authority in a political situation. Whatever the reason, this is something to be aware of.
- The Spare-Wheel – someone who doesn’t really know what their role is in the team. They might have once been a manager of a team in an older organisational context that now doesn’t really know how to add value. Changing organisations can often create Spare Wheels, so beware.
I’m sure there are many other personas we could name. I would be happy to hear some of yours. The key thing for managers and leaders are to keep an eye out for interfering behaviours. Advice is all well and good, if it does genuinely support the goals and needs of a team, but this does need to be managed carefully.
In the context of the programme, the distance I am talking about is that between the teams day-to-day work with their heads down working alongside their own product/domain specialists and that of the end-to-end business and Integration points. In one respect distance issue is the same in both telecoms and enterprises – the further away you are (in space and time) the more the communication degrades. It is often easy to become fixated with ‘getting your bit done’ in a large programme like this, but it is only as an end-to-end team would we be successful. A lot of my job as a manager was about making connections between the different teams and stepping into situations where misalignment was occurring without any of the teams being aware that this was happening. In large, complex organisations you cannot hope to know the full complexity of the political landscape and the intimate detail of the working software. You must have bridges and connectors to get the right people talking at the right time.
In the metaphor of the copper line telephony service, the Interface is a Modem or other Network Node. These are the senders and receivers of information. In an agile team, this might be a Product Owner or another team that you need to interface your software with. It might be someone within the business who will use your system. It might be some other interaction. Whatever it is, interfaces have a real ability to impact overall velocity of a team. This is an area where the wider ‘team’ in a programme sense needs to spend time to discuss how interactions will take place and how alignment will happen to keep the overall system moving forward as quickly and effectively as it can. Often, interfaces span organisational boundaries, technical boundaries or priorities and managers need to be aware how these can impact the teams. Teams can start to self-organise once interfaces are understood and relationships are built. Often the role of a manger with the wider organisational context is to grease the wheels of an organisation and make the connections to start with. It can all flow from there.
Wrapping it all up
Ultimately, as a manager of an organisation, you want your teams to go as fast as they possible can go and that the organisation, as a result, goes as fast as it can go (we don’t want fast teams if the whole slows down!), and in order to do that, special attention needs to be given to the things that can hamper a team’s performance. Noise, Interference and Distance are not things that you can do too much about in a simple copper network (there are some things you can do to help, but, only so much), but they are all areas that can be managed and looked at in complex organisational environments. A lot of these elements are often overlooked by managers and in some cases it is the manager takes on the personas described. Forearmed is forewarned. The success of your programme may depend on it.