I read an article by Seth Godin the other day. In it he said that the average worker is going straight to the bottom. The workplace has changed so much over recent time, that workers should not be content with taking orders and everyone should make themselves unique and different so people seek out their specific set of skills. If he is correct then this will be a challenge to every company that says ‘our people are our greatest asset’. I don’t think it is as black and white as the article suggests, but I do think that business environment has changed in terms of expectations and speed, and the average worker needs to figure out how they contribute more effectively. However, I also believe that some of that responsibility lies with the enterprise, and their need to change their environment to help employees.
In my previous post I wrote about the fact that talent isn’t as innate as we think, and that the only way to ‘world-class’ and becoming an expert is based on practice. Purposeful practice. And, lots of it (approximately 10 years of hard, deliberate practice). In reading around the topic it became clear that many of the stories describing the path to success seemed to be centre around a couple of things. A person who was to become the future star with a desire and motivation to succeed that was often developed as a result of an early influence in their life. And an environment that was constructed by circumstances often including the input of a third party who played a key role to the main protagonist. Matthew Syed put it well when he said, ‘Child prodigies do not have unusual genes; they have unusual upbringings’.
The environments within these stories turned out to be unique and extreme in some way that helps the future star become the person they become. An environment so powerful that the future star develops a dedication, the skills, the support and the opportunities to rise to the very top of their chosen pursuit.
There are lessons in these stories to help us shape our own environments to develop the talent of our people. We may not be starting with susceptible kids who at the age of 3 decide that they want to be the future star of formula one or the next mozart, but there are people who, with the right conditions, can strive to be the best. We always have an opportunity to improve and excel regardless of when and where we start. As leaders it is important to recognise the environment that we really find ourselves in. Max De Pree in his book Leadership Jazz said ‘People must be able to pursue their potential’. It all comes down to environment and opportunity.
Albert Einstein said, ‘I never teach my pupils. I only attempt to provide the conditions in which they can learn’.
What I find most interesting about the stories of talent and determination I’ve examined is that one or more of the elements of any of the backgrounds has been completely uncompromising. The fathers of sporting prodigies such as Venus and Serena Williams, or Tiger Woods, or Lewis Hamilton created circumstance of every situation for helping their children develop mentally and physically. These environments were based around extreme and exacting standards. There was little compromise. They helped focus on their weaknesses to develop, but also helped them shape an utter belief that they were meant to be part of the elite. They relied on the idea that practice makes perfect, and nothing but perfection was acceptable. Does this sound like your workplace?
We are what we repeatedly do. Excellence, therefore, is not an act but a habit. ~ Aristotle
Standards such as these are often encountered in the business world too. Two examples spring to mind: IBM and Apple.
For IBM they needed to transform themselves from the mainframe supplier of hardware to a services based company that used the expertise to shape solutions. They created an environment based on values and principles that were upheld from Lou Gerstner’s vision. The change required a move away from the aggressive sales approach of product and a move towards a more service-based culture developing and delivering solutions, and relationships. Dee Hock’s quote describes the problem for most of us in the enterprise space well:
The problem is never how to get new, innovative thoughts into your mind, but how to get old ones out. ~ Dee Hock
Underneath all the sophisticated processes, Lou Gerstner concluded, there is always the company’s sense of values and identity. This is where he decided to focus. In his book, Who Says Elephants Can’t Dance?, he said, “It took me to age fifty-five to figure that out. I always viewed culture as one of those things you talked about, like marketing and advertising. It was one of the tools that a manager had at his or her disposal when you think about an enterprise.” He added, “The thing I have learned at IBM is that culture is everything”.
They spent years resetting the standards and upholding the expectations required. I think this is a key enabler for performance. It is rare to see it upheld. It is more likely to be talked about and dismissed like Gerstner refers to.
The other example (and there are many more) is Apple. Since his death, Steve Jobs has had many things written about him. Not least has been about his approach to leadership and management. He had a pursuit for perfection. It is written that his ego drove him in a way that ensured that everything about the product created by Apple was exact. He worked tirelessly to be the best and he held the whole of the company to his very high standards. Nothing was ever good enough and he constantly challenged to improve. It will be interesting to see if the environment continues.
Enabling Fast Feedback - To stretch, fail and learn
The complexities and dynamics of how a single person’s performance can be linked with the entire performance of an enterprise is too great. There needs to be another way of getting more direct feedback on performance, and what can be done to improve.
As business leaders or managers, providing fast feedback is critical for the growth of team members. This is what the environments of the elite did for them. Often we can go weeks, months or, in some extreme cases, years without giving real feedback on the work our people do and how they are performing it. We are often very critical of the results delivered by people, but not the practice that generated the result. This needs remedying, and we also need to create environments outside of the day-to-day job to develop skills.
Now, I’m not of the opinion that you only learn from failure. Learning from success is also useful, and good for the self-esteem. But, what I am a fan of is that you learn more from the situations where you have been stretched and tested. Max De Pree said ‘We need to learn to think in terms of discovery. Once a discovery is made, we need to make the right connections and to give relevance in our current environment’. This means we need to develop a learning culture.
Julia Cameron once said that ‘Making a piece of art requires a myriad tiny steps’. Many little lessons need to put together to develop a masterpiece or an outstanding performance. This is all the work that is done behind the scene that often goes unnoticed. People need an environment where they can make mistakes, gain feedback and improve. This needs to happen regularly. In sport, this is the training ground.
In business, we don’t have training grounds. We are always on. We don’t get the time and luxury of professional athletes. We are less tolerant of failure in business like sports fans are in the big games. Even Michael Jordan regales stories of missing some really important points in crucial games on his way to becoming one of the greatest. Maybe this is something we need to improve upon.
Developing the business training grounds is necessary. We need to develop communities of practice that enable us to learn and improve in a safe but challenging environment. Maybe in teams and projects outside of the normal spotlight. The problem is that many enterprises have developed a fixed mindset culture. One where a commitment made (however realistic or not) is one that must be met at all cost or at least expectations managed appropriately. And there is no room to learn or improve when you are on one of these projects. The fear of failure permeates everything and most people do things within their own comfort zone so that they are not to blame or culpable within a project that is destined to hit the rocks. This means that the project will never get the best and most courageous ideas or the most effort invested in it. In a sense, they are set up to fail because of mindset.
Making the Time
If the numbers are to be believed and it takes 10,000 hours to develop a world-class expertise in sports, arts, business or any other discipline, what does it mean in terms of supporting the development of our people? Remember the Dee Hock quote? The skills that have already been developed in our existing workforce may no longer all be relevant. Some will be, but the business environment has changed. The business environment will continue to change. Traditional companies are already struggling. Kodak anyone?
We know teachers are already teaching students skills that will help them deal with jobs and technology that don’t exist yet. We need to be doing the same in business. This means unlearning some stuff that we’ve always known to be right (or at least we thought we did!). We need to prepare people for uncertainty. We need to encourage and support people to experiment and improve for the good of our companies. We need to create a culture of critical thinkers. This requires a change in our environment.
People will need time and space to improve. It might not require 10,000 hours for everyone in an organisation, but it will take committed time nonetheless. It means that we need the right influences in our organisation that represents a set of exacting standards that helps us develop. But it also requires a strategy for developing a new set of skills, and releasing the latent potential within the organisation.
The world of business is moving super fast, and the practice that is required to remain world class is increasing. We might not think the kids coming out of college are quite ready to run our businesses, but they are more savvy with technology than most of our workforces. They might not understand the politics of our organisations or the nuances of managing a message, but they certainly know how to connect with people around the world and are more ‘agile’ than most middle-aged business folks. They know how to communicate in 140 characters or less. Their environment is one of ubiquitous technology, speed and communication. This is what Godin was referring to, I believe. They are already many hours ahead of us on their way to 10,000.
Our environments need to cultivate learning and skills acquisition that help all levels of an organisation improve. Not just the graduates, or apprentices. Not just the people in the talent pools. Nor just the workers. This includes leaders and followers alike. It includes the young and the old. We are all products of our environments. So, our results depend on our ability to create the best environments for today.
An obvious statement. One that I sometimes find easy to forget though. I have been talking about writing for some time. I’ve always wanted to write well. I am an avid reader. I’ve read many fantastic books: Fiction, non-fiction, biographies, comedies, tragedies. The list goes on and on. I must have read thousands of books. Because I read such exceptional work and see the amazing end product, I feel I should be able to produce something as compelling. The truth is that I don’t write well enough and it doesn’t come easily to me. In reality with my current situation I am never going to produce a written masterpiece. My talent is not great enough.
However, one of the books I’ve been reading recently is Bounce by Matthew Syed. This is a well written book covering the idea that talent is a myth and the people we believe to be born with god-given gifts are really the product of their environment and the amount of hard work and dedication they have invested in their chosen discipline. We see the tip of the iceberg. Matthew’s premise comes from many studies, but also from his own, personal story. He became the British number-one table tennis player at the age of 24 and has reflected on what shaped him to be the best in the country. I’ve come across many stories like this before. Gladwell’s Outliers covers a number of situations where notable individuals in recent history were shaped by a unique set of circumstances and an opportunity which others didn’t capitalise on. Some of these came from the largest names within the computer industry who grew up in the Silicon Valley area at the time when the first opportunities to mess around with technology appeared. The opportunity and temerity to play helped shape their futures.
From the field of sport, Jonny Wilkinson and David Beckham are two notable sportsmen that I’ve read about that have stories (Jonny’s story) that border on the obsessive. They had a desire to perfect a particular skill which helped them to become part of the elite within their chosen fields. It wasn’t just the desire though. The conditions were right.
I have a similar story (not exactly mine, but one I was part of) that parallels much of the thesis in the book. When I was 7 my parents moved across my hometown, Stevenage. It wasn’t too far, but far enough away for me to have to find a new group of friends. I lived on a green at the front of my house. A patch of grass that was about 20 square meters with about 10 trees and various stumps that made excellent football goals. Around the green were 8 houses. In those 8 houses there were 6 boys of similar ages. Martin, Ashley, Jason, Ross, me and Andrew. I was the oldest and Ashley was the youngest. He was born the year I moved into the house. He was also the younger brother of Martin. Around the area (not directly around the green, but within 100 yards) were around another 10 lads who were mostly older than me. The one things that we all liked playing was football. As I grew up I played a lot of football with different groups. Sometimes with the older guys, but often with the lads around the green. We played all the time. When Ashley just started walking he joined us ‘out the front’ (as we called it) and he loved it. He loved trying to emulate his older brother (and his Dad, Luther, who was also pretty nifty with a football at his feet). Ashley was always first out and last in. He ran tirelessly and he always worked hard and had a great temperament. He couldn’t compare to most of us when we were 12 years old – he was still only 5, so we’ll let him off – but you could see he was shaping out to be very good. Because we played constantly and we actually played at a high standard (Martin and I both played at a pretty high standard as teenagers – actually, Martin still plays at a high standard) the younger boys became really good for their ages and they all went on to play together for many years. It was a great training ground. In fact, out of the 6 people around the green, 4 ended up playing professionally. Two of them found very good professions in the English Premiership. Jason played for Norwich City for a while. Ashley now plays for Manchester United and is a regular in the England first eleven. The environment helped shape two-thirds of that small population to get paid in a game that they loved. The 10,000 hours invested (I prefer Seth’s view on this, but in the case of well-established vocations 10,000 hours seems about right) never really felt like work. This story feels more than a coincidence.
Hard work, practice, an environment of challenge and a support network that encouraged and nurtured has helped shape an elite sportsman. When you read the life stories of many of the most successful people in the world they have similar characteristics in their narrative. Often, very unusual upbringings.
The formative years for people really do shape them, but I believe hard work, environment and opportunity could play as big a part in later life as they do at the beginning. We are just more attuned to helping youngsters because we believe they require nurturing and a supporting environment. The challenge is: what comes first? The opportunity or the hard work?
In various roles I’ve had I’ve been asked by my team members to promote them into positions of leadership. For me, it feels odd when someone comes up to me and asks for me to tell her team-mates that she is now in charge and they should listen to her. People who know me, and have worked with me, know that I am not someone who would generally take the requester up on their offer. I have done, but it has been under specific conditions. My view is that leaders lead. They don’t need me to tell others that they’re the leader. Project managers manage projects. It should be obvious, and everyone will know. A head-of-sales will sell and run sales. It is who they are. I wouldn’t need to explain. If someone needs to ask for help in setting other people’s expectations (and they’re not new to the position) then I tend to think that my interfering in a process that should be one of self-organisation is wrong. People tend to do the job they are most capable of.
But, I have helped people take up the position they desired. It has only ever been on the back of a serious amount of dedication and application of practice to be able to do the role. That is, the person has shown and demonstrated the hard work required before any opportunity arose. The aptitude and attitude are inextricably linked. Without the attitude the aptitude will never be gained if, like me, you believe in Matthew Syed’s thesis.
If you desire to lead a team then you need to do it. You need to practice it. You need to find and create opportunities to develop your skills. Most people tend to do what they can do. If you aspire to greater things then you need to do things you can’t do. This is what rounds us out and develops our skills. The difference between who you are and who you want to be is what you do.
We see less practicing in adulthood because everyone expects us to already be the finished article, and it is scary to show weakness to our peers. We tend to develop the skills to hide what we’re not very good at. We must resist this temptation and encourage ourselves and people around us to continue to practice and develop even if this means lesser performance whilst learning. Without this, we will stick in our comfort zones and continue to develop the defence mechanisms that maintains the status quo.
As for me, these stories give me hope with my writing. It means that my lack of innate talent shouldn’t hold me back. It is all reliant on my ability to practice which is more down to my priorities, my motivation and my work ethic. So, as it says at the bottom of this wordpress page (when editing) I should just write.
Last night was a terrible one for Manchester United. They were comprehensively beaten by Newcastle United; A team six places behind them in the premiership. In some of the post-match reports the spine of the Newcastle team were heralded. This is a phrase that you often come across in football (soccer) and many other team based sports. The spine of a football team is: the goalkeeper, one of more central defenders, one or more central midfielders and at least one of the forwards. The spine of the team is the core that allows the rest to perform around them. A spine that is in unison, strong and powerful is key to success of any top-flight sports team. The spine discussed in these reports is a team within a team (eleven people on the pitch) within a team (the squad of players and the management, coaching staff and other supporting members). There are often many spines within different organisation structures, but there can be only one performing on a football pitch at the moment of play.
The telegraph described “There was a pace and purpose to Newcastle’s football, a quickness to their tempo as they poured forward, black-and-white-striped streaks”. The report goes on to describe how the different elements of the spine of the team were critical in making this situation real. Each player brought something to the spine on the night. They clicked. They were in harmony. It wasn’t really expected though.
It is amazing to think that on a different night, in different conditions the same spine may have been completely ineffective. Or, with one change of personnel in the spine, they may have been overrun by six goals the other way. That is the reality of teams in different situations. Individuals can make a difference, both positive and negative. Normally the Manchester United spine is the one lauded at the end of a match. Not their opposition’s. Manchester United, on the night, lacked a spine.
Shared purpose, interdependent roles and shared responsibilities supported by organisational structure and a goal that measures the team not the individual are important. But they also need to have time together to be effective. They need to learn instinctively who will do what and what skills are required to deal with different situations. They need to examine the conditions they are going to be playing in and who the opposition is going to put in their way. Tuckman’s model of Forming, Storming, Norming and Performing explains the phases over time that are required. This happens both outside of the playing pitch and then also on any single time that team get together to take on their opposition.
In business there are many teams each requiring strong spines. The elements of a spine is normally made up of individual members who come together to bring different elements of a business into cohesion. These are the people we trust, make things happen, generally good communicators who know their roles and responsibilities, and the skills of the wider team, what is important and how to get things done with the people around them. The similarities to the team within a team within a team notion is clear. When developing new IT systems or products the players on the pitch are the team delivering the work. They are (or should be) supported by other well-functioning teams (finance, PMO, HR, Project/Programme Management) with interconnecting member who help them prepare for, plan and execute to meet the goals set by the wider organisation and by them themselves. If any of these teams don’t have strong interconnected spines then trouble for the team on the pitch looms. The team playing the game is not enough.
The most common architecture
5 years ago I inherited a big ball of mud. It was an exemplar of ‘this most frequently deployed of software architectures’ described in the paper written in 1999 by Brian Foote and Joseph Yoder. It was then 2006 and the system was part of the new strategic architecture. A shiny new system that represented our future. Yet, it was still a big ball of mud. When will we learn?
The project was interesting. It was part of a crucial business transformation. It was to deliver a key architectural component that integrated into a more complex system of over 70 individual components – some new, most existing – and it impacted thousands of people and processes. It was based on an off-the-shelf product that we had never managed to successfully deliver before. It had been outsourced as a fixed-price piece of work to the company that built the software, and we had 3 people ‘managing the supplier’ back in to our business. It was the biggest instance of this piece of software in the world and I was their biggest customer. We had insisted that another 3rd party service provider be part of a design and integration team to de-risk the situation. And, to make matters worse, a bigger supplier of off-the-shelf software then bought the supplier of our product for strategic reasons. The project was interesting. The project was not simple.
A happy coincidence?
Because of this context and the need to join a few things together, I decided to focus my current studying needs of my MBA dissertation on ‘Relationship Management and Collaboration in delivering large business programmes using Agile Methods’. I thought it was worth killing the proverbial two birds with one stone and these both seemed like big birds. At the time of starting out on the project, I had been reading Implementing Lean Software Development book by Mary Poppendieck which set the tone for my approach to the delivery. In addition, I also read widely on the topic of relationships, partnerships, contracting, alliances and a whole gamut of other agile texts to explore how they might interrelate. For the purpose of this post, I am going to focus on the need for managing relationships and not step into the world of contracts (maybe another time). My position at the time of inheriting the project was to damn the contractual position. If I (and my business) was to be successful then we all had to be successful together and no contract was going to help us or get in the way of doing the right thing.
Understanding the landscape
When I started working on the project my first job was to go and live with the supplier on their premises and get to know them. Ask them questions. Understand what their philosophy was in their approach. Know thy enemy (well… not enemy per se, but it was clear a fight was coming).
My guiding light when starting out was to use the ‘Working software as the primary measure of progress’ as a way to judge the current position of the project. Every person I talked with I asked ‘…and how does the work you do help create working software?’ and ‘…how do you know you’ve done a good and effective job today?’ I was a right pain in their behind. But, the problem was not one person told me about the working software. For me, my approach was simple and very engineering focused. I believe that quality and speed are inextricably linked. So, if there was any dubious approaches to quality, then my belief was that they’d never be able to go fast enough for my business. They told me about their designs, their reporting, the project plan, the paper-based architecture and other very important elements that they thought an IT director should hear about. Frankly, I was horrified. Even more so when I found out that the 3rd version of the project was released into a production environment over 6 months late, missing most of the important functionality and had generated in the region of 400 major defects. In addition, there was NO WAY to deliver that same version of the software again because they didn’t actually know the configuration of the software and the metadata that went with it. Boy, was I in trouble? They were already underway developing version 4 and version 5 in parallel <sigh>.
But, this gets worse… It wasn’t just the people delivering for my project that I needed to worry about. This solution was based on an ‘off-the-shelf’ product that ‘just needed configuring’ (huh hum), so I really needed to look in to that too. Oh, and we also had that extra dimension of a 3rd party doing the integration work that I needed to just cast an eye over.
In the paper Big Ball of Mud, Conway’s Law is mentioned a couple of times. It is also discussed in other lean and agile texts when discussing strategies around scaling delivery practices. It says: …organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
If this law is true (and I believe there is a lot of evidence to support it from my experiences) this has big implications for how you manage relationships, communication structures and how you might choose products to build your systems around. The number of points for communication between a supplier and your organisation can be vast. In this case, my project had over 200 people involved, plus the product engineering department of the supplier and all the management roles involved in the relationship. In addition, there were all of the integrating systems within the rest of the programme to consider. The communication structures were complex and inconsistent. The goals, scope and delivery approach were not well understood. The people working for the suppliers didn’t really understand what needed to be delivered, and the direction set by the supplier was not one destined for success.
Working on the relationships
After assessing the project for the first few days and spending time with the team it was clear they were under a huge amount of pressure from their management and from the management within the programme. My first step was to build relationships with the people who were desperate for a change. These were often the ones who could see what was being done was way below the standard needed or people who were constantly in the firing line of the flame-thrower. Basically, these were the folks who were not resistant to change.
I chose to close down the communication channels from within my own company who were creating the pressure and noise. I chose to take the heat away from the team; I needed to build trust and I could do that by removing pressure and creating a more collaborative environment.
Because of a need to do primary research and analytical study for my MBA I explored a few models that might help me empirically manage to a better situation. I found a model created by the Department of Trade and Industry from 1997 that described 5 dimensions to consider that I decided to use to better understand the situation:
- Compatibility – the degree to which each parties’ business interest coincide
- Trust – the degree to which the parties open up to each other and discuss sensitive issues such as pricing and quality problems
- Closeness – how much the parties know about each other’s businesses
- Depth of Relationship – the depth and breadth of contact between different levels of the hierarchy and departments
- Reliance – how dependant are both parties on business output
When setting out, the only measure that scored highly was reliance. This was empirical information from over 200 people. Our destinies were entwined at this stage so we’d better improve the other 4 scores!
It is really easy to tell someone what you are going to do before beginning a project. It is much harder to deliver what you said regardless of your intentions. Parasuraman, Berry and Zeithaml proposed a model in 1985 called the Service Gaps Model. This described simplistically the different areas where gaps can appear between managers, the people who do the work, and the service received by a customer, and what factors might be involved in generating these gaps. Ultimately, any programme delivery is done by the people who do the work and they are the people that you need to build trust with and get to know. You do need to understand what their challenges are and work out how they need to be helped for them to be successful. Sometimes their challenges come from within their own organisation. As a manager of such a programme this was part of my job. I needed to understand who, what and why blockers were coming. There were lots of different reasons. One thing that became clear was that there was an authenticity gap. Most people can spot such gaps when words and behaviours don’t match. The words of the management team didn’t always match the work of the team. Sometimes it did, but there was, obviously, some conflict going on. The excellent Cluetrain Manifesto talks about this in regards to the authenticity gaps of a business. Business is a conversation. It is many conversations. It is a conversation that happens at all levels. The people doing the work are quite happy to tell you about things that are not working. They are happy to share with you the troubles that they suffer from. If they are not happy to do so, then there may even be deeper problems in the culture of your supplier. Silence speaks volumes. There are rarely no problems. You have to be open to listening to them and resolving them together. But, you need to believe that the problems and solutions you are discussing together are for the good of your objectives as well as theirs. If the answer sounds like one that you’ve heard before, it will probably lead you to a similar result you’ve experienced in the past.
The folks doing the work are the people who really define the service and outcome you will receive. An old boss of mine always said ‘Know your people’. I believe this. As with all relationships it is working through the problems and creating shared experiences that improves the bonds.
I needed to reset expectations with all parties. I needed to set the standards that I needed based on the poor engineering that had been delivered to-date. I needed to Demand Technical Excellence. I also need to create an environment where all the parties felt that they could participate effectively (this did have some contractual implications and is for another time). I also needed to insert people into the overall team who knew what it would take to meet the quality standards that I was expecting. There was no point in relying on my suppliers or the people who had managed the project so far as they were the team who had taken us to the position we were in. I decided to hire some agile coaches and technical leadership to help the existing parties really understand. The funny thing about trying to change a situation like this is that people are very quick to think change has happened, and claim success, but my experience is that people want to tell you what you want to hear rather than to show you what has changed in reality. Holding the line on the new standards was difficult. It meant heated discussions and politics at different levels within the relationship. This was an 18-month battle and we made incremental steps of progress in terms of building trust, deepening relationships and delivering on our promises. We did manage to improve the quality of the software, and we did deliver our business objective. Every iteration and release was better than the previous one. We need time to retrospect and continuously improve. If the line wasn’t held though and quality demanded the project would have reverted to its old ways. I am absolutely convinced of that. My job was to take my suppliers on a journey that was fit for my business. The core competence of my suppliers was supposedly software delivery. My experience told me a different story and one that I see repeated in many clients. It wasn’t because the people were not good. They were, but they didn’t have the environment or support to succeed.
Why share this story?
At the moment, I have a number of friends and colleagues involved in a huge Big Ball of Mud fight. I feel for them. It is a massive project recovery that is taking its toll. It is a death-march, for sure. These things don’t come up because of one person’s decision-making capability. They occur because of ‘the system’. They occur because people believe that someone else will fix the problem. They occur because of the short-term need for higher margins. They occur because people still don’t know what great (or even good) looks like. They occur because wishful thinking is still predominant in lots of companies that I see. And they occur because active management of relationships and suppliers is not happening with people who can get under the covers of what is really going on. What does happen when your luck runs out?
As an aide memoir, here are a couple of things that I learned through this experience that I would urge managers to consider:
- You can outsource work; you cannot outsource your problem. It will end up hurting you more. Help your supplier through the problem.
- You must build relationships at all levels to gain the best and most complete perspective. Businesses are full of conversations. Don’t believe the brochure. Know the people doing the work.
- You should explore how well aligned your communication channels and cultures are. How do you know that your partner will be successful and support your needs?
- Be aware and actively manage all parties interfacing with your supplier and from your supplier into your business. Communication channels are important to look after. Loose lips sink ships. Remember Conway’s Law. If your communication channels are confused, your software will be too.
- You need to know what great looks like, set that standards and help all parties achieve that standard. If you’ve never seen great, find someone who has. Find examples of great even if they exist in different industries. Don’t rely on the team that has been deployed to your project without validating that what they are doing for you is, indeed, world-class. Just because the supplier says they are doesn’t mean that team knows what awesome looks like or that their company can make great happen. Judge results on working solutions not on hyperbole. And keep the feedback cycles short. As google says at number three in their philosophy, ‘Fast is better than slow.’
- Get to know what objectives and systems your suppliers have in place. Is your success really (and I mean really) aligned to your success? Change control is still a key business mode for many System Integrators – the more Work-In-Progress that exists, the more expensive change will be to your business. That’s good for them, but terrible for your ability to deliver quickly.
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, this technology has created a little bit of contention in the marketplace because customers like to know the exact speed that they are likely 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.
A few weeks ago I was facilitating a session with a group of people responsible for delivering a software platform to support a number of very large institutions in complex markets. The session was centred around how you could create more collaboration, predictability, communication and feedback into their delivery cycle and how the different groups and roles might better interact with each other to deliver higher quality, valuable software and solutions to their customers. They have had problems meeting their commitments to-date and when they have delivered it hasn’t really met their customers’ requirements. A common problem that we’ve all heard about many times now.
Their normal approach is full of hand-offs, long lead times between specifying something and seeing it in reality to provide real feedback, and very document rich to support people’s ailing memories across these long lead times. During this session there was a real feeling of parochialism. The Development Manager was arguing the QA needed to step up to do such and such. The QA Manager was saying the Dev were always delivering sub-standard work. Everyone was pointing at the requirements still being worked on. And the designers and architects had such grand plans that weren’t achievable. It was the classic example of the silo organisation. The interesting thing is that all of their backs are against the wall because they have deliveries to hit. My point to them was: QA fails, you ALL fail. Dev fails, you ALL fail. Design fails, you ALL fail. There was silence in the room and then the penny dropped. They realised that they should be a team.
I read two blog posts yesterday that made me think about this situation. The first was the TradableQualityHypothesis by Martin Fowler. The second was Mike Gaultieri’s ‘Want Better Quality? Fire Your QA Team‘. Both posts were ultimately about the ownership, accountability and responsibility of quality. For some organisations they believe that quality is improved by spending more time on getting the requirements right. For others it is about getting the design right. For a lot it is about spending all the time on QA. Not many firms actually believe (in my experience) that the developers are really the ones who can help because it has become for large enterprises a commodity – which is completely wrong. However, for the teams and organisations who actually produce high quality work they understand it is about everyone systemically collaborating and working together to develop solutions. Everyone is responsible for quality. Interestingly, in Mike’s article, the extreme position of firing the ‘Quality’ team had the amazing effect of everyone else taking accountability and responsibility for the quality of the output. It would be interesting to understand what actually happened and if it supported the hypothesis of Tradable Quality too. My guess is that the Internal Quality was increased significantly as a result.
I’m not necessarily espousing that all teams need to fire their QA departments, but I am very much of the mind that all of the roles and responsibilities need to be blended into a one-team mentality whereby everyone succeeds or fails on each others’ quality and performance. The key thing for me is that Managers and Directors need to understand that they will damage their future business unless they really understand this. As I said in my last post, Demand Technical Excellence, or you will all have a case of high dynamic complexity and lots of finger waving when the IT platforms grind to a halt.
Over the past few weeks I have visited a number of our clients to discuss how their Agile Enablements are progressing. For me, it has been a hugely enjoyable experience to see and hear of the transformations taking place and the energy and value that has been created. However, often it is not the response from the teams that is most telling of progress, rather the reaction of senior managers. The reason that I say this is that senior managers get more than they bargained for by embarking on their agile journey. The normal promise for any improvement in delivering software is Faster, Better and Cheaper, and most people have learned to live with improvement along one dimension against a trade-off along the others. However, after only spending from as little as a few weeks to a couple of months with a coach learning the basics of running an agile team the key difference that people notice is the energy and drive of the people involved. This is when the reaction of the senior managers brings a smile to my face. They claim that their teams seem to be having fun. Fun at work!? How can this be?
Every person seemed to have a renewed interest in the value that they are delivering for their business partners and customers. This is a repeating pattern that we find when we coach teams. It has to be more than the Hawthorne Effect.
Is having fun an acceptable practice at work?
It got me thinking about the work Lynda Gratton has done on Hot Spots. Her book is about how groups of people can come together to deliver amazing results. It’s a book that explores “Why some companies buzz with energy and innovation – and others don’t”. She starts the book by saying that you know when you’re in a hot spot.
“You feel energized and vibrantly alive. Your brain is buzzing with ideas and the people around you share your joy and excitement.”
This is what the senior managers were describing to me and I wanted to find out how the lessons and practices described in the book compare to and support agile.
Throughout the book the following equation is referred to:
Hot Spots = (Cooperative Mindset x Boundary Spanning x Igniting Purpose) x Productive Capacity
Bringing together and fostering cooperation that spans across and beyond organisational boundaries to work on a problem that supports a brighter vision of the future seems like a reasonable recipe for success, and the book explores a lot of examples and practices that support this. However, it was the final element of the equation, Productive Capacity, that really piqued my interest in regards to the comparison with agile. 5 practices were identified that described how teams could increase their productivity and support more complex Hot Spots:-
1. Appreciating Talents
2. Making Commitments
3. Resolving Conflicts
4. Synchronizing Time
5. Establishing a Rhythm
When I read on to understand these practices in a bit more detail I realised that these directly complement agile practices and principles.
Running an agile team (correctly!) directly supports the Productive Capacity practices required to create a Hot Spot. Agile brings together people across organisational boundaries who have often not interacted in any meaningful way before. This is the first step to appreciating other people’s talents. The basic agile framework describes a number of key ceremonies that:
- get everyone making commitments publicly and not having commitments thrust upon the team through Release Planning and Iteration Planning (One volunteer is worth ten pressed men);
- synchronize everyone’s times to ensure participation in all the key planning and feedback sessions such as Show and Tells, Retrospectives, Planning games and Stand Ups;
- and establishes a cadence for releasing solutions.
The final link between agile and the practices behind Productive Capacity is in resolving conflicts – this can sometimes be the hardest part. Running a project in an iterative way that is ‘planning driven’ and takes constant feedback will highlight problems (or opportunities) – daily. It is the job of the team to address these problems and remove blockers. Conflicts will arise and must be tackled. These problems have always existed – agile highlights them. The best teams that I have seen embrace the feedback and work together to resolve conflicts to continually improve. When you can combine these practices with agile’s non-negotiable approach to quality you get really amazing results.
There are many examples of Hot Spots in her book – some of them are IT related, but most of them are not. The Agile Values – communication, feedback, simplicity, courage and respect – supports a company’s ability to bring together high performing teams that create Hot Spots of innovation and performance. If you could really have Faster, Better and Cheaper being delivered by people who are energised, motivated and committed to achieving your goals, wouldn’t you do it this way? I know a number of organisations who believe the answer to this question is now a resounding ‘Yes’.