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.