Confido Q&A: How do you grow an empowered engineering team?

You know that becoming a leader isn’t something that happens overnight. It’s a skill like any other that needs to be developed and nurtured. Becoming a leader that not only motivates, but also inspires and effectively implements change is the ultimate goal.

There are countless approaches that companies and individuals take to leadership and scaling teams & during this Q&A (and others in the series) we’ll be capturing individuals experiences and knowledge to bring these to light.

Marco Massarotto, Engineer Lead at Lloyds Banking Group, has had a varied career journey. Starting as a Web Developer & Front-end JavaScript specialist in his native Italy, Marco’s need to constantly push and challenge himself has driven him to the leadership ranks. He’s now innovating software technology for one of the biggest banks in the world, Lloyd’s.

We caught up with Marco to discuss everything from how to inspire and motivate your engineers as a leader, through to the challenges of implementing startup mentality and new tech to a more-established businesses.

If you’re an experienced engineer that’s looking to take that leap to leadership, or you’re a leader looking for new ways to scale your team at a time of transformation or growth, continue reading to discover how Marco has achieved both.

Hi Marco, could you quickly talk us through your career journey?

After completing my Computer Science degree I was lucky to have a very interesting first job building a bespoke ecommerce site for a luxury fashion retailer in Treviso, Italy.

I then changed direction, moving to Bologna, and a Front-End Dev role using JavaScript for a security company that specialised in analytics & monitoring network traffic for the Italian military and then to a rapid prototyping company. In both of these roles, there was an extreme amount of innovation and collaboration with the outside world, including Stamford Uni.

After that I moved to London and a startup called Mendeley, who’d been acquired by Elsevier. This was a time of great change for me, with the cultural shift by country, moving from a small city to a big city and from a small company to a growing startup. I was employee number 90, 2 months before I joined, they were 25 only and by the time I left a year and a half later, they were up to 250 people. That gave a lot of opportunity to drive the growth and technological innovation with the company. 

I then moved to the Mail Online as a Senior Dev and was quickly promoted to Team Lead. It was my first step into my leadership career. I was able to create a strong tech team around me, implement my way of working across the team and formalise it, before rolling it out across multiple teams. I think we created a very strong Front-end JavaScript development team.

Again, my desire to grow and continuous search for responsibility & I wanted something bigger – they did want to keep me, but when I set a direction, I rarely change my mind.

I accepted the role at Lloyds as a Software Engineer Lead, and I was promoted to Lab Engineer Lead after a year. Now I’m responsible not just for the software, but engineering as a whole, enterprise architecture, software architecture and stakeholder management & innovation.

I think there has been a lot of innovation so far, implementing Opensource and startup mentality in the banking environment, is obviously a huge challenge, but something the company is looking for.

2 and a bit years later, I’m still here and still growing, there is a lot of opportunity.

You’ve progressed considerably – what’s that transition from hands-on to leadership been like? 

I think in my time as an engineer, I got examples of good leadership and bad leadership. I’m a strong believer that a good engineer makes for a good engineer lead. It is important you have that knowledge, compared to someone detached from that technology – you need to speak the same language.

My transition was scary - I won’t say ‘fake it til you make it’, but obviously the bank was very corporate. There are lots of people to speak to that are not at the same tech level and there is a lot of process. It wasn’t the easiest transition, and it was challenging, but as you may have understood, I like challenges. But I think challenges are the fastest way to grow.

Moving from software engineering to engineering leadership, I still try to dedicate a certain percentage of my time to coding, coding review, pull requests and technological decisions.

I’m not sure it’s important for the role, but it’s important for me. Even now I spend 20% at work on code. In my personal life I still do Hackathons, I do competitions. I would struggle if I didn’t have an element of coding my daily job.

What are you like as a Leader?

Luckily, I had good role models to follow in my current job, my current and previous upper-level Engineer Leads, were very good at both the tech and business parts of their roles.

I am more than a General, I am someone that works together with an Army. I take that type of leadership, to push from below to solve problems, rather than give directions.

It’s just one type of leadership, but one that suits me the most (although there are other styles) and gives me the chance to keep that 20% hands-on responsibility.

There are obviously multiple styles of leadership and strategies - what is the key to a successful leadership approach in your opinion?

I don’t think that strategies are the problem. It’s usually the people. You can follow the best ‘strategy’, but if you don’t trust your engineers, your strategy is going to fail. The core for any leadership strategy, is trusting your engineer.

I believe that hiring needs to be a leadership responsibility. You want to be able to build that core team around you. Once you have that core team, you can delegate. Once you have something that works, that others can crystallize around, that system then can self-expand, because you have the right people in the right position.

The worst way to lead a team, is to hire a good engineer, pay them a lot and then tell them exactly what to do.

If you were building an engineering team, for a Startup from the ground up, what are the core roles you would put in place? 

Culture and how you define the culture of your team is critical for the early phase.

That can be the success or failure of your team. A good culture where your team feel they can innovate and are passionate about that, will increase the likelihood of a successful project.

I would prioritise passion over tech experience, but it’s obviously better if someone has both. Otherwise, you try to get both by combining different engineers.

Communication is very important especially in your first team - to have the soft skills to communicate problems. Engineers tend not to be good communicators, which we except. But, if you’re a startup, you need to get that information bubbling up.

You also need a very good Scrummaster - someone that is able to set up those ceremonies and properly mix up the product and development team. They need to be able to explain to the product team how a high performing engineering team works.

A product owner is essential too - someone who is experienced and comes from the tech world, not the business world. Otherwise that can be a problem, the focus should be the software product, not the business product and you might risk prioritising the work incorrectly.

That for me is the critical core characteristics.

Then you keep replicating this model over and over.

Passion is a core attribute you look for when you’re hiring - how do you gauge that passion and any advice to your peers on how to show it?

It’s hard to explain & replicate. When I’m interviewing, I might focus on the technicalities, but then put away the standard questions and move on to the technologies, news that just came out or ways of doing things. There is no right answer, but it’s the conversation that I expect from a leadership engineer that shows the sparkle.

A leadership engineer, that doesn’t follow the news, doesn’t keep up to date and doesn’t have a specific opinion, might be too blunt from the role.

I might not agree with opinion, but I love to discuss it, especially if it’s different from mine. I expect to see that passion.

When interviewing for a startup, as well as tech discussion I like to talk about the product. For example, if you’re interviewing for a startup for self-driving cars, if the engineer doesn’t show a curiosity or interest in this topic, they might not be the right fit. It might not mean you don’t hire them, but it might also mean you need someone else, that has that passion, because it motivates the team.

As a manager, apart from trust, are there any other factors, or processes that you implement that are crucial to your team’s success?

Tracking your developers’ performance is important in any leadership role. Code review helps you do that.

When you set up standards around quality and ways of working methodologies – you don’t want that to slowly fall apart. You might not have enough time to follow all your team, but checking in, giving some useful comments is crucial. Never stop measuring your engineer’s performance, there is nothing to hide, there is nothing shameful in it.

Especially if you use modern tools and solutions, they give you daily metrics, both for a leadership level, to identify any under performers or potential issues you might need to discuss with your team – is something going on in the office or at home? But they also provide feedback at an individual level to help someone with their own growth, for example, learning to make a smaller commit if you consistently over promise.

Some people are hesitant to track their team like this, because engineers might feel observed or worry that’s how their bonus is calculated. But, that’s why you have to be open with it and be as transparent about it as possible to your team.

What do you think is important to motivate your engineers?

Well, money certainly, but you can find that everywhere nowadays for engineering. It’s not an underpaid job and over a certain amount that’s less relevant.

1.   Autonomy

2.  Opportunity for growth - so having the ability to see what their next step and pathway is, even if they’re not ready.

3.  Challenging work – every engineer wants to do a good job and do an interesting job.

4.  Opensource visibility – the system right now doesn’t try to hire engineers’ long term; it’s very hard to get an engineer and keep them. What you want to do is create an environment and good culture to attract a good engineer, so that when they leave, they speak well about you. Opensource helps with this, you get contribution and visibility for your own company and at the same time give visibility of that engineer’s work for their future career.

One of the biggest challenges our clients talk to us about is the struggle in aligning technical and business visions, both for startups and more mature businesses. How do you approach this and what can you advise?

It is a struggle. My favourite approach and what I believe works best is to start with something simple. Demonstrate you can get it done.

Again, it’s a trust problem. Product people don’t trust engineers based on bad experiences in the past. There’s a vicious cycle where engineering does not trust the requirement and product don’t trust the deliverable.

Start with the simple things, get them done properly and then open the communication channel at the point when you are speaking the same language. You need to be clear you’re speaking with someone that isn’t a tech person. You need that translation layer and talk about your tech benefit in terms of product benefit.

It’s not just a new toy, you’re going to create benefit in short term, medium and long term. It’s an ability you learn and I’m always aiming to improve. To turn that technical idea into long term non-technical benefits.

The products you’re building day-to-day, how have you gone about improving practices and ways of working?

I’m very opinionated on this. My opinions aren’t on right ways of working or the right standards, but about the level of detail and level of quality that your ways of working have. The first thing I did in this team is set up those standards around code quality and ways of working.

Upon setup of those standards, I setup a framework or way of thinking about any new standards or methodologies. Other teams then picked it up, because it worked and they wanted to adopt it – I didn’t push it, they just proved valuable.

Don’t focus too much on the detail, you don’t have the time to do that, and you don’t want to impose.

You just need to set a perimeter and let people move freely inside. But… as soon as people move outside of that, you do need to pick them up.

If you were speaking to a peer or offering aspiring leaders' advice on engineering leadership, what would you say?

That is a hard question. I would say, try to find a role model follow them, or find a negative role model and do the opposite!

Don’t stop being an engineer just because you move to leadership because that won’t be good for you probably. It’d be hard to do work you don’t like.

You don’t have to be a leader to proceed your career. Some engineers think the only right way is to move to leadership, but it’s not. You can be a highly skilled highly paid software developer.

Only move to leadership if you think that’s something you would like! The more technical you were, the harder it is – it’s satisfying, but it’s a skillset you have to build from scratch.

Leadership is like any other knowledge; you need to study. There are books and training. It’s not something you get by osmosis (partially yes), but you need to put effort into it.

Experiment and find a way that suits you the best.

Don’t forget to follow us on LinkedIn and Twitter to keep up to date with all our latest Q&As and content, including career tips, startup life insider information and the latest tech news.

If you’re an aspiring leader and would like some further guidance on progressing your career, get in touch today.