Building Effective teams

Team building is a lot more difficult than most make it out to be. It is not something that one can easily learn in a book, or in a team building exercise for that matter. It is something that requires collaboration, understanding, time, and patience for it to occur. It tends to come together in the more stressful times, and much like a family involves conflict, misunderstanding, shared successes and failures, and a common thread that pulls everyone together. It is also something that must live and breathe like an organism, for while there might be a nominated leader it takes constant feedback, leadership and effort from everyone to succeed.

I have been part of attempts to build many teams throughout my career. In fact, I really enjoy building them, bringing out the best in people, and building a greater organism that brings with it friendships and learning. Some teams have come together and through thick and thin achieved amazing feats, while others behaved worse than a random list of names on a piece of paper. Some acted like elite special forces units, some like an eccentric family, while others like two year olds on the first day of nursery school or worse strangers on the Tube. While building a team isn't necessarily something that can be done in a prescriptive way, it in time be a lot like cooking. In fact, like Iron Chef, it is almost like being given various, sometimes almost random, ingredients to combine in various ways to attempt to create a delicious feast.

The best teams were rarely made up of the best from a talent and skills perspective, but rather those who were willing to put in the heart and effort, against the odds, to help the group. They came together naturally rather than being artificially put together based on some formula. There were always missing skills, things to learn, and stuff that looked set for failure that sometimes did. Roles sometimes seemed fuzzy, and would sometimes change frequently to keep the team balanced and on track, as well as sometimes providing the added benefit of ensuring that experiences (and pain) were shared. Nicknames often were given to people, places, things and ideas (I have had many bestowed onto me). Bread was broken, drinks shared, ideas constantly flowed, and it was quite normal for work and personal life to intermingle at times. I have had many key strategies and architectures drawn on a series of napkins and the back of random junk mail at people's homes and at random family style restaurants. Disagreements would abound. In fact, impassioned arguments always seem to be one of the biggest signs of success. Working through the heat of passion of people who really cared and who were allowed to confront each other in the desire to find the best way through. Ideas, discussion, and feedback must be constant, like blood flowing through the body. If feedback doesn't flow, or worse puddles in a silo, the team dies.

Teams have been of a wide variety of sizes. I have had organizations of many hundreds, and sometimes consisted of several teams, but I would not call any of the organizations themselves a "team". Organizations can pull together through alignment to a common vision, series of working groups and aligned teams, and occasionally "nested teams" where there might be some folks who have a natural knack for being able to be members of or straddle more than one team that has related goals and can cross pollinate both to create something that is far more than the sum of the parts. From experience the team itself is usually between 6 and 12 people, preferably 8 (+/-2), which seems to follow a lot of the common anthropological data on effective human groups out there. A team with any more than 12 never seems to gel, as it allows for people to overly specialize, or hide/be overshadowed by others.

Above all, the most important item is having a common purpose or goal that everyone shares and believes in. The shared thread, whether it be a project, a product, or a transformational mission, must be shared and believed in by everyone. That doesn't mean that people can't have different interpretations and opinions, even strong and contradicting ones. They also do not necessarily have to agree on the particular path. However, the belief in the high level end goal needs to be the same, and must be nearly a mantra. If it is not, like the two year olds the team will never gel.

Service Engineering and Service Management: The Forgotten Elements of the Virtuous Circle of Success

The understanding of the importance of the customer's role in ensuring fit for purpose products has improved significantly over the past several years, as has to some extent the interaction between developers and the customer community. However, in the many years that I have been building highly scalable services, one of the biggest challenges I have faced is developing an appreciation and understanding of the roles that Service Engineering and Service Management play in developing and ensuring an effective service. Ensuring that these two groups are ever present in the conversation, either as separate entities, or as roles within more traditional Engineering and Operations organisations, has rarely come easily. This oversight is one of the more costly sins that limits the effectiveness of organisations to truly exploit and achieve what is possible with cloud services.

To help appreciate the functions these two roles play in the ongoing collaborative discussion that develops and improves services, let me describe what each in my experience has looked like when implemented effectively.

Service Engineering

Service Engineering is perhaps the most difficult to describe, as the functions of the role span a variety of traditional roles, including Release Engineering, as well as IT Operations. Working in conjunction with the development community, this group develops the frameworks that transform bare metal and bits of byte code to reproducible on demand services that can flex within the constraints of the business. They are, in essence, the providers of the foundation of the service. They ensure that there is effective physical inventory, and that configuration information is authoritatively captured in a way that allows for reproduction as well as traversal for better understanding of dependencies. They design key elements of the datacenter, including networks, storage, and compute, and look for standardization and modularization where possible. They manage automated OS, hypervisor and application installation and configuration. They ensure effective application packaging, and consistent and repeatable builds and installations of the entire stack. They usually understand breadth and depth of the stack, and try and provide as much of an ant farm approach to providing visualization. They have a very keen eye towards service performance and tuning, and can often be found better understanding kernels and database design. They are sometimes called "Systems Engineers", "Reliability Engineers", "Release Engineers", "Operations Engineers", and "Infrastructure Engineers".

Service Management

Service Management provides the management wrap around a service. They develop and tune monitoring systems, service desks, dashboards, and other items that provide a better understanding of the performance, health, and help capture and understand patterns that may be of use for the rest of the organisation, as well as the customer. They help developers and service engineers develop hooks and harnesses that they can interrogate to better understand, collect, merge, interpret and roll up key aspects of the service. They need to understand dependency trees, understand what is most meaningful to customers, engineering, and the business, and effectively represent it as this information is critical to effective service exploitation, risk management, and contractual reporting. They understand and tune IT Operations support processes and change management, and must work especially closely with Service Engineering to capture and help coordinate any automated changes.

Engagement in the Lifecycle

Both of these groups provide the key elements for which a service is provided and managed. However, they mostly produce what most would consider non-functionals, which are the items that are not very whiz-bang for the business, and are simply assumed to be there by the customer. They are usually poorly understood, rarely invested in, and ignored like plumbing until it breaks. They are typically blindly squeezed as a cost line, and are sometimes viewed as a form of janitorial function that can do magic voodoo with computers. Business people often fear putting them in front of customers, afraid that they will scare them with their quirkiness, or that they might reveal something about the infrastructure that might terrify them. Good engineers understand their importance, but often do not have enough cycles to work with them while they work on more feature development. QA often misses that effective Service Management captures much of the same sorts of data, albeit usually unfortunately only in a production sense, that they need to assure the level of product quality that is expected. These Service teams themselves often under appreciate their own role if not shown the light.

By bringing these teams to the table, there is a much more effective grasp of the entire service lifecycle. Service Engineering can help understand the demands for flex and agility and provide both the understanding, as well as grounds and execution needed to provide it. Service Management can help with understanding the services themselves, whether to better understand user experience, user exploitation, code and service quality, as well as performance and capacity, and present these back to each of the key audiences in ways that are most meaningful to them. Working together with the rest of the players within the lifecycle, they can rapidly and continuously improve. They can reduce waste, and delight customers through collaboration and preemptive service management.