Manager interview: Pedro Santos - AMA
Contents
These are my replies to my first AMA (ask me anything).
It’s interesting how this made me think and clarify many ideas. I’ve left the AMA format open and added the Ask me Anything page that has instructions on how to receive more questions.
On this interview I give my opinion on several topics regarding engineering management, problems I’ve faced and how they changed me, how to measure performance, how to organise my time and about leadership.
Nuno Silva, Engineering Manager at Pipedrive
Nuno: What is, for you, an Engineering Manager?
I see engineering management as a progression from a team leader. In fact many times EMs are team leaders or tech leads, but with some responsibility shifts. It’s more about the people and outcomes and less about technology. As an engineering manager we need to:
- Train people
- Motivate people
- Deal with the fact that we’ll be interrupted all the time :)
- Focus not only on our teams’ outcomes but also on the success of the teams we interact with
This means responsibilities in other areas like onboarding, recruiting, customer success, product management, etc. But I’d say that the biggest focus is on mentoring and growing the team, and making sure that they are motivated. If a team leader delivers features, an EM delivers healthy teams that deliver features.
Nuno: I’m a new at the Engineering Manager role. What should be my main concerns since day one?
A new engineering manager will be in that situation where he/she will be able to perform the team’s work better than the team. But that won’t scale. The EM will need to change the focus. This was my biggest challenge. Okay, I can deliver features with with quality. But how can I train a team to deliver features better than I would?
This means more mentoring and teaching and less hands on code. I do think an EM needs to be hands on, and be technically proficient. But focus on growing people means that we need to focus less on sprint commitments.
My first struggle was actually the one-on-ones part. I never did them and I didn’t know how to do them. I saw several articles but I didn’t quite relate. Ultimately I ended up grabbing several pieces of advices and come up with my one-on-one framework.
When I started as an EM I also did something that helped me a lot. I managed to book one on ones with people from other areas. With the heads of product, human resources, etc. This allowed me to learn a lot about those areas and understand how I could have a bigger impact.
Do find mentors and try to take the most out of them. And do read a lot. You can start with High Output Management.
Ricardo Fiel, Cloud Solution Architect at Microsoft
Ricardo: What was your toughest decision so far and what made you decide one way or the other?
I don’t recall any situation where I consciously had a hard decision to make. I do recall lots of bad decisions. There was one time I was promoted to a team leader and I had a great team. One of my teammates was someone that was super social. He was that guy that everyone liked and that was bringing a lot of good vibes to the team. He was also very technically proficient and always had ideas and pushed us to be better.
But when I started leading him I started to notice that his productivity was very lacking. He could be the less productive developer we’ve had. At a given point I was sometimes covering for him. I didn’t know how to handle this and honestly this started to have a snow ball effect. I started to change the way I interacted with him, being less friendly and not being able to share what was bothering me. He on the other hand started to understand that something was off.
At some time I started to confront him, in a way that was not the best. Eventually our relation started to become toxic. So toxic that I got sick to my stomach just with the idea of interacting with him. All this was just between us, somehow we managed to leave the rest of the team on the side.
So my bad decision was hoping that things would fix themselves, instead of actually facing the problem and acting on it. Looking back, if on one hand he might have been less productive, I definitely could have taken so much more out of him if I properly took advantage of this other strengths. I still regret the way I acted on this, and to this day I still review in my mind what would be the best way to deal with this problem.
José Miguel Malaca, Software Engineer at IPNLis
José: Engineering Manager, Project Manager, Tech/Team Leader. Great titles that convey great responsibility. In your opinion, what do they represent and what are your advices to people who would like to reach them?
On the first question I talked about what it means to be an engineering manager, so I’m missing project manager, tech lead and team lead.
The team leader may be the most senior person on the team. Or maybe someone with lots lots of context. The team leader will have responsibilities in the deliverables. Is the team delivering on time? Are the delivered artifacts with quality? Is the code base easy to change and adapt? Are we adding value? When things go wrong, it’s the team leader that needs to step up and deal with team. The team leader should have a vision and goal for the team, and should lead the team there.
A tech lead is someone that can deliver a feature from start to finish. Can be responsible for the design phase (like writing the RFC), writing the code, managing dependencies, ensuring quality, deploying the feature and assure it’s being used with success. Sometimes the tech lead and the team leader are the same person. But my personal style is very different though. As a team leader I believe that everyone should be a tech lead, even the rookie developer. Empowering a rookie developer to deliver a feature end to end is great for the rookie’s motivation and sense of recognition. And if the feature is tricky, we can add a seasoned developer as a sidekick for help and mentoring.
The project manager is someone more focused on tasks, deadlines and dependencies. Assuring that everything is going according to plan and dealing with problems that may arise. Will deal with clients and manage the expectations of multiple parties. The PM will be a JIRA/Trello/Asana/etc master (?) and will have the tools to understand where the team is at, and help with planning. Now allow me to be somewhat controversial here: I do believe that if this is what the PM is doing, we’re not taking the most out of the PM and that the team is lacking. In my opinion, we take the most value of a project manager if his/her main focus is on forecasting.
If you want to reach a specific role my advice is to start doing it now. Empower yourself, start to do the role’s tasks, get one-on-ones with a good mentor for that role, start reading books about that role. Set a goal and a training plan to get there. Ask your line manager for help.
Paulo Silva, Tech Lead at RUPEAL
Paulo: As an Engineering Manager, how do you balance your time between technical issues and people stuff? Do you split 50⁄50? Or do you spend more time on tech? Or more time with people (coaching, 1on1s, etc.)?
That depends on the maturity and the size of the team. A team with less experienced developers means that we need to be more hands on. We need to take care of loose ends and help with the deliverables. As the team grows in size and proficiency, we won’t need to have code commitments and we’ll need to focus more on training them and motivating them. It’s hard to balance all this and things are always changing.
I’ll tell you what’s my ideal comfort zone:
- I don’t have any deliverable commitments
- I have some code project that is not related with deliverables but that adds value somehow. For example improving the CI pipeline, some refactoring or performance improvement. This allows me to be up to date on the coding part but not having the stress of a deadline
- I review all the pull requests of the team. From the frontenders, backenders and quality engineers. This gives me a broader perspective of what’s happening and I can influence things if I need to. This also gives me a lot of context to be a better mentor on my one-on-ones because I can detect improvement points
- I’m available for something urgent that might came up, like a bug or some patch, not needing to switch the context of a developer for it
- I’m always ready to be interrupted. If I don’t have a feature to deliver I don’t need huge blocks of focus and I can be more available
- If some feature is behind, I can step in and help when needed
- I perform one-on-ones and focus on having a plan to challenge and grow the team
- I focus more in proactive tasks and try to have a clear picture of the next 3 months of development
Ygor Cardoso, Deliver Manager at Sky
Ygor: How do you measure your projects performance and success?
This is something that I find very hard to do, and never did see it done in a way that worked. Some teams talk about SCRUM’s velocity for this. But I think this velocity is more about capacity planning. I mean, we can assess how much a team is able to deliver, but we can’t compare the delivery speed of two teams.
I may have a sense of how things are going. But it’s hard to take that to numbers. In Accelerate they present statistic evidence of several factors that are associated with high performers. And I’m completely aligned with their findings. But they actually invest a chapter explaining why gathering this kind of information via surveys is better than doing it with measurable automatic data.
So, I can have a sense of how’s our delivery speed is going, but I can’t come up with a framework/process that gives me those numbers periodically. Maybe too much unknowns in our area. :)
But I do struggle with this. There are things that I pay attention too:
- Ping pong between developers and support/quality. Are we delivering things with defects?
- How hard are change requests to be implemented? Is our code easy to change or do we need to invest a lot in maintenance?
- How much time to developers allocate to things not related with their tasks (meetings, interviews, reviewing pull requests and RFCs).
- Are we doing things that are not used? Let’s try to have the whys before starting development.
- Do we have a clear picture of the future? If we do, we’ll be able to build code today that is better suited to be changed tomorrow.
All this maps indirectly to software quality and developer proficiency. But lately I’ve been aware of something that is even more important. When developers work on something they start to gain context and learn more. So they start creating abstraction layers. This makes them more effective. In time we’ll have many indirection layers. So the bigger challenge here will not be a technically one, but rather it’s related with learning.
How can we make sure a team is aware of everything that is happening? And when new developers join the team, how can we make sure that they are up to speed faster?
So, to finish this up, let me say that I have a simple test that I use to assess a team’s performance, that tries to bundle all this. It’s very simple: could someone new to the team, perform a small patch, touching 2-3 files, and deliver it to production without being reviewed?. Would the team be comfortable with that? I call this the Commit Challenge Roulette.
To have confidence in saying yes, we’d need to:
- Have a simple code base that can be easily changed and mimicked
- Have standard practices that everyone follows, that influence the newcomer to write code in the same way
- Have a build system that tests the project with good coverage. If the newcomer leaves some mistakes, will the build system catch it? How confident are we in that?
- Automatically deploy to production
- Easy way to rollback if something bad was really introduced :)
Monika W. Felicio, Helping leaders build healthy organizations and develop consciously
Monika: Do you consider yourself as a leader?
That’s a tricky question. I don’t believe in self-proclaimed leadership. I believe that we are leaders if the ones around us see us that way. I do think that there are things that make up leaders and I do try to achieve them and I want people to consider me a leader. I just have to work every day to achieve and maintain that status.
For me, being a leader is about having a vision and the courage/resourcefulness to take a group of people in that direction. It’s about motivating and inspiring.
Regarding myself, I tend to lean more towards a transformational leadership style.
Monika: What do you think makes someone a good leader?
In my opinion there are two things that good leaders are good at:
- When things are going wrong, they are able to turn the ship around
- When things are going well, they able to push them to another level
These points translate to added value and are a bit generic. I believe we need experience as leaders and a diversity of problems and situations to test us. This allow us to grow and better handle all types of scenarios. And for that we need time in the trenches. There is no workaround. Training, books, coaching and mentoring help, but they’re no substitute for experience.
I once had a manager that told me something that got stuck with me: if you’ve been mostly successful as a team leader, it just means that you haven’t had a diversity of experiences that allowed you to fail, and that ends up being a flaw in your career.
Monika: What is your most valuable lesson learned or unforgettable advise that significantly influenced the way you interact with people and do your job?
I tell this story a lot of times on my one-on-ones. Many years ago I was the typical developer that was very productive and proud of this work, but was lacking in social skills. I was promoted to team leader and things were going really well. I focused on my department and make sure things were running smoothly. Or at least I though so.
One day we were having a retrospective. I don’t remember the details but I do remember that all the leads were there (support, marketing, sales, product, …). Something went wrong and we were discussing it. Well, not me. I delivered my part of the bargain. At some point I was actually distracted because nothing there related to me when someone pointed at me and in a really loud and emotional way said: the main problem is that Pedro’s attitude is terrible.
That caught me completely off guard. The technical part could have been ok, but I was focused on my silo and was not helping other teams succeed. Not only that but focusing just on the engineering side of things was actually crippling my peers work.
This was eye opener especially because it was the second time I got this kind of feedback. It made me question my beliefs and at that point something clicked. I really understood that doesn’t matter much if my team is having good output but it’s damaging other teams work. At this moment I started my transformation into a manager.