Roles and responsibilities, yes, I have seen many, many organizations and companies struggle with this. This is a challenge to get it right. I'm not, I don't claim I know how to do this a 100% correctly. But I've seen and been in environments where roles and responsibilities are very blurry, it's not clear. And no one knows who is doing what, and who is responsible for what, and it's very confusing to everybody. So I put this slide together. Let's see if you can identify what scene this movie is from. So, [LAUGH] employees are unclear on roles and responsibilities, mass chaos can ensure! Okay, so there's two people running away from this crowd of people. Does anyone know what scene that movie, it's from a movie. Do you know what it's from? The original black and white Body Snatchers, anyone ever see it? No, well. I came across that, and was like, that's perfect. [LAUGH] Because, angry mob chasing you, I've felt like that before when I've been in these situations where roles and responsibilities aren't clear. So you get this, nobody knows what's going on. And so a crowd will come after, figuratively speaking, come after one person, or two people in this case. And you don't want chaos in the workplace. You don't want chaos in your team. You want everyone to understand, what is my job? What am I supposed to be doing? When is it due? There's a term called work product. That's the stuff you put out, the code you put out, the documentation that you write. When are my work products due? Good managers will make sure that is clear, and everyone knows what their roles and responsibilities are. So in the ASIC design example, manager's responsible for the project schedule, the task assignments, scheduling reviews, performing all that HR stuff like annual performance review. Some companies call them focal reviews. Accounting for vacation planning, I mean employees have to take vacation, right? And you need to make sure that when someone takes a vacation that other people can step in and fill the role of that person that's on vacation. So these are the primary things that the manager focuses on, his roles and responsibilities. The architects in our example, there was one software architect and one hardware architect. They focus on requirements and those architecture specification documents. That's what they work on, that's one of their work products. That's one of their outputs, they create the architecture specification documents. And in an ideal world, all technical decision authority should lie with these persons. When it's not, it starts to blur the lines of roles and responsibilities. It is effective, when there's engineers inevitably discuss multiple sides of any particular technical choice that is being made, whether it's hardware or software. And having and knowing in your organization, in your group, that there's one person you can go to to resolve this, is really useful. Because otherwise, it gets really blurry. And what ends up happening is it takes a lot of time to get answers to, should I design it with NAND gates, or should I design it with NAND gates and inverters? I mean, I'm just making up an example. And that can spin around, and around, and around, and go on, and on, and on, for days or weeks, if there isn't one person that you can go to, just that makes that decision. So if it's possible, the architect should be the ones that have the final say and make those technological decisions. This is what we're going to do, listen to the pros and the cons of, the architects would listen to the pros and cons of the idea or ideas being presented. And then, if it was me, I go sleep on it. [LAUGH] And then I come in the morning and I give the team an answer. Software and hardware leads, they're all about how it's actually going to be implemented. They're going to take the architecture specification, and they're going to weigh all the implementation trade offs. They're going to write a bunch of low level documents called micro-architecture specifications, or micro-architecture documents. This is where you're going to define all your software register bits that, when software sets those bit and initiates a DMA transaction, or whatever all the registers are that you have in your product. They would produce a programmer's guide, that's essential for software. They're going to want that right away. In fact, it seems like you can never get the programmer's guide ready fast enough for the software, because they're biting at the bit to start writing software after the architecture is done. And so it's important to get these documents written and get this information in the hands of the software team. Verification lead, this person defines the test bench architecture and the test approaches. How are we going to test this? How we going to verify it? What's our strategy? What does this look like? What is the test bench going to be? How are we going to test it? How do we know when we're done? So he'll create a template document for module level test plans. A well run basic design program will force the RTL designers, the hardware design engineers, to write a test plan as they're writing their micro-architecture documents. So they're writing their micro-architecture documents, and that's state machines and the data path, very detailed. The model has all these inputs, this clock, this reset, blah, blah, blah, blah. And as they're writing that and doing that design work, they're also thinking about, how do we test this? And so as the ideas pop in their head, this needs to be tested. So they've got their micro-architecture document open in Word, and they're typing in that. And then they've got their test plan document, or maybe a spreadsheet, or it could be a Word document, they're typing tests. I need to test this, I need to test this, I need to test that. And then, this needs to be tested, blah, blah, blah, blah. And those two things happen simultaneously. Now mechanical/physical lead, they're responsible for all the mechanical design and the thermal analysis, shock and vibration. And I have some more to say about that, how am I doing here?