Archive for July, 2011

The Budget Battle – interesting data

Posted: July 26, 2011 in Politics
Tags: ,
1

OK, blogging can be difficult. I just got back from a trip to San Jose so there has been nothing new for well over a week. The trip was very productive in many ways but the blog suffered. While there, I was discussing many things with several companies. Some will show up here. As a teaser, OLED and the necessity of RGBW technology, non von Neumann computing, and high speed memory and the need for serial I/O. This is all very techie stuff. So, today I’ll post something entirely different.

I am watching the news and the budget debate is very frustrating. There are claims and counter claims. Without taking sides, I found the first table in this Wikipedia article interesting. Don’t just look at who was president, although that is very interesting. It also shows which party controlled the House and Senate. Debt as a percentage of GDP is interesting. Mostly I am posting this to get you thinking and looking at facts rather than following whichever party rhetoric you are inclined to align with. Enjoy and think.

Advertisement

IP Reuse

Posted: July 16, 2011 in Management
Tags:
0

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 Management
Tags: , , ,
0

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.

Humbled by WordPress

Posted: July 2, 2011 in Wordpress
Tags: , ,
0

Writing the posts on visiting Johnson Space Center was frustrating to say the least. You can add the word humbling to that too. Back when dinosaurs roamed the earth, I maintained a website. Initially I wrote the HTML code using Microsoft Notepad. Later I shifted to Frontpage. So… when I had trouble formatting the pictures and text in my blog I switched from the visual editor to the HTML editor. All I wanted to do was add some hard carriage returns. Every time I posted, WordPress decided to “clean up” my code by removing what I had entered. ARGH!!!! A Google search showed that I’m not the only one experiencing this. I finally found a code snippet that did the job but why wouldn’t standard HTML work? Worse, why was I in HTML mode anyway? Isn’t the point of sites like WordPress to make this easy? I have written a lot about user interface design. One comment I made was that the more natural a user interface gets the bigger small defects appear. I am sure I’ll learn to format around pictures and make the site look the way I want. At one time my standard answer would have been RTFM. But now, as I move from playing with technology to wanting it to be a working tool, I sympathize with those who ask why a manual should be necessary.

More Thoughts on Spreading Corporate Knowledge

Posted: July 2, 2011 in Management
Tags: , ,
0

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.

Sharing Corporate Knowledge

Posted: July 1, 2011 in Management
Tags: ,
0

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.