��Ӱֱ��

Episode transcript

��

[MUSIC PLAYING]

��

Alexey Boas: Hello and welcome to the ��Ӱֱ�� Technology Podcast. My name is Alexey; I'm speaking from Santiago in Chile, and I will be one of your hosts this time, together with Scott Shaw. Hello, Scott.

��

Scott Shaw: Hi, Alexey. I'm one of the hosts, also of the ��Ӱֱ�� Technology Podcast. I'm based in Australia, and I work across the APAC region.

��

Alexey: And this time around, we have the privilege of having Ricardo Cavalcanti and Arturo Santos here with us. They're both from Brazil. Ricardo, I know people call you Caval, so I'll call you Caval. And would you mind introducing yourself to our listeners.

��

Caval: So I'm Caval. People in ��Ӱֱ��, especially, know me as Caval. Anyone would have a hard time calling me Ricardo. I always say if someone has to deliver me a package in the office, if they say it's for Ricardo, I just won't receive the package. So, Caval, I'm a technologist at ��Ӱֱ�� for about 11 years now. I come from a dev background; acted as a tech leader most of my career. Past three years, I've moved to a managerial position — I'm a market leader, as we call it here. I manage the local Brazil market of the clients we serve at the local Brazil market here in ��Ӱֱ��. I'm based in Recife in the Northeast of Brazil. Yeah, that's me.

��

Alexey: Amazing. Thanks for being with us this time. And how about you, Arturo? Could you tell us a bit about you?

��

Arturo: Yeah, for sure. So I've been at ��Ӱֱ�� now for eight years. I also come from a developer background. I have played a tech lead role on a couple of engagements here at ��Ӱֱ��. And since last year, actually, I'm moving to a position closer to the quality part of the projects. So I'm anchoring the quality strategy and quality-related aspects of any engagements at ��Ӱֱ��. I'm also from the Recife office but based in a city close to it, three hours from Recife, called Maceió. So that's me.

��

Alexey: That's great. Good to have you with us. And so I'm thrilled because this time we have the opportunity to talk about tech leadership. I find the topic fascinating — and I'm sure many other people do. So I know you've been compiling a list of styles of tech leadership, so maybe we can start with: what is a style of tech leadership? So you'll tell me that there isn't a right or wrong way of doing that, here are different styles — so what do you mean by that?

��

Caval: I can start. Well essentially we– I mean, I think we all would agree that there's no right or wrong way to do tech leadership. There's probably multiple ways that you can call it wrong when you see it, but there's no right definite way to do it. What we called styles, back when we started discussing it, was ways that people would act and interact with other folks in the team, and stakeholders from clients, essentially ways to solve problems, ways to deal with situations essentially. And certain… we saw that certain folks would do that in a kind of a style or a manner that would repeat itself; would have some similarity to like in the daily fashion. And so we compile these ways of working, let's say, or means to act and interact with folks. And we call that styles of tech leadership.

��

Arturo: Yeah. Something else that we are trying to do is, having based on those styles of acting on the team, what to be finding and documenting, based on our observations, what would be the benefits of doing and acting like that? And also what you could find as a problem in a period after you act in this way on the team. So it’s almost — you can see these styles as almost a documentation, what are the advantages and the consequences that you have to deal on so we start acting or working the way that we describe on these styles.

��

Alexey: And where did it come from? I know that both of you have extensive experience in working in different projects with different teams, and also seeing different teams working in several different contexts for clients and those kinds of things. So did it come more from observing different teams? What brought to you to start compiling and cataloging different styles and putting that together?

��

Caval: It all started when I was in a big client in the US, and back then we had like six or seven teams, each one with its own, like, tech leader. I was– so to say, the leader of the tech leaders, so I could essentially observe and, I guess, the best way of learning — learning from someone else's mistakes. And in that, I could see that each team had a different manner of solving their internal issues, dealing with conflict, dealing with stakeholders that they had and so forth. So from that almost… I guess back then they already had like six different people, different styles of working, and then we started with those, and then we thought about our own experiences, and then we thought about a structure to map those styles, and then we came up with the catalog or the catalog that we built essentially.

��

Arturo: For me at the time that we started building, Caval and I had actually worked on an engagement together, and he was kind of a mentor actually when I was on this engagement. So we had these conversations on what were the capabilities that I had to evolve to become one of the tech leads on this engagement on this account? And then he called — he asked me to join on this effort because I was both someone who was eager to take the role, and have a good experience on doing it, and I was actually on the beginning of doing my first time as a tech lead, so it was a really good, a really good experience for both myself observing and translating that the way that I act onto this document, and also coming from the past experience at the engagement at ��Ӱֱ��. Also documenting what I could observe as the other people were doing the right things, and also coming to the mistakes we usually see when acting as a tech lead.

��

Scott: It's interesting that you said you observed these styles within a single organization, or maybe two organizations combined. There's a lot of different things that could — I would think — organizational culture itself would be one of the influencing factors, but I'm interested in hearing what are the… is it the team? Is it the leader? Is it the technology that's involved? Is it the organization? What dictates the style?

��

Caval: Well, my perspective, it's a mix of all of those actually. For example, so just to dive into a little bit of an example: one of the styles that we mapped, it’s called democracy above all else. It's like, kind of a leader that is always trying to put things to vote, and trying to solve things through voting inside the team. In the case where the team is very young and junior, you can see that not working really well, because they don't have the education to do like a nice voting session. So essentially, in such a team, such a style would fail miserably and rapidly. So it's very easy to see this style essentially being ejected, and being not used or essentially failing rapidly.

��

Also for such a style to occur, I would say there's a huge need for organizational — the organization must allow that to happen, essentially. So depending on the stakeholders, these ways of working would take longer to arrive at decisions, and so some organizations just wouldn't allow such a time to take and to have come to a decision. So this will all happen. So different styles would have different factors to influence more or less, I would say so, but essentially all of the above, I would say.

��

Alexey: Yeah, and I would imagine each style has both strengths and weaknesses and things like that. So how did you go about? So you mentioned this structured to each style, how did you structure that? And maybe we can get into a couple of more examples just to get a feel of that.

��

Caval: Yeah, sure. So one thing that we started from was that, I mean, obviously, it is just — it comes from observation, so it's not like a scientific methodology or anything, but we wanted to have a catalog that would be easy to someone to consume. So inspired by the many catalogs we have in software engineering, like the Gang of Four, design patterns or the refactoring catalogs, we came up with this structure. Essentially, we talk about the consequences of using such a style or acting as such a tech leader. We talk about weaknesses and strengths of such a style because there is time for everything. And also, if you want to develop yourself into that kind of leader, there's some skills that you have to develop. So we also listed some of those skills. This is the main structure of each style.

��

The styles are also not very, I mean — they talk about ways of working, they talk about ways of acting, but they don't try to be comprehensive in everything that you have to do as a tech leader. Some of them will focus more on how you communicate, some of them you focus more on how you make decisions. So in some sense, I would say they are not necessarily mutually exclusive or anything. It's just like patterns of behavior that we observed.

��

Arturo: Yeah, which is something that we also talk about on this catalog. When we are talking about the styles — on the catalog — we even say that on a given day, in different meetings, you can act and use those styles to choose the style that better fits the situation, and work and play with the benefits, the advantages or the consequences of each of them. So for instance, on the scenario that Caval described on a junior team, you can be a benevolent dictator and also be the democrat that opens everything to voting on the same team, but in different situations. So if it is a light decision, something that you have well envisioned the consequence of that decision, you can open for voting on the team. But if it's something that you want to have more control on the inputs or the outputs, you might play as a benevolent dictator. So you will impose your decision for now, and then work with the team to document this decision and evaluate what was the impact of the decisions in some time later. So you can — by doing that, by putting writing down these on the catalog, we want to basically provide some tools to those tech leads where they can play with these styles, and when opening for voting, they can promote open discussion with the team, understand what are the interests or what is the experience from the people on the team, and take that and leverage on the future, for instance. So we have the catalogs focusing on these consequences and the advantages, basically to facilitate the work of the tech lead on these scenarios.

��

Scott: One of the things that I'm puzzled by, I guess, is with a more democratic or collaborative style. Who takes accountability? In the end, someone has to be accountable for the decisions made. It can't be a — if everybody owns the decision, maybe nobody owns it.

��

Caval: Yes, that's exactly one of the weaknesses of such a style. One is you could very easily arrive at suboptimal decisions: you make decisions that are just not the best decisions just because not always the voting or the majority has the better idea. And also you could have, such as in democracies, you could have very — people that have a very high level of influence, but they're not the ones accountable for the decisions, but essentially, the one that come up with a decision has to pay the price for the decision made in such a style. So that's why it's like a double edged sword, essentially. I also agree with you, Scott that someone has to take — has to be accountable for the decisions made, regardless of how you arrived at that decision. So that's definitely one of the risks of having such an approach.

��

Alexey: Yeah, I think — I think it might go back to what Caval was saying about the maturity of the team as well, because I have seen — I have seen teams in which they — people just felt that they had a vote and there was a democratic process, so you needed to respect the vote. But I saw very democratic teams that just felt that everyone had a right to provide input, and to have a very healthy discussion, full of passion, full of very strong opinions, but then someone would make the decision, and everybody would back the decision taken at the end. So it's interesting because I think it goes back to that maturity thing about maybe the level of experience of the people, and even how much the team has bonded as a team. I guess it would change the flavor completely of something like that.

��

Caval: Yeah, absolutely. Essentially, to increase the level of commitment as well, that's a nice way to increase the level of commitment of the team. Essentially they choose that. And the other — on the other hand, if you are the one that lost voting, there's probably some motivation — some work to increase the motivation of such people. So disagree but commit is a very nice principle to go together with such a style.

��

Alexey: Another interesting thing was what Arturo said. So you can have different styles in different situations — so maybe you have one conversation, you use one style, and then the different conversation with the same team, you are left kind of using a different style. So based on what you've seen, how much, how intentional are people in using those styles? So do people consciously pick and choose different styles for different types of situations? Or, in your experience, have you seen people just defaulting back to a personal style or to a team style and being more kind of an unconscious process that just happens, and the team just functions in that way under that style? Or have you seen people being more consciously making a choice of switching styles in a different situation and things like that? So how does that work? I'm curious about that.

��

Arturo: This is a topic that we have discussed while putting together the document. The conscious part is very cost for any human, so you have to be aware of all of your current style to be able to switch to one different style and act like that for some time, and don't default back to what you usually do. And this is something that the catalog also helps, which is you want, at the end of a day, for instance, there might be some meetings that you have to take a decision. And if you are choosing to be an enlightened dictator, this will pay heavy on your cognitive load by the end of the day. So you might just defer the discussion to another day, or even as we discussed during this putting together the catalog which is you can go as a dictator — an enlightened dictator — but given you’re tiresome, you're tired, you can fall back into an open discussion and start gathering some inputs to then go back to the decision and impose your solution, for instance, but using the inputs.��

��

So you… we definitely haven't seen people switching consciously from one style to another because there is all this cognitive load of doing that, together with all the cognitive load around the process, around the stakeholders, the technical context that you have to put into a meeting and take this approach.

��

Caval: I would say also the phase of the project, the time in delivery where you are also plays a very important role. So there's two almost opposing styles — one which is someone that is addicted to coding, so usually a very young tech lead that has been a dev for so long, and then started to act as a tech leader. Doesn't see herself, himself as a multiplier of the team yet, but it's a huge contributor, but he’s just arrived at this position of being a tech leader — and so essentially the team is very dependent on that person on his or her contribution to delivery. If you are in a point in time where there's a delivery crisis you just need to push things out of the door, that's very important to act in that role. That will be very valuable for the delivery aspect of things.

��

On the other hand, an opposing style, we call it someone that is essentially unnecessary to the team, so you build yourself, you act in a way that the team doesn't need you anymore, which seems, as it seems, very interesting, so you want — as a leader, you want the team to be independent, autonomous. That's essential when it's time for you to go, essentially for you to leave the team. Well, probably if the team is still forming, you don't want to be on that style. If it's in the beginning of the team, you probably need to be more present, you need to establish standards, help establish the standards. And so depending on the timing of the formation of the team, the time of the delivery — the delivery pressure, so there is a multifactorial, essentially, but the same person can definitely work in different ways, or enact different styles as we said. This versatility takes some maturity, essentially, as Arturo mentioned. So you must be aware of yourself, and then, OK, did I… am I coding too much? Am I coding too less, am I putting too much things to voting, or am I taking too many decisions? Should I let more people take more part in multiple things in the project? So these are the kind of decisions thatyou're making. So the styles help you be a little bit aware of what you're doing, if you're doing something too much or too less.

��

Scott: One of the things I've noticed that a lot of new tech leaders are very slow to realize is it's — your goal should be to make yourself redundant to… I think a well-led organization should function even well when the leader isn't around. And I think sometimes a good leader appears to not be very busy or be doing much, but I think in a lot of ways that's an ideal. You want to be there if needed, but the team ought to run on its own. It shouldn't depend on any activities that the leader does.

��

Caval: Absolutely. But then, on the other hand, I would say if you're just starting a team, and if they are just ramping up, if you're not there or if you try to reach this ideal too quickly. It's almost like a sink or swim kind of way of learning — and they will probably sink in this case. So, again, is this the idea to pursue?

��

Scott: I wish I could say I had been successful at that more than I have!

��

Arturo: I think that's a shared feeling for sure. For instance, as I mentioned in the beginning, I was going through my first time as a tech lead, and even though I was able to observe a couple of tech leads prior to me taking the role. I was actually falling into some of the same mistakes. And the thing is all those styles, they have the benefits. And the stakeholders will benefit from someone that becomes a tech lead, and is too close to… because the velocity, the quality of the delivery is still there. And there is no ramping up of a new person, there is no new context setting. So the speed of the team is still — there is still present, and everyone will benefit from it. The folks, the other folks from the team, will still go for this person to get more context, to have guidance on the design of the solution or the architecture itself. But the person will have to become aware of these bottlenecks that they are becoming, and start scaling this knowledge into the team. So there is the conscious part of it is becoming aware that you might be starting to fall into many of the weaknesses of each style, and then hold a little bit and start acting on a plan that will put you on a different style, for, instance or maybe come back to the strength of this style and leverage it, given the context that you are in.

��

Alexey: And just to dive deeper into the catalog itself — so can you talk a little bit about other examples of styles? I don't know. Do you have a favorite one or a very surprising one or something that you, I don't know, you find very common or that's been useful to you in a personal situation or something like that?

��

Caval: I have actually a couple. And I say a, couple, I mean, very specifically, because what we've observed that very — usually, they come in pairs. They come in opposing behaviors or opposing situations, I could say. One of these is what we call an appointed leadership, so essentially, you are such an organization where you were chosen to be the leader. Which in a given very hierarchical organization, could be very natural, but in other places, a more organic growth, someone that is kind of acclimated as a leader, by acclamation could be a more of a natural way of arriving there. So an appointed leader can be a very tough situation to be, if you are someone who can suffer from — you're going to be putting yourself into an imposter syndrome situation,very easily. If you are in an organization where people question a lot like, why is this person here? Is kind of going to be the question you're going to face a lot, so there's some time to prove yourself, even within your own team. On the other hand, if you're someone who has a reputation within your organization and you're an appointed leader, people would just be amazed to work with you — they will ask for you to be their leader. So it's kind of just two sides of that coin of being an appointed leader. So that's something that I find very interesting.

��

For me, something that's like there's no ideal — it kind of reflects the fact that there's no ideal way to — there's no kind of given path or specific path to become a tech leader. You might be appointed, you might grow into that role and be like the obvious choice for the organization, and everybody will be OK with that, but there's always challenges in these situations.

��

Scott: It's interesting you were talking about appointed leaders. One thing I've noticed in every organization — engineering organization — I've been in is that there are two parallel hierarchies. There is the formal hierarchy of the organization, and then there is the organic hierarchy that forms amongst the technical people. And if you ask anybody in any of the developers, engineers who is the leader, they'll all give you the same — they all know. Somehow they all know who the person — the thought leader, or the person they look to for guidance is, and that, most of the time, isn't somebody with a formal title. But I think it's really important for the people who do have the formal title to be aware of that shadow hierarchy that exists. And I think you can use it to your advantage if you embrace that.

��

Arturo: Yeah, so for me, the one that I started actually writing about is the person who is addicted to code, which is as we already talked about, one of the beginners mistake when someone becomes a tech lead, which is still coding too much and not paying too much attention to the team. And at least while I was writing, I was actually starting to get the mindset that the catalog puts down now, which is, even though this is seen or and described in the literature, there are many books that talks about this mistake, and this is often the first mistake that we all make. I started to notice what could be the strengths of acting on this style and the balance that you have to have to choose when it's time to do it? So if you are on a delivery pressure or a tight deadline, you might, as a leader, come and start coding to improve the team delivery. But if you still continue after this pressure, this deadline, the team will start to have some anti-patterns such as people depending — the delivery depending too much on this person, or the team members not expressing their opinions or not expressing their interests in the code, waiting for this leader to reveal which is something that we've seen through the PR's review, the coding, and refactor or even remake the whole solution to do it because you are too involved, the product became a pet for you, and then you are too close to it to not allow for some mistakes that everyone will have to have a chance to commit, to actually learn. So there is this — this is my favorite. And I think by the time that I finished writing it, Caval and I had a discussion, and then I started to visualize other styles that I've been experience with other tech leads, and not only judging them because I experienced their making a mistake, but seeing or at least having some perspective on why they chose to act like that, was there something in the context for the organization that drives that decision, that drive their acting. And what — I started to ask to all the tech leads what was the context more instead of just getting some feeling and starting judging if they are making any mistakes or not.

��

Alexey: Yeah, one of the interesting things about patterns is that it makes you aware, besides giving you a language to talk about these things. It makes you aware of things. So one thing I wonder about and I wanted to ask you, so I know you've been using this catalog to have conversations with many teams. How have people been using it? So is it mostly about applying it to the teams, or has it been useful for people to grow as a tech lead to understand their own behaviors, or behaviors of the team, so how has it been helpful to other people and to teams?

��

Caval: So the feedback I've been receiving is essentially about growing into this tech lead role, and perceiving oneself more as acting in such a pattern. One thing that might happen — but didn't happen, thankfully — was for this to become almost like a self-fulfilling prophecy, as in people start prescribing the way: oh, I should be the coder. I should be the — some given style. Instead, they say oh, I act as such, maybe I should try something else in a given moment. So essentially, open someone's awareness of what's possible. And that's the feedback we've been receiving. People reading through the catalog, understanding, “oh, that's actually something, and it has such and such consequence. Interesting. Now we can connect these two things, and I can be more aware of, when I do that, what's the risk I'm taking? When I start coding too much, what risk I'm taking, when I start coding too less, what risk I'm taking, when something to vote,” and so forth. So essentially increased people's awareness of themselves.

��

Scott: That sounds very helpful. I would have liked to have had something like that when I was first pressed into tech leadership — and most of us are. I think most people are sort of recruited into it, they didn't start out to be leaders. And having some guidebook, I think, would be very helpful.

��

Arturo: I think for me, the feedback that I got is something similar, not from the tech lead perspective, but someone on the team that was not senior tech lead falling into some trap, and use one of these styles to point out what we put in the catalog, what would be the end result, and they were falling into this trap of one of the weakness that we documented. So it is very helpful. And I think he goes — when I started writing after we finished, I think he complements or works really well with the talking with tech leads from Petqua because it is something that we observed on the experience of other people, and we documented in some way not like Petqua did with testimonies, but with our understanding afterwards, what would be the end result of such acting one of the given styles?

��

Alexey: Any learnings or any final comments you want to share, maybe some advice for people starting as tech leads? Things you have seen and learned from seeing so many teams?

��

Arturo: So my main learning is actually having this self reflection on what is the style that I'm enacting at the moment — to observe what was the weakness or what are the advantages of continuing or stopping this style. Am I doing good for the team by acting and coding too much? What am I missing on the bigger picture that I should be getting from the team and also the relationship with the stakeholder by just spending so much time coding, and in a focused manner with the code? Should I open this decision for the team to have more opinions on this? And what would be the benefit of learning the team's perspective on this new tool that we're about to choose? Is there anyone with prior experience on this that could help me actually also take the decision? So both the self-reflection and also going through the catalog again, to take out some of the gifts from it to use on the actual engagements is the main learning that I have.

��

Caval: So for me, I think as well awareness is the key learning here, so self-awareness. Understanding where you can grow, understanding that you don't need to act the same way every time, that there are consequences, whether you perceive them or not, but you can start looking for them, the consequences of your behavior. And based on that, you can start trying new things like looking for versatility. And then definitely do a better job, make your team, grow faster, produce more quality and so forth. So I think it starts with self-awareness and unlocking this potential within.

��

Arturo: And on top of this self-reflection, something that we also added to the catalog is — the last session contains some guidance on capabilities that you might grow on your skill set to help you acting, or perceiving if you are falling into one of the weaknesses that we talked about. So we have this reference for you to improve the way that we are working, either by enhancing one of the capabilities to adopt even more the style, or be more aware of if you should stop doing it.

��

Alexey: That's amazing. Thanks. Thanks. And, well, unfortunately, we're coming to the end of the episode, but it was a great conversation and a great joy to have you both with us. Thank you so much for joining.

��

Caval: Thank you.

��

Arturo: Thank you.

��

Alexey: Thank you so much. I learned a bunch during the conversation, and it was lots of fun. Thank you so much.

��

[MUSIC PLAYING]