Integrated Core Team
/
How did we get here... everything is a team?
Seems like when more than one person gets together to work on something today they are called a “team.” We see “executive teams,” “development teams,” “process improvement teams,” “launch teams,” and so on... you get the picture. I think most of these teams are masquerading as reconfigured functional silos. People are on so many cross-functional “teams” now the concept has been lost.
Lets look at a simplified example of the problem. The blue dots are my software group, green is hardware, and orange is operations. They represent functional departments with hierarchical reporting; goals, and measurement systems that favor vertical communication over horizontal cooperation. At the bottom of the hierarchy are the workers. The size of their dots and numerical value indicate the number of teams each individual is on. The high performers are always onmost the teams since everyone wants them. The better you are; the more over-allocated you get and ultimately the more ineffective you become.
When there’s a project; a team is formed from these over utilized resources. They are called together at a kick-off meeting where the project’s lofty goals are communicated by an executive; everyone is told that this project is a “growth opportunity” ... and that yes... they are over-worked, but to remain competitive they must reach down deep inside and pull out one more success. Sometime during this conversation they are told that new hires have been frozen for at least the next 2 quarters and they will have to make due with the limited resources they have. The meeting always ends with a reaffirmation of everyone's commitment to success.
Once the “team” is assigned a project they reproduce the functional hierarchy within the so called team. It becomes in effect a small version of the larger departmental structure they came from. The only difference is that they are called a team and have yet another project on top of the 10 they already have on their plates.
Since we know that self-managed leaderless teams rarely work, someone from above inserts a Program Manager who is supposed to “manage” the project. Usually this poor sap is introduced to the team by the executive at the kick-off meeting. He or she is given no control of the schedule, or the budget, or the people working on the project; yet they are expected to deliver it on time and under budget.
The kick-off meeting ends with everyone chanting the mantra that we will hit the unrealistic target dates with a product that will “delight our customers.” The next week the Program Manager struggles to get people to respond to his planning workshop meeting invitation where he requests they “buy-in” or “sign-up” to the schedule he’s already created. Life goes on and most of the people immerse themselves in the ongoing projects that they were already working on before the kick-off meeting interrupted them.
Typical Core Teams
The Program Manager or “great coordinator” continues his effort every week to “herd the cats,” but he’s too low in the organization to have any power, so people ignore him, and too far above the real work in the functions to know what is going on. It is usually at this point that executives realize that development teams are not performing and bring in a consultant to implement a new “business process transformation change management initiative” and lots of people are sent to Project Management training classes. At the end of the day, nothing changes because the structural and capacity problems are never fixed.
It is actually made worse as more and more projects are piled into the already under capacity system. We’ve actually seen people assigned to more than 15 teams at the same time. They get multi-tasked to death and their effectiveness drops to zero. They tend to identify more with their functions which is where they get their financial rewards and career advancement. Customers and products usually take a back seat to the silo’ed incentive and reward system that emphasizes vertical communication over lateral integration and cooperation.
The Integrated Core Team
Many years ago we started studying fast teams in Silicon Valley. We wanted to know what they did differently and why they consistently delivered the right products at the right time. One major difference was in the way they organized themselves. They called it Integrated Core Teams.
Let me define “Core Team” in the FTTM context. Members were dedicated to 1-2 projects at one time, not 15. They were empowered to deliver a new product to the market and have control over budget, resources, and decision-making. Since they are focused, they view their Core Team the same way a start-up would look at its founding members; they own the outcomes. When people own the outcomes... and feel they can control them; they tend to work more effectively and much faster when they can see the results of their contribution.
We saw this teaming configuration used when time was a factor and a new product had to hit a defined window in order to maximize share, margin and revenue or when company survival depended on new product success. In the technology world, this describes most of the players that survive. Further, the structure I’ll share in the following slides is used when programs are complex and in many cases spread across multiple sites, time zones, and stakeholders.
Elements of Integrated Core Teams
The core team is small in number; members have roles, rather than functional or departmental titles. A Core Team is less than 6 and not 25 or more as we have seen in some companies. It is not a reproduction of the functional hierarchy, but rather a small business management team. It is the same team you would form to do a start-up. Start-ups rarely organize around functions at the beginning due to the inefficiency of the hierarchy, yet in large corporations when teams are organized they merely reproduce the known hierarchical structure in smaller subsets. Fast teams don’t do this.
Roles on the core team
Core teams report to Steering Arms comprised of three senior executives representing core functions of a product development project; marketing, engineering, and operations or manufacturing. Their role is strategic, they break ties that involve cross-functional issues; they make decisions that the core team get stuck on, and they provision the team with information and resources. Most importantly they interact with the core team on an exception basis. This means the core team is left alone unless they request help from the Steering Arm or they deviate from a specified metric such as budget or schedule.
So for example if a project slips past a 2-3 month buffer, teams must report their corrective actions to the Steering Arm. However, if they are within a defined schedule and/or budget parameter; then they are left alone to run their projects. Steering Arms can typically manage many simultaneous projects.
Program Sponsor stays outside of the daily operation of the team, but their role is to provide periodic leadership and give the team clout as it competes for resources and mindshare inside the larger organization. In the start-up world, this would be the VC Board member that is providing the primary funding and who establishes the targets for a successful outcome.
Program Director participates more in the daily activities of the project. This person is the keeper of the project vision and reminds the team when they get off track. Defining and maintaining clear vision on long and complex development projects is very hard. Someone needs to keep the “what” and “when” vision clearly in front of team members that tend to get distracted by interesting technical problems.
Steve Jobs was a good example of how an effective Program Director behaves; always reminding people of the project goals, the market time frame within which they would be competitive, and what customers want (of course from his perspective). He continued to perform this role up until his death on most of the products we see being introduced today. Setting and maintaining clear vision is no small task. Teams need this ongoing reminder and focus.
Program Manager (also called Systems Integrator) has the operational responsibility to manage the project. Think of the Program Director as the CEO and the Program Manager as the COO of the project. We also think of them as Systems Integrators; people that laterally link the pieces of the project into one integrated whole. This is a very different role than the un empowered coordinator, rather these people have market, customer, and technical expertise and are well respected by the technical team members.
Architect does the same thing as the Program Manager in terms of laterally linking, but in this case they focus on technical system design and integration. Similar to the Architect of a building; the systems architect in a technology development project defines and manages the interfaces within the system. In chip design they provide the “high level architecture” that describe the behavior of the complete system and how its parts should interface. The complexity in systems is usually in the interface points. The Architect owns these connections and sees the compete system from end-to-end. Most failing projects we see lack a System Architect who manages it end-to-end.
Engineering Leader is the person that gets it done. This person is the VP of Engineering on the project and who’s teams design, develop, and implement the new technology. All technical direction for the project should come from this leader.
Marketing Leader is the voice of the customer for the team. This person understands the customer’s business problems, as well as the market environment for the new product. This includes external competitive forces driving product requirements. The marketing leader owns these requirements and is responsible for reconciling the differences between what is wanted by the customers or the market segment... with what can be delivered within a given time frame.
Extended Core Team
This tends to look more like the functional departments within a corporation. People ware two hats on these Teams; one is the overall role they play; in other words architect, marketing leader, etc. and the other is to represent their function; such as “automation expert” or the “software guy” and so on.
The extended core team typically ranges between 10 and 20 people depending on the project scope. With a project that has five core team members and 25 extended core team members we might find 100-200 or more people individually contributing on the project during its development life cycle.
Milestone Teams
The fastest teams we’ve studied and with whom we’ve worked use a concept called Milestone Teams. These are cross-functional teams organized around integration points on the project. Most projects have 5-10 major points of integration where functional work streams come together to produce an integrated deliverable. For example; deliver engineering samples to a customer, deliver integrated system for field trials, combining hardware and software on a platform, a demonstration of mechanical and electrical behavior in a prototype, or an early prototype demonstrated in a customer’s system... these are some that come to mind. It is the output of multiple functions versus output from just one.
The configuration of these sub-teams are designed around the lateral flow of work, and not around the functional deliverables such as “Engineering Release,” or “Tape-out” or “MRD complete,” for example. These are functional departmental deliverables. Rather Milestone Teams form around integrated cross-functional output.
What is a “milestone” in FTTM terms? Its an integration point along the maturity curve of a product moving from a concept to reality. It’s usually cross-functional and something that a customer would care about, versus an internal company checkpoint. We also design schedules around these integration points rather than around the functions, but this is a topic in another screencast.
The Milestone Teams tend to look more functional in makeup with each of the cross-functional stakeholders represented. These are the functions that have to deliver the integrated milestone. The Milestone Team Leader is the person with general knowledge and the best technical grasp of the problem to be solved. So it is not uncommon for example to have a Software guy leading a team that includes Hardware, Reliability, Operations, and Marketing resources. This is the definition of a cross-functional team where the functions must cooperate and share the outcome versus tossing things over the silo walls.
The Milestone Teams report in to the Core Team. This is the only hierarchy on fast teams; two levels... Core Team and Milestone Teams.
This is an involved topic, but I wanted to briefly touch on the organizing method that differentiated fast teams from average performers. We continue to see different variations of this structure. We also design structures with clients around these principals, but each project is different and each organization has unique readiness and acceptance factors to this kind of structuring. Sometimes we design and implement hybrid structures, since we know that organizations adapt at different rates.
We have the most fun using this with autonomous teams that have clear time-to-market targets or in start-ups where missing a market window means certain death. People tend to pay attention to ways of going faster when the fear of running out of money is ever-present.
We’ve used variations of this teaming structure on projects as diverse as the first Sony Playstation at LSI Logic, with Tony Fadell on the Philips Velo which was the first windows-based CE device, to large-scale start-ups of semiconductor fabs in Malaysia and New York. Tony recently reported to me that later he used many of these organizing principals at Apple on iPod, iPhone, and iPad projects. They really work.
More Resources:
Download Systems Integration Manager (Example of a Job Description)
Download Core Team (a template)
A note on using this as a tool:
Adapt it to your project
Add or eliminate roles needed/no needed
Get the roles and responsibilities right, before adding people’s names
Once you have the roles right, then add in your team members by name
Normal size programs use a core team and the interact with the functional resources
Large programs use a core team and milestone teams