I ran across an old magazine a few days ago and it brought back a lot of memories. The magazine contains an article entitled “The Chip Man Finally Comes” discussing the founding of Integrated Device Technology’s (IDT) Atlanta Design Center (ADC). This was IDT’s first design group outside of California. ADC was different not only in location but in concept. it was a central design organization and worked with all of the product lines in the company. For 16 years I ran ADC and it was the most fun I have ever had in my career. From just an idea it grew and generated hundreds of millions of dollars of revenue in many areas including networking, memory, logic, clocking and power. It’s a great feeling to create something like that and I feel fortunate to have had the experience. To take a small group of engineers and beat the competition when they have more money and more people is an awesome feeling. Looking at the operation today it’s easy to forget the early days of $10 surplus desks and a few people in a single room. For those interested, and particularly those who experience ADC, I have posted the article here.
Archive for the ‘Management’ Category
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
- 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.
Tags: investing, venture capital, Yamacraw
At one time I sat on an advisory panel that reviewed requests for venture capital. This was related to Georgia’s Yamacraw initiative. The panel was advisory only but included local Atlanta businessmen. It was a small panel and we had some great discussions. The state would only invest if other venture capital funds were already investing. Consequently the proposals had already survived initial vetting. Still, I was surprised at what I saw. I was discussing this with a friend and thought I would post a few of my observations.
Observation 1: Commitment or lack thereof.
Time and again I saw companies based on work down at Georgia Institute of Technology (GT). GT is a great school and there is great research going on there. The problem was that the professor was proudly listed as a founder and key player but when I asked if he had given up his tenured position to focus on the company the answer was always a resounding “No!” Let me get this straight. You want people to put millions into your company but you aren’t willing to work full time to make it a success. I’ll pass. I am sure there are lots of examples of successful companies done this way. I just don’t like the odds. I want to distinguish this from the case where a graduate student has invented a technology while working with a professor and the student is forming the company with the professor as a consultant. As long as the founder is full time, I’m good.
Observation 2: Serial entrepreneur who doesn’t take responsibility.
There was one guy who had started an earlier company. We heard how the failure of the earlier company was the CFO’s fault. This guy had been the CEO. It happened on his watch. At the minimum I expected to hear about painful lessons learned and future corrective actions. Instead it was all excuse making. I passed.
Observation 3: Big ego and insistence on retaining control.
This one isn’t from the Yamacraw Advisory Board. Rather it is a painful lesson from a personal investment. I thought I had done my homework. The technology was sound. The market seemed ready. There was diverse funding. However, when more funding was needed, the founder refused to give up control of the company. I learned the hard way that this is a big red flag as is a person putting his name on the company. The CEO would have been an excellent, and probably very wealthy, VP of Engineering. Instead he became a failed CEO. Unlike me, the smart money refused to invest unless the venture capital crowd gained control. Hey, it’s their money and they wanted a meaningful say in what went on. They were correct in wanting that. I was too naive to see the danger signs. If a CEO is afraid of having to convince a board of directors then he shouldn’t be CEO.
Observation 4: Willingness to work hard and generate a hard work culture.
Building a successful company is hard work. Just ask people who have done it. Many will tell you that they are glad they hadn’t known how hard it would be because they might never have done it. When looking at a potential investment I want to know that the entire team understands that they are in a race against time and money. That means hard work; lots of hard work. It means being careful with spending. Generating a hard work culture doesn’t mean generating an oppressive one. People should be excited that they are building a company. Their ownership in the company should generate adequate motivation. The work environment should be alive with energy. People should be working hard because they want to win. This can be difficult to judge but it can come through talking to the executive staff.
This is by no means a complete list. I have avoided the standard topics of market analysis and threat analysis. Most books on the subject cover that better than I can in a blog entry.
For the past several years, intellectual property (IP) reuse has been a major topic in many companies. The idea is that a large corporate database of IP will reduce design times and disperse knowledge throughout the company. Rarely do these efforts work. The list of reasons is huge. That doesn’t mean IP reuse can’t work. In certain situations it has had a lot of success. You just have to go into it with your eyes wide open and a bit of a skeptical mindset. The distinguishing characteristic that separates success stories from failures is motivation. If the person doing the work is the person receiving the benefits then it will work. If you are asking people to do work just because it’s the right thing to do then the system will fail. Systems that work follow the rule “He who benefits does the work.” This is best done by looking at the most common structure, which happens to be a failing one, and comparing it to two structures which work.
In the most common system an IP repository is put into place. This might be something as simple as a list of IP and who “owns” it all the way up to complex systems with checkout tracking and automatic notification of updates. The engineer is told to put useful IP into the system. Users of the IP explain all that is needed to make the IP useful. This usually involves long lists of documentation, simulation files and testbench files. I once asked an engineering manager what would be required for reuse within his group. He gave me a long list of items he insisted be present. Now it turned out that this same manager was sitting on a lot of IP that might have corporate-wide use. I contacted him and asked him to please submit it. Of course I asked for the supporting information this manager had said was the minimum set. His immediate reply was that I was nuts. No way was he going to submit all of that. It was too much work. I had hit the fundamental problem. There was no reward for doing the work. Like most organizations, the company rewarded this manager for getting product out the door. It didn’t reward getting IP into the system. The manager loved the idea of grabbing IP if it aided his design efforts but was uninterested in helping others. Sadly, he was correct in his assessment of the reward system. When proposed, IP reuse usually gets shown as a time saver. It is pointed out how much time can be saved by reuse. What isn’t pointed out is the wasted effort getting items into the repository when those items will never be reused. Also not pointed out is that a lot of reuse has usually been going on all ready. People who design related items have been talking to each other be it in the hallway or at lunch and have been sharing. The informal sharing has been productive and efficient albeit undocumented.
In certain companies the design process is such that IP reuse can be done in a natural and efficient way with aligned motivations. A good example is a company which designs a family of large ASICs all of which are different combinations of building blocks with large groups of related products being on the same process. These blocks might include an HDMI input or perhaps a X4 USB2 block. The architect requests the design of different blocks and projects are generated within a group devoted to block design. Placing the block into the repository is no longer a side item with zero recognition. Rather, it represents the culmination of a project. For this block design group, release to manufacturing has been replaced by entry into the repository. There is alignment of interests. Reuse of the blocks is assured since there are defined products for them to go into. There is little waste. Where this works it is a great thing. The problem is that it can only work for certain companies or certain subgroups within companies.
The last example I want to give is something that is ready to be implemented but needs to be done carefully. The key is to make entry into the repository a natural part of the design process requiring little extra effort on the part of the design engineer. If a block doesn’t get reused then there is little lost effort was since little extra time was spent. Engineers don’t rebel because they are just getting their engineering work done as they would if the repository didn’t exist. Where the heavy lifting comes in is on the design flow and engineering software support side. When a design block is started the engineer is asked to classify the block and put in a brief description. Everything else is automatic. The owning design engineer, overall project name, design technology in use, etc. are all noted automatically. A placeholder is put into the IP repository complete with an expected release time based on when the design project should be done. This solves the old problem of parallel development where engineers don’t have insight into what others are working on. Someone needing an HDMI I/O might see one under development that should be done well within his schedule constraints. When the block design is completed it is marked as provisionally done and can be checked out. Once the original design has been checked out completely it is shifted to a verified design status.
I’ll write more on IP reuse in the future and mention some specific software programs that can help. For now I want to summarize what to look at. First, do the company’s products share a similar architecture and process or is the company diversified across many different product types? The answer dramatically affects optimum IP reuse policies. Secondly, corporate culture must be considered. IP reuse requires alignment in culture across the company and a unified message from the top down. The key here is honesty by top management about itself. Remember that the goal is selling product to the customer and not fancy PowerPoint slides or internal metrics. Reuse is a very good thing if you pick the proper shade of gray i.e. an implementation that aids productivity rather than generating lots of work with little return. It can be done.
I have one final thought. IP reuse is different from sharing corporate knowledge. Be careful not to confuse the two. Each can aid the other but they are different.
Tags: excellence, leadership, management, motivation
I was watching a TED Talk on leadership and it reminded me of a conversation with a good friend and how management often just “doesn’t get it” when it comes to motivating engineers. It is said that people will live up to or down to the expectations that are set for them. Management needs to be careful that they don’t set expectations that have their engineers living down to the expectations set by the company. My friend’s case is a good example. He works for a very large and very successful semiconductor company. He has been there through most of the company’s growth years and has been part of other successful startup companies. It seems his VP had come to give one of those inspirational talks VP’s are asked to give. I’ve been there so I am sympathetic with getting in front of a large group and needing to be motivational. It isn’t easy and I have messed up more than once. Still, as my friend relate his story, I was appalled at what was said. It seems this VP explained that my friend’s design group would never be allowed to venture very far afield from what they were doing. The VP further explained that if the company needed something done in a new area then the company would acquire a group working in that area. He explained that Wall Street looked more favorably on acquisitions than on internal investment. There is truth to what the VP was saying. I have seen this issue myself where a company did a poor acquisition at a cost of $20M and I was left thinking of all of the great projects not being done that could have gotten done for much less money. What surprised me was that the VP said this in public. The impact was immediate and horrible. The engineers left the meeting feeling that the company lacked faith in their capabilities and that they were destined to be second class citizens. To them the company’s vision of their engineers was one of widgets who were pigeonholed as to what they would and would not be allowed to do. Today my friend longs for those earlier days when the company he works for believed in their engineers and challenged them to change the way things are done and to invent a new world. The damage is now done. The VP missed an opportunity to talk about excellence, doing great things and how those engineers had changed the world. The sad thing is that my friend’s group has changed the world. Many readers of this will use the results of their efforts every day. Because of what they have done there is a billion dollar company around. Instead of challenging them to yet again take the company into the future, they were left feeling like yesterday’s news.
I said it was a TED Talk that reminded me of my friend. The topic of the talk is leadership and appealing to the emotional self. It focuses on companies as a whole but I think it says a lot about how we, as managers, should motivate and challenge. It isn’t a complex talk. The concept is simple but I do think it is important. In the engineering world it is all too easy to get lost in the details, datasheets, project targets and other explicit items. We like to think everything is rational. However, the vast majority of us are motivated more by our inner emotional self. Watch the video and let me know what YOU think.
Tags: CKX, Compendian, Sharepoint
After writing my last post I have been thinking some more about the internal sharing of corporate knowledge. I want to add a few more somewhat random thoughts. First, noting can completely replace personal contact. Having people get to know each other is valuable. It breaks down barriers. Next, there is a lot of software that can help but, unless fully supported from the top down, it will fail. Sales side software seems to be more advanced than the engineering side with lots of products out there aimed at sharing knowledge about customers. Compendian CKX is one such product. I am sure there are many others. Microsoft Sharepoint and many other products can be configured to give project and production status. However, these programs are more about improving the visibility of information and sharing internal corporate facts (project status, sales numbers, etc.) than about how things are best accomplished. Unless data entry is a normal part of the work flow, it won’t get done. Similarly, just because data is accessible doesn’t mean it will get accessed. Put another way, placing information into a repository is different from sharing information. Software can be an adjunct but only if part of a structure and culture which makes its use natural.
When companies are small, knowledge gets shared naturally in hallway conversations. If a company is a serial design company having only one design team doing parts sequentially, then knowledge sharing occurs naturally in the project meetings. As companies grow and multiple designs are going on simultaneously by multiple design groups then these communication paths break down. As companies grow even larger, they develop silos. Most often these form along product line boundaries. This isn’t anything new and it isn’t some hidden issue. A lot of companies make valiant attempts to reduce the problem and some do it with good effect. One of the most common methods is the use of internal conferences. An example might be an engineering conference where different engineers present what they have been working on. Usually the focus is on new design techniques or new products ideas. Sometimes support groups will be brought in to discuss new tools that are available or how to get problems resolved. A good example might be having IT discuss new customer tracking tools at an internal sales conference. Another useful idea is to have different areas give insight into what is going on in the company. Marketing and sales might present at an engineering conference and explain what they are hearing from the customers. Engineering might present at a sales conference and discuss why some aspect of a product is special and should be highlighted to customers. One often overlooked aspect of these conferences is the need for lots of social interaction. Probably the most important thing that can happen is for engineers in different groups to get to know each other and get comfortable helping each other. Everything from the length of breaks, how snacks are set up, and seating arrangements should be done with this in mind
Another method, seminars, is related to the conference idea. These can be small, lunch time, seminars on a narrow topic or larger, day long seminars on something of major interest. An example of a major seminar might be a presentation on electrostatic discharge protection and the resources available within the company. A smaller topic might be equalization used on a specific serial I/O.
A less often use method is having people change departments for periods of time. You read a lot about this when it comes to growing executives. The importance of top talent seeing various aspects of the company are stressed. There might be a stint running operations in a foreign country. For all that this gets stressed in books, the same people seem to ignore it when it comes to people not on track to get to the corner office. Some companies have done this in the past but it seems to have fallen out of favor. At one time several companies had programs where new hires would spend several months in one area and then several months in another. Mostly this involved college new grads. I have no direct experience with this method so I can’t comment on its effectiveness.
More recently, intellectual property (IP) reuse has become a major topic. The idea is that a large corporate database of IP will reduce design times and disperse knowledge throughout the company. Rarely do these efforts work but that’s because people don’t understand the issues involved. In the cases where this has been effectively implemented, the returns have been huge. The list of reasons for failure is large and will be the subject of another post. For this post the main point to understand is that even when this works it is better at sharing work product than it is at sharing internal corporate knowledge.
The final method I want to discuss is something I stumbled upon in my career and have since used to good effect. It involves a central group acting as a pollinator of ideas i.e. a group which, as a natural part of its operation, disperses ideas throughout the company. At a previous employer I had been part of a team putting together a remote design center. This design group was a general corporate resource and, as such, was not aligned with an individual product line. Work was done for whatever group needed the extra resource. While there were some other experienced people at the site, I found myself managing mostly new college graduates. These engineers were very bright but green. There were difficulties jumping into totally new designs but we did well on follow-up designs. We had been doing a lot of memory chip design, which was my specialty at the time, and we had gotten pretty good at it when we were asked to do a PLD. We had never done a PLD before but it was a follow-on part. It was the third member of a product family and the simplest family member. This was a boring design project for the main design team associated with the PLD product line but it was new and interesting to my group. As we started working on the design we found a lot to be excited about. This was our first encounter with high voltage routing and also our first experience with single ended sensing. Previously all of our work had involved differential sensing. I had expected this and the design was playing out as expected until one of the young engineers asked a question. He said he had been looking at the data path so he could learn from the more experienced engineers and he didn’t understand the reasons for the device sizes use. I took a look. Crud. I didn’t understand why either. I started thinking about how I would size things. The young engineer and I decided to run some simulations. The end result was that my sizing was faster. As you might expect, the next step was to redesign the speed path based on the way a memory designer would do it. The end result was that the part done by my junior team was a full speed grade faster than other members of the product family. In the end the main PLD design team redesigned the other members of the product family with the changes my group had put in. When I looked back on the project I realized what was happening. We were cross pollinating ideas. My team had brought high speed SRAM design techniques to the PLD group. In return, my team had learned about high voltage charge pumps, high voltage routing, single ended sensing and PLD architecture. Knowledge was being transferred across the corporate silos. As time has passed i have seen this happen again and again. Usually it is much less dramatic but the transfer is there just the same. An additional side effect is that the central group transforms from an immature, green group to a flexible group with broad skill sets capable of getting the company into new product areas and better able to take on tasks in new product areas.
I need to explain what the central group mentioned above isn’t. It isn’t the main design group for a product line. It is never meant to be the main design resource of the company. Rather, it is a smaller group of flexible engineers having diverse skills and able to augment the central teams where most needed. It also, over time, becomes a great group for initial design work in new product areas. This allows going into new areas in a rapid fashion without the startup delays that come from having to first hire a new team.
Why worry about all of this? Because execution and excellence matter. In the example above, a product family wound up being a full speed grade faster. That’s huge. In other cases having people mix at design conferences resulted in the sharing of IP and reduced design times. In yet another instance, the insistence by a group that they do things on their own and remain isolated resulted in the reintroduction of a design flaw that had been found and removed in an earlier iteration of a product. The corporate culture must be such that engineers communicate across product line boundaries and that the communication is friendly and supportive rather than competitive.