Organizational Memory

Closing chips is hard and it’s getting harder. As we discuss Pinpoint with people, we find that organizational memory is one of the pervasive problems in the industry.

We all have a limit for the amount of things we can keep in our head at one time. We remember the mistakes that we made most recently, but tend to forget the ones that haven’t bitten us in a while. This can cause problems when you close chips, managing ever increasing complexity, hoping you’ll remember all the various gotcha’s.

The more complex the chip, the more each engineer must specialize, creating unique solutions to unique issues. Passing this learning on to the team is very difficult.

Complexity also brings unexpected side effects. Just this last week, we heard a story of a team who spent a good deal of time putting in place clock gating for the whole chip. Things looked great until they pulled in the logic from the BIST module which introduced an extra 20,000 ungated flops into the design. It was a power nightmare.

Key problems facing teams go beyond the difficulty of tracking metrics. They must also make sure the entire team can see the effect of each member’s changes on the chip at large as well as provide a mechanism to capture organizational learning so that past mistakes are not repeated.

Practicing Frequent, Small Scale Collaboration

Our products encourage collaboration for our customers, and at Tuscany we are reaping benefits internally by taking our own advice: Build the strength of your team by regularly practicing frequent, small-scale collaboration.

Earlier in our life as a company, our practice was to assign each engineer the responsibility to deliver what were essentially independent features.  This worked okay, but it had several big drawbacks. First, it isolated the engineers into their own thinking. Sometimes there would be some coordination between a couple of engineers where features overlapped, but mostly each engineer worked independently and developed isolated solutions that only he or she understood. Helpful feedback between peers could be a big challenge.  Second, the engineer who took the longest, delayed the overall release.

We got the job done, but over the last six months we’ve changed our approach, and it’s increasing our productivity and strength as a team. By breaking each major feature down into it’s component pieces, and then assigning the various engineers to work on parts of those pieces, the team is working better than ever. Besides minimizing the two costs above, we develop better code faster.  Since people can pick up slack for each other, and since the team shares a more global understanding of each feature because essentially we all work on many parts of many features, the excitement of everyone involved increases.

Visiting our Fort Collins Engineering office, you can sense the enthusiasm of the team.  They work fluidly, collaboratively, and together get a whole lot done. We also see it happen with our customers, Physical Design teams who have the tools they need to better collaborate and share their work. And when a team is working together toward a common goal, it’s 1+1 = 10 (not just in binary thing, either).