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.
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. 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.