The moment you have somebody who is responsible for process only, you get to the point where
you have too much process and these people's jobs are dependent on running the process.
So it's not in their best interest to drop the process if it doesn't deliver the value.
It's not in their interest to simplify the process also.
It's in their interest to increase the process.
Hello, hello, hello.
Welcome to episode 37 of the Metacast podcast.
Here we have Ilya and me, the co-host.
Today it's a metasode where we kind of reflect on the last episode and go through some of
what we're reading and listening to and all that.
So it's going to be a bit light.
We'll try to keep it short also.
Yeah, we'll make it light and enjoyable for ourselves in the first place.
Yeah, that's the only way to make it enjoyable for others is to make it enjoyable for yourself.
Exactly, yeah.
And also, we are recording another episode later today in about, I want to say, four and
a half hours or so.
We will have Karl Ulrich, a Wharton professor who teaches innovation, entrepreneurship and
other things.
And we are going to talk about, can you teach entrepreneurship to MBA students?
And also, one of the topics I'm really interested in is, what is the value of MBA right now?
Like, is it worth doing an MBA?
So I'm really, really excited for that episode.
I've not talked to Karl for eight years at this point, and I'm really looking forward to
reconnecting.
Cool, cool, cool.
All right.
What else are we going to talk about in this episode?
As usual, things that we are improving this time.
We want to reflect on the latest episode that we've just released today, actually, episode
36 with Melissa.
So yeah, we're recording this on Wednesday, September 20th, and it will come out a week
later.
And it's a historic day for us.
Like you said, it's the first time we're recording two podcast episodes on the same day.
Yeah, it's going to be a podcasting marathon.
Stepping up the content creation.
Yeah.
Yeah, so we're going to reflect on that episode.
It was a great episode, but there are some things that we're not sure about, actually.
And that's why we wanted to just chat about that.
Also, to make it really light, we're going to talk a bit about the things that we are reading
and listening to right now, and just share some thoughts and some recommendations.
Yeah.
And if that time permits, we want to thrash threads a little bit.
That app that had a lot of premise, but doesn't seem to be delivering.
All it's delivering are notifications.
Right.
Yeah, the infrastructure works perfectly.
So the things that we want to improve, right?
I'll start with the episode 34 that we did, right?
Or 35, when it was just you and me talking.
We wanted to chat about all the tech that we are using and talk about our love and hatred
relationship with the Google products.
And then we ended up talking for like 25 minutes about...
I don't even remember what we were talking about.
What did you talk about?
I don't remember either.
But I remember that we were running out of time, but it was hard to maneuver it quickly
into the other thread, yeah.
Oh, we were talking about positioning.
We were talking about positioning and how people think we build a podcast while we are building
a podcast app and how we said we would repeat this ad nauseum that we are a podcast technology
company, not a podcast studio kind of thing, right?
And we also came to the conclusion that this podcast is less of a marketing channel because it doesn't
really help us drive awareness as much, at least not yet.
But it's more of a user radio.
Yeah, community engagement channel.
Yeah, where people can, you know, see what's behind or who's behind the app and get connected
to us, actually participate in the process of creating the app by giving us feedback.
We could discuss it in real time, you know, when the app is public and all that.
But I was also thinking about when we first started the podcast, we were thinking about
recording live streams.
I think right now the size of our audience doesn't really allow for that.
And also, I guess the utility of that will be minimal.
Well, wait, wait, wait.
So I think this is a good time for an update.
How many people are listening to our show now?
Have you been looking at the metrics recently?
Yeah, on the podcast downloads, like specifically in podcast apps, we get 100, 150 per episode.
We get more on some of the guest episodes when it's just you and me.
It ranges between 1940, I think, depending on the topic.
So yeah, it depends.
But on YouTube, we have been getting a lot more views recently.
And the newsletter that you started, you moved it to like talk about the innards of the company
rather than the podcast.
And I think that's getting a lot of like new subscribers and people reading it.
Opening rates and all that are much better now.
Right.
Yeah, we have, I think, 298 or something subscribers to the newsletter right now.
It's almost 300.
Hopefully, when I post the next newsletter, we'll get some more and we'll cross the 300 threshold.
Yeah, so that's been going well.
I think on LinkedIn, I've reached 7,500 followers right now, which is actually really great because it gives that a lot more reach to anything that I write.
Like previously, I would write something and it would maybe get like 1,500 views.
But now, because I've almost doubled the number of people who subscribe to my updates, like my latest post from Monday got 15,000 views, 340 reactions.
So, and I keep getting kind of new followers every day, like 10, 20.
Thanks to you, I also keep getting, like you post and tag me.
I don't do anything on LinkedIn or any social pretty much, but I keep getting like random people or not random people.
Very, very appreciated followers following, yeah.
So, yeah, so this has been going pretty well.
I think it will take time to build up the audience, but I think it's been going pretty well.
But coming back to live streams, I think once we have our app in public and people are using it, I think live streams could be a great opportunity to actually have people connect, join in, ask some questions, offer some feedback in real time.
We'll probably not let people like talk because there will be random people there.
Maybe we will, I don't know.
But yeah, at the very least, they could just say something in chat and we can address questions directly.
And then anybody can listen to that a week later when we publish the podcast.
So, but I think for that, we need to have at least five to 10 people ready to join the live stream.
I don't think we're at the point where we could get five, 10 random people, yeah.
So, coming back to the randomness of the previous episode, right?
Yes, before we go to random now.
Yeah, it was half about positioning and social media and all that stuff and half about technical stuff.
So, like, if that's the only episode you listen, you'd be like, what the hell are these guys doing?
It's just like so random.
So, yeah, I think we need to try to stick to a topic.
If we have a topic, we should just try to stick to that particular topic, maybe with a little bit of updates.
Yeah, and then we have an episode like this where we just like chit chat about random stuff.
Yeah.
Okay, so before we chit chat about too much about random stuff, let's make a move.
So, that was the first thing we want to improve.
The second one, I think you also wrote that one.
Yeah.
So, as I was listening to our episode 35 and 34, I'm like, I don't like how it sounds because some of the dynamic of the conversation gets kind of...
There are some sounds that got swallowed by the sound effect and that's a thing called compression.
So, it's like if something is too quiet, then you amplify it.
But if it's something that's too quiet, then it actually might get just cut out.
And then you end up with like unfinished words.
Or they sound like unfinished words.
So, this time I decided that for this latest episode that I will not use compression.
It's kind of, I guess, a bit of a heresy in this world.
When you say latest episode like this one that we're recording right now or last week with Melissa?
Melissa's episode.
Okay.
So, 36.
36.
Yeah.
So, I said not use compression at all.
And I think it came out just great.
I was just listening to it in my car and I think it sounds good.
And the dynamic is so much better.
I haven't listened to the latest one yet.
I didn't get that feeling.
But then again, you always have a much more like, I think, tuned in audio receiver inside your head than I do.
I'm a perfectionist, you know?
Yeah.
And I felt like I kind of screwed up that a little bit in the previous episodes.
And I'm like, instead of just trying to fine tune this compression thing, I'll just get rid of it.
And it actually sounds good.
I think where compression is really good is like when you move around the microphone a lot.
But because we don't, then we speak in pretty much stable volume most of the time.
So, we can just amplify the volume of the whole thing to the level it's supposed to be without having to use all this sophisticated sound engineering stuff.
Where do you do this?
Is this in Descript or Isotope or something else?
Oh, it's actually a good question.
I stopped using Studio Sound in Descript.
It's not good enough.
It used to save you quite a lot of time.
It does too much, I would say.
And then it also applies compression.
You can't control it.
Then sometimes you get like echoes.
I had the chat with support.
They know about this bug, but it's still not fixed.
And I'm like, just screw it.
So, I'm importing this thing in Reaper anyway, in the digital audio workstation.
But I already have all of the presets from the previous episode.
So, basically, I just like insert the new files into the old preset, hit export, render, and it's just done.
But for the video that we put on YouTube, you're taking it from Descript.
I'm taking it from Descript, but I don't apply Studio Sound anymore.
I just apply a volume normalization thing just to make sure that all of our volume is the same.
But I don't do any of those effects.
I feel like it sounds more natural.
So, yeah, Descript is not there yet.
It's very hard to like take this audio output that you did for the podcast and overlay that or merge that with the video, right?
For YouTube.
Yeah, maybe I just don't understand the technical stuff enough.
What I'm seeing is after about 20 minutes, there starts to be a drift between video and audio.
And then it just doesn't look well.
And I'm like, screw it.
I'm just like, we are not at that level of popularity to care about this kind of stuff.
So, yeah.
Right.
Okay.
And then the last thing I wrote down for improvement, this is actually a recurring thing.
A few episodes back, I don't know when, we said every time we have a metasode, we'll talk about what we're reading and listening to and all that.
And I think we did that in that episode and then we didn't do it again.
Let's start it with today's episode again.
What brought that about was I was listening to a really interesting podcast and I was like, okay, we have to talk about this.
Yeah.
And what we know from our user research is that people discover podcasts mostly from recommendations on other podcasts.
For me personally, I think it's true for many books that I read.
Let's talk about the latest episode.
Yes.
So, that's the episode 36 with Melissa that we had last Wednesday.
It came out as you're listening right now.
We're recording on Wednesday, September 20th and it came out today.
But yeah, as you're listening, it came out like last week.
Right after the recording ended and we said like thank you and bye-bye and all that, you and I, we dropped.
I think we dropped.
And then I messaged you and like we immediately hopped on another call and we had this discussion that we need to talk about this in the next metasode.
Because, okay, this is where you take over and do the hard part, yeah.
First of all, this was an amazing episode.
I listened to it after I got the edited version back.
I listened to the whole thing.
I really enjoyed it.
I was listening to it again in the car this morning.
It's a great episode.
I think I personally learned a lot from it in terms of like social media stuff and also just the mindset that she was talking about in terms of working with development shops, contractors.
Because we thought about contractors, but we didn't really talk to anyone.
But this was like, okay, she gave us a lot of information to process, which was great.
You can totally accelerate your like product using that, yeah.
Yeah, yeah.
And I know actually people who work for companies like EPAM and other outsourcers over in Eastern Europe.
You know people in India, right?
It's like we actually have the contacts.
And I think she helped us really better understand how we could use that in the future.
So where I think you and I had concerns is the part where we were talking about equity split and specifically giving equity to kind of co-founders and the difference between the CEO and CTO and how it cannot be an equal split that CEO gets more, all that stuff.
I think Melissa has a certain position there, right?
She thinks a certain way that CEO should get more because it's all kind of business and CTO like doesn't contribute as much because business is not just a product, which I think is a fair position to take.
It's just not how we think.
And the reason why you and I were talking about this episode is by not challenging, by not arguing with this, it almost feels like we are accepting this and kind of endorsing this position, right?
Whereas we don't.
And I think what was not comfortable to me in the moment is when people come to our show, I want them to look good.
I don't want to argue with people.
I don't want to challenge them.
I just want to have like a nice, light, friendly conversation, right?
But at the same time, this does not represent our way of thinking.
And I don't think we made it clear.
And I think that might be okay.
I was thinking about it afterwards too, where everybody's going to have different perspectives.
You're not going to like talk about everything about we are going to ask this question and you're going to tell us what are you going to tell us before and all that before we hit recording.
And like you said, it was a great episode.
And it's a valid perspective, like you said.
It's just not the one that you and I also agree with.
And I have no problems with that, right?
With the perspective itself.
I think the uneasiness that I was feeling was how much do we push back on it during the episode recording?
And if not, how do we like talk about this after?
And it was just like, while you're interviewing, you also have to listen to what she's talking about.
You have to think about what you're going to talk about next.
And there was all of this going on in my head at the same time.
So it was a bit hard to like manage the episode for me.
We didn't want to argue or like start a debate on an episode.
And we did ask some, I think, follow-up question, nudging or trying to understand her viewpoint more and more.
And I think we did a good job with that.
But like you said, we didn't have an avenue to like clarify where we stand on it.
And that's why we thought, okay, this is perfect for a metasode reflection.
So that's what we're doing now.
Yeah.
And I think this is a more generic point that we're bringing up right now, right?
What if our guest says something that, you know, we think differently about.
How do we deal with this, right?
And, you know, one way is just like what we did last time.
We just say nothing and then do reflection like this.
But I think what we could have done is we could have just said like, yeah, we actually have a 50-50 split, which I think we said, right?
And maybe we could say that, you know, we just think about this differently and we kind of appreciate your perspective and our perspective is different.
But yeah, and our next topic is, and don't dwell on it, just like move on, right?
But I wonder how like people, let's say like Lex or Joe Rogan, how they, actually, I want to listen more to that to see where they have guests that have conflicting kind of positions to theirs and how they navigate this.
Lex has some great episodes on this, yeah.
I mean, obviously he does a great job asking follow-up questions.
I don't know how long they record for because the published episode itself is like four and a half, five hours.
Oh my God.
I think he hangs out with his guests for the entire day and then they record.
Yeah.
So I think talking about the episode itself, I think after the follow-up questions, I understood the position that in their company, the CTO came in much later,
like a year after, like a year after, and I think it's a very different CTO, CEO role than what we are doing.
Or in fact, what we did even in AWS was very different from what she was talking about, where the CEO, or if you will, the product manager or GM in a big company,
or a CEO in like our size two, three people company, very soon to be three people, by the way.
The CEO is the person making all the decisions, looking at the strategy and how to change, how to bring that strategy about into a smaller step roadmap, how to look at what you have delivered, iterate from it.
And what's the next step and what's the next step and all that, right?
And if I may like kind of try to paraphrase what she was trying to say to her, the dev team or the CTO was like,
I am the person, the CEO is deciding all of this, the product, and you're the one implementing it versus in the way that you and I work.
And this is the same way we worked in AWS.
I think most engineering teams in like AWS were like this.
It's much more of a partnership.
The engineering team, the UX designer, the product manager, they all work together to define what the product is.
They all work together to understand how people are using the product and how to refine it and all that.
While the product manager is the person in charge of like laying out the strategy and breaking that strategy down into what are the next chunks?
How are we going to go about it?
But they do that with a lot of collaboration with the engineering team, UX designer, and lots of other roles in there.
Yeah, I think the different framing here is, I don't know if I'm correct or not, but my perception is that I think Melissa comes from a more traditional kind of business background.
And she approaches a technology business like a traditional business.
So there is a person who is an entrepreneur, and then this person hires people to implement their ideas.
I think that's how pretty much probably most businesses work, except for kind of deep, deep tech startups, right?
Whereas I think we've cut our teeth in tech, in Amazon in particular, right?
Where the product itself is so sophisticated technologically that you can't just come and tell engineers what to do because it's just too complex.
And you have to work in partnership, like you said.
And I think also, both in Amazon and in Google, PM is an engineering function.
I think Amazon is kind of, I guess, maybe a bit of a gray area.
But in Google, they have different ladders.
There is an engineering ladder.
Not ladder.
Oh, man, I forgot how exactly they call it.
But it's like PMs are part of the engineering group of roles.
Actually, design is also part of the engineering group of roles.
Whereas marketing is its own kind of business function or some other kind of vertical, right?
In Amazon, too, wasn't there like a PM technical and a PM like external services and something like that?
And a PM that you could have, let's say, in Amazon Books or Amazon Business.
That doesn't have to be technical.
Actually, you're right, yeah.
And at Amazon, PMs tend to eventually report to an engineering manager or engineering director.
Or it could be a product director.
But still, it's not like these are two parallel tracks.
They all converge at some point at like level 7 or level 8.
And they would be like either a senior manager or director of engineering more frequently or like a product director who also has significant engineering chops from the past.
Usually, that's how it happens, right?
But I know what you mean.
Like in the past, when I worked at a bank, too, it was more like the traditional approach.
It's like they come like, here's the work to do.
Like do the work.
Yes, yes.
Here's the business people.
They will write out like specifications and like this is what requirements.
And the engineering team goes and builds it.
And I hated that, which is why I'm here now.
There's no partnership, yeah.
So actually, somebody asked me about like whether Google or Amazon has a business analyst
or system analyst kind of function.
Basically, a kind of function that transforms requirements from business into technical specs, right?
And I told them that, in my opinion, in the product organization where you like build a product, where your business is a product, having an analyst like this is a dysfunction because it's like a proxy.
You have to have your product manager who is kind of on the business side and your engineering team who is more on the technical side just work together in partnership.
And basically, that kind of analyst function just gets shared.
You don't need that proxy.
By the same talking, project managers are a dysfunction, in my opinion, like in small teams.
Let's say a team of 10 and you have a project manager, that is a dysfunction because projects are managed by individuals on the ground, right?
Same with like Scrum Masters.
Like the moment you have somebody who is responsible for process only, you get into the point where you have too much process.
And these people's jobs are dependent on running the process.
So it's not in their best interest to drop the process if it doesn't deliver the value.
You know what I mean?
It's not in their interest to simplify the process also.
It's in their interest to increase the process.
Yes.
Yeah, and hire like an assistant project manager to help them with that process.
Yeah.
I mean, you and I clearly, we subscribe and we've been like molded or influenced by the Agile Manifesto and Pragmatic Programmer, those kind of books and all that, right?
I totally agree.
Like if you need a person to translate what the product manager and the engineering teams are saying to each other, then neither side understands what the other side is doing.
Yeah.
And I think this is probably what Melissa was describing early in her career when she did not have somebody technical like on staff.
She was managing the contractors herself and that was difficult.
Yeah, because I think she said something like, I expect you just tell them what to do and they give you a deliverable and it just wasn't working because software is kind of a bit different that way.
It's very similar to construction or like renovation kind of projects.
If you've ever done even the simplest things in your house, like I had like gutters installed in my house.
It's a very simple job compared to like building something or I don't know.
To be fair, I think even in software, there are probably lots of places where you do need that it is so complex that two sides, the product side and the engineering side, or maybe there isn't a product side at all.
Or maybe it's business and engineering, don't know how each other work and you do need a person.
We are in a bubble, but we also prefer to live in this kind of a place where you build things together in partnership in a way that you understand what the other person is doing and how it works and all that.
Yeah.
Actually, sometimes people ask me like, should the product manager code?
And my answer is always no, but if you take a course, let's say in Python, like spend just, I don't know, 10 hours in this, right?
And you will eventually, inevitably be in a situation where you bang your head on a wall trying to fix a bug that's supposed to be not there, but it is there.
And it ends up being like some very simple, stupid thing, but it takes you like a whole day to figure it out.
And that's what your engineering partners are dealing with every single day.
And when you do this yourself, just as a course, you will build empathy as to like why software engineering is so hard.
So like you don't have to code, like do your job, but like to build a relationship, yeah, spend a few hours.
I think Melissa said something like this too that I really liked was, it's just move this button from here to here.
Why does it take so long, right?
Oh my God.
I mean, it's a bit of a detour, but I've been coding all day on Monday or Tuesday, when was it, right?
In Flutter.
And because it's this asynchronous model of programming, which I never really did before.
And also like Dart is new to me, like Flutter is new to me.
Like, I guess I know enough to just be able to like write some logic, like figure things out a little bit here and there.
But it's very slow, right?
Because some of the concepts, they just don't translate from, let's say, C++ in the Dart, right?
Or in the Flutter.
And I've just been banging my head on the wall.
And well, I've done more refactoring than coding at this point after I like see APR and you're like, okay, do it here, do it there.
But there was like a very simple thing that I needed to do, which would have been like super simple in any other language.
I just need to initialize the initial state.
I'm still not sure if I actually have understood how to do it.
It's not the language.
It's because of the asynchronous model.
The reactive model, that's what's making it hard for you.
Because you don't understand.
The thing I would say is when last week you decided, right, that this is the thing you want to work on.
And I told you, right, like, okay, there's going to be a lot of new stuff because there's UI work and like asynchronous state changing and all that.
And you actually did a way better job of picking it up than I thought.
I thought it would take you like at least a week to wrap your head around like what's happening where and how the state is changing and all that.
But you had like after two days, you were like, okay, I have a banner showing up here.
And I was like, wow, that's cool.
Yeah.
Yeah, that's what I mean.
Like, I guess I know enough to be dangerous because of all of the past experience.
But yeah, let's say like if you are new to programming at all, like zero, I would say like picking up something like Flutter, that would just like completely.
That would be hard.
It would be very hard, I think.
Yeah.
But I think the other perspective on this is you don't need to be coding as a product manager.
But if you do know the basics, especially something like Python or some shell scripting, something like that, you will start to realize how many more things you can accomplish just by yourself rather than waiting around for like an engineer to do.
For example, in the last eight years that we've worked together now, there have been many instances where you would like go script something up yourself or take the data and run like a Python script or do some regression analysis and all that.
And if you had to wait for like an engineering team to do all that, those things would never get prioritized.
And I think this is where you don't need to be coding to push code out into production, but you need to know what's happening and that'll make you a much better product manager.
Also, if I ask you to do that, like some of those scripts, you would have done it in a much less hacky way than I did.
Like what I did in half a day, you would probably spend like a week doing, it would be like bulletproof and all that.
I'm necessarily bulletproof, right?
And then for me, it's like, I just need to get the job done.
I don't care if it fails every second time.
I can just restart it.
So I can afford to do it at a much lower quality than somebody for whom it's like a full-time job.
Anyway, so what are you listening to our number right now?
Because we have five minutes left.
Okay, so I wrote this because Walter Isaacson, he is a author who has written a lot of famous people's biographies.
Steve Jobs is a good one.
Steve Jobs, Albert Einstein.
Ben Franklin.
Ben Franklin, yes.
The latest one is the Musk one that came out.
However, I'm not reading the actual book.
That's going to be more like a project for me, I think.
It's a pretty big book, right?
I mean, his books are like a thousand pages.
Yeah, and I really love the Steve Jobs one.
So I really want to read this one.
But it's going to take some time to get through it.
So instead, I was listening to...
Lex had an episode with Walter Isaacson recently talking about this and many other things.
It's four and a half hours.
I listened to about an hour of that.
And the hard fork, New York Times hard fork, they had a really awesome episode about it this week.
I just listened to it yesterday.
The thing for me from this is, like many other people, I also was like in awe of Elon Musk.
Something changed in him recently, right?
And this book...
Well, I haven't read the book, so I won't go to say this book.
But from what I heard about Walter Isaacson talking about Elon Musk and about the book in these two podcasts, it tells you what changed and why that changed.
And I think it's going to give me empathy for Elon Musk.
I think it's hard to be Elon Musk.
It's hard to be Mark Zuckerberg.
I don't think it's easy to be any of these people.
But I think it goes into...
Like, we know that Elon Musk is very mercurial, right?
He has mood swings all the time.
He is often, if not often, sometimes very cruel to people, publicly or privately, inside Twitter, inside SpaceX, or sometimes on Twitter itself.
It almost feels like he's up for a fight.
But this book tells you his personal relationships growing up as a boy, what kind of led to this darkness in him and how he tries to understand the darkness.
And sometimes how he uses the darkness to, like, produce something amazing.
Yeah, it's interesting.
I want to read that book.
Yeah, I have this episode also on my list.
I need to listen to that.
I'm really interested in listening to the book because what Walter says at the end is he asked Elon Musk not to read the book.
So I'm really, really curious how this is going to end.
But if you don't have time to read the whole book, I would say listen to the Hard Fork episode.
That'll give you a really good, like, synopsis into what's going on in Elon Musk's head and what has led to it that he has this kind of, like...
It's like different personalities altogether.
Yeah, so we do have to wrap up.
We have a meeting starting in 30 seconds.
So therefore, we are not allowed to overrun our recording time.
But maybe we'll just spend a couple of minutes in terms of, like, listening and reading stuff.
Because you mentioned darkness.
About a month ago, I re-watched the entire Star Wars feature movies.
I think it was nine or ten movies.
I started from the very first one, 1977, and all the way until whatever.
I think Rogue One was the latest one.
You watched them in the storyline order, not the release.
No, I watched them in the order they were released.
I'm like, if I was, like, 60 years old, and I watched this thing for the first time when I was, like, a child, right?
Well, not a child, maybe, like, an adolescent.
How would I perceive the entire story?
Yeah, so you started with episode four, yeah.
Episode four, yeah.
And I think the first three movies came out with, like, three years difference or four years difference between them.
77 or something, yeah.
Yeah, 77, I think, 80, 83.
I was born in 83, so I did get to watch them in the release order.
But then I think there was a break up until, like, late 90s, I think.
But watching them all in sequence within two weeks gave me a lot of appreciation for the story and for the world-building skill of George Lucas and, you know, other people that were involved there.
Also seeing, kind of, the actors, like, I forgot his name, but the guy who played Luke Skywalker in the first movies.
And he was also playing himself, I think, in whatever, The Last Jedi, I think, was, episode eight, I think, where he is a much older gentleman.
He was, like, 20-something in the first movie, and then he was, like, maybe 60 or something.
So, yeah, it was very, very interesting, very touching.
But also, they have a lot of, like, interconnected things in the movies that if you watch them, like, with a three-year interval between them, you may not notice them.
But then you watch them, like, the next day, even though there is, like, a 20-year gap between the movies, they make a reference, and you, like, you get it right away.
And, oh, my God, like, I love this whole thing so much.
I gained a lot more appreciation for Star Wars.
I'm a big fan.
And, yeah, I just want to wrap some feathers.
I tried to watch Star Trek.
I didn't like it at all.
Same.
But to me, I also don't like Star Wars, episode one and two too much.
Jar Jar Binks, those ones, they're, like, so hard to get through.
Yeah.
Anyway, what I was going to say is we're two minutes late.
We need to drop, but we are overdue for a sci-fi talk episode.
We did one back in, like, episode 7.5.
Like, we released a bonus episode.
This conversation makes me want to do another one.
And there's so much to talk about recently.
So, yeah, let's do it sometime soon.
Yeah, absolutely.
All right.
So, we got a wrap-up.
It's a chicken wrap.
Or dinosaur wrap.
Yeah, you'll have to link in show notes to make sense of what you're talking about because I don't know if most people will go to what dinosaur rap you're talking about.
Yeah, anyway, it's a wrap and at least episode 35 for more details about dinosaur raps.
Yeah, bye.
Okay, bye.