Managing software engineers is not as easy as you might think, mostly because in my experience some of the learnings you might have from managing other team members don’t really apply to these professionals. I’ve seen several leaders failing at managing software engineers and this is ultimately leading to turnover in that team most of the time. As you know at different stages you will need a different approach and type of leadership, but I believe that there are a few evergreen suggestions to manage software engineers the right way and that’s what I am going to talk about today.

Selecting the right leader for your engineering team will deeply change your ability to retain software engineers. While that’s not the only thing that will help you improve your turnover, I think you can’t really achieve high retention for software engineers if you don’t have a strong leader managing them.

Who should be managing your software engineers?

This is where to start: who is the best person to manage your software developers? In the early days, that person was usually the CTO (and sometimes one of the founders), while down the road you should have a Director or VP of Engineering managing your team. The person leading your engineering team must be technical! It doesn’t matter if they are still able to code or not, but they need to be able to coach and lead your team from a technical perspective and – in my experience – the more hands-on they can be the better until your team is really too big to have such a thing. I’ve seen CTOs and VPs stepping into roles where they couldn’t contribute and lead the technical aspect of their organization and they quickly lost their team’s trust, especially when they had to fight and impose specific decisions.

If you decide to hire a CTO or a VP that is not technical and will not want to step into the weeds I highly recommend having them hire a Director or a strong Engineering Manager that can coach the team and guide them through the day by day. It’s still not the ideal situation in my opinion, but something that might work out in the end.

As a general rule – if you are scaling your engineering team beyond 20-30 people – interview strong technical leaders that know what the team will need to do and have experience managing software engineers.

Last but not least, I’ve seen great product leaders being able to manage and motivate software engineers. In both cases I’ve personally seen, they had a technical degree and they could speak the engineers’ language. If you find such a profile I think it would be even a better choice considering they will be able to connect product and engineering in a much easier way.

Give feedback to your engineers: coach them on soft and hard skills

Over the years I’ve seen several leaders approaching feedback to engineers in various ways. I concluded that the best leaders put a ton of attention on soft skills for technical figures and they mostly leave the technical aspects to the rest of the team and the culture they create in their teams. What does it mean? Software engineers are usually well-selected in most companies and they learn a lot of their technical skills in their training time or working with the rest of the team, while they usually don’t have a clear way of learning new soft skills. For a software developer, soft skills can be the real way to progress in their career. Working with customers is likely the most important soft skill you can work on with your engineers: it will help your people deliver a presentation to your customers, engage in a conversation, and explain things to them, even with difficult conversations at times. It’s a critical skill because it allows them to understand your product/service and the problems it solves, while it helps your company in creating a culture where everyone knows the product and can talk about it with customers.

Working with sales, product, and marketing departments is the other critical skill that few engineering managers teach to their teams: I’ve seen this done the wrong way in several cases. Engineers get invited to random meetings with these departments where they “learn” on the spot without any guidance. Engineering managers and executive should guide their engineers in how to explain things to the other departments (simply avoiding technical explanations) and coach them on what matters/drives the other departments inside the company. That’s usually enough to make things easier for everyone and give your engineers invaluable skills. I always insist on this in my company because engineers can bring a ton of value to other departments when they are properly trained to work with them. That’s also why a lot of your software engineers can easily transition into other departments and overperform from day 1.

Last but not least soft skill you need to consider: teach your software engineers how to talk to non-engineers. I know this is a cliche but in my experience, this is a true superpower in most organizations. The engineers that get promoted are the ones that can work well with a lot of different people and situations, and those are usually really good at simply explaining things, focused on the business more than the technical side of it.

Coaching on soft skills should happen on the business: invite your engineers to meetings and let them be flies on the wall while you talk to other departments, vendors and customers. Over time you can have them stepping in for simple things. At the end of each session give them feedback: precise and constructive on what they could do better next time.

Having your software engineers presenting to the rest of the company is the best way to train them on their soft skills while also giving them the opportunity to learn what works and doesn’t when you have to explain things to non-technical audiences. It’s also the first safe-step you can take before they have to do that in front of external stakeholders, like your customers. 

What about hard skills then? A lot of that, as said, will be taught during their normal job from other colleagues. What you should ask them to do is to follow their career path, invest in learning new things and also have small side projects for your company that give them new technical skills. Similar to soft skills you should give them continuous feedback when things happen and during your 1to1s.

How to incentivize ownership in your software engineering team

When your software engineers have a strong sense of ownership, projects advance much faster and problems are easily solved, before they spread to other departments and to the rest of the product.

Ownership can be developed and while some software engineers will naturally approach things with it in mind, the majority will need constant coaching and an environment where ownership is highly valued and incentivized. Small teams that have a strong sense of ownership will ship software much faster than larger teams.

Explain what you mean by ownership

This is the first step. Ownership is about having full responsibility of a project or a feature that the software engineers need to build: when your team is fully committed to it you will see how they review tasks, they try a lot of their software several times in multiple cases before realizing it and most importantly, they care about feedback.

I also found engineers that have a strong sense of ownership to be the most curious ones about the strategy, product and business direction of what they are building. Ultimately to really build something great you need to know as much as possible about it and great engineers are usually the first ones challenging the overall company’s assumptions.

If you are leading a company where your technology and software engineers are key, you should introduce them to the concept of ownership and explain with a few examples what that really means. The same thing should be done regularly by your VP of Engineering or CTO.

A good way to see how your organization is doing in terms of ownership is looking at what happens when customers report bugs or serious issues in your software: if your engineering team doesn’t want to look into it as soon as possible and really spend a few hours to get it fixed, it’s clear then that the right expectations are not there. Instead if your engineers are demanding to look into it and want to know more – no matter how big the issue is – that’s always a great sign.

Trust your engineers and keep them accountable

This is difficult, especially for leaders not in the engineering department or for founders and CEOs. The reality is that building ownership in your company is a long process and it starts with trusting your people. The same goes for software engineers.

The key thing here is to learn how to trust your software engineers with their decisions but make them accountable for them. They should know that they are responsible for that decisions and will have to work with the rest of the organization based on that. Quite often this is the opposite of how companies manage software engineers: they impose deadlines, decisions and strategies just to blame them as things fail.

Mistakes I’ve made managing software engineers

I’ve made almost all these mistakes at different stages of my career and I ended up learning a good lesson from each. In my experience several founders – and many executives – make the same type of mistakes. Some of them will have a direct impact on the tenure of your engineering organization so avoiding them will save your company a lot of money in recruiting fees!

Mistake #1: assume your software developers know your business
I got a lot better at this over the years but in the early days I would simply assume our software engineers knew why we were building specific software in our business and why our customers were asking for it.

This led to all sorts of issues, from products that were not really solving the problem we had in mind to the need to adding management levels and processes to check that things were running fine, when instead I could have spent a lot more time explaining our goals and needs to the engineering team, while coaching my executive to constantly do the same. If your organization is small enough to allow for this, spend time with your software developers as CEO/Founder or owner of the business. Tell them what you hear from customers and create the connection for them between that need and what they are building: nobody wants to work on useless things and it’s always easier to ask for strong commitment when the “why” is crystal clear.

Mistake #2: I did not set expectations upfront
This happened when we moved from a B2C business model to a B2B one. I ended up not setting the right expectations with the engineering organization in terms of reliability and flexibility of our solution and it took us a lot longer to build a truly enterprise solution.

I should have spent more time explaining what our enterprise customers were expecting in terms of reliability. Whenever there is a big change in your business, you should really spend time setting expectations with your software engineers – in my case a lot of the final result was ultimately dependent on them as they had to rebuild several parts of the product.

Mistake #3: Tell them how to build things
A classic mistake. Executives telling the software engineering team how to build solutions or ship new features. This never works: going back to the example of moving from a B2C focused business to an enterprise platform, I felt the need to direct our engineers too much into specific directions.

Needless to say this approach never works and it won’t help in reducing your turnover rate.

Mistake #4: Impose technologies or vendors to your team
Don’t try to impose technologies or vendors to your team: at times I felt they couldn’t see the strategic advantages of some choices and I had to step in. Later on I changed my strategy and I simply worked on the needs and requirements of our company more than the technology or vendor we needed. Forcing things on your software engineers never really works in my experience, imposing vendors or technologies is as counterproductive as telling them how to build software. Something you can consider is actually involving your team in this type of decision making: you can still have the last call in your role if you need to do, but you should really listen to the PROs and CONs of the team first.

Mistake #5: constant pressure to deliver more features and products
Every company experiences stressful moments where things need to accelerate and strong deadlines need to be there. The reality though is that these moments cannot become the new normality, especially for your software engineers.

Your engineers can definitely work under pressure once or twice a year, but pushing that further will inevitably create turnover.