Leadership advice · Building and inheriting teams
How engineering leaders build and inherit teams
Starting a team from scratch, taking over someone else's team or codebase, and building a culture that keeps improving.
Interviews
Questions we asked
Asked on camera at our meetups. Where more than one leader answered, the answers are side by side. Transcripts are lightly edited for reading.
You've inherited an existing codebase that isn't yours and is full of tech debt, but the business already uses it heavily. What's the best way forward?
2 leaders answered this one.
“One of the first steps for me is to change the mindset of the members that this code is yours to maintain and to grow.”
Read the full answer
It's very similar to what happened to the current engineers in Angkas. We have an existing system that we wanted to maintain, and the responsibility and ownership was transferred completely to us. One of the first steps for me is to change the mindset of the members that this code is yours to maintain and to grow. Because some engineers don't want to dig into the code, since it's not theirs in the first place. So we need to fix the mindset.
Secondly, once you fix the mindset, it becomes easier for people to find things in that existing codebase and figure out how to fix them, and to know it like the back of their hand. Eventually the challenges become easier once you change the mindset.
“Every time we would do a sprint, we have a specific ticket for refactoring.”
Read the full answer
I've actually experienced that. When I joined a previous company, I was the only developer at the time, and a lot of technical debt was coming up while we were doing the project. In my opinion, the best thing we did was this: every time we would do a sprint, we have a specific ticket for refactoring. Every time we touch something, it's a must that you refactor the specific component you touched while doing the feature.
Another thing that was effective, at another company, was a Friday hackathon. It was basically about addressing the tech debt that was really prominent or really affecting the project. Those are the things that really helped us.
You've inherited an existing engineering organization. How would you go about managing it?
“You can't put any changes immediately because maybe they'll get culture shock. So you'll just need to adapt gradually.”
Read the full answer
In inheriting an existing engineering team, I think the important part is knowing every team member: their character, their attitude, their skills, and especially the current culture of that team. After that, you need to decide how you're going to integrate yourself into their existing practices. You can't put any changes immediately because maybe they'll get culture shock. So you'll just need to adapt gradually: introduce new rules, introduce new standards. I think the most important thing is blending in.
You're the first member of a newly created engineering organization. How do you decide what people you need, and how many of each role and skill level?
“I need to learn deeply the architectural structure of the company for me to decide what resources would properly fit in and what roles do we need.”
Read the full answer
For that, I need to learn deeply the architectural structure of the company for me to decide what resources would properly fit in and what roles do we need. And then incorporate the team's and the company's goals in parallel, which would eventually translate to the success of the team and the company.
Can you share an example of how you successfully built and led a diverse and inclusive engineering team?
“It's important to allow your team to fail fast, but at the same time, set up some guardrails for them to fail.”
Read the full answer
So, in UnionDigital Bank, right, as a new bank, an upcoming bank, one of the things that we wanted to practice as an organization is being open and being inclusive of different types of sexuality, different types of beliefs, right? And in order for us to foster that, we have one unwritten rule: that we should respect other people's beliefs and opinions. That's one.
And number two, for building a strong engineering team, we should allow our team to fail fast. I know it's cliché, but it's important to allow your team to fail fast, but at the same time, set up some guardrails for them to fail. So if they fail, it means they've learned something, but at the same time, it's not going to affect the business heavily.
The way that I put an analogy around it is F1 racers, right? They move very fast, but there are guardrails on where they go, so that in case accidents happen, there's a limited blast radius.
How do you approach fostering a culture of continuous improvement in software development processes within your team?
“During the sprint retrospective, this is where people or teams discuss mainly all the things that they could improve.”
Read the full answer
In the project teams that I'm handling, mainly developing a specific product, one of our techniques is Scrum. Within Scrum, there's a framework that lets the team talk about the things they didn't like, the things they want to keep doing, and the action items that would resolve the things they didn't like. We call it a sprint retrospective.
During the sprint retrospective, this is where people or teams discuss mainly all the things that they could improve. It could be the way they collaborate with one another. It could be communication. It could be the process: how they do testing, how they do code reviews. And of course the technology, like what they lack in terms of automation.
We have a lot of teams within White Cloak working on different products, and we make sure every team does the sprint retrospective religiously, and that the Scrum masters or project managers follow up on the action items. That's basically it when it comes to building a culture of continuous improvement.
Takes
Short takes
Clips edited down to the answer, labelled with what they're about.
Take · On collaboration in hybrid and remote teams
There's still something really important when it comes to people meeting up once a week. That helps build up camaraderie between engineers.
Read the full transcript
The way I encourage people to be collaborative in a hybrid or remote setup is to have open communication. We have a huddle where my team members can join and have a discussion with their peers. You can just jump into a call and invite someone to a discussion. If someone needs help, they can join that meeting any time.
And of course, there's still something really important when it comes to people meeting up once a week. That helps build up camaraderie between engineers, or members of your squad. They can have lunch together. That also helps bring people closer in your team.
Take · On the pressure to grow
All companies are being pressured to grow, and you cannot support your operations if you are not growing.
Read the full transcript
I think the point is this: all companies are being pressured to grow, and you cannot support your operations if you are not growing. People, especially executives and leaders, are being pressured to grow their businesses. From a startup, even if you're already mature: what's the next level of growth for your organization?
Take · On getting engineers to speak up
We don't invalidate any ideas from any engineers in the team.
Read the full transcript
I really encourage the team to be involved in the project. That's the strategy I built: I made them very comfortable with the team and the organization, to give them the courage to participate and speak up with their ideas. Then, of course, we acknowledge and validate their ideas. We don't invalidate any ideas from any engineers in the team. Basically, encourage everyone to give their suggestions, feedback and ideas.
Keep reading
More leadership topics
Your turn
Come to the next eHeads.
Open to every technology leader, especially new ones. It's free.