Hi everyone, my name is Patrick you.
And for today's episode, we covered a ton of esteems and
cover. A lot of social aspects that are
in and around creating software. My guest Michael feathers on
which currently, directorate r7k, and Chief Architect, a
globe and I'll put the links to his socials in description
below. And with that being said, enjoy
the episode. To Beyond coding, a dive into
the world of successful people in IIT from your sponsors Z,
Bia, creating digital leaders. Here's your host, Patrick akhil.
If I were to ask you, what makes a team really a team.
What would you, what do you say about that?
Because I think there's a lot of aspects that go into that.
Yeah. What makes a team really a team?
Yeah, that's kind of fascinating one.
I guess there's all these different dimensions we can kind
of like think about and conjunction with that.
I think for me the main thing is you just feel comfortable with
you. People you're working with okay
and you got to know them pretty well.
And essentially you're able to share technical knowledge and
lore about the history of the system that you're working in,
and I love that. But that that's not really
technical, right? Any team can do that, but you
need to know each other also even more The personal level,
then. But you think yeah, I think so.
You know at least just be convivial I guess it's kind of
like just like hey how are you doing?
How was your weekend and you enjoy each other's company?
Yes, we found a waiting on kind of Rapport.
I think that's the main thing. Yeah, you think I completely
agree. What I've noticed is that, I
mean, everyone in my team is working more on my remote still
now that you can go back to the office but people isolate
themselves, also kind of socially, right?
It's weird if we have stand up and we kind of talked about Of
non-work wise, you know, people enjoy it.
Some people are like why I need to get going.
Basically already have those moments that you just grab a
coffee with someone and get to know them.
Basically which is weird. Have you noticed as well?
Yeah I have and it's a it is a funny thing it's really kind of
a shame because you know I've always enjoyed that sort of
thing like an in-person working. Yeah.
You know I think it's one of the things that we really haven't
figured out in the industry yet or just in general with the
world. With remote working, what we're
actually kind of missing in terms of like body language and
being in the same space with people, you know, I kind of
wonder about the from the like the mental health aspects.
Also, I think there's this, there's lots of things that we
try to abstract away and then we abstract away, we kind of like,
you know, don't realize that we're suffering in some manner
where we feel vaguely at unease but we don't know exactly why.
Yeah, I might be a great example of this is just like the thing
of like, you know, we move beyond the work around.
For instance, if you About Twitter and social media.
It's kind of like when you're communicating just by text with
people, there's so much Nuance that's missed really are so much
possible misunderstanding. Yeah, I think the same thing is
true with even with remote audio and video but it's like a you
know, too much lesser degree. Yeah I mean I have that I have
friends that are like interpreting a certain email
with completely like a different.
How would you say that a different tone, a different
attitude but it's just text, right?
That's the Their own interpretation of a piece of
text. I'm like, it doesn't, it doesn't
feel like that to me, and then when they talk to the actual
person that I've, no, no. I didn't mean it like that.
No, that's just how I write. I'm either.
I mean, I'm talk to him Direct. That's how it goes.
I try to avoid text and email, I mean with remote.
Now, everything's through slack. So I think you need to know what
people's preferences are in the first place.
Or I think take that extra step and putting that new ones in
there. I think emojis are a great way.
Doing that now. Yeah, I agree.
I think it's kind of fun that way.
Yeah. Well I think we've all had our
ways to cope with it. Which is kind of cool.
Yeah. But it's still any what's kind
of rough for me right now? And I think, you know, there
were a lot of people are going to having a lot of conversation
about remote working likes. Maybe six months or so ago
because of covid. I'm the the question is always
been kind of like do we go back to in person and under what
circumstances, do people actually do that to
organizations do it? I think there's a real forcing
function there in the sense that so many work.
Has a shins are hiring people remote and yes, almost like
would be impossible at this point to go and actually move
back to Common facilities. I think, for many organizations.
Yeah. That plus, I think Engineers
have a preference and I feel like, I mean, I'm more and more
on Twitter. I feel like that's moving
towards remote. Engineers are already scarce and
hard to hire for. So I think if there's a stigma
there, then organizations need to accommodate for it or they
need to have something else that.
Attracts Engineers like a magnet.
We do stuff in office but we have other cool stuff so you
probably want to come to the office.
Also. Yeah, I think there's that.
I think the other thing is kind of funny is I have also joked
with friends about this thing of like, maybe in five ten years or
something like that. People are going to go and say
we did the spectacular thing and guess what?
Our secret was our secret was getting everybody together,
right? Yeah.
And of course, everybody was involved in the early, agile
movement will just laugh at that point because we kind of fell
from the very beginning. Having people co-located with,
you know, a great, you know, a great thing that was really kind
of like a productivity and cosine feeling sir.
But you know, I think for that sort of thing it's probably
going to happen with very rare projects.
You know it's always go back and think about like I'm back.
I just like in the 1960s there was the calmest Skunk Works
projects for like I guess the dod like the SR-71 Blackbird was
a famous no secret project and they just basically put a bunch
of people in building. Yeah.
And You know, they worked for, I forget how many months doing
this very intensively, you know? And you know, that kind of
thing, can't happen. I'm probably guessing probably
does happen in some some very important Tech areas.
Yeah, I have a buddy of mine who's building a remote start
up. So he's hiring all over the
world and he says, we still need 13 get-togethers per year.
I don't know why 13 probably out of some book, but I think that
is has very much to do with the Bonding you talked about in
really forming that team, right? Having those kind of
interpersonal moments face to face instead of kind of having
them remote. I think that's very important.
I'm kinda waiting for us. I think that, you know, it's
kind of funny because people talk about the whole thing about
like in-person conferences. Also yeah.
But I think you know an interesting opportunity for them
is to go to actually have like you know hey we're having a
conference in half the day will be conference sessions.
The other half is you and your team's, you know, basically
co-located at the same place. It seems like there's a good
dual-purpose aspect to that sort of thing.
Exactly. Run a conference for then also
basically be like a hosting space for, you know, having this
kind of you know, team in company.
Team meetings. Yeah.
Yeah, I agree. If I think back to where I was
kind of most effective, I was in the team with people that I know
even on a more kind of interpersonal level, I knew also
their skills and this was when I was kind of more early on in my
career. So these are the people Needed
to kind of pull up towards. I think that's a Dutch
expression. I don't think that's necessarily
translate opal, but I needed to really put in extra effort to
get to their level basically and they knew they did everything
they could for kind of kind of doing that knowledge transfer
but we were within an organization and had a lot of
trust within that project at a lot of autonomy, there as well
to get it done. Make the technology choices that
we thought would best solve the problem and then actually We
make it happen and I loved being in that scene.
I don't know why that isn't why the way that doesn't happen more
often. I feel like there's a lot of
bureaucracy that goes in kind of organizing and managing teams,
which is weird. Yeah and I, you know, I agree
with you that thing about that being like, a great thing,
really career, you know, because I had roughly the same thing.
I was hired into a biomedical company and had a really cool
technical challenge. I basically worked on with
several people. Yeah.
And It's a great time to grow and I think there's also that
thing of if you've been reading the Koran in the industry for a
while you basically have networked and kind of know many
people. Yeah but for people getting into
the industry now I think remote working as its own special
challenges with regard to having actually developing a network
because it's not, it's not quite as you know you don't get the
deep bond thing. I think online was exactly in
person work situation. Yeah, I've noticed onboarding is
very hard because I need. You need a special Type of
person that reaches out, right? And that doesn't sit with the
problems they have, if they don't reach out, you're never
going to figure out which problems they have.
Therefore, I feel like onboarding has become that more
difficult. Yeah, I think it is funny,
though, for us to go. And basically think of the
forces really are kind of a line towards basically having a lot
more remote work. Yeah.
So it's gonna be a big challenge for us and then, you know, we
are making Headway on and I think it's so it's very
interesting to see where we're going with that.
So the autonomy thing to me is very interesting though because
you mentioned autonomy in terms of like, you know, in your early
work experiences going and working with people co-located
and and actually having having a common task, you're working on
something hard, right? Yeah.
And you know, it's funny because I read a lot of literature about
team autonomy and things along those lines and it's really
fascinating because it can be so energizing.
Yeah. But it's also like, there's that
interesting thing of that, you know, quite often the work that
we do has to basically be coordinated with other work in
other parts of the organization. Yeah.
And so it's like that thing of going in figure out how we
actually best do that now. It's exactly.
Yeah. What do you think the like a
good balance in there is because I've I've seen kind of the fully
autonomous side, but there I could make it see some pain
points. Right?
That it would not necessarily fit in the organization, how we
would Envision it, or when we leave, because we were kind of a
task force agency model. We did a chunk of work and then
we would leave outside of the organization, the organization
would need to adopt it. I could see some issues there
also being effective, but it not being there, kind of long-term,
all of the time. I think it's hard to figure out
the right balance there. Yeah, I mean it's a thing that
can work. It sounds like you were able to
do that. I think it's just one of those
things where basically being clear up front whether this is
like a handoff situation or it's really something which is meant
to be durational across the organization.
I think the thing that I find very interesting right now is we
know the teams feel better when they're working at to
autonomously but it really touches on so many other things.
Like if you're working on a product, what's your
architecture of the product and is it set up in such a way that
you can really kind of minimize the amount of coordination that
has to happen and enough to going to basically last certain
teams to have a great deal of autonomy.
And I think, you know, when you start getting into the area of
like what standardized within an organization, so it's kind of
like, yeah, you've got a town to me, but, you know, you have to
do this, this, this and this. So it's kind of like the
semi-autonomy thing and it's very easy and people in another
part of the organization, And basically come up or things that
you have to do, and then it's kind of, like, never really see
what the impact is and basically go and see that a certain point,
the team starts to feel that almost everything better work
practices dictated. That's really kind of
problematic, you know? Yeah I guess so.
But if from an organizational point for you, if you would have
too much autonomy or kind of full autonomy, I think you would
have kind of Technology spin out of the out of the Woodworks
basically languages you might have never heard of because they
fix certain problems. Very distinctly but maybe are
not very good for longevity, right?
If you can't hire for a certain programming language, should
that be within your organization for the long term?
Yeah, I don't think so and it's funny, I love that.
You asked that question because it makes it leads me to this
thing. I keep thinking about over and
over again within the industry, which is kind of like how long
should code live for instance, right?
Yeah, I think there's this interesting thing is that
there's lots of constraints that we place on ourselves because of
the technology that we have. And the fact that we don't
really Kind of like psycho itís much, you know.
So I know just as a way of going and getting back to that
question, some of the earliest microservice implementations.
There was a company called forward in the UK and they did.
What if I think the earliest microservice things right then
and you know, for them, the type of business they were in
basically, they would write Services would only have to last
for a couple months. So there was no problem for them
at all. To go just basically use a
random research programming language and just kind of know
that if if things weren't working out, they were going to
be right at anyway or just sort of like retire that service and
build new ones. Yeah.
But I think there's that interesting thing where you know
it's the things that persist in an organization that basically
become constraints. Yeah.
And yeah and if we can find a way to make them not persist
then we basically have a bit more freedom.
Yeah. But you're already with an
organization you have so many ties starting off with the
programming language of the implementations, the previous
implementations that are there. Looking to hire for those,
right? Because those need to be
maintained within the cloud environment you have three big
players. I mean, Ali Baba Cloud.
I'm not necessarily considering but as your Google Cloud
platform in AWS, you're also tied to those.
I've seen companies migrate but I think that's a very costly
decision. Even the infrastructure that
you're on currently you're already you already have some
ties, right? You can only move so much yet.
You do see organizations rewriting their stuff and moving
towards either. Either a new language, or a
different framework because they think that is going to be more
future-proof than the stuff their own now, but it's very
it's always going to be gradual. I feel like I don't think I
don't think code actually has an end once it's in production.
Yeah, that's the hard thing. Well, it's an interesting thing
with this too because, you know, I, I tend to basically think of
software as biological in a way, right?
So it's kind of like, there's, you know, we say the code
doesn't have an end point, and then I'm start thinking, well.
In almost every other aspect, it has the same kind of growth
characteristics as biology. Yeah, but the thing that biology
has that code doesn't is essentially apoptosis which is
essentially like programmed cell death for instance, right?
Yeah. So the thing is very unfortunate
for us is that we have nothing which basically goes and says
that coach it only lasts for five months or five years.
If we had that solve a lot of problems and it's really kind of
hard to Advocate that sort of thing because that means
continuous rewriting of things. Yeah.
But But you know, when you look at the the trade-offs that may
not be the worst thing, you know, basically visit
organizations where they are. You know, they're working in
systems that were come from like three companies ago, right?
And they're 30, 40 years old and nobody can get rid of them
because they are so valuable. But it becomes a trap and that's
really kind of awkward, you know?
I would I would love to see you study, first of all, had an
episode with Jessica current, she said the exact same thing.
It's more analogous to biology, now And we had a metaphor of
kind of an organism, and when you need it to shake hands with
another organism, just to hand would appear and you would shake
hands with something else. And at the end up, you would end
up with kind of a monstrosity of like seven different arms and
missing fingers just kind of map out your organizational
structure and the interface is that it has.
Yeah I think anything anything that when changes Easier by
adding things rather than changing what's their existing
away Becomes like, biology. It's kind of like the growth of
cities. Also, it's hard to tear down
buildings to make new buildings. Yeah.
So you end up having two buildings in Old buildings and
Building C refurbish, right? Yeah.
So there's a biological aspect to a lot of, you know,
growth-oriented building. Yeah, I love that example.
That that is exactly how it feels to me as a software
engineer, right? We have old streets, we have old
cities and somehow somewhere, we need a new building.
We make it happen. That's how I feels but we never
clean. We never sometimes we demolish
but also gradually. Basically, it's not radical,
it's nothing like self-deprecation basically.
I would love to see study where they continuously rewrite every
x amount of months and see see what happens.
Why did some research into this years ago?
I mean, not like doing that directly but actually kind of
looking and seeing, you know, is there a good threshold point for
going rewriting things and you know, the thing I could the
thing I could find in the literature that was kind of
interesting with this notion of like saying that as things grow
basically does. How does like defect count get
affected by growth of things, right?
Yeah. And it's kind of like, you know,
the hope that they had, what's would be were set.
There would be some inflection point past which you could say
this thing should be re-written. Because when you go past this
point, then basically have a massive increase in number of
books, right? But end up being rather like a
smooth curve in a way. So it's kind of like just the
bigger things to get the more bug.
They become right? Exactly.
Some portion inflection point at least have something, which be a
good prompt for going and doing the rewrite of things though.
Be easy. Yeah, it's kind of unfortunate.
Yeah, be easy. So, the thing that's weird about
that is someone think about, you know, how do we actually get
mechanisms in place to actually, choose to be right things in
order to, it's always going to feel pre-emptive and yeah, and
that's kind of unfortunate about this.
But, you know, I think one thing of this kind of nice is that
that was part of the original story around, microservices, no
way. Is that you just get to rewrite
the service. Has inch and, you know, you can
look at the services being almost being like cells and
organs went away, right? Yeah, people just don't do it
often enough. So, yeah, it's a shame.
I feel like whenever we do something, that's pre-emptive.
People think it's a waste or kind of stakeholders, or maybe
even a product on it, because it's a waste.
Yeah, but I love the example. I had an episode with Hassan
Habib and he says, we implemented something, which is
called code rub. It's like rubbing your glasses
every day you pick The file see, if it's still neat, if it still
makes sense. Otherwise, you polish it, and
then you put it back, that's it. And it's daily.
It's continuously. And I think it's because the
thing you mentioned that it's doesn't really have an
inflection point, right? It's continuously.
And it's kind of curving off with regards to complexity and
stuff that you need to rewrite that you need kind of a
continuous process there. I thought that was.
Yeah, that's good. And I think the, it reminds me
of something that feels like, it's good to talk about, which
is that, I think that the picture that people have in
their minds of code, bases is not terribly accurate,
sometimes. And the way that I approach
talking about that is that, you know, what?
You just described is like a random process.
We randomly going to go find something, right?
Yeah, but when you look at basically like the commit
history of any code base, you'll discover there are some Really
could basically get massive amounts of change over time now.
There's the maybe have like one or two commits ever in like five
years grunts right. Yeah and it tends to be like a
power law distribution so you basically have like a smaller
system gets many made commits and lots of areas that have, you
know, very small number of commits and you know if you're
looking at where you want to go and concentrate effort in a
system. Yeah, it's a great, you know, a
great guide post of course these hot spots are going to kind of
like move around over time within a code base and That's
fair, but there are some things that are rather persistent and
so I think there's that interesting thing of like once
you really sort of internalized that then you're kind of like in
this space of like, well, you know, we know there's a high
level criticality in this area and we can treat this different.
Yeah. You know we basically don't have
rules of engagement about how we actually work in that area and
maybe even do the thing of going in saying I go as mentioned
earlier preemptively, we're going to have a pre-entered
rewrite schedule for some of these things.
Just because, you know, I think that has really been
internalized. See this tree as well as it
should be. No.
I was I always I mean I talk to
a lot of people and at one point I think I asked someone I forget
who, what would make kind of the engineering experience better?
Right. What would make Engineers more
effective? I feel like we have a lot of
tools and I feel like sometimes it's something's missing when
kind of defining a mental model on what the co-pays actually
reflects, right? Because my mental model is
something but the co-pays actually is it's probably
something else. There's a mismatch there and I
feel like we need Thing to better internalized.
What is actually out there? What have we created?
And also have that kind of aligned within a team because
there's even more mismatches there.
Yeah and what you mentioned kind of really triggered me in.
I think that would help a lot where you see where the hot
spots are kind of the whole areas that would at least bring
Focus or attention to the right places even.
Yeah. Now, I think so it's funny, they
might take a chance to going to mention this.
Now, there's something I got from Back many years ago Thunder
of like extreme programming. He basically wrote some place
that if you can't explain your system using for objects, you
don't have an architecture which is kind of like very, you know,
direct way of saying something which is kind of profound and
true. Right?
Yeah. But an exercise I kind of like
got together from that. Insight is something I enjoy
doing with teams which is kind of like let's say you and I
Patrick we're working on system together and we know it very
well but I'm going to say let's play The Story of a system game
and then you'll say, hey Like okay, let's do that and I'll
say, Patrick the system were working on, explain it to me
using just two objects, right? Yeah.
Two things entities and then you have to think for a second.
What's the two most important responsibilities this system
has? Yeah.
And what's the high-level messaging would happen between
them and it's really kind of like a gross gross
simplification what the system really does.
Yeah, and the thing is that when you tell me that you start to
know where you're sort of likes, oversimplifying things, first,
kind of lie in a sense and then you To ask yourself what?
See, why couldn't it be that simple?
And then you start to go and get this sense of like you know,
what's more important? What's less important ways that
communication can be Consolidated and stuff like that
and then we'll go back and forth and I'll say okay well it's
going to expand. It was like a three objects for
obvious five objects. Yeah.
And in process of doing this you're kind of like centering it
on what the most valuable you know critical responsibilities
and system happen to be. Yeah, and this is a great way of
going in and getting some degree of consensus on a team about,
you know, What the most important things are what's the
simple story would tell to people about how the system
works. And then you start thinking,
well, how do I keep that story simple without the exceptional
cases that are jarring to people when they go into the code and
try to go and make changes and I find that very valuable thing.
You were mentioning earlier about like the distance between
us and the code is like I think we're always going to have that
but maybe the best thing that we have as an antidote in a way is
the fact that we can communicate with each other and that you
have from you than I do. And then we can communicate
those things and hopefully arrive at, you know, kind of
like a closer truth. Yeah, it's kind of a consensus,
but even so I was thinking how that would happen within my
team, but we going to have roles and responsibilities.
Even we're currently not operating full stack.
For example, so people that would more be more UI oriented.
What people actually see what give a complete different answer
than people that are more action-oriented, more.
Atta even event-driven is our current system, so those answers
will completely be misaligned. I feel like it would be hard to
get them even to a consensus if your team isn't aligned and what
it's doing kind of throughout technology.
Yeah, but still we and then there's areas of specialization
that we just feel that we have to kind of pursue that way
about. I love the thing of like walking
somebody else's shoes for a period of time, it helps young,
you know, there's things that you miss we miss forward kind of
like yelling across the fence of our disciplines.
Yeah. Yeah, I've experienced both so
within a team, everyone's responsible for kind of
everything and obviously within that you have specializations
people that know more about X then y.
Sure. But also people were currently,
my role is a back-end engineer. I don't really touch the front
end. I do some stuff here and there
because I can, but my main focus is more on the backhand side
because the skills are required there, and I'm one of the people
that can actually do that. So we do have kind of that kind
of roles and Possibilities within our team but there's also
a kind of distance that gets created because of that because
we are not doing the same thing we can yet we don't and I do
feel some some friction here and there sometimes because that is
there I think it'll always be there.
If I think the thing, I always hope for with teams is that they
basically get to the point where they realize that That these are
the Dynamics in our and then it's kind of like and they can
see the situation the way that you see it with your team and
then going, okay, well this is the way we're kind of oriented
right now. What can we do to kind of
mitigate the bad effects of it. Yeah.
Right. Can we collect more
communication? We have shown tell us or
something like that, or to go and sort of like, let me get
myself into the, you know, the mind frame of being a front-end
engineer to be able to go in at least see that world.
Like make better decisions about things that I do, right?
And you know it takes a great deal.
Self-reflection and systems awareness to see these things.
And I that's one things I just I always hope for.
So I think a lot of my communication with people is
about getting to see those things.
Yeah. Yeah.
I love having like a conversation that triggers kind
of a reflection point about what we've been doing or kind of
Europe puzzle piece and how the bigger picture kind of fits
together in a way. Because that's it's hard to get
that from your own point of view, right?
You really need a time and a place.
Do that kind of reflection and for me, it would trigger is way
easier than setting a time place for myself to think about that.
They may be seen in. Yeah, and I think thing, we
talked a bit earlier with the whole thing with like remote
work is that, you know, it's kind of like you don't really
have the hallway conversation quite as easily.
Yeah. Kind of work I do.
Yeah I was thinking something triggered me, I don't know what,
but I had a conversation which was actually quite recent where
a certain problem need to be solved.
Moved. And one of the stakeholders
already said, I Envision a team of like eight or nine people
working on this problems to get faster and stuff like that.
And I challenge that I said, I mean, is that the actual number?
We're going for it because with that many people we're going to
have other issues, right? You might think it goes faster
but throwing more developers in the same team isn't always going
to make it faster, actually. I think it's going to be
counterproductive for the for the problem that we're having.
I was of the mindset that Team of three or four for this
specific problem would be best, but they completely disagreed.
And this kind of a dissonance in what the optimal team sizes for
the problem at hand, I've always been in teams that are like
three or four people never quite larger than I think seven yet,
there are teams that try that. What was your experience with
that kind of team? Size wise, pretty much it's the
same thing and I think what's fascinating to me is basically
like, Think about how best to communicate this to people with
those that constraint is one way.
I like to explain to people her like maybe not in the technical
realm, is kind of like, okay, you've got a group of people
getting together, trying to figure out what restaurant to go
and get dinner, right? Then easier, conversation among
three people are among ten people, right?
How long is conversation going to be between, you know, 3 and
10. And you know, the thing is for
people that are systems oriented.
You can just go and say this is the N squared problem, they kind
of get it right. If you have like, in graph
Theory, you basically have a certain number of nodes a
certain number of edges, As n increases the number of
communication paths, increases by the square of N.
And that's just, you know, a constraint that we have for
going and growing things and that gets connected to like the
Dunbar number. I mean, for the number of people
that people can own an organization.
There's all these loose constraints that we deal with
all the time and software development.
And, you know, I think it's interesting to consider consider
how best to develop a bit of a language to go and discuss.
These things because they are real, you know, and it's we can
try to go and be a rather loose about them and say, hey, but you
can put, you know, 30 people on a slack Channel and it's going
to work out fine. And it's like, well no, you
still can have that constraint and it still weighs.
It's gonna be easier with three or four people, right?
Exactly. Yeah.
The metaphor, I like with that
is that two people make a baby in nine months more people do
make a baby faster than that Yakima.
Same with with the restaurant thing, It's funny how a lot of
us. Now, just there's this book, the
mythical man-month by Fred Brookes back.
And I guess the 1970s, yeah, that when the first operating
system projects for IBM and he basically, you know, articulate
Brooks law, which is adding late getting people to late project,
makes it lighter. And essentially, the argument is
that and squared thing, it's just what it is.
Yeah. What's your take on?
Kind of? I mean, the tech the tech sector
right now is quite hectic. I feel like, I feel like a lot
of people are switching, it's because salaries are increased.
There's more opportunity with companies hiring remote, so
anywhere where you are, there might be more opportunity if you
are within the tech sector, but that also means a lot of
friction for existing teams, right?
A lot of people either flowing in or flowing out.
Do you think that, I think that a team takes time to actually
form a team, right? We already talked about kind of
having that interpersonal communication and knowing things
about each other. But if you continuously have
people flowing Out and flowing in.
I think that's very hard to get to static level of comfort and
Effectiveness. Yeah, I think that's a
definitely an issue and I think it's particularly now a problem
because you know the way the economy is and I guess also you
just general issues of retention, you know keeping
people and stuff like that. Yeah but I think the interesting
thing about this is I think there's like an in-between spot
with its right. People are coming and going and
it While ago and Joe a team. But I think there's also this
thing that you can do organizationally where you have
kind of like a team of teams in a way where it's not really like
this bigger. Team is a cohesive team in any
sense, but at least the people know each other well enough.
Yeah, so like, say you and me and maybe two other people can
get together and work on something for a week.
Yeah. But we don't have to go to form
new relationships to our you have a relationship, right?
Yeah. And then actually it's like
maybe we kind of like reteam in a way and I'm working with like
several other people in the organization that I know already
very Well as well, right? So there's this thing where we
can, you know, we can basically have Team boundaries that are
changing more often than we expect in this bigger space.
The slightly bigger space. Yeah, and that can be really
advantageous, you know, so I think that getting used to, that
degree of change, is actually something.
That's kind of useful in an organization as well.
Yeah, I think that would work out really well.
Actually, it does go hand-in-hand with kind of shirt
delivery Cycles because then you would deliver Piece of software,
Polly kind of reframe re-shift in different teams, where it's
needed, only based on expertise also, but that would also mean,
because you are interacting with so many people, probably new
people as well as people that you already know.
I think the knowledge gaps are going to be less big, right?
Because if you're the only security guy, the only Cloud
ninja near even the only front-end or back-end guy and
you go away. My team has a huge issue or
might have a huge issue because that knowledge He's gone and
because you're kind of making those relationships, right?
It's all people in a graph and lines in between that knowledge
Gap is going to be less huge, I think.
Yeah, now definitely and I think that's, you know, you mentioned
earlier mobbing and I'm having is really a very important way
of going in dealing with that sort of thing because if you,
you know, say you're working with like, you know, a data
engineer or something like that. Even if I'm not a data engineer,
I can start to think about how that person thinks if I'm
working with them often enough, right?
Yeah. You'll help me.
Interviewing other people it'll help you know help me basically
sort of arrived at some similar decisions even though I may not
have the Deep knowledge that person test.
Yeah. So I think yeah in a way it's
kind of like so much of what happens in organizations these
days. That's really kind of like about
decentralized Knowledge Management in a way.
It's like us Bates being aware of what needs to be known in the
organization and making sure that we keep that knowledge
alive. Exactly.
And a lot of knowledge, you're not going to use immediately,
right? But it's going to sit somewhere.
We're in your storage and at some point you're going to be
the called, This is Andy, you might not even know where you
where you got that information from, but it is probably going
to be from some sort of dialogue, some sort of
interaction and it might not even be a technical problem.
You are solving might just be someone giving their
perspective. You having a chat about whatever
which is also I think the the beauty of being in this space,
right? A lot of the technical problems
we've solved, don't get me wrong there's still a lot of people
solving, a lot of technical problems.
But I think a lot of them we've solved.
We're now dealing with more of the biology aspect, right?
The communication, the team building everything around
creating software and I don't see changes, I really enjoy
like, you know, learning you know and I'm just curious about
things and some of the most enriching experiences I've had
in software development have been basically working with
people who did not have formal CS education.
Yeah, but came from a wildly different field like one guy
worked with you guys. Ali went to school for political
science and then discovered he could make more money doing web
development and he just had like a very very different view of
the world and it was really enlightening in a way and the
more perspectives you can get on a team to go into when you're in
problem, solving them better off.
You are the other thing as well as it's a nice going in going
really deep into your domain. Like I worked with a trading
company wants to basically brought in special training in
the depths of trading for the Developers.
Because they figured that having them have extremely deep domain
experience. Be extremely valuable for you
know what they were doing. Yeah, never pass up an
opportunity to learn something wildly different.
It can often be useful. Yeah, I completely stand behind
that completely agree. I actually know a guy, his
trading company has that with with the engineers as well that
they learn something about trading and the other way around
as well that the training people, the domain experts there
know, something about software engineering I just the basics
because that already helps with the dialogue.
I think and the dialogue is crucial right?
Without Community communication, nothing gets done wrong
problems, get solved problems, get interpreted incorrectly,
nothing happens. But with that communication with
basic knowledge about what the other person's doing, makes it
easier to speak that language, right?
Yeah, definitely. And I think that's almost like a
meta skill in a way and it's like if I think back about like
my career, yeah, somehow I've always been kind of thrown in
those situations. I've had to basically deal with
people who have wildly different models of the world, young.
I went to a university in Florida and practically
everybody. There came from another country
and so it's like there's a bit of a language barrier and it was
like that thing of picking that up.
And then I worked at a research Department company where ice
working with, biologists fluidics engineers, Mechanical
engineers electrical engineers, Optometry, you know, Optical
engineers and it's kind of like, okay, even communicate with each
other. It was just, yeah, I think it's
really a key thing to be able to go and try to sort of lean.
Another person's model enough to be the gun sort of, like, find
the common ground of communication.
I completely agree. One of the benefits there.
I mean, I joined a company and it was very Multicultural.
Like, we had kind of eight different countries where people
would come from and we were all in Amsterdam, kind of with In
the same team, obviously, kind of in a team of teams but still
the conversations that you would have.
Only I'm not even talking about the technical conversations, but
just learning about people. I think it enriched me as a
person right on a personal level and that made it so much more
enjoyable to go to work to do the stuff that we're doing
within that team, right? I think you'll always have a few
things that you go to work for for the actual stuff that you're
doing, the people that you're doing it with and probably, Are
you doing it? Because you can have several
reasons there and for me the people that you're doing with
right now, as always been the biggest factor.
And I don't think I see that changing Yeah, that's a good
thing. And I think the interesting
thing for me is to enjoy learning so much that I feel
like it. When you enjoy learning then
sometimes you feel you can get some kind of you can direct it a
little bit sometimes. So, so I think, when way of
directing it, which is kind of powerful for us in.
This industry is to become, genuinely curious about how the
systems that we work on work. I think, you know, quite often,
we can get into this thing. It's like, okay, this 10 year
old code, it's really difficult. It can be Info and it's like,
then you swerve Flinch at the pain in advance of actually
experiencing the code, right? Yeah.
But you can also kind of like approach it, you know,
metaphorically as, if you were wandering into a jungle and
you're exploring, you know, it's kind of like, it's, you start
thinking, like, some, I wrote this code this way.
Why do they write the code this way?
What's really going on with this particular thing and sort of
relish? When you get that experience of
the light bulb, going off, when you finally understand this and
something, that's rather complicated and rather alien to
you in a while. Yeah.
So I think maintaining that kind of mindset.
Yet, when you're working older, code is often a very enriching
experience. And I try to communicate that
with people. I work with because it's easy to
get into that thing. If like, oh no, I'm not working
on the bright, shiny new things, you know.
It's kind of like a good but you know, it's a Wilderness out
there and the Wilderness is kind of fun sometimes.
Yeah, I agree. I wonder because, I mean, you
still have kind of from an individual point of view you
want more knowledge, right? You want to learn, probably what
your goals are. You want to achieve those goals?
It might be doing more database stuff, might be doing more Cloud
stuff, might be doing completely something else within a certain
domain. And then you have the team
goals, right? And those kind of hopefully are
aligned but if they are not, is that going to create friction,
then are you going to Trail off somewhere individually?
While the team would benefit from you, you doing something
else. I wonder how that kind of
interoperates I think it comes back to.
I think I've mentioned a bit earlier is that if you going bad
and you're basically least aware of that situation, you can't end
of the bat. I think some of the most tragic
circumstances, I see our when it's kind of obvious to me that
somebody has like a completely different goal than the team
they're on. And they're not even really
quite aware that they're being pulled in that direction.
Yeah. I think it's kind of, but if
you're aware of that, then you can basically ask yourself the
question. Should I be here?
You know, I think that's a very valuable question.
You're going to ask, you know, if you have a deep interest at
some place else, But yeah, I mean that can happen.
I think there's AA quite often an awful lot of overlap.
And as we've mentioned, you know, the benefit of having
diverse opinions on one team is really kind of powerful.
I think you know for me when I feel like I'm in that space of
like should I be here because this is kind of like a really
interesting that over there. Yeah I can all find something
very interesting local you as well so exactly I know that I
can kind of like put that in my pocket.
This is something I've learned and I'll be surprised.
Maybe. 34 years that I pulled out of my pocket and that was an
experience that I had. I may not appreciate it at the
time but has made me a better, you know, a better developer
better thinker today. Yeah, yeah I think I am similar
in that aspect that I will find stuff that is interesting to me
that I can learn from right. Even though the the situation
might not be optimal. I feel like I find the silver
lining, the thing I can still learn.
If that is not there, then I know.
Okay, this is probably my exit. I've learned all I Have to learn
or it's time to move on basically.
But I've also seen the opposite where people are like, I've
tried this thing. It's not working for me.
I'm gone. I don't see anything else real
quick. And I'm like, man, we have a
plethora of things that you can still bite down on and take
ownership of right. Really.
Learn the depths of the depths there but they don't see the
same. Yeah, I think it's going to be a
personal choice for most people. I think for anything for me in
my first got into the industry, I'm very much into music and I
kind of noticed that there were some musicians that basically
would stay with a band for a period of time.
And then they would just leave proactively because they're kind
of like I've learned everything I need to learn here and I can
go on and basically be part of the next thing in advance my
career as a musician, right? Yeah.
And you know people can have different inclinations around
that some people, you know, enjoy doing that they're kind of
a bit of a personal Journey. You can learn more about
software development and there's others that just are happy.
I'm happy. If you know basically I'm
working the same system as working in five years ago and
you know, I think those are both very valid ways of being right.
There's there can be downsized moving too much so you can be
downsized to staying in one place for too long but it's
something that we have to make as a personal choice of to deal
with the consequences. Yeah yeah yeah I love you
pointing that out because there is no optimal, right route.
Right. There's too many choices.
Has too many opportunities. Everyone's environment is
different, even when there came from, everyone's journey is
different. So I also don't think there's a
perfect answer, a perfect choice, perfect opportunities,
there's multiple good ones. So as long as you're aware of
the opportunities, the choices that you have and you pick one
of them and you move forward, I feel like you'll be fine, right?
Because you can still switch diagonally.
You can make different choices. Don't dwell too much in the
past, I should have done something else but try and Try
and be aware of what you have learned, what you have gained
along the journey that you're on.
I think we're the most valuable things that people can do for
each other. Sometimes is to make them aware
of the fact that they're making choices.
Yeah, sometimes people are doing things and they feel like
they're that, you know, they're in a situation, they may not
like it, but for them to go realize that it is a bit of a
choice. You know.
We had to kind of do. Yeah.
And you know, yeah, let's go information sometimes.
I agree. I do that.
When people complain that they're stuck and I'm like, you
always, you always have options. I know I'll try and figure out
together. These are the options you have
right? Worst case scenario, absolute
worst case. You probably know what it is,
right? You remove yourself from that
situation, but you could still have a dialogue with with X.
Y&z might be your manager. It might be a teammate and those
conversations, they are not easy, they're not comfortable,
but they're very valuable because the more you have them,
the better. You get at them.
The way, you can understand the person sitting across from you
and the more you are aware of the situation, right?
Right, you're more aware of what's Happening.
You can probably have that communication to the best that
you can and you'll get better at it.
That's a difference between basically seeing your life as
something that happens to you versus something you engage in.
Yeah, yeah, exactly. And that's also where it kind of
I think that's the same mindset where the people that don't find
anything, that's there to learn. They remove themselves from the
situation because they're like a lot of things have happened to
me. I don't like it, I'll switch to
something else. Yeah exactly and there was a I
love the conversation started kind of from Team autonomy and
it kind of went off. All over the place.
I loved it. Is there a, is there still
something that's missing that you wanted to share?
Not really, I mean it's like there's any number of things
that we could get into with us. But I think the yeah, I like the
fact that we basically, sort of like, did a good span across
Tech, and social systems. So yeah, great, it will works
for you. That's great.
We'll wrap it up then. Yeah, exactly.
I apologize. Again, we had lots of technical
issues behind the scenes, but I'm really happy.
We still had this. Station.
Yeah. Me too.
It's kind of funny. I think the one thing is
freaking out a bit as a basically like when the video is
going back to me and I'm seeing myself on a delay but yeah I did
those it's one of the cameras behind ya guys in the in the
production room they all the camera work but let's run it
off. Then Michael feathers I'm gonna
put all his his socials in the description below.
If you've made it this far, leave a comment.
Let us know what you thought about the episode and thank you
again Michael. For, for joining us.
Thank you. Thanks for having me.
Take care. Thanks for listening everyone.
If you like the episode and want to support the show, don't
forget to leave a rating better yet.
Share the episode with a friend. Let us know in the comment
section below. What you want to hear.
I will make it happen. Cheers.