12 Leadership Essentials for a Software Engineering Manager

Most engineering managers and leaders today, including myself, come from technology background and not necessarily from people or business management.

In a lot of cases, good software engineers are handed the mantle of responsibility with the assumption that they will pickup leadership skills on the job.

While we do seem to have a certain tactical advantage of understanding technology — leadership is a discipline in its own right and should be treated as such.

I thought it would be helpful to share some of the essentials, that I believe, every new engineering manager should know. This is not a complete list by any stretch of the word, just some things I found useful. At the very least, it should serve as a good starting point for further reading and discovery.

Leadership

1. Excel at the technology you are managing

A lot of management theory exists around trusting your people and building the right team. I don’t discount that, but in my experience being good at the core technology you are managing goes a long way in improving the quality of your product and experience of your customers. You also gain valuable insights and develop real appreciation for your team’s work. If you are not already good at something, don’t shy away from asking your team to teach you. At the very least, know the basics well.

2. Don’t code large features, do code small things

Should mangers write code? This question has been a point of contention for some time. There are no hard and fast rules and I do recommend reading Nikhil Garg’s excellent article on this topic.

My thinking is that coding small fixes and features will keep you much closer to the pulse of what is happening at the ground. You should do that. Coding large feature will keep you away from much important work that no one else can do; so avoid doing that.

I also recommend reading through code and occasionally doing code reviews. Exception to this rule should be used for large teams with multiple direct and skip-level reports. In those cases — limit yourself to design and architecture.

3. Don’t change someone’s code without consent

If you are coming from an engineering background it might feel tempting at times to make small edits, or in some cases, simply rewrite someone’s code to make it “better”. Don’t do it. It creates a toxic environment. Instead, give feedback to the original author and have them make the changes. Help them become better and provide background. This will create long term value at the expense of some waste of time in the short term. There are some exceptions to this rule but those are rare; like the original author not being available or if you are working as a pair.

4. Focus on People, Vision and Process

Your primary function as a leader is to figure out who needs to do what, whats the long term plan of doing it and what process should be followed. When making new processes try to keep things simple.

When choosing between simplicity and completeness, choose simplicity. Complex systems have a way of finding unanticipated problems.

If things are failing don’t be tempted to jump in and start coding, work on long term fixes and process improvements and remember to involve the people who will be using the process. It will foster creativity and seamless alignment.

5. Do regular 1–1 and team meetings

Gathering and delivering feedback is one of the primary function of the manager, yet so many managers still don’t have a structure around this process. Regardless of the team size, meeting with direct, and if possible, with your skip-level reports is critical to a well functioning team. Team meetings are equally as important and help build a fluidity to your team that comes handy in critical moments. Keeping a journal of your 1-1s and sharing them with the individual is a great way to build trust and consent.

6. Use the LARA method when receiving feedback

While it’s natural to some, not all of us a great listeners. I found it very helpful to use the LARA method when receiving feedback.

LARA stands for Listen, Affirm, Respond, and Ask Questions. The LARA method builds respect and common ground between people in conversation, allowing you to explore your differences more openly and honestly. LARA is especially useful when people are feeling that their hot buttons have been triggered. — Stanford SPARQ

Side note 1: Remember to setup a follow up when a problem is brought to your attention, it doesn’t matter if the problem was solved or not. You have to follow up.

Side note 2: There is a ton of stuff out there about “active listening”. I recommend investing time in getting better at that.

7. Use the SBI method when giving feedback

SBI stands for Situation, Behavior and Impact. This is a great system when giving positive or constructive feedback but specially useful when providing criticism. Try not to get emotional and never pass a judgement. For example never say something like“You are a bad programmer” instead stick to the facts and use SBI method to explain what was the situation, what they did and what impact it produced.

Remember to start and end with positive feedback when delivering any critique — there are exceptions to this rule though — some times is necessary to go straight to the point to avoid confusion and make an impact about the severity of the issue.

8. Learn to negotiate

Negotiation is a key skill to learn as a manger. You will be negotiating up, down and sideways. It is imperative to learn to do it without making enemies. There are two excellent books that I highly recommend on this topic. Getting to Yes by Roger Fisher and Never Split the Difference by Chris Voss.

9. Develop social intelligence

It may sound obvious but I’d like to point it out, because sometimes it just gets lost in the day to day.

Everyone you work with is also a person; with their own background, life experiences and personality. Spending time and energy to understand them and their situation can only help to make your (and everyone else’s) life better.

Note that, social intelligence is a developed skill that one can build over time. Sometimes you may get things wrong, and thats ok. You are a person too.

If you are really struggling with someone it may not be a bad idea to work with them and do a personality test, share your results with them so both of you can work better together. I’ve tried it — it helps.

10. Setup goal oriented career paths with focus on Intention

Intention is defined as an over arching goal for an individual that will help to shape their short and long term goals and help weed out any activities that don’t support such goal. A person’s career path should be built around their main Intention.

The trick is to build customized career paths that are meant to drive an individual’s career towards a particular target.

Using OKRs is a popular system of tracking this but you are not limited to that. If you find OKRs to be too complicated a simple system of documenting intention for each team member and tracking intermediate targets that meet that intention will work.

Define intention first in a collaborative manner. This is key. Everything else can fall behind it and just becomes planning and execution.

11. Develop a relationship of trust

You might have heard a lot about building trust, but not a lot about how to go about doing that. Here is how: Don’t lie — ever and keep your commitments. Explain and apologize when you can’t, be honest. Clarify Expectations. Try not to criticize in public, try to praise in public and private. Don’t pass emotional judgment. Bring real facts and stories when praising or criticizing.

12. Use well-documented methods for tracking productivity

Often time managers rely on their gut feeling to gauge the performance of their reports. I propose maintaining a separate journal for each team member contains record for their hits and misses as well as tracks 1–1 conversations and progress of goals. There are a ton of tools out there for setting and managing this but something as simple as a google worksheet is as good as anything if it gets the job done. Simplicity is better anyway. I recommend splitting these up by yearly, quarterly or monthly basis so its easy to find information. You will need to become a master organizer if you like to keep this manageable.

Final thoughts

As you can imagine leading a productive and successful engineering team is not a straight forward task. You can begin to master this by starting with simple methods and overtime building your own system based on your team environment and culture. I would love to hear from you on this topic, feel free to reach out if you have any questions or comments.

If you are a developer you may be interested in reading my blog at effective-programmer.com

Cheers

Technology leader, entrepreneur and angel investor. Director of Engineering at Kinoo. I write about software engineering at medium and effective-programmer.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store