Lessons learned in engineering teams management from interviews with Country Managers, Engineering Team Leads, and Scrum Masters

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. 

Carrots and sticks management is long gone, today’s modern managers are enablers.

I couldn’t have put it in better words and I have no additional commentary to add to their direct quotes:

• Engineering Team Lead, Jose: “The role of a manager has changed, the old books teach about reward and punishment, but when you’re dealing with creatives you have to adopt the ‘servant leadership’ approach where you focus on removing blockers, coach them and allow for autonomy, mastery, and purpose. 
• Country Manager, Javier: “Enabler; that’s the word the describes what a manager should be. They should know the team’s strengths and weaknesses and they should internalize that they are the team’s sponsor that helps remove blockers and resolve impediments. They are also a shield that isolates people from situations and distractions that might affect their performance from simple company-related hurdles to personal problems.”
• Scrum Master, Hector: “A manager is there to guide you as opposed to acting as a leader. They are there to make the team aware of where they are going and what the roadmap is. It is also their responsibility to make sure that no one is falling behind, and if they are to find ways to support and help them as a team, not as a manager.”

Engineering performance is guided by trust, clarity, and measurement, not micromanagement.

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 – build trust so you can have difficult conversations and everyone feels comfortable with pointing our problems or giving constructive criticism. 
• Time management – blocking time, using the Pomodoro technique, using WIP limits, and ruthlessly prioritizing. 
• Team accountability – nothing happens in silos, everyone is important to deliver value.
• Simplicity first – it’s not an easy thing, but it’s something you should strive for. 
• Value the individual – know what they like and dislike, to be able to be a better coach. 

“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:

• Clear communication of KPI’s – quarterly goals, monthly goals, and success KPI’s
• Transparency on how decisions are made – taking time to explain how and why a decision was made, to understand how to do it in the future without your input. 

He also believes in empowering your team by challenging and giving them space to experiment and get things wrong. 

• Allow team members to take bigger, but reasonable commitments, that are risky or outside the scope of the project
• Present their work, research, or implementation of certain technology to the team. 
• Reinforce that every decision made is taken as a team 
• Focusing on learning before moving on. 
• Allowing them to say no. 

 “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:

• Burndown
• Ticket Velocity
• Committed-to-completed ratio 

“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.”

It’ll take you from 9 to 12 months to build a stable, productive engineering team of 10 from the ground up.

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” 

Knowing when to grow your team shouldn’t be a knee-jerk reaction, but a measured one.

As a Country Manager, Javier has seen it and done it multiple times and his guidance is clear. 

Focus on these metrics:

1. Completion Rate – stories taken versus stories completed and the history of this. 
2. Story Complexity – are the user stories broken down to their most granular point?
3. Team Mentoring – does someone in the team have knowledge of what we’re working on that they can share?
4. People Burndown – are they delivering, but are they exhausted and it’s unsustainable?

“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.

• Are you hitting your marks? 
• Are you delivering value at the rate your customers expect?
• Is your current team able to tackle the project requested by stakeholders?

“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.”

Agile is a way of thinking, not a cookie-cutter approach to project management.

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:

• Define what it means to your whole team, get on the same page
• Define what you’re lacking in your efficiency and what you’re looking for
• What are our team working agreements?
• How are you going to define work is genuinely something actionable?
• What’s the definition of done? Does it have to be in production, or ready for QA or in staging? 

“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”

The not-so-obvious reasons why remote work is here to stay – mindset and productivity.

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: 

• Jose: “We don’t reward presence anymore. The added value is that you look more at what comes out of your work, what value are you adding to the company, and not how much presence time you have at the office. The mind-set is changing and that will continue to happen to other industries and positions. The rise of better technology, communications, security, and work tools have become enablers for us to do this” 
• Javier: “ Work and talent opportunities, team diversity, unit economics for both employee and employer, and more personal time are all factors that are becoming apparent after COVID-19. Those that were thought of, as ‘theoretical’ for most positions. It has also shown the disbelievers that remote work is not only possible but productive and cost-effective. I expect all companies, especially tech companies, to have between 20-50% of their workforce working remotely in the near future.”