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
- 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.
Thoughts on Venture Capital
Posted: August 3, 2011 in Management, venture capitalTags: 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.
Leadership, Motivation and Not Saying the Wrong Thing
Posted: July 8, 2011 in ManagementTags: 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.
More Thoughts on Spreading Corporate Knowledge
Posted: July 2, 2011 in ManagementTags: 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.
99 is a Failing Grade and the Limits of Engineering Authority
Posted: June 29, 2011 in Engineering, ManagementTags: core values, engineering, management, training
Earlier I wrote about the need to instill certain core values into new college graduates, NCG’s. It is often during the training review that issues related to core values and expectations show up and where the initial reset occurs. One common issue is the belief that 99 is an A+. IN terns of the NCG, this has been the case for years. Consider a typical college engineering class project. A semiconductor design class might involve the design and physical layout of a small circuit. This must be done within class time constraints. The project will get reviewed to make sure the student understands the basic ideas. Small errors and deviations will be tolerated since time was limited and the student got the main point of the exercise. The business world is different and this is one of several places where expectations must be reset in the mind of the NCG.
To even get to the point of being able to reset expectations, without having prior corporate financial damage done, requires a well designed training program and, in particular, a well chosen training project. The project must be able to be completed in the training timeframe (5 to 7 weeks is a good range) but with some carefully chosen exceptions. In the past I have used an 8 bit register design project with specifications that were mostly easy to meet but with a few challenges. I will reference this project in several future posts since it has proven excellent at bringing out several common NCG issues.
Today’s topic involves meeting all, and I mean ALL, design targets. As the trainee chugs along through his design, most tasks come to completion in a straightforward fashion. He begins to feel that the main point is to show competency with the tools and that is certainly one point of the training exercise. However, there is typically one spec, be it speed or input levels, which is difficult to meet. OK, it isn’t doable for the average NCG. What I will describe next is a surprisingly common occurrence. During the review the NCG explains that he did his best and it’s close to spec. He explains that he met all other targets. The others in the room lower their heads. They know I am about to go on a rant. I start by giving an example of something most NCG’s can understand – buying that first new car. I ask him to imaging getting a new Accord, driving up to a stop sign, and finding out that the car won’t stop. He uses the hand brake to limp back to the dealer where he is surprised to find that the dealer thinks he should be happy. You see, the car is 99.9% perfect. The radio is fine, as are the seats, the engine and the environmental controls. The only issue is a bad seal in the brake system master cylinder. This is an A+ car! I then explain that just like he wouldn’t be happy with that car, our customers won’t be happy with our parts if they are only 99.9% correct. Consider a chip involved in routing data. If only 0.01% of the data gets corrupted, that’s a disaster. The only acceptable grade is 100.
If you have been following my bog (of course you have – right?), you might be thinking I am contradicting myself. Didn’t I say it was about just being good enough? I did and I still do. Read that older post carefully. It mentioned that quality is meeting customer expectations and needs. I wasn’t saying you could fail to meet the requirements. I said great engineering involved deeply understanding what the requirements really are and meeting them in a cost effective manner rather than brute force over engineering.
There are several other topics related to 99 being a failing grade and the training review scenario I have described above. I want to save some of these for later posts so they get their full due. However, I want to touch on the limits of engineering authority. Every now and then, and less than I would like to see, an NCG trainee circumvents my standard way of being able to relate the new car story and my ability to make the point that 99 is a failing grade. He does this in a very simple way. He discusses his inability to meet the target specification with his training supervisor and the supervisor tells him that the present performance is good enough. That is equivalent to getting marketing to change the target datasheet. For the majority of trainees that have not gotten this special dispensation, there is a second lesson, in addition to 99 being a failing grade, that they need to understand. They have exceeded their authority. In the real world, a company will put its name on the parts they design. Organizations will count on them. The company must be confident that changes, even if necessary, will only be done out in the open and with agreement from the corporate parties responsible for setting design targets. Working in partnership with others in the company is an important core value. It is important that we all know what our charters are and what they aren’t. That doesn’t mean being sheep. It does mean bringing issues out into the open and being part of the solution. For most reading this post my comments will sound obvious. To many NCG’s they aren’t.
Making the Most of New College Grads
Posted: June 24, 2011 in Engineering, Management, Microsoft, UncategorizedTags: Bill Gates, hiring, Microsoft, NCG
Just about every company pays lip service to the value of hiring new college grads, NCG’s, but few do a great job utilizing this raw talent. To start with, few realize the true potential and why NCG hires are so important. They hire a few, sprinkle them around the company and are done. Some pay lip service to training but with training that is poorly targeted. Even fewer understand what they should be looking for in NCG’s.
Let’s start by understanding the fundamentals of hiring NCG’s and what to look for. To do this we need to look at what the downsides are to hiring experienced engineers. If your first thought is salary then you are way off base. When you go for experienced engineers you are rarely able to get the best people. The best people usually have golden handcuffs keeping them at their present company. You get the person below the best. He may be great. However, the interview often tells you less than you think. It is difficult to decide whether the candidate is the creative mind generating the great work on his resume or a following mind led by someone else. Knowledge is great but the ability to generate new knowledge and be creative in previously unexplored areas of engineering are what make great engineers.
Now consider hiring NCG’s. There are no golden handcuffs. They assume they will be relocating so they are very mobile and will go where you want them to. You stand a lot better chance of getting that brilliant, creative mind. You do have to aim you interview process in the proper direction. The interview questions must look at understanding and insight rather than memory work. I once got told that all you had to know to pass my interview was Ohm’s Law, Q=CV, and charge conservation. That’s a bit of a stretch but there is truth in it. I replied that to pass my interview you didn’t have to just know those items but they must be understood at a deep, inner, level to where they had become intuitive. Those people are rare, whether experienced or not. However, your best shot at hiring one is looking at NCG’s.
Once you have hired that rare, insightful mind, you need to make good use of it. That means training them, setting expectations, and generating the habits of great engineers. It does not mean throwing them onto a project and calling the hiring process done. What I have done in the past is put the NCG’s through a five to seven week training program. A proper training program should accomplish several major goals. First, the student must learn the basics of the tools he will use. Secondly, he must come to understand the overall framework that a design process follows. This is much like a student taking general physics in college. The classes that follow, optics, mechanics, relativity, thermodynamics, etc. are elaborations of what was taught in general physics. The general physics class acts as a framework onto which the new knowledge is placed. In the engineering world it is important that it is always understood how individual processes and engineering steps fit into the overall design process. The third item that needs to be inculcated involves a number of attitudes that make up a great engineer. These attitudes are often overlooked. With experienced engineers they either have them or they don’t. With NCG’s you stand a good chance of forming a proper view of the engineering world. These attitudes are so important I will make them the subjects of separate posts. It’s just too much to include right now. It takes a lot to get these concepts ingrained but it starts with the first design review. The training program should involve designing a small part from start to finish. It should cover more than what the engineer will work on when on a real project. It is important that the NCG develop a sense of the issues confronting others and how his work will interface to their work product. The training, if successful, ends with a design review. It can be a bit brutal since it is meant to be a reality check. For that reason it is limited to senior staff who are intimately familiar with the goals of the training process. It is this review which introduces the engineer to concepts such as why 99% is a failing grade, the limits of his decision making authority, how an engineer manages his time and resources to prevent spinning his wheels, and how to properly run a design review so that the correct objectives are achieved.
After the design review has been successfully completed, the NCG is ready to become part of a design team and commence work on his first project. The project lead can extend the basics the NCG has learned during training and concentrate on bringing him along as an engineer. The group, having a common set of values and attitudes, is stronger and more functional. During the early days, Microsoft was built on this idea. It is key that everyone be well integrated into a common culture which elevates getting the job done in a correct fashion and discourages destructive behavior. Properly done, this culture brings out creativity rather than stifling it while keeping divergent activities in check. After all, the goal is to sell a product and make money. We’re talking engineering and not science.
There is a caveat here. Life is gray. It’s all about balance. I have been focusing on new college graduates. There is also a place for the experienced engineer. When to go for experience and how to select that engineer is a topic for another post.
“Good Enough” and Business
Posted: June 17, 2011 in Broadcom, Engineering, Management, Qualcomm, TrendsTags: good enough, GPS, trends
I just finish talking to a friend and mentioned my last post. As we discussed it I realized it was about the individual engineer. Missing was how the concept of “good enough” affects business. That was a very big omission on my part. It’s time to fix that mistake.
When it comes to business, the idea of being “good enough” has a huge impact on decision making and the future of companies. This is best illustrated by discussing an area I am intimately familiar with – the semiconductor business. Imagine you are running the fictitious company GPScom. GPScom makes the world’s best GPS chips. They are WAAS and LAAS capable, very sensitive, and simply the best GPS chips by far. They own the personal navigation device, PND, market along with being in most other GPS based devices. However, companies like Broadcom and Qualcomm start producing mobile phone chipsets with relatively poor GPS receivers in them. These chipsets have only basic GPS circuitry that lacks not only LAAS but WAAS. They aren’t very sensitive and the GPS might say you are in the parking lot when you are really in a cafe having a bowl of soup. The problem is, these receivers are mostly good enough. With proper software the mobile phone becomes a decent navigation device. Furthermore, after a couple of generations, these phone chipsets have GPS receivers that are more than good enough. Since they are integrated into the mobile phone chipset they burn less power, take less precious board real estate and cost less. This means they do a better job of meeting the needs of the consumer. The PND market begins to fade as mobile phones take it over. This is happening today. GPScom engineers can tell themselves all day long how their circuitry is superior. The problem is that sales, and hence revenue, are going to Broadcom and Qualcomm. GPScom will have to either diversify, get acquired, or watch itself become less and less relevant until it fades into the sunset.
As an area of technology moves forward there gets to be a tipping point when what can be put into a CMOS chip is good enough. At that point the technology gets integrated and becomes part of a bigger solution. Companies that fail to recognize this risk becoming irrelevant. This is why the idea of “good enough” isn’t just about the individual engineer. It affects core business strategy. Every company needs to be worried that their area of core competency will evolve to the point where “good enough” marginalizes their value. These companies must either diversify so that they make the chips with the broader functionality, acquire technology that can be integrated in, or get acquired themselves. Is your company aware of just what “good enough” is when it comes to their specialty areas or does hubris cloud their thinking?
paulplatt 