paulplatt

Today’s markets shift faster than ever yet companies structure themselves in ways that hinder their ability to respond to market shifts. Some of this has roots in what works for small companies. It gets magnified by a black and white reading of classic MBA materials.

When a company is just starting out, it is focused and targeted. Similarly, hiring is often targeted. As the company grows this view of “hiring the expert” continues. It gets magnified by the classic alignment of resources taught in business schools. While larger companies might hire a new college graduate, the new hire is placed in a product specific team where he is expect to become an expert in one area. This is the alignment of resources. The product area must control its engineering team lest the product line general manager lack the resources to meet his goals. I agree with this as far as it goes. Where I  disagree is with the black and white nature of this structure at most companies. Life is grey. What is needed is an engineering team structure which combines focus with flexibility. What we want to achieve is a very diverse set of objectives:

• Product area expertise
• Resource alignment with product line control
• Continuity of effort and knowledge
• Flexibility
• Diverse skill set
• Dynamic resourcing
• Dissemination of corporate knowledge
• Minimization of staffing & cultural disruptions

Classic engineering structures solve the first three items. The product line builds a team which becomes expert in the product line’s engineering area. The product line owns these resources. This provides  control so they can be assigned at the will of the product line manager (PLM). Additionally, assuming good employee retention, product line knowledge is retained. Successive products build on earlier engineering work. This is the classic engineering structure. It is simple and easy. In particular,  it is easy on the CEO. The CEO gets to defer resourcing of projects to the product line. This structure even solves some of the need for flexibility. The PLM is able to adjust his resources as he sees fit. This avoids excuses about the inability to control resources that would exist in a company with one, large central engineering organization and hence avoids a major headache for the CEO.

Now look at the last five items in the list. While there is flexibility in assigning the product line resources, a classic structure has little or no flexibility to move staff among the various engineering groups. This means a focused but narrow set of available engineering skills. Headcount only varies through hiring or firing of engineering staff. This leads to disruptions and a lack of continuity. During periods where the product line lacks ideas for new products (yes it happens), engineering staff is reduced. When times change, new people are brought in with the inevitable necessity to correct poor hiring decisions. This is disruptive and the engineering team is distracted from its primary job of creating new product. Finally, the product line becomes a silo. It gets isolated from other product lines. Mistakes in one product line get repeated in another. Little knowledge gets transferred between the different engineering groups. Corporate engineering conferences can help in this last area but it’s a fight. Knowledge transfer has to be forced rather than being a natural outcome of the engineering structure. This is one area where a central organization is superior.

In the past, some companies have tried to solve these issues by moving all engineering resources into one large, central organization. Doing this fixes many of the last issues but exacerbates the first four. In particular, the PLM’s feel they lack the ability to control their future. They are asked to perform and yet have no control over the engineering resources that are key to their success.

The correct solution is to remember that life is grey i.e. what is needed is a mix. Most resources should be aligned with the product lines. Each product line should have adequate staff to execute the product line’s normal engineering work load. In addition, there needs to be a central engineering team. This is best viewed as a “hit team” for the CEO. Resources are assigned to various product lines based on where the CEO wants to place overall corporate emphasis. Properly executed, this augmentation of the product line resources solves several issues. Resource flexibility is enhanced. Since the central team works in many areas, it develops a diverse skill set. Resourcing is dynamic with both product line and overall corporate flexibility. Knowledge gets disseminated as a natural result of the central team working with various product line engineering groups. Finally, staffing and cultural disruptions are minimized. When one area is entering a slack time, central resources are pulled and assigned elsewhere. Churning of engineers is reduced.

The structure I have just described works well. Well, it is more accurate for me to say it can work well if properly executed. Like many things, what appears simple is much more complicated in reality. Staffing the central group is different from staffing the product line team. The prime requirement is for an engineer who understands engineering. I don’t mean the “A” student who memorized his way through his classes but rather the student who has a deep feeling for engineering. This requires a different and usually deeper interview process. The engineers will be required to work in various areas rather than being specialized in one.  They will have to depend on their deep understanding to guide them when working in unfamiliar areas. Furthermore, personality screening must be done to make sure the prospective engineer will adapt well to being a central resource. Many engineers prefer the ownership that comes from being part of the product line. The central group is one where most of the hiring should be new college graduates. In this way the engineers aren’t specialized by years of working in one narrow area. A few experienced engineers will be needed to guide these new college grads and those engineers must have good leadership skills.

This central group has to be built. That brings up another problem. It goes through growth stages and management must be able to adjust to the stages and properly nurture them. Initially the group will be green. That means it will require close supervision and what amounts to micromanagement. Also, initial tasks should involve simple extensions of the work done by the main product line engineering groups. An example is a migration of a proven design to a next generation technology or a simple change to generate a differentiated product. This also helps alleviate the fear the product line groups will have that the central group is out to replace them. As unfounded as that fear is, it will be there. Pointing out that the central group is taking the boring jobs so the expert product line group can handle the cool new challenging designs will make things work more smoothly.

As time goes on the nature of the central group will change. The central group will get exposed to designs from each of the different product lines. That means the central group will be the one group that has exposure to the full set of corporate engineering knowledge. Eventually they will become an agent for cross pollination between the product line groups by bringing engineering knowledge and techniques form one group to another. The central group will also mature out of doing simple “follow on” project to the point where it takes on more challenging tasks. Eventually it will become an elite group taking on some of the most difficult projects the company has. At this point product line fears will reemerge and must be dealt with by management. There will be a fear that all of the good work will go to the central group. Management must reaffirm their faith in the product line groups and point out that the central group is not sized to take over all engineering and can only augment the product line groups. Additionally, management will have to do the difficult shift from micromanaging a green group to being the supportive enabler of a mature group.

There are other issues that must be dealt with if a company is to be successful with this structure. In particular, the CEO must be willing to be an active participant in the direction of the company. Resourcing of the central group will involve CEO direction. I have been surprised by how many CEO’s want to abdicate this responsibility. It is simpler for them to just dump the responsibility for the direction of the company on the PLM’s. Worse, as the central group gets more experienced, it will, if properly nurtured, develop into a resource that gets fought over by the product lines. Indeed, there will be an ongoing attempt at “land grabs” i.e. the PLM’s will explain to the CEO why they should control the central group. This will require a strong CEO who is willing to drive overall corporate direction and resist the pressure to break up the central group. It comes down to a CEO willing to do what is right for the shareholders rather than what makes his life easier.

What the central group is not is an extension of the CTO office solely devoted to new developments. That said, it can easily report into the CTO office. Furthermore, the flexibility of the group and its diverse skill set makes it the perfect tool to to be used for entry into new product areas. Consider the way most companies handle entry into a new product area. First, the company looks to hire a team or do an acquisition. An acquisition may be the right answer – sometimes. Often it represents a huge waste of shareholder money.  A failed startup is acquired at a high price. The internal engineers are sent the message that management lacks faith in them to enter the new area. If  a new group is built from scratch then the company looks to hire experts. What they usually get are the “B” level players. The “A” players are locked into their present companies with golden handcuffs. The big problem is one of time. Recruiting and building the new group takes time. If done too quickly, the result is a poor quality group and a failed entry into the new area. A better approach is to get one experienced person in the new product area and augment him with resources from the central team. The central team can start even before the experienced engineer is found and hired. The result is rapid entry using a quality team which can extend what has been previously done by other companies. This contrasts to the acquisition approach and from scratch team approach which often lead to a “me too” and mediocre product.

In summary, it takes a combined structure of engineering resources to maximize execution together with flexibility. This can be accomplished but requires the active participation of the CEO. Additionally, the CEO must be willing to resist “land grab” pressures that will develop. Properly done, tho structure enables a company to move rapidly into new areas, cross pollinate ideas within the company, reduce engineer churn and shift product emphasis rapidly.