a16z Podcast - a16z Podcast: Building the Right Technical Advisory Board

Episode Date: September 21, 2015

There is increasing interest among companies -- small and large -- in putting together technical advisory boards. It sounds pretty straightforward: get some senior technical experts to help with the technical speed bumps. But if that is all your technical advisory board is, you are missing out. Built and utilized correctly, a technical advisory board can be a huge advantage when it comes to mapping out a long-term strategic plan, finding talent, and building a great engineering culture. On this segment of the a16z Podcast we break down the right way to build a technical advisory board; what you should expect from the board (and just as important, what you shouldn’t). And for those looking to serve on a technical advisory board, the reasons to do it, as well as the things to consider before committing. This conversation was recorded as part of an event featuring four technical experts: Arnie Goldberg from PayPal; Purnima Padmanabhan, former CEO of Cavirin; Alex Roetter, SVP of Engineering at Twitter; and a16z General Partner Peter Levine.

Welcome to the A16Z podcast. I'm Michael Copeland. There is an increasing interest among companies small and large in putting together technical advisory boards. It sounds pretty straightforward. Get some senior technical experts to help with the technical speed bumps. But if that is all your technical advisory board is, you are missing out. Built and utilized correctly, a technical advisory board can be a huge advantage when it comes to mapping out a long-term strategic plan, finding talent, and building a a great engineering culture. On this segment of the A16Z podcast, we break down the right way to build a technical advisory board, what you should expect from the board, and just as important what you shouldn't.

And for those looking to serve on a technical advisory board, the reasons to do it, as well as the things to consider before committing. The conversation features four technical experts, Pernima Padmanabon, former CEO of Kavarin, Alex Roder from Twitter, Arnie Goldberg from PayPal, and A16Z general partner Peter Levine. Peter Levine starts us off. I was talking earlier with a couple of folks, and one of the things, you know, this notion of technical advisory board, I first want to clarify that there's a difference between a technical advisory board and a board advisor.

Okay, so for those of you just so were clear here, a board advisor is somebody who serves with the board of directors. Typically, you'd have venture capitalists on the board, and then some third party, another person who might be a board advisor, come and be on the board of the company. So we're not talking about that. Now, the other, I'm on the board of lots of different companies here at A16Z. And I often talk, and maybe I'll start open up the sort of panel here, I often talk with entrepreneurs that I serve with about a customer advisory board. And here we're now talking about a technical advisory board.

So maybe, I don't know, if you guys have some views on kind of the differences between one of those and the other. I know we're here to talk about a technical advisory board, but then I talk about customer and do we have two of those and like, what's the difference? Should we think about one? Maybe just we can start. Okay. Go ahead. Yeah. So at Box, we had both, and they're very, very different. So the audience or the population of your customer advisory board are really what you would expect to sell to. Right. So in Box's case, it would be the CIOs of big companies across different verticals that would be interesting to penetrate into. And they really should inform your roadmap for a product point of view. At least that's the way we looked at them. and that's how they served us. So they could be customers or they, you know, existing customers or potential customers, but that was really the point.

Then on the technical advisory board, it's very clear, at least for me, what I wanted out of that board, and it's important to understand why you actually want a technical advisory board and that influences who you get on there. I needed technical problems to get solved and not that I couldn't solve them within the teams that I had, but a lot of it was I needed smart people from the outside, outside that didn't have a lot of vested interest in the solution or weren't going to be there necessarily to deal with the consequences, to just bring some informed opinions from their

experience into some tough technical choices. So to me, pretty distinct difference. Any other comments? So I have had primarily customer advisory board, but what I found was once you formed an advisory board, and by the way, when you're starting out, even though it's a You call it a customer advisory board. None of them are your customers. And actually it turns out to be great because you're getting a lot of feedback from the customers, as you said, on the use case, on the pain points. Does the solution even make sense? But then I found the same advisory board, customer advisory board would nominate some technical folks from their teams to actually participate in, let us say, a beta or an alpha or even early feedback.

So some of the best requirements I've gotten detailed technical requirements, like multi-factor authentication, how do you want to build it in your product from customers who nominated technical folks? And then would those nominated technical folks then become the basis of a technical advisory board? Yes. In my case, it became, yeah, a basis of an informal technical advisory board, but it was kind of connected to the customer advisory board. All right.

I've only ever been on one, just the technical advisory board, but I would say even if you know that you want that, just be really clear. I would write, start everyone that raised their hand saying they're thinking about forming one. I would just start by writing down what you're trying to accomplish. That's just a thing that people do, and it's an outcome, but what is the thing that you think you need a technical advisory board for

and be very clear on that? And maybe it'll lead you down the road of a customer advisory board instead. I don't know. But I think just being super crisp on what you're trying to do is where I would start and then you figure out the right. So, Alex, maybe just on that, like, what was asked of you when you joined the technical advisory board? And then how did expectation versus reality actually pan out? Yeah, that's a great question.

I think it varies a lot. I mean, I think a lot of companies create these, and they don't quite know exactly what they're trying to get out of it. And maybe it evolves over time. But in some cases, it's formal meetings where you sit down and you learn a bunch about the architecture and you're asked specific questions. and then you can kind of comment on that with various degrees of follow-up over time. In other cases, it's really much more one-off things

than there isn't a board, but it's more you're just being an advisor. Some earlier stage companies, if the founders themselves aren't technical, done a lot of things around, try to help, you know, they're trying to hire their first engineer, but they have no idea how to do that.

So even things like, they'll mainly get a GitHub profile. Hey, is this person a clown or not? Is this even make any sense? I don't know how to recode what you know, what do you think. And so I get to poke around and try to give advice and that sort of so. So I think it varies a lot and sometimes those companies grow into more formal things. And did you find that the expectation was about the same in reality? I guess are there any surprises like that came up along the way? I think everyone is a surprise, but not in a bad way.

And I mean, I really think that it's such a blanket term that can mean almost anything that just ask the specific person creating it, what are you trying to do? How can I be helpful? Yeah, yeah. So Arne, maybe along those lines, when you did this at Box, what were you hoping to get out of your advisory board and did it, you know, did you get out of it what you thought? Yeah, did it work? So, yeah, I joined Box at the end of 2009. We're 10 engineers and, you know, through subsequent rounds of funding over the next 18 months, shit got serious really, really quickly. And so I needed some help in arbitrating some pretty deep technical choices and architectural choices. one good example

would be so without giving too much away about box obviously it's about cloud storage but what's interesting underneath that is the permissioning is a waterfall permissioning and so to actually

model that you could go down a path saying there's a graph and that graph is actually represented in something like Neo4J so a persistence model could be Neo4J but It was built on lamp.

So six months went by, and this debate raged within our engineering team, and even as we hired more senior people to come in and the debate wouldn't go away, all it took was one formal conversation with some of the, as I created this architecture board, this advisory board for people from the outside that would come in, give them context as quickly as possible around the problem, and they had a lot of seniority and experience and actually going down the path of some of these choices, quickly we realized we need to go down

a more tried and true path versus another path. So for me, those were seminal choices and forced in the road where it could have been pretty disastrous if we went down some more experimental choices as the company was scaling really quickly. And while in my role as VP of Engineering for Box trying to scale the company, I had a co-founding CTO that didn't want to manage anymore. That's basically how I got into Box at the very beginning.

We had a good relationship, but he was very much a shiny object type of person, so wanted to explore new technologies, but was pragmatic enough to actually listen to other people. And so I knew I wouldn't be able to get to an answer internally without maybe some external people that he respected forming or helping him form his opinion. So that's how I use them. Great, great. Pernima, you've set up several tabs,

and I'm just curious on the structure that, you know, like how many people, when did you do it? Like here you had a technical advisory board of 10 people, what's been your experience? Do they all look the same after you've set these things up? They actually look different. And one of them was at a large company. So that looked very different.

But for smaller companies... And what makes it... I mean, what makes it... That was almost like a... It was not a technical advisor. It was like a customer advisory board, CIA advisory board. And you meet once a quarter and then once a year you have a retreat. So it's a very different structure.

Okay. But with startups and smaller companies, things move very fast and so you need constant feedback. And so you have... From a structure of perspective, six to eight member... is actually works out well. The other thing is your needs change. So instead of having a four-year term, usually we have done a two-year term for the advisors.

And then you can always renew if the advisor is still relevant and is providing a lot of input for another two years. And if it becomes too large, because one of the thought is, okay, if you have these advisors, you can also go talk to them one-on-one. and state the problem and get advice. But having a board helps because you have a lot of discussion. And sometimes if you can state your problem simply and clearly,

you'll have some debate, you'll have counter opinions. So that is the big advantage of having a board. So if it's 6 to 8, then you have good discussion. More than that, it just tapers off. Yeah. Well, it does. They start fighting. I agree.

Six, seven. fighting with each other at that point. You know, two of them don't show up at any given time. That's exactly right. You end up with five. Five to seven, yes. I feel like it's the same guideline for basically all meetings ever. I don't have more than eight people on a meeting.

Then you are. Nothing else. Maybe it's informational or not. So I was going to ask you how often did you meet because that's the other factors, like limit number of people and then like limit number of meetings. So what do you think is most effective? I've done like twice a year. done a lot of just one-off things

where the whole group actually never meets, maybe hop on the phone or maybe otherwise, two one-on-ones. I mean, I think honestly, as someone that sits on these but hasn't ever created one, Twitter is far enough along that it probably, I don't know if it's the case, but I think probably don't need an external one

at this point. Twitter, of course. Yeah, we get it all figured out, so it's fine. Don't worry. I need any external advice. The goodness is we get a ton of it. So if anyone has ideas, we're short external product ideas.

all your problems would be solved with a technical advisory so for those who you want to join a technical advisory you want to talk about it. I totally forgot what question I was going to find me. Something about, oh, frequency. Yeah, frequency.

I mean, I think it goes back to the first thing I said which is figure out what you're trying to solve and then do the thing. It sounds stupid when you say it that way. It's a tautology. But if you need, if one-on-one is helpful, go do that. If having presentations is helpful, go to that. The only I have a story of something, I think, not to do, which is you assemble these things

and make sure that you're setting the right context. If it's just you going in as the CEO or founder or head of engineering or whatever it is, you probably know why you're then and what you're trying to get out of it. I've been on certain ones where they've invited engineers in the company to present something. And in one case that I'm thinking of,

I really got the feeling that they were a bunch of people that were actually being productive that day. And at some point, on short notice, who were probably asked to stop being productive and make a presentation for some people they never met, all of whom have fancy titles somewhere else so they don't care about. And then come in and give this presentation

and I felt before like, I'm just wasting a bunch of people's time. They actually don't have questions for me. Someone with good intentions, like sort of invited them to give a talk, but there's not a clear reason that I'm there to add value, so we're all just older, basically, at the end of this meeting. So if you're going to invite other people in,

be really sure that they know why they're there. And, I mean, I sit in these things to help. There's really no other reason. Like, it's fun and interesting, and you meet smart people, and you're there to help. So when people have questions, I'm around, and the other people are around. That's why they do these sorts of things. But otherwise, make sure it's not a tax. It's like, oh, it's a presentation.

I have to give to a bunch of people to get approval for my thing, and I'm just wasting time. So that's one way I think you can fail. Yeah. Arnie, maybe along those lines, what sort of frequency of meeting, which we just talked about, How long should one of these meetings, you know, in general? And then what's sort of a framework of how to think about the meeting to get the most impact? What you, maybe to all of you, what have you found maybe the most impactful meeting you've ever had? What does it look like?

The way I tried to structure mine and, you know, I sit on other advisory boards now, so it's interesting to see how they're structured differently. But what I really needed was advice. not just for me, but for my technical leaders to hear and a decision. In a lot of cases, it's why you actually put this meeting together. It's not to present something and get approval, but it's to debate a point and to debate something that is worthwhile enough to get all these people, high power people from across the valley or whatever into a room together and make it worth their while, but also worth the while of

the people who are actually within the team to feel like we're moving forward as a company in some direction. And so we would get together quarterly and we would put our agendas together, you know, a month or so ahead of time. And if we didn't have it, we would delay until we had something. And, you know, eventually, you know, box got big enough to where we didn't need it anymore, right? We actually got to a size where, you know, we had enough smart people and enough of the problems were behind us to where the external advisory board is it needed. So I think, you know, That's one part that became very important for me to understand when are we now just going through the motions and it's no longer actually an interesting exercise or an important exercise.

And it's okay to disband these things if they become, it's actually, you know, people appreciate it. Even though the people in a room have fun hanging out with each other, if there's not real actionable things that have to come out of it, you're wasting everyone's time to agree. Yeah. Pramina, how maybe along the lines of setting up the meeting, how do you decide what gets presented to a tech advisory board versus not? I mean, does it everything? Is it one thing? Does a VP of engineering decide? Like who creates the list and how does that come about?

That's an interesting one. And I think something that I have learned over the course of a few boards, which is, initially, the tendency is you want to present, and you want to kind of get validation. We're nodding, yes, this is good, and is this the right path, and this is the right architecture, but then you realize you're not utilizing the advisor's time well. Most of the people who get on advisory board get on because they want to help, they are passionate about the problem, they want to help shape the future of your company, and so the best is to pick a problem.

statement. Whatever you want to solve. So you think one per meeting? One per meeting is what has worked best because then you give enough time. Number two, give them a heads up on the problem statement so that they can prepare. I have had some fantastic meetings, albeit not one example I have is it's not necessarily a technical problem. It was around how do we justify the ROI of the product to an IT shop? And this. we sent an agenda item, in fact I call it homework, almost like, okay, this is what we are going to discuss. And some of the advisors, customer advisors, had actually done a survey in their organization and found out what were the metrics.

And it was a fabulous discussion because the peer group also exchanged a lot of notes. So they got value out of the meeting, which was nice. And we got an answer to that specific problem. So when we do presentations, we don't get that discussion. So my rule has been, if you are spending more than 10 minutes presenting, you're wasting the advisor's time. Okay. It's very hard to react. If someone wants to do something and they just design a presentation,

designed to convince you that they're doing the right thing, basically you have almost no context, even as an advisor that's coming up frequently, it's very hard to have anything intelligent to say about that. It's much better to get. Here's the question that we're grappling with. Here's some convicts that we have. Let's talk about it. I think it's much easier to be helpful.

And I think that's why you want to have diversity of experience and personality on the board as well because that conversation is where the magic happens. And so what happens if you have vocal advisors, and so this is also where it goes back to the point about refreshing the board every couple of years because I got advisors on that seemed great on paper but didn't contribute. And so I would have loved to refresh, but I didn't realize that I should probably put something in my clause to do a refresh, so they stayed. But where you really have to think about as just quickly and as deeply as possible set the context and just let them at it. And so they'll pressure test each other. And eventually what comes out of that is something that whole

Hopefully it's quite insightful for the problem. So, Alex, you before related to this had mentioned write down what you want to get out of this thing. How do you choose, how do you think, you know, what's your advice for choosing the right members of an advisory board? How should somebody, maybe we can all jump into that, but like, how do you do it and how do you find the folks and, you know, to get enough diversity versus all similar? I mean, what do you think you've sat on a number of these? That's a great question. I mean, it's not dissimilar to hiring. I mean, I suppose it is a form of hiring.

I think I've only ever sat in ones that I've been introduced to from people that I know. Either I know the founder or something or they know someone that introduces me to someone. So I think, honestly, like tapping the network of, if it's other A16C companies or other companies you know, is the way to meet people. And generally, I would just go meet the people for a coffee or something,

maybe even give an exam, much like interviewing, giving real problems that you're working on is, is one of the better ways to understand, get real signal from people. So I would just talk about where the company is, why you're putting it together. Some of the things you're grappling with and see if you feel like you walk out of the coffee smarter. And if you do, that's probably a good signal

and you get along in some other things. If you don't, maybe you should keep looking. Cool. The other guys on... Yeah, I think you have to tap your network and your extended network. Yeah, I brought a couple of people that I knew personally and then there

the rest of them were second degree connections to someone and the beautiful thing about this valley is you can actually create a board of just amazing experts here that's unlike anywhere else in the world so within your short notice

you can actually have people assembled that can provide you world class advice and you know I think it does have to gel as a group to where you know it's all personalities, sometimes pretty big personalities, and you have to also make sure that one person isn't going to overshadow everyone else's point of view. And so, you know, that's where, you know,

the harmony of the group, you know, needs to be adjusted sometimes. And so sometimes when you do the coffee shop thing, you can see if this person is going to be, you know, bull in a china shop or, you know, someone who's actually going to really participate, you know, in the way you would want to, from whatever it is that you're trying to establish. Yeah, I would say almost you always, you have to meet the advisors. Of course. That is given, and you have to spend some time with them. Many times it is through introductions, so you may not know the person from before.

I've also, another thing, just I think back to what Alex said, what is it that you want to accomplish? So in one case, we needed expertise around security, and it was from different domains. So in terms of thinking about the composition, it was not just, okay, go and get which were security experts you can find, but it was how do you get security experts who have worked in different domains, maybe the financial industry, maybe the healthcare industry, and they bring in different perspectives. And so the board then has a balance for what you're trying to go after. Are there any maybe open for any of you?

unexpected outcomes, things that you might change going forward. Like, what did you, you know, maybe what do you learn and how would you, how might you do things differently, given the advice here? I would say one unexpected outcome on the positive side. Yeah. You come over, come over the course the advisors become friends of not only the company, but also you make personal friends. The other thing is on a positive side. unexpected outcome, that was not the stated goal, many of them ended up giving referrals to other deals as well as really helped in some of the hiring decisions.

I didn't, that was not my stated goal at all, but we were looking for some technical experts and they had access to the pool. And we didn't even think of asking the team, but it was just at the end of a meeting, we were saying, okay, we have a problem here. And then the advisory board sent us recommendations of people that we were able to hire. Alex, were there, or either of you. For me, you know, what was really cool about the board and just the people that I was lucky enough to get on it is, you know, not just getting technical advice out of them, but they also became, in their own ways, mentors for me in certain situations. So it wasn't always about technical opinions.

You know, these guys had all traveled down the path that I was going down before me. And so, you know, things like, like how do I do org structures? You know, I've got a group of people that all want the same title. But then I've got another group of people that want to be promoted to principal engineer and architect. And, you know, I don't even know if I want an architect role. What did you guys do at Facebook and Google and, you know, stuff like that? that's not really the role of a technical advisory board but super important conversation to have

as you're scaling company 10X within a short period of time and trying to keep a culture intact. And so having someone that I can actually do a heart-to-heart with around some of those things was really, really important. I found it was interesting how you try some things which at the time seemed right and then you learn in retrospect they weren't right and you learn from it and then you oftentimes forget that you once didn't know that

So actually, sometimes when the meetings that I felt best about, I actually feel like you can be very helpful by just sharing, like, hey, here's the stupid thing I did, the time seemed reasonable, and I think you're about to do that thing, and you can explain it. Some fraction of the time they actually listen to you, and it's kind of nice, so I think that's productive. And I would second the thing about hiring. I mean, everyone good, I know, of course, I try to hire a Twitter.

But, you know, Twitter's a certain-sized company. They're bigger company, smaller companies, and it's not the right fit for everyone. And so I'll often refer either people I was trying to hire or people that have just left because it's been years and years and they want to go to something else and I'll know they want to go somewhere else.

I'm happy to send people around to other places. So I think it's probably... It's interesting. You had the same experience about hiring? Yes. Because, I mean, why not? Unexpected, albeit? Yeah.

But it was fantastic, yeah. So, Per Nima, how do you think maybe from a CEO perspective versus a VP of Engineering perspective? Like, how do each of those different folks view a technical advisory board? And maybe, you know, how do you normalize that? Does the CEO typically go to the technical advisory board meeting? Is it the VP of engineering?

And what do you think each expects out of it in that sense? And I guess there are, in listening to you, I've realized there are, I think, even the technical advisory board can have multiple flavors. And so the situation where I talked about, there was a customer advisory board and there was also a technical advisory board within the same company. From a CEO perspective,

the customer advisory board, the biggest one is validation of the problem statement, especially you're building a company, you want a layout, okay, this is the pain point I'm trying to solve. Is this real? Will it resonate with you?

Will you pay if I build this? Will you pay if I build an extra set of features and so on? That is where direction as well as, I would say, I would not be shy even presenting marketing materials to them because they are going to be the ultimate consumers. But on the technical side, it's not just for engineering.

I found it was very valuable for the product management folks because these decisions that you make on architecture should, okay, I'm going to put it on a SaaS and do multi-tenancy. How should we do that? And should we have separate data structures or should we just do it all pooled has huge implications on the other requirements that you may have. So having product management team,

I've always had product management team also drive some of these meetings on the requirements. Great, great. Orney, what are the characteristics of the best tab member that you've ever worked with? Other than Alex, character. Yeah, I think... Second best.

Second best. Being able to quickly grab. the context of the problem, right? And so, you know, this 10-minute rule, I think, is a good one. So, they're coming in cold. You know, they don't understand the six months of conversations that have gone on in the halls or, you know, in front of whiteboards. So you've got to give them some context.

So the best ones will get the context and pattern recognition and pattern match against, you know, a problem that they've seen in the past. And then, more importantly, I've had some experience to say, like Alex was saying, And hey, you're about to do something really stupid. I've actually done that stupid thing, and it worked out this way, and here's how not to repeat that. And so the board members who can actually articulate that in a way that fosters debate, but then gives clarity into a direction or down in direction to get to an answer are the most valuable ones. So the ones who sit there just ingesting information but never giving back any energy,

are the ones that, you know, just end up being somewhat useless. Yeah. Yeah, okay. And Alex, what's, you mentioned wanting to help the company as being, you know, your interest. What's the other, you know, maybe some other values of being a technical advisory board member to the advisor? To the advisor. I mean, I personally find it interesting. You meet smart people that are working on different problems.

it's nice to feel like you can occasionally be useful by having people avoid the dumb stuff that you did. I mean, those are the main things, I think. Okay. I think that kind of maybe the flip side of the question you asked him, I think the best arrangements are when the company's just super, not too formal about it, just really honest about what they're, instead of, oh, I have a technical advisory board meeting next week,

oh, shoot, like I have to think of an agenda, and now it's a to-do item. I think the more it's just around, I'm stuck on X today, so I want to go talk to some people I trust about X. And it can be right down the middle of what a technical advisory board is for, or it can be a little, you know, you mentioned product management, or it can be around, well, you know, we just promoted an engineer to be the VP of engineering, and so they've never done management before.

So how do you help with this case? I think just the more it's about real-world things that they're struggling with, the more you can actually be useful. How do you compensate a technical advisor? Maybe, or any of stuff? Yeah, so for me, it was pretty straightforward. I just gave a stock option package that was equivalent to a seasoned engineer. And, you know, I put my board together pretty early on in Box's life.

So it ended up being a pretty reasonable package at the end of it all. But it was, I think, a three-year vesting period, so accelerated over what was generally a four-year vesting package. It was all stock option-based, equity-based. I did the same, all stock option-based except I did a two-year term. I wish I'd talked to you before that. That's a great idea. Two-year term and then renewed again. I've seen the same thing.

Okay. How I've seen quite often when I've set up customer advisory boards, which may be slightly different, all your advisors work at companies. And often there's an ethical dilemma of, like, if they're a potential customer, and I pay them stock options, and I want them to use my product, like it's, you know, one hand feeds the other, and it's a little bit of a bribe, and, you know, then you want them to go and recommend the company to investors and blah, blah, blah, well, you know, I mean, that's what happens.

Yes. So, you know, how do you sort of deal with that? And if a company doesn't allow, you know, if a company may not allow it, how do you get around that, or do you just say, no, you know, we're not going to do it? I mean, kind of maybe just speak to some of the potential ethical pitfalls there. Actually, I have had a few situations like that. Yeah. And you have to be careful twofold.

So one is a simple situation where you can, you want someone as an advisor. They may go and ask their company. So my example was I was trying to bring Kumud, who was from Intel on the board. And Intel has a very strict policy that you cannot accept any. So after a lot of back and forth, she still wanted to be on the board and provide advice, but had to sign an agreement with Intel, and we had to sign an agreement with Intel that in no shape or form we will be compensating her with any stock. Okay.

That's one form of, but that was kind of something that we... And she ended up serving on the board, yes. For, I mean, for two years. Basically for free. For free, yes. The second one is a very interesting one that you brought up, which is someone might sign as the advisory board member. But let us say you actually want to sign that company on as a customer data.

Right, of course. It can really hurt you because it has happened to me once where I signed on someone as an advisor. And then when the con, we had a completely separate sale. So the advisor wasn't really in part of the approval chain. But when it went to procurement, they came back and said, you have this person on the advisory board. You cannot do the deal with us. Wow. So be very careful.

So now, actually, the third time round when I did it, when I wanted some of them as advisors, some folks I had as informal advisors, still I sold the deal. Once I sold the deal, then I brought them on as a formal advisor because having gone through that. So those are the two variations. And maybe just along these lines you're on some of these boards. Do you ever find that the company,

along this ethical sort of boundary, the company is asking you to promote the company too much relative to sort of what's really happening? I mean, do you get into like that weird sort of, you know, like young companies, they have a series, an investment round coming up and they're like, hey, Alex, you know, like the investors are going to call you. So we'd be happy for you to give us, like, a great story. You know, I haven't had that happen to me? Well, what if they did? Yeah, I think of that. Yeah, I thought you might say that next. Someone would just be up front. I mean, I would just be up front. I mean, first I'm an advisor.

I mean, generally people don't do these things for the money. I mean, I guess it would have been nice to join the advisor board on box. I should have thought about that. But, like, in general, you don't do it for the money. But you should be like, look, here's my relationship with the company. Here's what I think about the company. Okay. In the way that, you know, you often probably, you guys get reference calls,

and not every reference call you ever get is for, you know, the best person you've ever known because it can all be one of those. So, you know, you just, like, handle it. You don't lie either way, but I would say, you know, all the people that were on my board weren't doing it for the money. They would have done it for free, you know, if it was a conflict of interest. And, you know, I would say 60% to 70% of them came to me after each one of these, like, oh, this is like the best, you know, four hours of my quarter because I get to actually be out of the operational, you know, just craziness that I'm in and see what, what someone, I don't have to live with. the consequences of everything I'm talking about. That's why I do.

My job is awesome. It's expensive advice. There's a duality of what's going on and who's getting what out of it. Well, thanks you guys.