Episode 04 Transcript

The Main Thread, Episode 4 Transcript

Welcome back to the main thread.
Today,
we're talking about vision and strategy.
How do you as a Staff+ engineer,
establish a vision of the future that addresses a specific business need for your company?
And how do you turn that vision into a concrete strategy to execute? Our guest
Brian Jones has a long history of leading complex technical projects across the finish line at various companies using the techniques
he's going to discuss with us today.
We'll explore setting a North Star, leveraging one-on-ones to build broader acceptance of your vision,
building a canonical strategy document and using OKRs to maintain alignment during execution.
Oh,
that reminds me we're going to drop a lot of acronyms in today's episode.
If you find that you're not familiar with every single one of them,
no stress.
I wasn't either,
but we got you.
We've included a glossary in the show notes for your reference. With that:
I'm excited to learn from Brian Jones and his experience and I'm excited to share that learning with you.
Let's get into it.
Welcome back to The Main Thread
everybody.
I'm your host,
Brian Ogilvie along with my co host,
Alex Gaiser and we are joined today by Brian Jones who is an engineering manager in central security at Meta,
uh,
Brian.
You want to take a couple minutes to talk us through a little bit about your background,
who you are,
how you got to where you are today?
Yeah.
Sure.
Yeah.
My name is Brian Jones,
as Brian Ogilvie just said and I have been in IT for a long time.
I kind of took a,
I guess a bit of a non traditional path in like the Bay area where I didn't go directly to college out of high school and get like a computer science degree.
I actually started working immediately out of high school and in IT for the uh US government in a company called General Dynamics.
And there,
I was like working on a,
like a help desk actually,
like on graveyards back in the day,
I was like,
basically a mechanical Turk.
So I would be sitting there watching like a console as these like tickets came in with various attacks that were going on.
I copy and paste the IP out of the console,
put it into like a whois service,
copy and paste the whois service output and put it back into the console and then send the ticket to the next team.
That was my entire job.
And all I did. From there I moved to like doing desktop support to like network engineering.
And then eventually I started working for the US army deploying like an IT service management platform globally. After a while,
like the contracting game in,
in the government gets really tiresome because you have furloughs every year.
Uh You have like a lot of uncertainty about your job.
End up having to travel a whole lot.
So I ended up like converting to full-time remote there and moving out to California and like going to school where I actually did end up getting a computer science degree while I was like,
still working full time.
And then I guess like a couple of months before I graduated,
I actually got laid off.
So it ended up being a pretty good move.
That was kind of the pivot or the time when I pivoted into info sec when I was working for the government,
I was actually like sort of forced to get a CISSP because when you're like a systems engineer there,
it's a,
it's an expectation.
And so that allowed me to get a job with an MSSP that like one of my boss's daughters was working at.
And from there,
I kind of like started in the Bay Area.
Like my first job was at like a health tech company where they were actually building a pretty cool product.
It was like one of the first medical devices in the cloud where they would do like CT scans,
use them to build like a 3D model of your heart.
And then do some like fluid dynamic simulations on it to be able to like uh measure the pressure in your your heart valves uh without having to do any sort of invasive surgery,
like pretty cool.
So we had to do like a lot of compliance work and like uh SOC work for that uh plant from there.
I moved to a,
a fintech company called Symphony which was doing end to end encrypted messaging services for like financial services companies.
So we built this like big platform that allowed these different financial services companies to trade messages.
They,
they had the custody of their own root keys and HSMs on site.
And there,
I was like the lead security engineer,
sort of like helping to like build the technology running their vulnerability management program.
And then after that,
like,
I actually ended up getting a role at Twitch.
A lot of,
a lot of you might have heard of that one,
a pretty cool company.
Uh very,
very awesome video game culture there.
And I was their uh lead security architect that was like a really new experience because they had a huge AWS footprint with like thousands of accounts and they had,
they were like top 10 traffic in the world.
So it was like a big transition from a lot of like startup culture into like,
you know,
the FAANG culture of having like a huge technology footprint.
A lot of teams that you're working with a lot more XFN partnerships that was kind of an eye opener.
And like,
really,
I would say the first time when I actually started having to push and develop technical visions and strategies.
And then from there,
I moved to Meta as an infrastructure security engineer.
I was in their fintech division where they did,
they wrote like Libra,
the Cryptocurrency.
We also did like an NFT project for Instagram and Facebook.
Both of those products were sunset after the crypto winter,
unfortunately,
but from there,
like that team sort of uh got dissolved and I moved into central security leading their vulnerability management and,
and asset management functions over there.
So that's where I am now.
Awesome.
Before we get into our main topic,
I'm I'm curious about your initial job working in IT and that move to go get the degree.
And all of that: was the initial job experience actually useful in your job applications after you got out or was the degree itself more helpful?
I asked this as someone with a,
with a non-traditional background who actually does not have a computer science degree.
I'm always curious about whether people feel like that time was well spent or whether the on-the-job experience was more valuable or a combination of both.
I mean,
it's a fantastic question.
So it's something I thought about a lot actually because,
you know,
I I think not only was it substantially helpful for getting a job after the fact,
like the,
the experience was factored into the roles that I was getting,
which was like,
excellent,
you know,
especially coming out of college.
I didn't want to be like an intern or something.
Uh,
after having worked for 10 years beforehand.
But also even when I was in college and I was in these computer science courses,
the level of context that I had about the things we were learning was just like above and beyond the majority of the people that I was going to school with.
So I think it actually made things like much easier for me because like the things just kind of clicked when I could associate them with experiences that I'd already had.
Yeah,
thanks.
So,
moving ahead into our main topic for today,
the reason I wanted to have you on the show is you and I have done some work together uh in some cross functional efforts.
And one of the things that's really impressed me about the way that you work is your ability to align all of the potential ideas that people want to work with a business goal and set this into cohesive strategy and communicate that strategy effectively across teams.
And I wanna see if we could talk through a little bit about your strategies that you employ to actually do this effectively,
to communicate well with management above to say how you're addressing their priorities and with other teams that you need to coordinate with to keep everyone in line rowing towards the same goal,
that kind of thing.
Yeah,
absolutely.
I guess,
like,
thinking about this from the perspective of like,
the Staff+ engineer,
one of the things that I often see in,
like more junior engineers and something that I think is like a great mindset shift as you're,
as you're progressing in your career is you begin to focus more on business problems than technology problems.
I think that is like a,
a huge difference maker when it comes to actually being able to take a look at all the ideas that are out there and say like,
is this actually something that we should be pursuing or not?
If you ground all of your thoughts and the and your approach in like what the business needs,
what's your value proposition of the product that you're protecting?
How can you tie the goals that you have like technically to that value proposition?
I think you end up getting a lot more success when it comes to having those conversations,
especially with leadership.
One thing I found for sure is that when you're talking to executives,
they don't want to hear the deep technical jargon and the mumbo jumbo about all the things that you're working on,
they're really focused on.
How can you like help my product sell more money?
How can you de-risk my product in my case as a security professional?
How can we provide the customer a better experience that's gonna drive our DAU or whatever,
like the particular metrics are that they're interested in.
And so if you can take the thing that you're trying to do and like,
frame it in that context of what the uh what's important to the business,
you're gonna come with a really compelling story to tell.
Yeah.
So I'm curious,
like,
how do you view the differences between a business goal and a technical vision?
Are those things one and the same or is there overlap there?
And I'm curious about the difference between a technical vision and subsequently a technical strategy uh And how all those things align and relate to a business goal?
Yeah,
good question.
So in my mind,
a business goal is sort of the starting point.
And so when you identify an opportunity to,
like I said,
drive either one of those metrics or one of those objectives that is sort of aligned with the priorities,
the value proposition of the product,
then you found a place where a technical strategy can be implemented basically.
So a good example of that would be,
you know,
you have a uh a new product that you're launching and you found that like your customers are like begging for a higher level of security.
And so you suggest something like,
oh maybe we can think about end-to-end encryption for,
for the product because that's gonna be something that's like really well aligned with the value proposition. So now that's like kind of the starting point of the technical vision,
right?
Like,
OK,
we have this goal,
we have like a very broad brushstrokes approach to how we can make progress against that goal.
So then you kind of what you do after you've identified the goal is you have,
you set a very,
I'll call it a vague and ambitious target.
Some people call it a North Star.
Uh I think it's something that is not achievable in the short term,
maybe never achievable.
That's,
that's really what,
what I think of as a vision.
It's something you don't change very often.
It's like a kind of a longstanding thing that like guides the rest of the efforts that you do.
It's not something that you can execute against directly because it is so vague and it's not something you could just like hand to engineers and say,
OK,
go build this.
That's where the strategy comes into play.
So a strategy is how you take a vision.
You know,
the vision is the horizon,
you say,
OK,
how do I walk the first like 100 miles towards that horizon?
That's kind of the strategy.
One of the high level things that you should do to,
to get there.
So I guess like talking about end-to-end encryption as a a technical vision,
some of the steps that you could do,
for instance,
are we're going to refactor,
our crypto infrastructure to align with this new uh encryption methodology,
we're gonna go buy HSM because that's something that's like really important for us to do to like house these,
this crypto securely.
So like these are all like very broad brushstroke steps and not something once again that you could like execute against directly.
And so then after you have that strategy,
that's when you sort of break it down even further and further until you have like,
you know,
if you're into like uh Jira use like epics and,
and stories and things like that.
So you get all the way down to a level where now you can pass this to the actual,
like more junior engineers to go and like build,
I guess the pieces that would lead to you getting closer to that technical vision. You mentioned earlier that as you,
as you've gotten more senior,
like the type of language that you need to use for the type of people that you're talking to changes,
right?
Because they're not interested in like the the deep technical details.
I'm curious,
can you go into like some of the more specific skills that you've needed to learn in order to be persuasive to like leadership or other stakeholders?
Once you get to that higher,
like level of that higher realm of responsibility,
I can give you an example from my job as I've gotten more senior,
I've written a heck of a lot more than I ever did before because I'm putting together reports,
right?
To say like we're actually like we have X number of users who are doing XY and Z and you know,
and the best way to get that information is just to pull it directly from the database.
And I can say now that we've run,
you know,
this cleanup,
we've eliminated XYZ amount of useless users or data or something like that.
Is there anything like that that you've learned that's been really helpful for you?
Yeah,
I mean,
your,
your example is actually fantastic because the thing that I like that you were discussing is like you set a very concrete measurable data driven goal.
And so then I'd say there's nothing executives love more than to see a number move on a dashboard,
which is kind of uh kind of interesting,
right?
So I think that's like 11 great way to like go and talk to people like you,
you present these,
I guess you start with the data,
you sort of define how you can measure the,
the specific strategic goals that you have or that you set forth as part of this process and then,
you know,
take the before and after to show your progress.
I think another thing that it,
it's interesting,
maybe under underrated,
in my opinion,
the,
the one-on-one is a skill that I think is like incredible.
So let me give you like,
I think one of my favorite tips for when you're gonna go into like a potentially contentious situation or something where you're going to a big meeting where,
you know,
you have to land the message because like this is your only shot with a VP type of thing.
One of the tricks that I use is I'll find out like who's gonna be on the invite and I'll schedule one on ones with all those people individually,
like all the people who I need to convince because I,
what I found is it's like so much easier to convince people in an intimate one on one setting than it is in like a group setting where you have to deal with things like dog piling where one person says something like negative and then everyone else like jumps on top. If you can address all of those concerns before that group call,
like in those one on ones,
maybe even adjusting your proposal beforehand.
I think you just have like a much better chance of success.
So that's like one example of something that I've like picked up over the years I think has just been a tremendous help in,
in getting things across uh across the board.
That is a super pro tip.
I love that pre- pre-giant-meeting one on ones is great.
It rolls in nicely to one of the things I wanted to ask you about is when you've got this vision,
you've got this strategy that you think is gonna work.
You think it addresses the problems that the executives are concerned with.
How do you go about turning that vision and strategy into an actual document that can become a canonical source for the work being done over the next say multiple halves or multiple years as you move towards that vision?
Yeah,
that's a great question.
I mean,
I think the first,
the first step here is identifying who all the partners you should be bringing into this.
I mean,
I personally like to start a chat group before I start writing a document.
And so I'll go and I'll look across the company,
like,
you know,
you kind of have to do some legwork ahead of time.
Like you should have,
maybe I should have talked about this earlier,
but you should have already been looking across the company to find people who have similar interests or similar goals to what you're,
what you're trying to do,
like who are the people who would be positively or negatively impacted by,
by your proposal.
Like those are the people that you need to get really close to and like identify early on.
And so once you found those people,
hopefully you've had like one on ones with them to kind of get them on board,
especially for the detractors.
I would like,
I like to uh create like a chat if you using like slack or,
or in our case,
workplace chat,
you create a chat,
you bring all those people in there and you sort of write an introductory paragraph or one-pager or whatever saying,
ok,
here is like all the,
here's what we're trying to accomplish here and you get everyone aligned first on the business problem and the problem statement before you start writing a technical vision document.
So,
you know,
maybe you'll schedule a meet and greet with everybody so that everyone can kind of get to know each other and stuff and see that there is a bigger problem than maybe they thought there was in at the in the first place.
And then yeah,
after you have that initial alignment on the business problem,
that's when you like dive into this like technical strategy document.
So in this document,
the first thing I like to do is I like to document the current state which will include all of the initiatives that are already going on in the space.
So one example would be like in one of my previous companies I saw there was like a bunch of different teams uh who were working on cloud security across the company independently.
You know,
this team was using this open source platform.
This team was like trying to buy this vendor,
et cetera.
And so pulling them all in, documenting the initiatives.
What were the goals of those individual initiatives?
What were they trying to solve?
I think that's like an important first step because then you can find ways to like align that technical vision in a way where you can address multiple of the the goals from these different teams at the same time while still like pushing towards that,
that grander vision.
So another thing that I think is really important is making sure that after you started,
I guess lining out the current state,
you line out like,
what's the North Star that you're aiming for?
So this is kind of like the really high level,
if everything was perfect in five years,
like,
what would this look like?
This is gonna get people sort of to start to visualize what,
what your vision is in a way that's like a little more concrete than just like a vision statement or something.
And so like writing maybe like a one-pager or two-pager or,
or one or two pages I should say on exactly what it is you're trying to accomplish at the end of the,
the rainbow,
I think is a really important piece as well.
So one thing that I like to do when I'm writing a document maybe a little more tactically is I like to make sure that there's like,
it's a lot of iterations.
What I've noticed from some people is they do,
I guess the waterfall method for like building one of these documents and they'll go like into their cave and write a 20 pager on,
you know,
whatever.
And then they come back and people are like,
oh man,
I don't know,
I don't know what you were thinking in that cave,
but it's not what we were looking for.
Right.
And so you end up having to do a ton of rework.
Instead,
if you get people involved throughout the process,
you have multiple iterations,
people are looking at it the whole time.
They feel like,
personally invested in the process and like their voice was heard throughout,
uh,
instead of like you just trying to ram something down their throat.
Yeah,
for sure.
I think building that alignment along the way as you start to formulate the strategy is really important.
I have a question about this though: There may be at the,
at the end when the document is nearly done,
you might need buy-in for,
I don't know,
10 different teams,
but that might be too
many people,
too many cooks to have in the kitchen as you are starting to formulate the initial idea.
How do you decide what the right size is for that initial core group that needs to start forming the right idea together and what,
you know,
how do you decide what that critical mass is and how do you prioritize who should be in that room?
Yeah,
I mean,
I think that's a fantastic point and a fantastic question.
I mean,
it really depends on your individual situation and,
and actually I would even say your company size to some extent.
One thing I found like when I was working at startups,
like the optimal size for these groups of people who were working on these things was maybe like five or six because that was really like representative of like large swaths of the company.
If you get the right people,
if you're somewhere like Meta or Amazon five or six people is like,
generally not going to be enough because there's just like so many stakeholders involved uh that you,
you need to have participate. At the same time.
Like to your point,
you don't want to have like 30 people in there because at that point,
it's just like too much noise in the room.
So I think my like ideal number at meta has been around 10.
And the thing that I'm looking for when I'm choosing the people who should be part of that initial like draft,
I actually look for people who are influential.
And so this comes,
actually,
I was listening to one of your previous podcasts and uh you guys were talking about how relationship building is so important.
So when you're especially getting more senior as an engineer and this is like one of those cases where I,
I think it like really reigns true because you have to kind of already know who those people are.
To some extent,
if you just get to a company,
you don't know who you don't know the playing field,
then it's like,
it's really tough to understand like who's like the minimum number of people,
like who's the right minimum number of people to bring in.
But once you've like built those relationships,
you kind of have a network there.
I think you,
you kind of get that awareness to some extent.
So what I was gonna ask is you need people to be invested,
but if you get them involved in the process early on,
is there a danger of people becoming,
I don't know,
tired of working on something at this early stage,
right?
Because you have to maintain their investment potentially there.
There's like an initial buzz when you start a new project.
My concern in some of these cases is like if you get people involved too early,
they get burned out by the time it's time to actually launch it,
if you bring them in too early.
Right?
I understand like we've all had that happen.
I'm sure where you put a whole ton of a time to something that nobody cares about or is interested in.
And that's obviously not ideal either.
But then I've also had it happen where like,
you know,
it takes a fair amount of energy to keep people involved if they're not,
you know,
in a project.
Yeah.
Do you think that it makes sense,
Brian, to,
to be upfront about,
you know,
I'm looking for five hours a week of commitment from this core group to participate in the early creation of this strategy doc?
How do you mitigate what Alex was talking about?
Yeah,
I mean,
that's a,
it's a great question.
I think it really depends on what your role is in the,
in the strategy like so in my case,
like often I'll be the one who's like writing the document and stuff like that.
And so I don't think you need to have people who are like continuously involved type of thing.
Um Because for the most part,
I feel like you,
you're going to have a few specific iterations.
I think one iteration should be fairly soon after you start writing the document.
But then like,
I think you'll have enough data that you've collected from the people who are around about what things you should be thinking about.
What are the aspects that are important to them where you can write like a significant chunk after that and then kind of pull in the people you need specifically for each individual part that you're writing.
So one tactic that I like to use is actually to write things that are like,
so let's say like I'm in security,
I'm working on what,
you know,
this like Phantom cloud security project that I was talking about earlier.
You could uh like have a,
a part where you're talking about like,
what are my compliance requirements in the cloud?
Because we're,
we have PCI uh a PCI footprint in AWS.
Like that's the part where you're gonna want to have GRC interacting.
And so you actually,
what I'll do is I'll like comments to the GRC person who's like,
you know,
my point of contact for this particular project and like @ them and assign them in the comments and say,
hey,
can you please like,
take a look at this section versus trying to have everybody look at everything,
you know,
sort of every time you want to have an iteration on it.
And I think having that like sort of specific division of people where they're only engaged when it's like relevant to them,
to some extent is a good mitigating factor.
There.
Also making sure that you space out your,
your requests for these iterations in such a way that you're not like asking people for constant and continuous involvement.
I think that's also like pretty important,
right?
Because that's the other question is you don't want to be the guy who's constantly scheduling meetings.
Um That to like being the guy who's like filling up someone's calendar,
that's like a,
that's a death knell man.
Like people,
people get sick of you so quick,
right?
And you were talking about relationships and all that,
how important that is like people's time is very valuable.
And if you're the guy who's like,
oh,
great.
This guy wants to spend like 20 minutes every day talking about something that I don't care about.
Like,
I'm gonna not,
I'm gonna find excuses not to go to,
not to answer that guy.
And that's like you said,
that's the death knell,
you know.
Yeah.
But what you said makes totally makes sense.
It's what, to put on my extreme nerd cap,
That seems like a much,
a much more scalable version of keeping
people involved.
So you go through this process,
you've got your core group in the room,
you work on this document together,
you're everyone's aligned,
you present it to management.
Management loves it.
And now it's time to execute.
How do you maintain alignment across all the work streams that are gonna need to be involved to make sure that everyone is honoring or pulling in the correct direction that was outlined in that initial document?
How,
how do you keep up with that as things go on?
man?
This is a fantastic question.
And it's interesting because I think depending on the situation you're in,
this could be harder than setting the technical vision of strategy in the first place,
I've definitely had situations.
So like just like to give an example of like where this can go wrong.
I had an on-site at one of my previous companies where I spent like an entire week trying to align a team on or,
you know,
I guess several teams XFN teams on this technical vision that we have sort of all agreed on before the on-site.
So we were all kind of on board.
I,
I left,
I had to go do something else for like,
a few hours and they had,
like,
a meeting while I wasn't there and,
like,
when I got back,
like,
everything had,
like,
changed,
the whole road map had been,
like,
blown up.
I'm like,
oh,
my gosh.
You know what?
I was gone for five minutes.
Exactly.
Yeah.
So,
yeah,
I really think this is an important question.
The thing that I found that really helps with this is having a,
like a fairly rigorous road mapping process where you set things that are objectives and then you make sure that you specifically align these objectives to the strategy statements that you wrote in your document.
And so even sometimes I'll have like a,
I'll make like a crosswalk where I'll say,
OK,
strategy bullet one,
here's the objectives that we're gonna target this half and the key results and to Alex's point,
the measurable key results that are associated with them.
I think having that sort of really grounded framework that you can use to track the progress over time,
makes it more difficult for teams to sort of sway off track because oftentimes teams don't quite have that rigorous roadmapping progress or process and they kind of just wing it and leave it up to TLs or whatever to kind of independently come up with this stuff and not write it down.
And I think that's where I've seen in many cases,
like teams will kind of go off the,
go off the rails.
So I I like to personally be involved in the road mapping process.
I don't just like hand it,
hand it over to the TPM and uh ask them to take care of all this stuff on my behalf.
I want to be like,
really engaged when we're talking to these other teams and like aligning the road maps to make sure that we get to the right level of detail to keep that alignment. Uh for our listeners who may not be familiar,
what does TPM stand for?
Oh,
yeah,
good call.
"Technical program manager" is TPM.
We mentioned another acronym earlier: GRC which uh for anyone who doesn't know is governance,
risk and compliance.
No,
it's cool.
Like,
like we were,
we were joking actually in our last episode about how like we just like our lives are filled of so many acronyms.
And sometimes once you even look up what the acronym means,
you still don't understand what someone was trying to say it to you,
but that's tech,
right.
We got,
we got feedback that we're uh that sometimes we,
we're a little too opaque in the terms that we use.
So we're trying to be a little bit more friendly in that regard.
I don't know if it makes it any better or not.
You know,
it's a podcast for engineers.
So we,
we assume some level of knowledge. Some level. Hard to believe,
but we're already up to time here for our picks and plugs,
which is a time where we just share with our listeners,
any resources that we are into,
uh,
whether it's tech related or not,
uh,
or anything you want to plug something that,
uh,
helps you make money outside of work,
whatever you're into,
I'll,
I'll kick it over to you first,
Brian.
Yeah,
I guess I don't really,
uh,
do podcasts or anything like that generally.
So,
this was like a,
a very interesting experience for me,
but I will plug a couple of things.
So I started reading this book called "The Lean Startup."
I'm interested in like starting a business eventually.
And this has been like a really good resource that talks about how when you're a,
a product engineer and you're going to start a business,
a lot of people focus all of their attention on like the architecture and the technical vision and strategy and these other things and don't spend enough time focusing on like the marketing and like the operations and all these other aspects that are like,
honestly just as important as the,
as the tech.
Um So I think this has been like a really good book for like kind of getting my head in the,
in the right space to uh start a business.
And then I'm playing this game right now called "Jagged Alliance Three."
I don't know if you guys played any of the previous Jagged Alliance games,
but it's a pretty fun game kind of like Xcom.
I love like turn base strategy games.
So uh it's been,
it's been keeping me busy.
Awesome Alex.
What do you have for us?
I actually have two youtube videos.
The first one,
one is,
I think I've mentioned it a couple of times and it's pretty famous,
but it's worth watching all the way through,
especially with all the AI art stuff that's been going around now.
It's "the art of code."
This video is actually a few years old now,
but it's pretty prescient.
Uh A lot of the stuff that is in that video is stuff that's all kind of come to fruition or stuff.
That's very hot topics right now.
I think it's really interesting.
Um The channel that I'd like,
I'd like to recommend a youtube channel too called Fireship,
which is pretty famous,
but they've been putting out a lot of really good videos recently.
So if you haven't been watching like Fireship IO's stuff,
they've been putting out some really interesting like they uh I think it's this week in code videos have been pretty interesting in the past few weeks because a lot of stuff,
interesting stuff has happened.
And another youtube video is uh I mentioned it last week but I wanted to like put it actually in the show notes is a unit,
it's,
it's called "unit testing where it all went wrong" and we'll put an actual link into the actual video and it's pretty good too.
And then the book I want to recommend is not a,
a coding book.
It's not a programming book,
but I've been reading it recently.
It's called "How To Reassess Your Chess."
And it's a chess,
uh middle game strategy book.
But really interesting.
I'm not very good at chess,
but this book makes me feel like I might be good at chess one day,
which is,
which is about as high a recommendation as I can give for a chess book.
Do you tend to prefer a more positional middle game or a more tactical,
middle game?
Well,
this book is all about positional middle games,
Brian.
That's what's so cool about it because it takes,
it means that you don't have to memorize a bunch of like tactics and,
and end game strategies.
You just get to learn like knights are good if you put them over here,
which is pretty,
which is,
which is about the level of thinking that I'm able to do.
So knights behind pawns are great.
The fact that I asked that question using terms like positional and tactical suggests that I know chess,
but I don't,
as it turns out,
my son is really a big fan of chess and he loves to listen to chess podcasts.
And so I sort of hear this stuff even though he can absolutely destroy me any time we play each other,
he could destroy a lot of people.
He's a monster.
I was impressed though,
Brian,
you said that with so much confidence.
I bet you're a great interviewer dude.
Yeah,
exactly.
That,
that's that you actually got a very good sneak peek into my system design interview.
If you speak with authority and confidence,
they'll never know that you don't know what you're talking about. For my pick.
Uh This is a real simple one this week.
Um I've been reading a blog uh by a guy named Pete Hodgson who markets himself as a technical consultant,
but he's got some pretty good content.
And there's a particular piece around what we were talking about today,
which is creating and sharing a strategic architectural initiative.
And he talks about a lot of the things that we covered in this episode,
which is co creating your strategy with other people to build better buy-in.
He talks about brainstorming on the current state versus the target state,
which is your North Star.
And another thing that he talks about quite a lot is over sharing,
right?
Communicating almost to the point where you feel like you're doing it too much,
but continue posting about your strategy whenever you have a presentation,
put your initiative as a bullet point right at the top and just reiterate it right?
This is a way to sort of build that ongoing sense of momentum for the strategy that you're iterating.
Anyway,
it's a great piece.
I'll put it in the show notes and that brings us to the end of picks and plugs and here we are at about the end of the episode.
So I wanna stop and just say,
Brian,
thanks so much for taking the time to be with us.
I know it was your first podcast experience and uh I thought you did great: terrific content and,
and I think uh the listeners will really benefit from this.
So,
thank you so much for being here.
I learned a lot.
No.
Thank you so much for having me.
You guys were great hosts.
I really appreciate it.
All right,
everybody.
Thanks for listening.
We'll catch you next time.
Thanks for listening to the main thread.
As always,
the views expressed by the hosts and guests of the main thread are our own and do not reflect those of our respective places of employment.
Are you enjoying the podcast?
Do you have a topic you'd like to hear discussed in a future episode?
Well,
please reach out to us with any suggestions or feedback.
We are @themainthread on all major social media platforms,
including Facebook,
Twitter,
Instagram,
and of course Threads. If you prefer,
you can send us an email at mainthreadpodcast@gmail.com.
For links to resources mentioned in today's episode or to download a transcript of the podcast.
Please refer to our show notes. That's all for today's episode.
Thanks again for listening and we'll catch you next time on The Main Thread.