Hi everyone. My name is Patrick you. And for today's episode, we cover systems thinking, we go over what it is in the first place and why it's becoming more prevalent as software grows more complex. I invited my guest, Diane amount a lien on who's currently dancing with systems over at metrics group. Love that Twitter handle. I'll put the links to our socials in the description below. And with that being said, enjoy the episode.
Welcome 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. I love the tea mug. He's me, I have a collection, some of them are gifts or they all have meaning. So, every time I make a cup of tea, I get to decide which mug to use, and always there's always some some good sort of emotional part of it. And so, yes. Me too. How many of them do you have that mr. Not a lot?
No, probably 20, probably a good 20 knots. Fits on the bottom shelf, but it's just neat to have meaning to feel connected to meaning in the choice and mood, you know, I choose different ones depending on my mood or sometimes to remind myself to stay calm, or whatever, the whatever it is in the day, another makes sense. It's weird. How when we get a gift, I hold a lot of value in that gift way more than what I would get something myself.
I actually don't really get stuff myself because, I mean, First of all, I don't need a lot of stuff and when I get a gift it's the more better. I think I agree. I agree. Especially with things like like the like a mug for coffee or tea where every day you experience the connection to the person that gave it to you. You think is yeah, I really like that ritual friend when she got married had as a gift. She said just bring Christmas ornaments bird. Christmas is.
And so every year, when she puts up her Christmas tree, She thinks it's an every person that that gave her, that that ornament. And I thought that was a wonderful idea. Yeah, I love hearing that II got a water bottle, which is a mean, sounds kind of stupid right by drink. A lot of water. I don't drink coffee, I sometimes drink tea, but water is what I drink throughout the day, and I love that bottle. I have multiple ones because people give them to me.
When I met my girlfriend, we were gonna date remote. She was moving to London within a month of meeting. Her. And I bought her this water bottle. And at first, I was like, who gives the person a water bottle. So I didn't bring you the first time I went, but the second time I did, I had enough confidence apparently, to give it to her and she still has that. She says, that was one of the best gifts because she had always those kind of shitty plastic ones that you would buy
in the store. So that's my, She carries you with her all the time. Exactly. Exactly. So I get that, some kind of emotional attachment to the stuff we get or the stuff we give. Right? Exactly. Exactly. Yeah. This is a lovely way to start the conversation. I feel much more relaxed. We can we can just keep it going from here. I don't need to do a countdown. We're already recording and everything. So welcome Diana, welcome to the show. Thank you.
Yeah we already kicked off starting to talk about tea and and water bottles so just keep it going. I invited you on to talk about systems thinking because I think it's getting more and more prevalent as software is getting more and more complex as our outside, world is getting more and more complex in the first place. But let's start with the system's thinking term.
What is systems thinking to you. So, it's interesting because I've really wrestled with that phrase and part of the reason that I have is because it depends on a context in your point of view. So an Academia for example it's developing a meaning and Technology. It's developing a meaning in business and even in marketing it's developing a meaning and so and so I've really struggled to integrate the Different definitions.
So, I've switched to using nonlinear thinking instead of systems thinking because then by then I can bring in things like pattern thinking, right? So when we, when we think about the orchestration in the system or or event-driven or the conversation, the relationship between software we're often thinking in patterns, Edward de Bono.
I I think he calls it parallel Thinking Out of the Box thinking all of these things are part and parcel of what, how I would Define systems thinking, but what we mean is that when you're thinking more about relationships patterns, the relationship between Parts. One of the, the one of my
favorite word's. It on in the subject is emergence, which is when the sum of the parts is more than any individual part could be. That you start having qualities that that can only happen because of the and if you put this and that you get a third thing that you couldn't have without that relationship that when you're when you're exploring that that's what I would call systems thinking. Yeah. If I take it back to software, right? If I put stuff together,
sometimes I have a side effect. I have this by-product which I can't really explain. But when you dive into that, when this happens in combination with something else, it's going to buy product happens that none of us could foresee. But I see it happening more and more, right? Because we're attaching a lot of stuff. There's a lot of Integrations, even when you're isolated, you still need multiple moving Parts within your application.
You're not going to build what you reuse, actually a lot of software. I mean, we We'll build a lot but we reuse a lot as well, which is great. But then kind of those byproducts happen when you say linear thinking. I'm I should think about really just cause and effect I guess in kind of a straight line. Well, so it's really tricky because we are so conditioned by linear thinking or linear thinking patterns that usually whenever we talk about thinking, it's what we mean.
And so for example this Ready to break down a problem into steps and then solve those steps towards a goal, that's a linear approach to and we use that in software all the time. It's really valuable a lot of a lot of Science is based on linear approaches. We usually when we engage the word concrete, we mean linear. When we say we want concrete thinking or a smart goals and linear thinking isn't separate from Near thinking, it's just not the container, right?
So, when we talk about systems thinking, or nonlinear thinking than it contains linear thinking, but it is not defined by it. Yeah, so when you compared it to software, so for example, because I most of my career experience has been in information systems and in content. So the shift we would install a piece of software and we would expand it and expand it and
expand. Expand it and add caching but the software was predominantly triggered by a page view request or a group of requests for the information but as we've moved towards towards a source of information, maybe we're editors work and and prove providing it. So for example, through graphql where you can in any time, right, and for asynchronous Cory, Geography, in any time, you can request information in multiple different types of requesters, you know, not just a
web page is requesting it. That's when you start to see a lot of emergence because then there's all kinds of things we can do that. We couldn't do before. Yeah. Right. Pushing and pulling information the the timing of what it means for something to be published or ready. Shared like that's, that's when you're still using software, but the relationships that you're designing Now, open up opportunities, that weren't necessarily there before. Yep. I like, I like the example of
graphql, right? Because if you compare it to normal rest apis, it's a bit more defined. What can happen within a rest API, right? You have this type of request and you only have these types of responses. Whereas, with graphql, your request can be lot of different things, right? Because it's available for you, the data to query, and then the response is based on what you actually asked. If the graph Q IPI, I think it's because things are moving faster
and faster. That we want more different types of information or two, different way of conveying that information or making available to the outside world. I think it's getting more complex that way as well, but it's getting a lot, interesting as well. Yeah so from my point of view that this is so this is one of my favorite subjects so you have it to dive into this. But so what happened? It used to be in you know, years ago. In my work we you build a house,
a digital space a website. Everybody did the New York Times And The Economist. And anywhere that anywhere that you went Amazon, it's going over to someone else's house and having an experience and everything was really designed for that. Yeah. But now people want information in the context, they're in. So it, you know what? It that's not just what device they're on, but also they're on different platforms.
And or in Facebook, or on Twitter and interacting with it, but also, depending on the context, they're in, they want different priority of information. So restaurants is a great example. Usually, if I'm sitting here at my desk, looking at for information about a restaurant in New York City, I usually want to see the menu and how to make a reservation. Yeah. But when I look at the same information when I'm on the street in Manhattan, I want Aunt directions. Yeah.
Where are you? Because usually, I'm on my way. And so this idea of this jet that, now our way of communicating is a giant graph. Yeah. And that we want to mix and match information, depending on the context that were in. And we want to prioritize differently presents. This truly delightful challenge to two systems design. That really just infinitely. Interesting, exactly. I love the restaurant example because Before you laid out systems thinking can have linear
thinking within it, right? Because it's more of an overarching, mean it's a system anyway. But with the restaurant example, it's one way. When you're at home, very linear what information you want to have and what you're looking for and then on the street is completely different. Probably in a different city, you're going to look at reviews. You have all of these use cases now and somehow, when we're building new software, we need to accommodate for those or even think about what we have.
And Then accommodate for that, which makes it infinitely more complex. If we just had a few use cases, right? But because we even have use cases, which we can't even think of, I think we just need to incrementally, keep going and discover and Implement. Basically. I think that's the only way.
Yeah. And it's so so that the challenge with systems thinking with with nonlinear thinking, is that out-of-the-box, we're truly terrible at it and and we're not Helped by the fact that we tend to be educated in a linear model. And so we really and more than
that. We all of our own cognitive biases, and logical fallacies, and all of, they seemed very real to us. And and we have to cultivate a lot of self-awareness to become aware of how our own thinking gets hijacked by our own preconditioned thinking and the ER, docs is that in order to see that we have to actually be good at nonlinear thinking to Nord, it's a see that we're not good at nonlinear thinking and so it's a, the way that I've been
writing and teaching about it is that it's a practice, right? It's not, you can't, it's not like JavaScript where you can go to training and then start, you know, in your writing code and it's more of a some principles and some patterns just I can systems. We are the system that we will
build, right? And so we have to adopt ways of working with our own patterns and find the the counter intuitive ways that we're operating that we don't really see in order for us to get better at Building Systems of software, and what happens, which is fine, it's totally fine. But I've seen this again and again where teams will go from A monolith to microservices, right, because this is really common in my part of the technology world, because that's what information systems are
doing, right? So the team goes from monolith to microservices and then discover they have the same linear patterns in their micro services that they had in the original software and that's because that's only so we could only change our thinking patterns so much yeah.
In order to build the microservices and that's fine because V2 You gets more asynchronous and less linear and so it's one of the things that we it's not there's no real lift and shift change from linear processes to nonlinear
processes. It's an iterative practice of Designing patterns but also changing our own approaches in our own ways of deciding what to do, as we're have more and more experience in more and more complexity, you know, I feel like Like, for myself, for kind of my personal journey, I was very much focused on kind of me. And the thing, the tasks I
needed to do, right? And as I got more comfortable with that, you move towards the team, and as you get more comfortable with that, you move towards, wait, what am I actually doing? What are we as a team? Actually doing and I come from an operations background. So, looking at different applications that are connected to each other, sometimes linearly sometimes in parallel. That's how I kind of got started in the adult works.
So then when I transitioned into software that kind of always stuck with me being that, okay, this is coming from a certain Source, then we going to implement something and then
it's going to X Y and Z party. But zooming out, I think that really just helps when you're good and comfortable in what you're doing, zoom out a bit more towards your probably direct sphere of influence your team and on their sphere of influence, maybe other teams, or parts of organizations to get an understanding of the system that at you operate within, right? Not even on a software space. But even on a business level, right, when a client actually has a problem, how does that get
to you? And how does that get to the software, right? And if that is has millions of hop scene between it then, do you actually know if you know your customer or you get some kind of version of that story in the first place? yeah, it's so for me the most The most essential initial practice, right? So then it's really the first thing I started talking about is, is in a single artifact that describes a task. So you know what your task is? Do you know why it matters?
Do you know why to the mission that you are serving this matters? And it's interesting because there's a lot of resistance to keeping that cohesion. And interestingly, I have experienced it from the People I we don't need, we just need that. You know, we don't need to explain what we just. I just want them to do what I'm asking them to do. Yeah, no yeah, no. I mean that's nice for you dear. I know that that's what you that's what it is that you want.
But we can't create code is Al is just a language and system speaks a coding language and people speak a, you know, English or German or whatever it is that they're speaking and that we can And we can synergize those languages better if we stay connected to the Y. And so it's really important that when I'm when I'm building something in my little piece of
the system. I also really do understand how this is going to benefit the the measured the system as a whole and the mission that that we're serving. And that's not really a trickier time-consuming thing to do, but it does go against a lot. The way that we organize ourselves to get work done, right? And so, so it really, this is the biggest challenge.
It's kind of like, when people adopt agile, but they still have a waterfall structure, but, and they put agile inside, then that, I mean, it works a bit but it's gonna push against the container. So it's the same thing with systems thinking and And bringing people's people together to, to work together towards a healthier system, a more robust system, one that has better relationships and create
emergence in that system. You have to start with, exactly how you said the task level, like improving the way we think about the, when we we move from thinking about investing in our or finishing, a jira ticket and we begin to think How are we, investing our time, energy and attention, where am I putting my energy and my attention in order to move this the software, the system or the infrastructure that contains it.
So that it is growing, right? Is growing, the whole ecosystem is growing and it requires often a change in the way that we lead as well as in the way that we code exactly. It kind of makes me sad that some People don't get that dialogue, right? That understanding of, why are we, why are we doing this? Or, why are we within a team
doing this right? What gold can does it contribute to which is makes me sad, because first of all, there's not a lot of Engineers. There's millions of job positions, not enough Engineers to fill them. So then when you actually are within our organization and want to be effective, if you don't get that information, if you don't get that dialogue, then it's just a waste because probably you're going to make some assumptions. All of them are going to be correct.
What? You're going to hit a strike now and then, and you are going to be correct. But with misinformation or lack of information, you're also going to make mistakes and those mistakes are not going to be bad, but they could have been prevented by just receiving the information. And really just having that dialogue. It really makes me sad that within some organizations friendly, you don't get that
which was a strange realization. Yeah, it for me, I confess it's very geeky confession, but it makes me systems sad too because of Conway's law that, you know, the way that an organization structures communication is exactly the way that their technology will be structured. If you want to see how an organization operates, you just look at the code and how the relationships in the code happen, right?
So, if you have an organization that that Wants to have a healthy system and to have benefits like you're saying like, you were saying, right? That is a byproducts that they didn't even expect like, they get, you get more than you give when you have a really good health East technology system, but if you don't have that exact same thing in the people, and the way that the people interact, you won't get that in
a system. So, it just it limits, what we can do, as technologists, it limits our ability to E to build and design things that, that matter and are useful and that grow. And, and that's sad to me because I, I like to see beautiful systems, right? And so they go, it's sort of like watching someone make a decision in their life that you know, is really going to limit them. Like it's not great for them and they're going to suffer the consequences of that. I feel like that about systems to.
Yeah, I get that it's still baffles. I might, I don't understand why that dialogue can't happen, right? It's something in that. Maybe in the people, the culture of the organization, I can't put a finger on it, but I hear more and more. That sometimes the dialogue just doesn't happen or the technical side of the operation. Doesn't have a seat at the table when decisions. Get made, for example, which is just I mean it's the basic element, right?
You grow up with it, communicate whatever you want together, we'll make it happen. That's basically what my parents said. We can always have a dialogue, right? And I can be incorrect or I can be correct, right? Depending on my age and how much I know about a certain topic, but there's always a dialogue.
There's always an understanding or at least from one side trying to explain for the other side trying to understand and somehow some we don't give the same time and attention within organization which is just ought to me. So it's really interesting you're saying this. I had not thought of this before but the that that is essential to system seek, like, you can't, you can't do systems or nonlinear thinking without what you're talking about. And that's the way I raised my son to the.
So if I say no, you can ask what you can we can you can ask. Why? Because it's right to have a discussion about it. You can't keep Sighing. Why? Why? Why why? What? That's not like them. Yeah, there was a time in which I said. No. And that's why is it? No no no. But when he went to college and then he was in a philosophy class and you called me and he's like um yeah some that the other student they can't think and this is what he meant Whitman. My son is now it microservices engineer.
Right? Surprisingly yeah so But it's this ability to have self-aware dialogue. Not just delegation delegation dialogue. That's not what I mean. I self-aware dialogue.
One of the things for me that I really lucked out earlier in my career I was on some really good teams communication wise and and the role of the product owner, the role of the technically the role of the people on the team and the All of the scrum master was all about this communication and rather than delegation what it was is. So at the end of the day, the product owner is going to be ultimately responsible for
delivering the value. And so if the product owner would suggest something and technically I thought it was a crazy. Not good idea, right?
Like just know, I would say that and we would have a discussion but in the end he or she would make the final Decision and I would respect it. And that's what I would do because I'm not the one who's going to, you know, I'm not the one who carries the responsibility, but the same with the tech, like, the product owner could say, well, I think maybe this or that, and I would still make the final decision.
And so I carried that into my career and I think this is why I eventually became a systems architect, right? And working at the Enterprise level because it it is all about communication. Vacation is funny because I'm on sabbatical, now writing a book and the eight ended up throwing away what I was doing and starting all over again.
And when I started all over again, I realized, you know, I was deciding between writing acting teaching the things I was doing before and writing code and going in technology and I made this big binary decision and now it's like, it wasn't it? It was a fake. Vision technology is communication. Exactly. Communication is taken. Like, there's no divert, there's no, my, my role is predominantly structuring thinking. And how is that really different from other kinds of roles that
structure thinking, right? Sadly. It's the same thing with in a different jacket or different challenges, I guess. I mean, the more and more I talk to first of all everyone that I've had as a guest on the show also the future guests, I'm going to have the I realize that the technical problems are actually quite easy, right?
If you break it down, if you go back to school, you think about the theory, think about an isolated problem, you can solve that problem, because that makes it very linear right, but everything around it. Connecting it to other pieces of software other teams in the communication around it. The more human side that is actually what we're struggling with that is actually quite hard, right? How do you fit that within kind of the overarching organization
and the structure? In the culture and the hierarchy there and then still be effective. That makes it a lot more difficult, all of a sudden. Yeah and it. So this this way, be dragons, but it's a dragon day so I'm going to go I'm going to say that Dragon Day part so so there are a number of things, so empathy, for example, yeah. When you talk about the, why and knowing the why write this requires a, putting yourself in
the shoes? Is of the people that are going to use what you're building or experience, what your building, which is one way of describing empathy. And then I've mentioned self-awareness right that you need to become aware of your own thinking and I would also add friendliness what I call Meta. Right? So this this ability to when you if you and I are working together and you share your idea that I see my role as As engaging with you to see if we can strengthen it.
Like, can we, can we add more good reason behind what you're thinking, right? So, it's a yes, and which I learned from acting and improv, it's an improv rule, right? You always say, yes. And you go with it, right? Well, Tech is a huge. No culture. Like no, no, no, no. Okay, no. Oh yeah. Someone is wrong on the internet like you and myself and my cell phone.
Included and so recently, I so while I've been on sabbatical in writing the book and pandemic and colleagues, at War, all these things that are going on, I went on retreat in which I was doing a lot of movement and a lot of self-awareness work and a lot of sort of rebalancing emotionally, right. So, I stopped reacting to everything and regain the ability to respond. And two things.
So what's interesting in my daily life is greater than 90% of the people I work with are when I'm teaching or speaking our men and on this Retreat greater than 90% of the people were women. And so it's like having about foot in these two worlds where we value one aspect of skill intuition as a big one, I don't know how people work in this industry especially as complexity Says without some intuition like you just kind of know, right?
And then systems are very counterintuitive, our intuition leads us in the wrong direction so we even have to learn how to trust and distrust our intuition. And so I was thinking at the end of this Retreat like we need to cultivate experiences that bring those two worlds together, right? So that a whiteboard test is not going to show you how people think about Relationships. But systems are only relationships than of.
I can be the best JavaScript programmer in the world and still be terrible nonlinear thinking. And so you have people that we're even saying in order to be
worthy or valuable. You have to be good at linear skills and we end the the others are soft skills of a colleague that I really respect and he started to call them core skills and he said it's been going Fine since he did that but for me I think it's the we have a cultural bias towards what it means to be someone good at Tech and that bias leans in the direction of a particular gender in particular race.
And and there is nothing about gender that makes one able to JavaScript exactly and so, but we don't the tricky part is that when we open up this can of worms, like it gets messy right away. Way, because it really isn't about gender. A lot of men suffer the same
kinds of things. A lot of women agree with the Nike. It's not, it's a very complex thing, but mostly it's just a way that we've, we've not merged the different skill sets that are involved in thinking and found a way to describe them in a somewhat non-binary way,
right? Exact. So And we need to, we need to give in pandemic and climate crisis and War and all the in the fact that our information systems are so vulnerable to abuse, we need to learn to bring different types of skill, sets than what we think of as it skills together or we won't, we won't, I mean, who knows? We won't? Where we won't get better systems? I don't know, I don't know
whether we survive as a species. Now that's a whole nother discussion but we won't get better systems will get the same systems that we already have in different forms. Yeah. Feels like a never-ending Circle at some point because somehow you need some intervention, right? But the people that are going to make the change. So new people can be brought in right with different sets of skills. You already need those decisions being made at the top level at
the people on the inside. I feel like if you're following a bachelor's degree Computer science. Probably I haven't followed computer science myself, but a lot of the skills, I'm assuming you get taught there is execution mode, right? Solving, an isolated problem solving, some algorithm solving some complexity issue. Something like that. I'm assuming. But I've also seen it in hiring, right? Do this kind of code lead. Hacker rank challenge, solve
these issues. Before you even have a dialogue, right? And before then I'm just talking to an automated email system that says alright thank you for your application. Do this hacker rank on a challenge. If you pass, then you get a person on the other end, which is so strange. And then they start still looking at very technical skills, but then first of all, the culture fit happens. So you already need a technical bar that you need to kind of
reach before. You can do, that culture fit, then you can see, okay, is this a good match on an organizational level, then your questions even get asked? And hopefully answered, but the bar is so high to get that conversation now, Days, which is so strange. I do see it changing, though. I more and more that conversation. Number one is just a culture fit and then it's a dialogue more about technology and everything around it. Rather than the actual execution
solving an isolated problem. And therefore I'm kind of hopeful that we're at least moving in the right direction. So it's interesting, I this is this is we're heading all my favorite subjects in the very fun that. So there's some of the best hires that I've ever had ever done in my career. The people that I hired did not have the technical expertise in this in the software that we were working in, because they learned that and they learned it fast because that's what we do, right?
I mean, whatever the skill set, that I started with what I was coding when I started, I don't code that it like that's not what I do anymore. They just so many constant skills. So I do think sometimes that suppress, sometimes you need someone who who does already. So I don't think that that's a universal doesn't matter if people have technical knowledge, it does matter for sure. But I've had great success not prioritizing that.
So it is very encouraging and I've never seen it fail, people learn or they don't that's what kind of gas. What we do. Yeah. But the way that the way that I the way, I think it's been most successful at least for me and then partly because it matches my style is that someone comes in may bring people from the team and someone comes in with a problem that they solved, right? And they walk us through it like, they walk us through. Here's the code here was the problem.
Here's how I understood it and that if 20 minutes later, we forgot that this is an interview and instead We're just all talking about this problem. And, you know, the, those other Engineers we're asking like, oh well, why did you do this? We've had that in the past ouo and you eat and then then then what else do you need really? Yeah. Like then we're going to continue to solve problems together and be able to work it out and be able to think well together and that's that's mostly.
It's mostly what? I what we do, right? Least for me that's what mostly what I've done. And what what I've done with teams and and the there's an interesting Quirk and it's kind of embarrassing to say I'm from it's funny because I feel a bit embarrassed to say it, but it's true. It's an interesting Quirk is that I've worked my entire career I have never not worked. I have always had the next thing as always come in.
The next thing is always come and I make A lot more now than I did when I built my first Drupal site for a local YWCA. That's good, many, many years ago. And so, so it's that way, if a very successful, I have never been hired through a traditional hiring route. Okay. That that I haven't done that very often because usually the next thing comes along and the next thing comes along, but a few times in my career, I have
done. Knee, like met someone who's like, oh, we're looking for this and submit your resume and I, it's never led to a job that way and I could be me, it might be me, but I think it also says something about because the, I mean I've been really successful for some of the same companies later when I came in a different way. Yeah, exactly. And do you think, I mean, you're probably on the inside, do they still do those traditional hires? Because this is more of a We
already know you. You start with a dialogue, right? Do other people. Get that same treatment when they come in. So I think some people are just good. Also, at the way that we that we at that structure, they're just really good at it. So I think a lot of people who, you know, are great to work with terrific to work with do fine in that structure and they get hired. But I know a lot of people who are more glue roll people, right? Which would be the systems
thinkers writers. The non linear thinkers. A lot of people have had really dehumanizing experiences in companies that everybody would know and think are awesome to work with. In fact they found it just humiliating really. So I think it's kind of it's like public education. Like not every 12 year old is working at the same level and every subject really.
So we have a linear model and some people happen to fit really well in that near model and some people don't and we don't question the model I have seen in my career and maybe it's just the way the environments I've ended up. I've seen more whiteboard testing as a way of hiring now than I did say 10 years ago and I am concerned about that Trend and not to say a black or white, yes, or no, good or bad. But I do think that this task Stir.
But this brings up a whole nother subject of communication in a hierarchy and nothing brings out our our our ego structure, like hiring, right? Like we like we like that a lot of us, a lot of us do, right? We sort of like that some of it feels like hazing to me like we're all applying to a fraternity and we have to get through this hazing in order and that isn't Partnering for for Progress, that isn't Collective, reasoning and collaboration and the kinds of things we need for
systems. So I think one of the challenges is as soon as we get this, this power aspect. Yeah. Playing a role then it's like Schrodinger's cat, right? We looking in the box that would change the result so we're making it really super messy. And also that you say that I'm sorry, no worries. It's interesting that you say that because I recognize that I, I got hired when I was, I think 21 and then at 22, I needed to do an interview but I was, the not, the interviewee.
I was the interviewer which, to me was weird because the person sitting across from me, was probably in their 30s or 40s and I had a resume and I needed to ask questions right already in my mind, there was some kind of weirdness here because there is some mean it was weird, interviewing someone.
When I was older than me, even though they had probably far more way, more experience than I had, obviously, in different areas, but still somehow it's shifted and I hadn't realized that until you said it, but now it's just a dialogue, right? I start with the conversation with listen. We're equals this needs to be a win-win. So we're also going to have that communication that dialogue as equals, right? Because in a team that's already
there. As soon as we hire, you were one in the same within the same team basically. And that's how we should treat each other. I don't know for myself, when it shifted, when it didn't become this weird hierarchy thing, but it just became kind of an equal level of communication. But I'm happy, I realized that now and I think it changed for the better actually. Yeah, yeah. And there's a difference between judgment and discernment, right? That we are.
We have to discern, we don't have to make a choice here, right? And there's some discernment that goes with the choice, but that doesn't have to be judgment or fact, or any of that. And, and also, we also many of our own biases, get in the way and in Tech, their reaffirm reinforcing. So you were telling you or
talking about computer science. So for me, I went to my mentor after the second year and I said, This isn't work for me is that I just took a final exam where the person who we all wrote code and the code fought against each other. And the last man standing got the a, this is not academically interests. Exactly. Oh, Come to Me said, I feel like I'm in a room full of Tonka toys and Legos and these, and I like those toys, but that's all that's not what I'm trying to do in the world, right?
And he said, and he was the reason he was my my Mint or whatever the right word is is because his class is terrific. That's what got me into computer into programming in the first place. And he said, he said, I wholeheartedly agree, Diana, I wholeheartedly agree. And I want to hire more diverse professors, but in order for me to do that more women have to stay and get a PhD, which means we have to go through the gauntlet of how things are.
And he said the thing that you don't know, No, though he said, yes, we've got these whiz kids and I was 35 when I learned to code like I didn't I had a whole life before I went into Tech and so in he said, he said, he said the thing you don't know though is your who business wants? He said that.
Basically what you're saying, he didn't say it this way, but it's what you're saying, it's the ability to have these strategic conversations, it's the ability to think this way that you've got these whiz kids with this incredible Tech skill. That's only part of the equation and I was getting a so it's not like I was struggling to write the code but I was struggling with the, with the, the culture of the structure of the work and the what we thought was winning, what?
What? The other people, the other students thought was winning is not what felt like winning for me. Yeah. And so that that has been a career-long challenge. And I have worked with many, many people. And, of course, almost all of them men, who have been instrumental in my ability to do what I do. I've had people throw me into in seemingly, impossible challenges and trust me to code my way out of it raid.
So it's definitely not, you know, it's not a duality and there's a lot of complexity here. But again, when in the G that I was in, it was reinforcing a set of cultural values of communication values of all kinds of things that didn't fit me and didn't have anything to do with whether or not. I should continue in the career and that happens in almost every organization and especially around hiring. Yeah? Right? We make assumptions that other
people will think like we think. And so we're testing to see if they think as long as we're testing to see. Do you think like, I think? Because that's what Counts. Yeah, well have no diversity. Exactly have no diversity. Will have no systems. Yeah, I completely agree. Right. On the other hand weight on top of that, we need both, right? You still need people that are the glue. As you mentioned it right there are great at communicating great at the riving.
Okay? Where's the value challenging? The product owner, for example, challenging the stakeholders in a way as well with that technical knowledge that can still execute, but that might be better at gluing things together. When it comes to dialogue and communication and then on the other hand, people that can execute when you give them a problem, they have X ways of solving it and they choose probably the right one, the most scalable one, the most effective one depending on what the
environment asks of them, right? If it's time they can be the fastest possible. If it's quality, they can build the best quality service, but you need both probably within the same people, but people are not necessarily equal, right? You can have your preferences, you can tip that. A little bit more towards glue or tip that scale a bit more to his execution. I just think the Whiteboard and the execution side is so well defined because that's way more
linear thinking way more. Okay, we have a we have a problem solve it. We'll see how you do it. We'll have a dialogue along the way. Where's the glue side is not as refined, I guess.
It's it's more soft. That's why it's probably called soft skills and that also makes it harder to test right harder to make it quantifiable if the person I'm talking to Actually has that or his movie faking it or is maybe just really good at storytelling because that also helps if you're great at storytelling but maybe they don't know.
It's hard to measure. If you can actually execute that within the current organization because it has a lot more factors going against it, I think as well. Maybe that's why the Whiteboard is just way more out there. Way more chests in that way as well. Yeah. And it again linear thinking is what we think is thinking. So we, you know, there's a lot
of reinforcement for that. And this is why the practicing pattern pattern thinking parallel thinking these things are really helpful, also, empathy, communication, self-awareness, it being embodied that, you know, we most of our reactions to things are not going to help write it. We need to be able to respond, which means that we need to Be able to process what we're hearing from other people and synthesize it with our own knowledge and judgment.
We need to proactively proactively, get other other people's experience and blend it with our own. And so these are real skills that you can practice if we're willing to think of them as it skills and the better we get it, that the more will develop something a little you know won't be a whiteboard test, but it will become more apparent to us. If someone has cultivated that that skill set and there was something you said that was very provocative. I wanted to respond to it.
Oh darling. Run out of my fucking about the kind of the glue in the execution, more tipping the scale and how he knew both. Yes, because of this is the star like to me. This is the highlight of at least for me the most valuable lesson that I've learned and that is Ownership. So a long time ago, I was lead on a team and there was some discussion about whether other teams needed lead or the role of leadership and bless their hearts. When the question came up of
what lead was? Someone said oh, it's team secretary. Hey, well, there's a loaded word right there that. Yeah, exactly. Like you know, like I don't want to have to be doing the communication. So first I learned that I was Doing the communication because my teammates didn't value it. And so that was a really important lesson to learn, right? Because I would just going to play Wendy in the island of Lost, Boys, for my entire
career. If I did not realize that the ID I needed to not overcompensate in that way. But also another engineer who was terrific and I still still one of the best ones that I've worked with. He said will die. And I want, I just want my code to speak for me. Your code doesn't speak speak like literally doesn't speak. So I stopped doing the communication and the team had 20 points prints because there was so much happening there that made the code deliverable.
But what came out of that is that he and I write code speak for me. And me we figured out that together we are better than the sum of our parts and he's the person I always want like Exactly what you're saying, the the execution, the like, no matter how good my code or my my architecture is he's gonna make it better right, conversely. I think I'm great at business language, I might speak normal.
I'm not like a Super Geek I speak nor oh yeah, until I try and do it. And then we would like to have pointed back in my career there, like read that paragraph Diana, and take out all the text speak in that paragraph, and I have to get rid of half of It because I still that's how I talk, right? Yeah. So I think I'm good at it and I'm not. So I partner with people who are good at it and together we one of my favorite Partners was he
was head of Graphics, right? So he's a speaks, a very visual language and I do not even though I'm an architecture is really weird because I have to make models and speak visually, but it's I've had to really practice that skill and I was not Born with it but I it's also because I learned from him, they just Basics. Like Diana, there's no key. There's no key on this picture that you've made what to any of
these symbols. But we don't need keys when we talk engineer to engineer because we know what we mean right? We presume we do but as soon as you talk to people who don't speak our language, they don't know what it means. So this this that a team is not a silent that we love this hero. Visual thing. But if you really want to build complex, interesting matter full systems, it's about the Synergy of bringing people together who can blend their strengths and compensate well for their their
challenges. So that you have exactly what you're saying. The execution, strong, strong execution, and also the willingness to always be learning like, no, it's it's hard for me to go into a team, which I've been recently were a team. They're brilliant, they're brilliant. And I'm supposed to be contributing but I'm learning as more often than I'm actually offering something valuable and that's how it should be. That's exactly how it should be.
And if we don't if we're not Is that not how we view relationships within technology teams or between the teams or in leadership? Then we're really again, it makes me systems sad Greg, we're going to limit our ability to create something. That's better than any one of us could create a loan. Yeah, I mean even within that team, right? You could call it a system because if you partner up if you release synergize then you're going to create that by product for talking about my love.
Dialogue is going to happen if we're going to realize together then actually oh we could also do this. We don't just have a and b, which I thought I had a, you thought you had bo. There's an option C because we have that dialogue and you can be that way loyal machine that a team should be, but you can't do it all. I used to think if I multiply myself and I was in a team of
Patrick's, we get stuff done. I luckily now realize that's actually not the case, I'm actually not as good at a lot of things that still are required. Right. But that's what we synergize, and we can synergize best by having diverse backgrounds, diverse people within that same team and knowing, and having that dialogue. What each other is actually good at what their preferences are, what we can help them win, or how we can still that share that
knowledge, right? Because I still want to know the things. I don't know that other people are better at, right? You're never going to stop learning. And I think, the only thing you need, there is just the hunger to keep learning. Yeah, and be better. That because of it. Right? And that and then you get to the next level rate, which is now for me when I make an artifact.
So an artifact can be anything really, any way that I'm structuring thinking to share, right to for people to give feedback or to see basically to show if we've come to a conclusion, then I want to show how we came to that conclusion. What are the reasons that support? But I'm saying, here's an action. I recommend here are the the strong reasons why I This action and also, some of the risks and, and weaknesses.
And in. So, in order for me to make a recommendation, that is sound, right, that I is trustworthy might not be right? Yeah, but it sound and it's trustworthy is I have to go find the people who don't think we should do that and understand why they don't and then discern. So does that change, does that change the way the argument that I'm making, right? Then I'm the conclusion that I have come to and if it doesn't then I need to handle it.
This A this is a point of view and it's a valid point of view and here's why I'm not I'm not flowing with that point of view like here are the trade-offs because we think, oh, do we think? Oh, we think we think there's a right? And a wrong. Yeah, we love and I love it. Like, at being at a conference in debating. Like how you do configuration Management in a piece of software, 2:00 in the morning, is one of my favorite things to do.
I'm never Up at two in the morning and less amount of conference something I've missed so much covid is are debating things as if there's a right and a wrong answer, but there isn't, there's only in the context that we're in. This is the best possible solution. We could come up with together by thinking together and also outside of our own little bubble and we've come up with. And so then we're going to try it. And we're going to see See what happens.
And if we're wrong then we're going to learn, right? Exactly. And that's not that again. This is where the root of linear thinking concrete, right? Or wrong yes or no show me how this is delivered you know break this down. Show me how it's deliverable the you're too abstract you're too abstract everything, the whole point. We build what we think. So, if we can improve what we think, we can't improve what we build. And so we as this the, you know, people say about well concrete concrete.
So if you have an architect, that shows up on the piece of property and immediately says, pour concrete over there. That's not what you want that role, right? You want some discernment because once that concrete is, is poured. That's where the house is going
to go, right? The same thing with software and there's a even there's endless discussion about the word architect and the role architect and engineer versus Team versus Rural. And sometimes I find it offensive and sometimes I find it tedious. And sometimes I find it incredibly interesting and energizing it really depends on my mood and also the where the
conversation is going. I was at speaking once sitting at a table at lunch and some Young man sat down nice and he saw that, you know, I was a speaker and Architects and he's like oh, you're an architect. I want to be an architect too but I don't know enough of kubernetes yet. Oops, that conference most of the other speak, most of us were constantly engaged in that discussion is senior technologist. Or is it?
And then a lot of people hate it because it's another hierarchy role, which I don't know how any architect it succeeds in that I need my teammates. Educating me like sorta to succeed. So I can't. And besides, I don't like who are they working with? With, I never worked with a team that wants me to tell them what to do, they that would never have worked for me. Like they wouldn't have done it, like, it had to be Collision.
But what I mean is that someone has to be the voice and thinking about the system as a whole, how the patterns and how the parts come together. So that some of us can focus more deeply. Some of us can focus more broadly, some of us can focus on business like big, so again, it's a Synergy but it is the one who is going to And nonlinear thinking, and nonlinear approaches and structural challenges, and tweak the abstract. So that the abstract is sound and and and strong and well
synthesized. Exactly. I don't think everybody has to do that, but everybody does do that like, it's not, it's not either/or, it's not that, I don't code. It's not though mostly I don't because there's too much. Alexa tea for me to stay constantly engaged but I do I still do that but that's not really the point. Like it's the - about we're all actually building the same thing.
Yeah, who are you speaking for? What are what's your point of view that you're contributing and what are the different points of view that are necessary in order for us to have sound reasoning? So that when we build something, we can be pretty sure that we've made a good guess and it's exactly. Yeah, and it's all about kind of getting that shared understanding, right? Because within that team, it's great. If everyone understands it to the same degree, right?
That's not necessarily required, that would be great. But you only need to understand it to a certain degree and then from a role of an architect, that's how I see it, right? They probably understand it more or better than the teammates, right? Because they are more involved
within that. They're also think about communicating that to the business more so than the people that are Within that team so it's a Synergy, it's relying on other people for certain skills and that makes the team actually a team at the end of the day when they can rely on each other learn from each other and execute the best. A team can. Yeah, and being open to flexibility that. Like I've had a number of different titles of CEO was my title once in a real Anna, in a
start-up. Like it depends on the context that you're in. What you're going to speak for like, what you're going to speak for and then what you call
yourself aligns with that. So it it, you know, I, at the end of the day, I think, probably in my heart of hearts Engineers, always going to be my favorite, my But it is it is someone I've learned so much from an expert in knowledge system, Knowledge Management wisdom like how we cultivate wisdom through Knowledge Management and has worked with some of the very biggest biggest brands and he said, you know, if you're saying Knowledge Management or information and
people aren't that, that's, you're getting tripped up on that. Don't call it that too. Stopa just practice the principles and I find this with agile, I find this with architect, like we got a bit hung up and people have had bad experiences and then they think that's the thing like they've had. They've worked in not really agile and then they don't like
agile, right? So so some of it for us to is about being contextually, strong in principles and strong in our practices, but a little less opinionated about what we call them. And I Reframe them. They were learning and and maturing ideas every time someone unfortunately it's like the virus right every time someone adopts one of these practices. Then it mutates somewhat. It change that connect and it
grows and it becomes stronger. And so, so that's another linear and kind of concrete way that we like to have absolute yes, or no, right or wrong. This is what we do. This is what we don't do. And we don't, I am a very I do. I my job is very hard and I think it requires a tremendous amount of self-discipline and and a lot of work but it's also can be very fluid and flexible and I think that's true in educating ourselves about anything. Like I'm definitely not. Someone once said was on
Twitter, they was unstructured. Learning is a complete waste of time. Like I said, like what, how who how do you get through a day without any unstructured learned? Like, we, like, we're constantly unstructured learning, but at the same time, structured practices are good. So what are they? What's that balance between just enough structure in order to, then be able to discover? And they think that What an
architect helps to do, right? It helps to create just enough structure for what we're building.
So that and with people building it not off on their own, but with people building it just enough structure and that structure is flexible enough so that it can some can change and some cannot and you're clear about what you're marrying and what you're dating in terms of the ideas that you're that you're that this this has but also creates the space to play in. And, uh, space for ownership of that, and a Reliance on other people's expertise.
So in the work that I do now, the, the moving pieces, especially so AWS is a great example. Like every three seconds, there's a new tool, I guess something a better way. And there's no way for me, these are not founded a to be the expert on all of that, all that. Exactly, but I don't have to because I work with brilliant people who know their head I gave you No it.
So it's okay for me to be wrong. I'm usually right about things like structure and patterns but I won't necessarily know the best approach but I've got five other people, it working with me to figure out together the best approach. So I don't have to know. I just have to know enough to make sure that were maintaining integrity and conceptual Integrity across the system and that we're asking the right kinds of questions about the type of patterns.
That will make a system like feedback loops will make a system grow and and I don't have to be the smartest person in the room or the most expert on this particular software, that particular software because it would hold everyone back. If we were limited by only what I know. And also that wouldn't be interesting to me, like, I think it's a do this, please? No worries. I think it's a, it's a strange comfort that you It from
realizing that right? That you actually, you don't have to know everything, it's fine to say, I don't know, but we can figure it out or I don't know. But I know, you know. So as a team we could figure it out, right? It's very comfortable because then all of a sudden those closed doors that you're standing in front of they get opened up right.
And you have way more options because you have that those people around you, those people that you could learn from and those people together with you can execute. Basically, I really love this. Conversation. It kind of went when all over the place. But I love the route that it took. Thank you for coming on Diana. Oh, I'm sorry, there's a little bit of a lag. I think. And I keep interrupting or is apologize for that.
No worries. I wanted to say, I want to thank you for coming on because it's very, I guess the last thought about this, right? Because I think we've landed in the exact right place and it's the secret Truth. For me, the teams that are really good at what you and Just talked about, we deliver a lot more faster. Exactly. That actually also been the most successful at doing what we're doing teams.
And the ones that really struggle with this or not, haven't just been painful, but we also get very little done. So, in my secret heart of hearts because I actually really liked building things. I'm like, but this is what works mentally like dead. Get out of our own way. So I like that we landed there like Effectiveness we It came from abstract and right back to, this is actually just how to write code, like, pow to deliver products, or whatever it is. We're building. Exactly.
I love the route that I took. Again, I want to thank you for coming on. I'm going to put all Diana's socials in the description below. And with that being said, thank you so much again. We'll see you on the next one. Great thank you. Thanks so much. Thanks for listening everyone. If you like the episode, I 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.