The role of a Software Engineering Manager

This is an opinionated view based on my observations as an Engineer and a people leader in sizable organizations over the past couple of decades. I have had the privilege of learning from great managers & colleagues. I have also run away from toxic environments that sucked the happiness out of everyone including the people producing the toxins.

If someone tells you that they have complete clarity on the role of an Engineering Manager, they would be lying. Simply put, this is one the toughest roles out there - one that requires you to operate at the intersection of people, process, product, and technology.

Team

Create an environment of fun, learning, & collaboration

This is hard work. Great teams love teaching, are diverse, and every team member has each other’s back. If you haven’t already read Google’s research on what makes teams great, I encourage you to check it out. As managers, we’ll have to have a pulse on the overall strengths and weakness of the team so you can intervene and course correct appropriately. Be it a tactical thing like offering training to the more nuanced forming of groups based on complementary skills.  Building trust across your team is foundational to creating a fun, learning and collaborative environment.  Creating a place where learning and failing are both recognized (positively) is essential.  

Hire and develop diverse talent

Hiring is a critical component of building culture and great teams. You immerse yourself in the hiring process and look for people who can augment the culture, not just be “culture fits”. Looking for eager learners that bring passion and energy to the interview process is something you strive to do.

Teaching to fish instead of fishing

Too often we get ourselves into situations where any work related to “X” always goes to one person who’s heavily knowledgeable in an area. While this ends up delivering the fastest outcome for the task, we end up doing ourselves a disservice in at least three ways:

1. We burden that person with always “owning” that particular area, which can put a strain on the person and can lead to somewhat reduced code quality over time (b/c only 1 person owns that area, hence they don’t have any ‘qualified’ reviewers)
2. We lose the opportunity to teach other engineers (who are often hungry for learning) about that area/technology.
3. That person burns out and/or loses all hope of gaining new knowledge.

Individuals

I do not doubt for one second that routine processes to check in with our Engineers help. Monthly check-ins, 1:1s, etc are all valuable. But what’s most important is if you know what drives Jane and what’s stopping Joe from excelling. To get to this, I believe a few important things need to be talked about:

• Ensure every employee is taking on meaningful, and impactful work. If you find yourself just allocating work to someone, stop and look for underlying issues. Note that the definition of meaningful varies by level: A Junior Engineer on his first job may be super excited to take on updating content copy in a workflow whereas a more Senior Engineer may be looking for something that’s end-to-end (full-stack, perhaps) to broaden her horizon.
• In your 1:1s, you ask specific questions.

What’s something that everyone is afraid of talking about?

What could we have done differently in project X?

What advice do you have for me before we start this new thing?

• You focus on personal development goals. Public speaking, creating tech presentations, opportunity to be mentors are all laudable goals and you are in a unique position to broker connections.

Servant leadership

When you are passionate on behalf of your Engineers, whether it be for the project, for developer productivity, or for their own time to “do what’s right”, this creates so much trust and appreciation.

Talkers vs. Doers: what you recognize, reward, and praise matters

A big component of a healthy culture relies on you keeping the folks who “talk more and do less” under control. In order to do this, you have to get a pulse of `real` work that is happening. 🗣

As teams grow and charters expand, it’s easy to encourage (and even rely on) story-telling, to a fault. And if that behavior gets rewarded (because you are unable to distinguish between what is being said vs. done), this can be a big drain on the entire team.

Your peers

For us and the initiatives we undertake to succeed, we need to help our peers. We lean on each other and continually learn from each other. Give each other candid feedback, call each other out, bring contentious topics to your group to discuss - but, avoid talking behind people’s backs.

Remember that your Team #1 is comprised of your peers.

Process

• You strive to create processes that add value and don’t become overhead.
• You acknowledge that what works and is needed today may become obsolete tomorrow.
• You try to create processes in a way that allows Engineers to focus on the most important part of their job: Building. Creating. Designing. 15 minute blocks of coding amounts to nothing. Four 1-hour blocks in a day are not bad, a solid 4-hour block is great! ⏱
• Processes and the environment allow junior engineers to have singular focus while expecting more senior devs to multi-task and context-switch.
• You do not create meetings in order for you to remain informed. You remain informed by sitting with your engineers and the working team.
• You empower teams to make decisions - but, you're not afraid to break ties.
• You create a culture where people disagree, but don’t get stuck debating. You help make decisions.
• You embrace the “It’s not my fault, but it’s my problem” mindset. (e.g., you take on a bug fix in a code repo that you don’t “own”).

Product

• Use your products. As an employee previously in a telecom company and now a Small Business software company, this is easier said than done. Not just the product that you and your engineers work on.
• Report bugs. Follow up.
• Play with competitors' products.

Technology

These days, frameworks are a dime a dozen and the technology landscape is changing rapidly. You simply cannot build expertise in all the areas where your Engineers are involved. My recommendation is to pick an area in a given month (if a month is too short, make it a quarter) and go as deep as you can. If you only stay broad, you’ll find it harder to stay in touch with the code and the decisions, imho.

Other components of building a great team and technology driven culture include:

• Always pay attention to performance. Digging deep on gnarly performance issues often leads you and the team to learn many hidden corners of your system, subsystems, and dependent services.
• Build the culture of “Ship & Re-factor continually”. As a manager, if you feel like you don’t have the bandwidth to take on an item in a critical path, dive into a re-factoring project/task that doesn’t have the same time pressures.
• Write unit tests. Celebrate great unit tests! Unit tests are a great way to stay in touch with not only the code, but also the core workflow!
• Fostering the open source culture (both “internal open source” and true open source). This is easier said than done as time pressures lead us to taking shortcuts that keep libraries, utilities, tools, and SDKs in the same git repo as our product.
• Instituting a healthy Pull Request review process that works for your team.
• Be the champion of Developer Productivity: Happy Developers build great products. A developer will join a team where a build takes 30 seconds over a team where a build takes ½ hr over a team where someone from SCM has to kick off a build. I subscribe to the philosophy that you’ve gotta be able to run a scaled-down production system on your laptop.
• Push for Continuous Delivery/Continous Operations. Immerse yourself in CD/CO and help your team get to NO-DRAMA releases.
• Argue & fight about Database design, be more forgiving on higher layers. Mistakes at the foundational layers can cost dearly, but you should encourage your Engineers to take more risks as they go up the stack.