About this talk
In this talk, William Mince discusses the often overlooked challenges that managers face in tech environments. He reflects on his journey from a software developer to an engineering leader at Coralogix, emphasizing the importance of understanding team dynamics and fostering clear communication. The speaker highlights the pitfalls of management, such as becoming a single point of failure and allowing ambiguity to stifle productivity. He proposes a framework for effective management that includes building an architecture of clarity, establishing contracts for expectations, and enhancing observability within teams. Mince encourages engineers to take an active role in their management processes by providing metrics and feedback to improve teamwork and project outcomes.
Full transcript
Oh, okay. That's it. Let's go. So, I'm glad that you all came to hear a manager speak. This is not usually what we do in dev conferences, right? So, before starting, how many managers do we have here today? One, two, three. Nice. So, you all can validate whatever I'm going to say and to talk. And for the not managers, I hope that one day you can use
this to become one. And if you guys don't ever want to become a manager, I hope this talk at least helps you deal with your current manager or the managers you might have in the future. All right, so you can take this to them and say, "I saw a fatty guy in a very nice conference. Take this. He said interesting things. Let's do it." All good? Okay.
So, before going on, let me present myself. Yeah. My name is William Mince. I'm Brazilian, so you can get that through my speech, right? I I've been living in Portugal for the past 9 years, so my mustache is entirely a Portuguese citizen now. And I am a father of a 20-month-old boy. This is my proudest achievement. Nothing else in life can be better than that. Other than
this, I am an engineer. I keep saying that even though I've been managing teams for a long time now. I have more than 15 years on the field. I've been working into almost every area. I was once a front-end developer, a software developer, a SharePoint which is, you know, hurts somebody. Uh then I became a devops engineer. I switched to the dark side of the force. And
then I did all those SRE things before they were called SRE. So, by the time I was just somebody taking deployments through production, building pipelines, before we had that name. right now, I am an engineering leader. I take two teams inside Coralogix. Coralogix is an observability company. We have open positions. You have my LinkedIn at the end, so we can uh connect. And I managed the internal
observability team inside an observability provider and the network team. So, I am inside the SRE group, meaning that my teams are exposed to everything that happens wrong and good And other than that, I am a community builder. I managed a community in Brazil with more than 20,000 engineers. We took a lot of talks and engineering uh lessons to people in poor communities. And I've been teaching and
talking about everything that I do for a long time. And that's it. Now that you know me, I want to be open with you. We know let's build this relationship. I built this talk to be able to speak about something we don't speak that often, which is where do we fail as managers? Where do we fail as teams? Where are we doing wrong stuff? So, we all
have been gone through those projects that it starts well. You know, you have a new technology to build. You have a new customer to build an environment for them to go to your company. Or you have just a shiny little thing that you have been willing to work with AI for now for a while, and the project got authorized. You started building it. Your team is started
doing whatever they want or whatever they needed to do. But the project start drifting. The product manager start coming with more and more requests. The priority shift, the team shift, the timeline didn't. So, what happens? Usually, we become the proxy, right? We the managers. And we have to deal with the frustration from the team for everything has been changing. Uh and the frustration from management that why
the team is so slow to deliver. Why we're not going on time? What's going on? And I have to to be honest with you, I started management a long while ago. I tried to be the guy that was the brilliant developer. Not that I was brilliant, but in the company I worked for, they considered me as as a brilliant developer. So, what do you do with a
brilliant developer? You promote him to a manager. And I was the worst manager I could ever become. I cannot imagine anyone worse than that. So, I did the pendulum, which is after being very frustrated passing through this a lot of times, I decided to become an engineer again and say, "Okay, this is not for me." Then I missed that and became an engineering lead again. And this
is how I learned to deal with those. Because whenever we move, this is what we feel. This is what made me go back to engineering and after moving back to engineering, understand what was going on on my first experience as a manager. So, what do we want as engineers, right? We to understand and to control stuff. We want to be able to debug stuff, to understand how
they're moving, why they're moving. And what we usually have as managers is that our systems, when they fail, we usually have a stack trace. We usually have metrics. We usually have logs that leads us to take a decision. When people is start failing, when we have an environment that doesn't bring people together to be productive and to be happy, they start giving you silence. And silence, after
some time, brings you absence. They usually go away. The first symptom of a good employee that is starts updating their LinkedIn is if they start going away from your retrospectives, from your one-on-ones. If they say everything is all right, but they're not discussing, they're not present on the team. And this is what happens. So, how can you troubleshoot something that doesn't give you any signal? That doesn't
tell you that, "Okay, I'm broken." I'm breaking, sorry. Uh so, and the thing is, systems are predictable. Some systems, right? Right now, we see that maybe a thousand pull requests in the same system for a single day make them unpredictable. But people is unpredictable by default. Even though we can evaluate someone's behavior by their past decisions, we change. And they might what watch a movie, watch something
that will make them move away, that will make them change their behavior. And you can be a happy guy, wake someone on the wrong side of your bed. You know, step up, go against your drawer. It's not going to be a happy day for you anymore. And this brings a lot of chaos and confusion. And as engineers, we don't like that, right? But I heard one thing
from a mentor once, we don't have to be bad managers. We can be trying to deal with people. What if we stop acting as people as an engineer if or what if we start acting as an engineer that have to debug something? How would we do that? So, instead of going to that quote that, you know, management is not a career promotion actually is not a promotion
is a career change that we hear that often, we go just just by it is a career change, but it is still engineering. In the titles, we have a team lead, an engineering lead, an engineering manager. So, let's make it work in that way. How can we use what we learned? And this is the framework that I built after that frustrating time. The first one is architecture.
Whenever we're building a software, we build we Please, come on. We build the architect the architecture first, right? I hope you at least design that at least when you're using AI, you use the plane mode. I think you do. So, let's build the architecture. Let's think about building our team and our work for clarity, for purpose. Then, we start taking APIs. We have architecture, we have multiple
systems. Let's build APIs. Let's build contracts. How do we operate? What is expected? How can we deliver what we need? And the last one is my field, right? So, if you're building contract, if you're building systems, how do you observe those systems? Let's start by architecture. Let's start by thinking that our teams are distributed systems, right? So, if a distributed system and you have the manager as
the single source of truth for that system, what do we have? A single point of failure. Right? Because if everything goes through the manager, you are the single point of failure of your team. It means that nothing will happen without your approval or guidance, that you're not building a team of you know, uh accountable people, but you're building a team of dependents. And we'll have to stop
treating people like dependents, right? The first action of a manager in my perspective right now, the first action I start taking whenever I have to do something is I act like ambiguity is our human latency. We understand latency in our systems, right? It makes everything worse. This is ambiguity. Whenever you ask someone, whenever I ask someone to do something and I don't tell them why they're doing
that, what is the timeline that I expect that should be done, and what I expect to be delivered, I am giving them ambiguity. So, they will fill the blank spaces with whatever they can on their minds. And this is not a success measurement. how do we remove ambiguity? We work with three pillars: lack of observability, logs, metrics, and traces. So, we build clarity of purpose. If I'm
build If I'm asking anything from you, I'll tell you why this matters for me. So, you can take a decision if this matters more or less than what I asked you before. The second one is what is my expectation on this. What good looks like? If I'm asking you to build an observability pipeline to a new system, I have to tell you what I want to receive
from that system. Do I want to be a complete to have a complete coverage from everything or I want only logs, traces or metrics? Do I want to have APM available? All of this has to be set up front. at the end, I have to give you the safety. Right? Is this a project that you can experiment with? That we can at least change a bit of
the timeline or is this something that our VPs are waiting to launch the product? Is this something that will be presented on the next conference? So, we don't have anything to do around that. We need to give it what they want. This creates a clear system without This means that the engineer who will receive any request like this can take the best decision that they have to
take to deliver whatever is expected. So, clarity solves 90% of management problems. If we start by this, the projects will fail less and less. The second one is contracts. And this is the worst thing in management or at least the worst thing that we hear about management, which is management is dealing with people. Right? And management is politics. Who hears that? Right? Who says that? That I
don't want to go to management because it's politics all the time. You have to go on meetings, you have to kiss somebody, something, you know? And this is managing. By the way, I already told you I'm Brazilian. In Brazil, we speak like that. So, we have some bad words. I'm our friend. Anyway, is designing interfaces. And this is the key. If you are building a system as
an engineer, and you want people to use that system, what do you do? We provide a contract. We say, "I want to receive data in this and I will give you output in this way." Why are we not doing that in life? Why are we not doing that with our teams? let's start building API contracts for humans. Let's start using whatever we use in engineering as a
concept to manage for you guys that are engineers, this is a lesson for life that I learned after having being kicked a lot. You are asked to manage up all the time. How do you manage up? Give your boss, your manager, your VP, whatever the person who's managing you, three-field JSON response. So, tell them what is the impact of what are you what you're building, and ask
them the impact of what you are expected to build. You receive a an instruction, you receive a task, you say, "Okay, what is the impact of this? Who is going to be affected?" is is there any risk on this? Raise it up. If you see that there's a problem on the the thing that I'm asking you to do or that your manager is asking you to do
that will break production and you know raise it. And sometimes, I never told you that, but you have to raise it written. Just to formalize stuff because whatever is spoken, you know, can be forgot. This The third one is if you're raising something, you ask for something. Is there any decision that your manager needs to take after you raising what you've seen or not? And this goes
for everything. Every time that I'm sending a message to my engineers, I do the best I can to fill those three things. Every time that I'm saying something to my VPs or to my leads, to my leaders, I'm bringing those three things. This is informative only for you to know, we've been doing this in that way and there's this risk. The team will will take care of
that or I don't know what to do because you asked me to build an API. If I build this API, this means that we're going to have duplicated end points for that and that and that service. How are we going to deal with that? Are we supposed to take these duplicated services or not? Who owns it if it fails? Am I the one owning it or not?
So, build those And after building that contract, define an SLO. Define metrics. Translate the outcomes the metrics they want to hear. So, instead of asking or saying that you want to refactor the code because it sucks, just say we need to refactor this because we have X amount of alerts, X amount of issues, X amount of engineering hours wasted. Escalate exceptions. Whenever you need your manager to
intervene, don't bring them to micromanage you. And I'm sorry, I know micromanaging micromanaging is awful. I hate doing that. But sometimes, when we don't have clarity, there's no other way to do it. So, instead of waiting or counting on your manager to discover if he needs to micromanage or not, and if he they start micromanaging, this means that they are losing signals. Start raising those signals. And
after that, build the SLOs or KPIs. How are you measuring my success? Are you measuring by the amount of tasks I deliver? By the impact I bring to the business? By the amount of ideas I start pursuing? So, let's do it uh weekly. Right? So, I'm closing X tasks. I'm closing X ideas. I'm solving X business And do the same for them. So, do you expect me
to work in that way? I need you to do a contract. I need you to tell me clearly. And whenever they don't tell you, you say, "We had five tasks. Three of them were badly written. I couldn't take any context out of it. This means that if I'm failing, we're failing together. Let's improve the system." And the last one is, let's talk about observability. We already built
the contract. We already built the the architecture. How do we know it works? We collect signals. And there's one very interesting thing. If you want to know how your database is going, you understand that you either have to poll data from it or that you have to have it exposing metrics, right? So, think of people as databases, but databases that get angry. If you poll into much,
they will kick you. Instead of polling people, let's start building dashboards and views that we can take about the stuff that we need to measure. If I want my team to go faster, I need to give them context. I need to build a contract. And how do I measure that I'm doing that? If you're using Jira or Linear or whatever other tool that you're using, you can
build a dashboard. If you have Cloud, Co- Codex or whatever AI that you want to use, you can build a dashboard on top of anything that you're asking our team to There's one project a sometime ago that was managed through a canvas on Slack. Giving Cloud access to that canvas, I could get a clear dashboard of the project status of everything that was moving on, everything that
wasn't moving on, and which topics we had open for how long. give this advice to your managers. And the managers here, we can use that. Let's build observability that delivers what we are asked to deliver. The principle that we have to take is, if I need to ask my team all the time for status update, I am not a manager, I'm just anxious. I am anxious, so
I have to deal with this in that way, right? Uh So, how do I do that? The first one is I really rely on one-on-ones, but I don't go one-on-one to ask people about their tasks. I go one-on-one to know about their about their mental health. How safe are they feeling? How well are they feeling? And I usually start them with one singular question, which is from
one to five, how happy are you? And after this, I ask, why? This gives me more insights than any other thing I can have. There's no dashboard that will tell you that some person isn't happy because of all badly written tasks they have or all the changes that you had during a singular week on priorities or about the behavior of their colleagues or just about the way
they have the neighbor uh dog barking at them all the time. It was just a bad day. You have to understand this to understand those signals. This is the first one. The second one, build a weather map based on your retrospectives. So, what are the topics that are appearing the most? What are the complaints that you hear the most? What are the things that impact your sprints
or your work that are never written down, that are taken as acquainted by the team. Do you have tribal knowledge? Do you have someone that you always pick the same type of request? So, if I have anything to solve on Prometheus, John will always pick because John is comfortable with or because John wants to be seen as the reference for Prometheus in the company. And if I
take that from him, he will be very, very sad. And the team will not deliver. So, you start leveraging those things. You start diagnosing if you have misalignment on your metrics. And one important thing, we hear about metrics all the time, right? There's data, there's lead time, there's sprint, there pre-built metrics in the field that we can take, but not a single of them tells the truth
alone. If you are observing a system, the way that you usually troubleshoot it is you go by an alert that you received. Then you look at the logs. Then you understand what's happening at that time. Then you go to the metrics and you look at what happened after or before the time or during a specific period. Then, if you want to go deeper into that, you go
to traces. Do the same with people. Do the same with your team. Have observability, gather data about what's going on, and how things evolve with your team. Don't believe in a single system for that. Do you Are you in switch? So, if you are on a time that you have to build a system for a conference or for something that will be given to a customer and
you have no time to negotiate, you have to measure speed. That's all. Nothing else matters. If you have that system delivered and the team is unhappy, it's time to rebuild their happiness levels. So, a buffer sprint or buffer zone between projects, and you start measuring the happiness level going back. Those are the metrics and the way that we can switch them to properly manage people. This is
the same time and the same thing that we do with our systems. management is indeed a hard job, but it's just engineering. If we build a system around it, it usually improves over time. And just two advices for engineers and for managers. The first one is managers over here and for everyone that wants to become a manager, before asking anything for your team, think about those things.
What are you actually solving by this How do we make decisions in the team if in this team if you are absent? Are you Zeus? Do you know Zeus, right? Is this the proper way? I'm Brazilian, again, we we call it Zeus. So, are you like Zeus? If you go away from Olympus, everything blows? Or not? Does your team Can your team take in the take decisions
if you're on vacation? Can you go give a a speech on a conference for 45 minutes or something? And have people without having people depending on you to take decisions? How free are you? How free are is your team? Are you managing adults or you just open a kindergarten? Not for the team. Anyway, and what signal proves that you're doing it wrong or not? We all debug
systems. We can debug teams. Let's build architecture. Let's think about the contracts and stop calling people. Let's make this a work that we can rely on. And for everyone who's not a manager here, managers, don't hear this. You can take the phone off, but your manager used to know and used to do what you're doing today. They are not doing this anymore. I have to remind remind
this all the time. Even with AI, whenever I jump to solve a coding issue, I am not an observability engineer anymore. So, I don't know properly what I'm doing, and I have to be aware of that. So, whenever you have to deal with your manager, assume that they don't have your context. Fill the gap. Give them metrics they can use to manage you. Give the metrics that
works for you, and start building this contract. Whenever they ask something from you, demand this back. Why am I doing this? Why is this important? They will have to answer this sometime. And whenever you have an issue, lead the postmortem. Say, "Okay, I understand I didn't do this properly. How can we make this work for not making to not make this again, to do not repeat this
mistake? I need you to give better descriptions of the task. I need you to give better space. I need you to tell me that I cannot miss the the timeline." With this, you're patching a legacy system. Treat them and treat me as a legacy observability engineer. That's it, guys and girls. So, if you have questions, feedback, or you want to share your CVs with me, this is
my LinkedIn profile. I'm glad to take any from this. thank you so much. It was a pleasure. As I said to my team, stay strong, guys. See you. [cheering]
