Philosophy of Software Engineering

I’d like to share what it feels like being an Engineering Manager, in hope of clarifying the expectations if you’re thinking of transitioning to a managing role, reduce the confusion if you are somewhere in the transitioning path, and maybe entice you to consider the possibility of leading, if you haven’t considered it yet.

I decided to talk about this, because when I took the role, I have no idea what I was signing up for. I went through a lot of uncertainty and confusion during my transition from a developer to an engineering manager. Now I feel I’m in a happy place. I have my job figured out. I would like to share my experience, so that you can see if this role is for you. And if it is, hopefully to get you to reach your happy place sooner.

What does a Engineering Manager do?

A big difference between the way a developer work vs the way an EM work is: developers are usually given a problem, with a definitive criteria of success; EMs on the other hand need to find the problem themselves, and there usually isn’t a definitive criteria of success. I see this as the single biggest source of confusion for a new EM. Once you know the problems you are dealing with, finding the solution is relatively easy given the abundance of online resources and the help from your peers/mentor.

There are certainly many “problems” you can find in any given team. Problems here means ways to make the team better, faster and stronger. Ultimately, an EM helps his/her team to deliver more value. Anything that could help the team to deliver more value can be seen as a problem waiting to be solved, an elegant puzzle if you will.

Now I understand this is quite vague and not that helpful. Let me try to break it down. I have listed the common “problems” every EM should pay attention to, with a few tips on how to deal with them from my own experience. I can’t say it’s a comprehensive list. But if an EM can get everything listed here done to an acceptable level, the team should be running well.

Short Term Support

These are the house-keeping tasks that need to be addressed on a daily basis. Often times developers tend to focus on more creative work and ignore them, in which case you’ll have to pick them up. If we drop the ball here, chances are your team will not move as fast or even stuck somewhere.

Short term support items fall into 2 categories:

• Unblock your team. This is the most obvious and straightforward way to support your team – they need certain resource to keep going. That resource could range from a user account in production system, to infrastructure outage blocking build pipeline, to having to chat with stakeholders for requirement clarification. Usually your team member already know what they need, and will tell you directly. You just need to find the resource so that they can continue their work.
• Handle interruptions. I’m sure you’ve all seen this comic before. To reduce context switch for your team, you’ll need to shield them from outside world. This would be convenient too since you’ll be the first point of contact for the tech side of your team, most likely. However, you’ll also need to keep the team in the loop. What to communicate, when and how can be a bit tricky to balance, and it varies among different teams and individual developers.

Short term support activities tend to take up quite a bit of your time. In some teams you might feel like drowning in responding to them. Nevertheless, it’s important to make time for the long term improvements, otherwise the team is not going anywhere. Often times, your short term support item can be seen as an opportunity of improvements – your team members asking for certain resources regularly is a strong indicator for automation in this area. Delegation is also an option.

Lastly, when providing support, it’s important to appear to be accessible and friendly. People can tell when you are reluctant to help them out, and they will be more inclined to hide the problem in the future.

Long Term Development

This is where the majority of the vagueness comes from. There are different leadership styles, which tend to have different focuses. However I think EMs need to strive to be at least OK-ish on every aspects. Doing poorly on any one aspect can significantly handicap your team.

People

Bosses guide a team to achieve results

Kim Scott. Radical Candor

Quite a few things fall under people management. So far I’ve identified:

• Personal Development
  • Technical skills – find the gap in each team member’s skillset, then provide resource, time and opportunity to grow that skill. In terms of outlining a developer’s skillset, I’ve found this Engineering Ladder quite handy.
  • Soft skills – there’s a fine line between helping to develop someone’s soft skill and personal attack. I’m fortunate that the teams I’ve worked with are filled with wonderful personality. But when a developereloper shows a lack of soft skill, it’s gonna be our job to correct that.
    • Communication is the single biggest overhead in software development. Effective communication is a must for modern developers.
    • Ego is another major concern. Let the research show that Psychological safety is the most important factor to team performance. Team bullies must be stopped at the earliest.
• Team building
  • Building rapport – your team need to trust each other, and not feeling stressed to talk to each other, so that they can work together without any friction.
  • Team culture – Psychological safety, learning community, Boardgames on Fridays, etc. Promote the things that you believe the team should have, facilitate it until it becomes everyone’s habit.
  • Morale – Because few people delivery good work when they feel down.
  • Inter-team relationships – help your team to build relationship with other engineering teams and stakeholder for learning opportunity and reduce collaboration friction.

You’ll need to really focus in order to find the disturbance in the force. To my knowledge, the most powerful way to both help find the issue and fix the issue is to promote Radical Candor, aka create a feedback culture.

Process

Good intentions don’t work. Mechanisms do

Jeff Bezos. Working Backwards

Pay attention to the way your team work. Be lean. You’ll need to actively look for the bottleneck that’s slowing down your team, then figure out a way to fix it. There can be infinite opportunity of improvement in this area and I don’t know if there is a way to categorize them.

The 2 major ways I find friction are 1). hear it from my team, i.e. retro and 1 on 1s; and 2). discover new ideas, from observing how other teams are doing and reading books and other online material. Your solutions don’t have to always work. But it would be really helpful if you can find a metric to evaluate if a change is helping, so that you can adjust quickly. To me the most helpful thing is the cycle time, i.e. the time from a task being brought to the team to it is shipped to production. If you can’t find a metric(happens more often than not), you can always fall back to hearing it from the team.

Technical

Should an engineering manager write code?

EM should be involved in all technical decisions: framework selection, architecture/solution designs, etc, both by executing them and reviewing the team’s work.

Whether this will lead to coding or not is up to the EM and team to decide.

Prospection JD – Engineering Manager

I’ve seen people say that non-technical EMs can work, but most seem to agree that EMs should be technical and should contribute to technical decisions. My view is EM can be involved as much or as little as you want in the technical aspect. This is because 1). it’s the area where you most likely can find a delegate; and 2). comparing to people and process, this tend to make the smallest impact on team performance in the long run. IMO, an EM’s goal should be to up-skill your team member so that they can be trusted to make the technical decisions by themselves. However you still want to stay close to the technical practises, because a lot of your work depends on you knowing the software, for example up-skilling your team member, or participating in discussions as a representative of your engineering team. In short, maintain your skill/knowledge to be up to date, but to put them in practice should be at the bottom of your to-do list.

Thinking like an Engineering Manager

As I learn more about being an EM, I noticed that my thinking pattern changed quite a bit from when I was a developer. 2 things stand out in this area.

Be Proactive

A developer can get away with not acting when he/she notices an opportunity of improvement. They are encouraged to act on it, but not mandated. As an EM however, if you don’t act on it, no one will. You will have to see to it personally for things to happen.

Engineering vs Craftsmanship

When I was a developer, I value high quality code because there’s certain beauty in it. I understand the reason behind SOLID, behind High Cohesion Low Coupling and all that, but that’s not really the reason I strive to achieve them. I get enjoyment in the process of finding a solution that hits all the quality gates, rather than the value it brings. What I’m aiming for is comparable to fine craftsmanship – I like making an aesthetically appealing cup, I rely on my own skill and experience to not produce a defect cup and 99% of the time it works well

As an EM however, I think more like a mechanic servicing a machine. It certainly feels good when I can make the machine work better, but to make the machine reliable is more important. Process and mechanisms are put into the team not to chase high quality product, but to limit the chance that we end up with a low quality product. I once told my guys: “To me, tests are more important than code.” They didn’t like the idea. But I genuinely believe so. Using the cup making example, now my concern becomes how do I make sure none of the cups produced are defected, while not getting in the way of my cup artists’ work. I can no longer trust the skill of the team member, because I had to assume at some point someone will involuntarily make a mistake. The aesthetic pleasure is basically gone since I’m no longer making cups myself. But on the other hand, maintaining and optimizing the machine is fun in its own right.

The Common Challenges

EM’s work have a few unique challenges that you’ll face every day. I’ll try to keep them simple so they don’t sound too scary.

• Things are very coupled – it’s often impossible to work on an isolated domain like micro services. For example if you wanna make a process change, often times you’ll need to consider the dependant process, how would your team react to the change and how to best help them accept the change. I tend to use 1 on 1s to gather feedback before I roll out changes.
• Knowing everything doesn’t mean you can do them well – there’s just too many aspects to keep track of, eventually you’ll miss some of them. Better start keeping a backlog of your tasks.
• Deal with the loneliness – EM and IC works on different things and they tend to have different mindset. Because of this, often times you’ll find yourself can’t really share your thoughts with anyone in the team – it’s not their concern. Other times you’ll find it hard to convey your messages to the other end, because they don’t see things the way you do. Let me be clear that I’m not saying EMs are “above” developers. Developers are brilliant in their own domain. It’s more like a gardener will at times find it hard to relate to an electrician.

Q&A

• What if I am not competent to be in this position?
  • Aka the imposter syndrome. From my personal experience, this is an illusion coming from not able to see your efforts into fruition. EM’s work tend to have really long feedback cycles – weeks, months or even years. It’s quite common that you put effort in something then never hear back from it, no impact positive or negative. Things like this tend to make people doubt if they’re delivering any value. Trust your dev team. They will challenge you if you did sth wrong. They’ve got your back. You can also talk with the developers or other EMs to collect your thoughts and validate your ideas.
• What if I f**k up?
  • I mean… who doesn’t? It’s damaging when an EM makes a mistake, because usually it’s the team that gets the hit. But on the other hand, because the developers are human beings, they can be caring and resilient too. They will be able to take the hit and carry on. What you could do at that point is don’t be defensive about your mistake, and don’t make the same mistake again.
• I’m an introvert, how can I manage without talking to my team?
  • Yeah … sadly no. You will have to talk with people. A lot. But the good news is, it’s a skill anyone can learn. Just need to keep pushing yourself and eventually you’ll feel less awkward. The important thing to keep in mind here is don’t let this awkwardness block the necessary communication; and don’t substitute face-to-screenface convo with email or slack message. It doesn’t convey the same amount of information, and it creates distance between you and the recipient.

• I don’t feel safe stop coding. Managing feels like … not a real skill. It doesn’t produce anything tangible.
  • I felt the same in the majority part of my journey too. But once you go through that tunnel, you’ll see that it is a skill – a rather complex one too, otherwise there won’t be so many talks and books about leadership and all that. It’s a very different kind of puzzle comparing to programming, but it’s equally fun and fulfilling. And it’s definitely recognized on the recruitment market.
• Where should I start if I’m interested?
  • Right where you are! You don’t need a title to start leading. All you need to do is to pay attention to the stuff an EM would, then be proactive. Drive the change, make your team a better place to work in. I think it’s a good quality for any developer to have. When you need authority to push certain changes, you can always go talk with your manager. I’m sure he/she will be happy to hear you out coz you’re basically doing their job for them.
• Let’s say I did become an EM, what will my future look like?
  • Switching from developer to EM is not a promotion. It’s a career change. As you climb the career ladder, you’ll be farther and farther away from coding. The higher up you are, the more you need to shift to the big picture: visions, strategies and process, rather than technical details. You will still need to possess certain technical skills, but it’s almost exclusively for coaching and communication purposes. Your product becomes the teams you support.