We sat down to talk with three experienced leaders and managers that collectively bring more than 30 years of experience in building, scaling, and managing engineering teams, some of those remotely.
The insights given are golden nuggets of information and practices that can help any modern manager improve their current engineering team practices to deliver better performance and make more informed decisions.
One thing that struck a chord with us is the way that they all go about managing their teams, basically using the ‘servant leadership’ approach, working to be a guide, a coach, and a blocker remover. They all share that it’s understanding this and seeing folks as people that have allowed them to truly deliver value and performance.
We compiled the best nuggets of wisdom from our conversations with these amazing leaders, we weren’t able to add all of them because it would be a complete book! If you’re interested in reading, hearing, or viewing the interviews to get all the insights, you’ll find the links at the end of the article.
I couldn’t have put it in better words and I have no additional commentary to add to their direct quotes:
To deliver performance, Jose believes in team accountability, sticking to simplicity, valuing the individual, and letting them produce the work themselves. “You hired them because they are the experts, you shouldn’t be telling them what to do, but letting them tell you what to do and trust their judgment. Ask questions out of doubt, not capacity”
He recommends the following to drive performance:
“Trust is not easy, it takes time. To build trust, you start by opening up. You become vulnerable, and when you show vulnerability, that signals that ‘hey it’s ok I’m not perfect and that I’m not here to judge you’ and they also start sharing. It happens over many conversations, like 1:1’s or the breakfast club where we get together to talk about family, life, like’s and dislikes”
Javier believes in enabling a team through communication, transparency, metrics, and support. He uses the following to ensure things are getting done:
He also believes in empowering your team by challenging and giving them space to experiment and get things wrong.
“I’m a firm believer that a manager needs to walk the talk with the team, shoulder to shoulder. Being a leader, a person that pushes the team forward from within. Getting things done by doing and executing on things. Sometimes it’s just being there as support – as not everyone can code the same function – other times it’s about doing things that only a manager can do like getting budget or removing a blocker”
For Hector, he goes about it through the agile methodology lens, start simple and iterate from there as you continue to gather data and see results. The first step is identifying what the goals are and how they should look like in the short, medium, and long term. Then identifying ways to track that you’re on the right path towards hitting those.
Here are some of his favorite metrics:
“One of my favorite metrics is the committed-to-completed ratio, which basically tells you how predictable a team is in terms of work done. As a manager, if you can say – this is what my team can do in the next month in terms of effort – with at least 95% confidence, you’ve succeeded in proving efficiency.”
Javier recommends starting with understanding the product you want to build, the technologies you’re looking to use and the customer you’re looking to serve. Granted, it all depends on what you’re looking to build: “Start with the goal you want to tackle and the roadmap for it, then move to the specific product area, module, library, or feature the team will be responsible for. This will give you the level of expertise the engineers needed, which feeds into the structure of the team, the engagement strategies, the salaries, career paths, and onboarding process”
It’s a process and it will take time to get everyone up to stable speed or as he puts it, “It’s important to understand that people will not be productive until about the sixth month when they are fully integrated. Senior engineers can cut that time in half. You should spend time hiring senior engineers first, waiting for them to mature their understanding of the product and then hiring more junior members when senior engineers can show them the ropes”
After 12 months then you can start making more informed and metric decisions as to who to bring in “knowing that you have a reliable engineering team that can support newcomers”.
It all stems from your initial and main objective, however, the roadmap doesn’t need to be and shouldn’t be 100% clear according to Hector. “If you’re familiar with the cone of uncertainty, you’ll know that it’s hard to have a full project defined from the get-go in most cases. This is precisely why the agile framework works great in technology. It allows for iterations”
As a Country Manager, Javier has seen it and done it multiple times and his guidance is clear.
Focus on these metrics:
“Once you start seeing that your team is consistently missing their mark on the completion rate, that means that the team is not well balanced. You then go look at the story complexity – how complex are your stories? Do we need to break them down into smaller stories or are they granular enough that it’s something in the team’s skills instead of the stories? Another good indicator is mentoring, you must have a lot of constant and close communication with people, they need to share their knowledge with the rest of the team. If you’re aware that there’s teaching and mentoring going around and you’re still not hitting the response mark, then you’re looking at an area of opportunity.”
From a Scrum Master’s perspective, it’s about understanding how you’re team performs in a steady-state, the targets you want to hit, and what business needs or objectives are sought.
“If you’re able to get your team to a steady state where you can get to that predictability point with your engineering team, and still you’re in a position where your customers are not entirely happy because it’s taking too long to release, then that’s an indicator.
If you’re constantly delivering value, but you could be delivering more value and want to deliver more value, then that’s another indicator, this is assuming that the requirements backlogged are truly vital to the release schedule.
Another conversation starter is when you’re analyzing the product roadmap and as the project manager, you realize that it looks massive and you won’t be able to hit that goal. So you say, if you want me to hit that goal, then we need two or three more resources. If it’s truly important for you as a business, then we need more people to do it.
It’s always a tough conversation.”
As a Scrum Master, with 10 years of experience in working with teams, Hector rapidly summarized what people usually get wrong about the agile and scrum framework: what it means.
“Agile is more of a mindset, a way of doing things, not necessarily a framework. Anyone can come up with their framework based on their needs, nobody uses Scrum the way the book says. Agile is about being efficient. The point is not to be agile, but to be efficient. If you’re switching gears to doing scrum because you want to, but there’s no reason. Then it’s not going to work. “
He recommends using agile in an unconventional way:
“It’s not about the ceremonies and the specific meetings you hold, but rather implementing something that makes sense for your team. “
Javier praises agile as the methodology that not only the technology departments should use, but also departments like marketing, finance, HR, and operations. He identifies the main challenge of adopting agile as “getting people in the same page and helping them get the hang of how to use a specific tracking software”
He believes that non-engineering teams can also adopt an agile approach focusing on the principles of delivering constant value in an iterative process without having all the answers.
“There are some teams that can’t work on a two-week cadence, but where the basic agile principles apply to them because they have quarterly goals, monthly goals and weekly to-do’s”
As a bonus question, we wanted to know what they thought about this new – forced – work from home trend. At CodersLink we’re remote first from inception, so we’re always interested in learning more about how people feel about it and where they see it going.
Here’s Jose’s and Javier’s take on it:
Building great things requires a very conscious effort on managing great minds. Our objective is to provide actionable advice and playbooks from top players in the industry for engineering managers out there to be able to implement.
Our eBook Engineering Onboarding Handbook is out now with actionable checklists for you to use to bring your engineering team to the next level.