What I Tell New Hires

My teams have hired a lot from academia, most often fresh PhDs. Most are well aware that in moving to industry, they’re getting into something quite different from school, but they rarely understand the full context of that difference. Here are three pieces of context I have sometimes shared:

One: During the interview

Industry is different from academia. In academia, you're responsible for your own work, you do it all yourself, and if you make a mistake, you notice it, and while it may set you back, you can just work a little harder to correct it, and then try again. In industry, whatever you're working on is important because, directly or indirectly, it impacts a product that we're trying to ship. Mistakes in industry are much more costly because, especially if it makes it into a tapeout or final design, it can take 6 to 8 months and hundreds of thousands of dollars to fix it. The money isn’t the big deal - if it's at all important, we'll happily pay. But 6 to 8 months means that we can upset the overall product schedule, and we could miss shipping on time, and that could cost us many millions, easily. That might sound scary - but remember that in industry, you never work alone. You're part of a team, and we're all responsible or helping each other. Your boss will check your work, your immediate team members will review it, and finally you'll present it to the project team. We're all responsible for making sure we're doing a good job. And every single person in the office is going to be willing to help you - to answer questions, to double-check your assumptions, etc. In academia, you sink or swim more or less individually. But in industry, we win or lose as a team. So while there's potentially a lot more relying on the quality of your work, you've got the entire team behind you. I think it's much more rewarding, and you have an opportunity to learn a whole lot more, including from people with different fields of expertise, and different levels in their careers. That's something you don't really get in academia.

Two: After they've joined, and they’re just beginning to try to get their hands around some problem they've been assigned.

You might think that we hired you because we need your help building a product. Sure, that's part of it. In a sense, we're designing a product, but it's not as simple as - design all the component parts, then put them together, tighten a few screws, and then people pay you money for it. There's a whole other piece to it. We're not just making a product, we're trying to build a machine that makes a product - in large volume. That machine is called a supply chain. Whatever product design we come up with needs to fit into some actual supply chain, which we also need to come up with. A lot of it has already been defined, in fact, because we want to be able to take advantage of the tools that already exist. So whatever changes we might want to make to improve the product, we also need to think about how they would fit into the supply chain - the vendors we've engaged with, the assembly processes we're designing, the testing procedures we're validating. And also the cost and schedule limitations. So there's a big picture to keep in mind here, or at least to be aware of its existence. Every design decision is just one part of a whole.

Three: A little later, once they have their arms around a problem, and are working on the particular form of their solution, maybe thinking about how to decide among multiple options.

Don’t get locked into thinking that you have to come up with one single golden design that solves the whole problem perfectly and without any risk at all. This is a new thing, and we don't expect you (or any of us) to have 100% confidence that it will be perfect. Communicate your level of confidence truthfully; we'll hear you. But pick one design that you think has at least some likelihood of fixing the problem, with minimal risk of breaking the the rest of the chip. Whatever you do, you should try to make sure that what you tape out has the right design somewhere in it. Obviously, you can include multiple designs (in engineering test area). At least one of those designs needs to be the right one, but the good news is you don't need to know which one it is in advance. For example - let’s say you're trying to improve the performance of component X by 10%. You think you have a good design, you put it in, we test it;, maybe it improve things, maybe not. As long as it doesn't fail so badly that it prevents us from testing the rest of the chip, we’re ok. We’ll pick the best design from your DOE and sub it into the final design later, with pretty high confidence. And we didn't even lose a design cycle - that is called a success. So as it comes closer to tapeout, you should focus more and more on how to make a good DOE, one that would help to validate and clarify your theory/simulations, and that has enough parameters in it that, even in the worst case where nothing works well enough, you have learned and tested the parameter space so you know what to try next.