Engineering Leadership: Building Culture, Career Growth, and Ownership

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with Thiago Ghisi. Thiago, welcome. Thank you for taking the time to talk to us.

Thiago Ghisi: Thank you for inviting. Glad to be here.

Shane Hastie: My normal starting point with these conversations is, who’s Thiago?

Introductions [00:40]

Thiago Ghisi: Yes, it’s a great question. So I would say professionally, Thiago is someone that has been in tech for the last 20 years now and has spent half of his career in Brazil and half in the US and almost half, but not fully half yet as a manager and another one as an engineer, someone that enjoys kind of writing and consuming a lot of content, creating frameworks, thinking about career growth, thinking about how to structure processes, how to go back to the core of things.

Shane Hastie: Cool.

So what makes good culture in an engineering organization?

What makes good culture in an engineering organization? [01:20]

Thiago Ghisi: That’s a great question, and I would say it is many elements, right? If I had to break it down, it’s not only the people aspect of it. I think the people aspect is an element of it, but it’s not only that, like it’s not only the kind of people, it’s the kind of technology you use, the kind of rituals, the kind of constraints that you have, right? And it goes from how do you interview people to how do you deploy software, right? How do you do meetings, how do you treat each other, right? I think culture is more important on how you act than how you think you act, right? It’s like it is the things that you don’t say you do, or almost invisible work that shapes the culture, right?

On the Peopleware book, they have a chapter, they say something along the lines, it’s like you can see the culture by sitting on the quiet room and just absorbing it by osmosis almost, right? So it’s everything that you’re not necessarily saying or is not necessarily written down, but all the elements of engineering, all the elements of collaboration, all the elements of is this okay to do, this is not okay to do. Culture is who you promote and who you let it go in some ways, right? It’s like are the hardest decisions that you make that shape how people see things, right? What is safe to say, what’s safe to do. That is a clear line between what is acceptable, what is rewarded, right? So many things in there.

Shane Hastie: So as an engineering leader, how do I craft the culture that I want to see in the organization?

How to craft the culture you want as an engineering leader [03:20]

Thiago Ghisi: I would say it starts with the leading by example. There are things that you can shape in terms of processes, in terms of the people, in terms of the code base, the engineering practices that you use, how you share knowledge. All those things, you can shape that by telling your engineers, your product managers on how you would like, or even setting a vision and saying how things should be. But nothing is as powerful as being the one doing those things, being the one initiating, being the one reminding folks, and not only reminding on a wishy-washy, kind of hands-off, but being the one that’s hands-on and the one that is like, “Folks, this is how I think we should be doing. Let me run this meeting. Let me run this thing. Let me actually be the example and let me try it out. Let me have some skin in the game”.

I think the best culture shapers are the ones that are on the day to day, the ones that are not afraid to change things, right? The best engineering leaders are the ones that are able to dive deep and whenever there’s a project that’s running late or whenever there is a people problem, the one that is going deep and putting their hands on the code base if needed and helping to go one thing at a time.

Shane Hastie: You’ve made the point, you’ve spent your career living in different countries, particularly Brazil and New York. New York’s the country, but the USA. I’m sure at times New Yorkers think-

Thiago Ghisi: It’s almost a country now.

Shane Hastie: So what are the big differences and how do you handle that crossing, I want to say, national cultures?

Cross-cultural perspectives [05:14]

Thiago Ghisi: Yes. The big difference that I would see is like, okay, you have a lot more opportunities, right? You have a lot more people doing the same things that you are doing, there are a lot of software engineers, there are a lot of companies. Like software engineering is almost mainstream, right? In Brazil, software engineering, especially 10 years ago, was still not mainstream, so you didn’t have as many companies, as many understanding of what is a software engineer, right?

So I think if you break down into opportunities and understanding of the area, you see that there is a lot of variation between how people do things in Brazil and how people do things in the US, and in the US, people are a lot more careful about their working hours, how many hours they’re working. In Brazil, at least in the reality that I was at, people would go above and beyond and it would not have as close of, let’s say, like a time span of from nine to five, right? Because I think it was a new thing and people were willing to sacrifice a lot more of their personal lives. Of course in the US, in the startup scene, there is also…

I would say the opportunities are different, right? So I think in Brazil you have to be a lot more creative. You don’t have access to the same resources, and that’s both knowledge and both language. So a lot of people in Brazil are consuming books that have been translated or using technology that are maybe legacy in some ways. Not that that’s not the case in the US, but I think used to be more and more the case in Brazil and other countries that were not English-speaking countries or to be a little bit behind. Now, I think more and more people are kind of fluent enough to read and to consume and to contribute directly, right?

But yes, I would say there is also more maturity in the US on the management leadership level than in Brazil. I think you can see Brazil as a much younger industry and generation. In the US, probably the oldest that you could see, like the professionals that have been the longest in the industry are in the US and Europe and maybe Australia and New Zealand, where you are like… In Brazil, that was pretty rare to see managers or people that have been doing that in more than one company, right? A lot of times you were the first engineer, were the first generation of engineers on those companies and the people are doing everything from first level instincts and judgments, so they don’t have a lot of people to learn from, they don’t have a lot of companies where they have been to, so you see a lot more reuse of knowledge and a lot more exchange in the industry now like in the US.

But, I mean, in Brazil the communities are growing. There are big cities like São Paulo where there’s a lot of companies and a lot of meetups. You have to think about that Brazil is a few decades behind in terms of the profession, like careers, titles, and salaries, total comp. All those things are completely different in Brazil and many other developing countries.

Shane Hastie: So deliberately designing your career, I know that you’ve got some thoughts about career growth, if I’m an individual contributor relatively new in the field, I’m starting to think what I want to do, where do I want to go. How do I make those decisions?

Deliberately designing your career as an individual contributor [09:02]

Thiago Ghisi: I wrote a very long article back I think in the middle of the pandemic called How to Build a Strong Career in Tech, where I laid down the high-level strategies on how someone should think about their career. I think it’s five years old, but it’s still pretty good. But if I had to pick a few ideas, for example, I’m a big fan of trying to build your career more as a generalizing specialist, more as a full stack versus a specialist at the beginning, right? So you should go broad, not deep. You should try to understand the fundamentals, not necessarily go deep in one technology.

The other thing is you should try to seek opportunities for companies where you’re going to be operating with less abstractions if possible instead of using internal frameworks and stuff. I think at the very beginning of your career, your goal is to go broad and to see different parts of stack, different frameworks, and not necessarily stay on the front end or on the back end for a very long time, right?

That’s one element. Another thing is I’m very big believer on the idea of glue work. Glue work, it is like who is going to be doing the things that are not necessarily technical or architectural, but it’s still necessary to make the team work, to make the project to be delivered, right? It’s like scheduling meetings, running meetings, dealing with vendors, or scheduling happy hours, taking notes in meetings. I see this as a big opportunity for you to grow. And the other pillar is leverage those opportunities instead of complaining about them. So if there is a broken process, if there is something, be the one that is doing this non-technical work that is not going to necessarily get you promoted right away, right?

The other thing is when you think about being full stack and doing a lot of this glue work is the idea of ownership, right? Is the idea of taking full ownership of the project, of the code base, even if that was not the thing that you wrote or is not necessarily your job title, right? Anything that needs to happen in the whole software life cycle for something to be delivered with quality should be your responsibility. And I think the sooner you adopt this attitude, the easier it’s going to be for you to grow, because the higher levels you grow, like senior lead, engineering manager director, the more that ownership mentality or that end-to-end ownership behavior is going to define if you’re going to grow or you’re going to stall, get stuck on that thing, and I see this as things that usually get a lot of people stuck.

And finally, I think communication. So if you bring all those things, communication, cross-function communication, you see all those things as opportunities for you to talk to different people, different roles, different languages, right? If you’re doing a lot of good work, if you’re taking full ownership, you have a lot of opportunities to be the translator and to understand, because having that experience early in your career is going to allow you to grow in either path you decide to pursue, as a staff, as an engineer manager.

So I think the better communicator you are, the more people you are able to relate. The more domains, like business domains, you have experience writing software, the different parts of the stack, different language, you need to expand like five, 10 years on a part of the stack or of a language to actually have some mastery on that, and I think one, two, or three years you already have enough mastery where you’re already reaching the point of diminishing return.

Shane Hastie: A lot there. Let’s dig into that glue work. I love that concept. These are the things that people often don’t want to do. You made the points and don’t complain about it, taking the notes at the meeting, but nobody wants to do that stuff.

The importance and value of “glue work” [13:17]

Thiago Ghisi: Sadly, yes, but I think the people that do it, in my experience, they tend to grow a lot faster and to have an outsize impact, right? But I think there is a very famous talk from Tanya Reilly where she talks about the problems with glue work, right? I think it’s like where especially for minorities, like in women in particular, they get overwhelmed with all the glue work, and that’s usually the work that doesn’t give enough credit for you to be promoted to the next level, right? Because then you see, oh, you didn’t do any architectural work, you didn’t do any big technical work. You did a lot of this glue, like small non-promotable work, right?

Okay, I’m not saying that minorities should do it or I’m saying everyone should do it and the manager, the leadership has the responsibility to balance that out, but I’m saying that the ones that are proactively doing it, the ones that are not complaining about it and seeing this as opportunity for growth are the ones that are going to have outsize impact, they’re going to have outsize influence, they’re going to get respect from their peers, they’re going to get respect from their managers, they’re going to get credibility. It’s the whole thing about, what is the term, goodwill, right? They’re going to build goodwill by doing glue work and also being flexible and not being super dogmatic about, “I only do coding”. You need to learn that coding is a small part of the job, right? It’s not the only thing engineers do, and usually it’s not the most valuable things that one engineer can do in many situations, right?

So I think the glue work is this idea that if everyone see this work as part of what’s necessarily to deliver projects, to work, especially in a bigger organization, to work with dependencies, to provide estimates, to communicate risks instead of, “Oh, I’m the engineer here. Leave me alone. I don’t want to do that”, the better we are going to be as an industry, I mean the more impactful we’re going to be as a softer team, right? And the more we’re going to be able to communicate and the less is going to be the gap between, “Oh, we need a translator in between the engineers and the business”, right? Or like, “We need managers that are doing this. We need product managers, we need people that are doing the translation”, right? Because there’s some people that don’t want to do this kind of work because they think it’s unproductive or whatever it is, right? And it might be unproductive at the beginning, but you need to learn how to deal with it.

Shane Hastie: Thinking about the manager role, one of the things that in my experience I see is that if somebody gets promoted to a manager role and, yes, they’re figuring out how to look after their team, but there’s another element, that now they’re actually a member of a different team as well.

They’re leading one team, but they’re now a member of a management team, and I have seen that fail a lot.

Transitioning to manager role and joining the management team [16:27]

Thiago Ghisi: So a lot of managers, when they first get promoted, they get this idea that, “Now I need to defend my kingdom”, right? It’s almost, “I’m a king and I have to defend my people, I have to push back, I have to bring more resources”, right? I mean, I’m not talking people as resource, but, “I need to bring more projects and even more people as well”, right? Rather than lose. They see this as a lose-lose instead of a win-win relationship where like, “Oh, if I lose someone, I’m losing as a manager”, right? And they get to a point where they forget that their main job is not necessarily serving their people, the people that report to them.

Of course they have the responsibility of people management, like psychological safety, but they also, they have the responsibility of execution delivery, like caring about the bigger organization, the bigger impact, right? And sometimes giving a person on your team to work on a project or losing someone to rotate to a different group because they are actually stuck or they’re not enjoying their day to day is actually better for everyone, right?

So this is one of the other controversial things, is there are a lot of first-level managers that they would rather stay with a low-performer engineer just so they have a bigger number of engineers than to have a smaller number and let one engineer go and being okay staying with less, right? Because it’s controversial. It’s like, oh, how come they are going to lose people or have less people and be more productive? The maturity of my management is going to be judged on how flexible I am and how open I am, and sometimes even proactively suggesting those things, not just being reactive.

The final thing is that you need to remember that the more you see yourself as a member of, let’s say, your boss organization, leadership group, whatever it is, and that being your most impactful thing is like what I can do that’s best for that group or for the whole organization, less what necessarily my engineers want me to do or what’s best for my group. The ease is going to be for you to grow, because once you get to an executive level, you are basically co-owning the whole company strategy, right? It’s not the CTO versus the CFO, right? It’s like they’re out together. And if something is not working, another executive org, it’s the responsibility of another executive to help to give feedback, right? And they should not be seeing things as us versus them.

The sooner you let that go, that is a win-lose or lose-lose, the zero-sum game, or it’s us versus them, the easier it’s going to be for you to make tough decisions that are going to be better for everyone in the long term, even for your engineers, even for the systems that you take care of. That might be painful in the short term, but if you think about the impact on the business health, the overall organizational health, like having managers thinking in different layers rather than just looking down is much better for one and allows them to see and to understand the business, to understand their peers and their challenge in a much better way than the managers that are kind of heads down and just like, “Nope, I don’t want to see it. It’s just my thing. My way or the highway”, right?

Shane Hastie: So stepping into that wider group.

What’s the engineering advice that people don’t ask for? And I know you have a podcast engineering advice you didn’t ask for.

Engineering advice that people don’t ask for [20:29]

Thiago Ghisi: I would say it is a lot about the things that seems obvious, but they need some experience, right? For example, giving feedback, writing down expectations, working with peers, how to delegate things. There are a lot of things like how to interview, why would you do something. A lot of the advice that people don’t understand is a lot of people would rather believe in mainstream advice, even if that’s harmful or almost completely wrong, right? So it’s almost the advice that is not the easiest path or what you usually think about when you’re just thinking about that thing for the first time.

So it’s like one-on-ones, for instance, a lot of the engineers, a lot of the first-level managers, when they think about one-on-ones, right, they think about, “Wow, that’s a weekly meeting I have just to chat about things, and I’m not getting anything”. This is like they need to see that as like a relationship building, right? They need to see that as your job as a manager is not to address problems when they appear. It’s to prevent them from appearing, right? The job of one-on-ones is to be catching those problems when they’re so small and so early that nobody’s going to notice that, right? So it’s like a lot of early-stage managers or even new engineers, they don’t understand why some protocols are there and their first instinct is just, “Let’s skip one-on-ones, let’s not do that”, right?

The other thing is feedback, right? Like one of your top responsibilities as a manager is to give feedback to the people that report to you, right? What people don’t say is that when do you have enough credibility with that person for them to actually see your feedback as something useful instead of fighting back, right?? How do you develop that thing, right? Like delegation, right? Delegation is something that’s also, oh, just delegate tasks or delegation is impossible. You see delegation as a task, you just throw over the wall and someone’s going to do it. Or you see delegation as not something that’s possible. You don’t see delegation as a process. It’s something you do in a gradual way that is almost a ladder, that is a maturity ladder that you have to follow to be able to delegate a task to someone. They need to be prepared, they need to prepare.

A lot of those things are things that come from experience, and there are a lot of baby steps to get to a point where, yes, that’s very helpful. This is like everybody’s seeing the value of that… Like interviewing, like why would I interview every two to three years or every year with other companies if I have a nice job and my company is doing well, right? Why would I do that? It’s a lot of work. Interviewing is a lot of pressure. I have to go back to do some algorithm stuff, right? Assist with design and being harmed down on an interview, and why would you do that? But if you see things long-term, because that’s your insurance policy, that’s how you get the 10x opportunities to grow, right? That’s how you negotiate your biggest raises of your career, is when you have leverage.

So those are all the advices that people don’t want to hear because it’s a lot of work and it is controversial, it’s not magical.

Shane Hastie: We’re in an industry that is pretty volatile, and there’s a lot of volatility with the restructures, the layoffs, the regrowth. How do we build resilience in there?

Building resilience in a volatile industry [24:20]

Thiago Ghisi: I would say it’s having enough knowledge and network and having the self-reliance that you can think about your career value as being equal across the industry and not being only high on that company, on that context that you work. So it’s like how can you be so good or have enough knowledge that you could switch companies, that you’re not on a position where you are just doing that job because you have been in that company for 10, 15, 20 years, right? You’re on that job because you actually have the knowledge and you could have an equivalent job in any other company, and if you’re not able to get there, you have enough self-reliance and you can learn things because you have the fundamentals right, you have the network, you have the connections of other engineers and other manager across other companies and they know you kind of have a good reputation, right?

It’s having that peace of mind that comes with delivering a lot of projects, like helping a lot of people, instead of having our eggs on the same basket and being surprised. That’s why you interview every year, every other years, to actually see, “What is the risk of my career of staying here for much longer? Can I get a similar offer, similar salary, similar position in other companies? What kind of gaps do I have? What areas do I need to develop?”

There are phases of your career where you want to be a little bit, like you need to focus on your family or whatever and you need to slow down, but every two, three years you need to have that check of reality, right? Of course, nobody likes to be laid off. It sucks when it’s a surprise, it sucks when you’re not prepared. So what can you do to protect one of your most valuable assets, your career, by doing all those things, right? It’s by being prepared, right? It’s by being healthy. I’m not saying only on the fitness level, but being in the healthy sense of knowledge, of connections, is by continuously maintaining that as it is something that can happen every day, right?

And there is the other thing. As a manager, you also need to prepare your team or you need to be doing what they call continuous succession planning, right? Because you also don’t want to leave a company because you got a new job opportunity in very bad waters, right? You want to, the transitions you want to do slowly because you know that someone that was on your team or your previous manager, you remember if you do that, right? So your reputation is as valuable as being prepared and having those opportunities.

Shane Hastie: What’s the important question I haven’t asked you today?

Choosing between technical vs management career pathways [27:15]

Thiago Ghisi: I think one question is like how do you know if you should keep growing on the technical ladder or you should switch to the management ladder, right? How should I know if you should try to go to staff or go to engineering management.

Shane Hastie: Cool. So how do you make that choice?

Thiago Ghisi: I think a lot of that will come to self-awareness, and I can give you my example and my story to illustrate. Because after a few years working in a few companies and different projects, different languages, with different people, as an engineer, especially working with other amazing engineers and amazing managers, you’re going to get a very good sense of when you look at someone that is a few years ahead of you, can I get there? Do I feel that I can be this person in a few years? Is this person inspirational to me?

And I think the realization that I had was like, when I was maybe 10 years into my career, I start to look for the amazing engineers that I was working with, the peers that I had, and I would see how quick and how much high-quality code they would produce, and I would see me as a decent engineer, but being a lot slower, and easily got to this realization that, “Man, I don’t know how can I be at 10 as an engineer even in the next five, 10 years”. But I would look into the great managers that I had and see what they were doing in meetings, in one-on-ones, like guiding, and I could see, “Yes, I can definitely do that”.

And the other sign that I was getting was, a lot of the help that I was providing and being asked to provide were on the things that are not necessarily on like how to do something on the code base, but more on the, “Oh, we are struggling with this decision. You can help us here. We need to interview someone, but we are afraid to interview. We don’t know how to do it”, and I noticed myself doing a lot more work on the surrounding areas than certainly on the architecture. Not that I was bad at that or not that I also didn’t get questions on those or onboarding, all those things, right? And then I realized management is the thing that I’m going to have the highest chance of succeed because that’s already my archetype. It’s not that I could not be a staff, right? But it is like all pieces were aligned to go in that direction.

If you ask a lot of people, they don’t have that self-awareness, they don’t have the data to answer that question, right? And after a few years on the management side, you can develop a sense of, “Oh, how could I switch to a staff if I want to? What skills? And how can I add value as a staff?” And it’s a lot easier to do that once you have been established yourself on the other side, especially if you already have some credibility and some goodwill in the company you’re at to switch between the ladders, right? So I know it’s not a checklist or a playbook, but it is something that you need to develop that self-awareness to then decide like, “Where could I be a ten?” Right? Like, “Where do I see myself reading stuff or researching, and where do I provide more value to other people? Where do I get most positive feedback?” Right? And then going that side. I think that’s a very interesting story and insights to reflect on.

Shane Hastie: Thiago, there was a lot of good, deep advice there. If people want to continue the conversation, where do they find you?

Thiago Ghisi: Yes, so I would say the best place today is LinkedIn. So I’m very active there posting. Every week at least I post something, some piece of advice or some insight on something that I read or the podcast that I listened to and I tried to compress down. So I think there is the best place to connect with me or to also consume a lot of the other articles and material that I have been publishing over the last decade or so.

Shane Hastie: Well, thank you so much for taking the time to talk to us today.

Thiago Ghisi: No worries. It was great. Thank you.

Mentioned: