Individual contributors, or ICs, are professionals who contribute to a team or organization but do not manage others. ICs may be responsible for a certain function within a team or “own” projects. They often collaborate across functions and teams, influencing others without having positional authority.
Engineering managers, or EMs, are experienced developers who manage the development and design of software projects. This usually involves leading a team of developers and helping them with their day-to-day tasks and projects. They are also responsible for inspiring the team members and for creating and maintaining a positive team and work culture.
2022 saw me transition from being an individual contributor (IC) to being an engineering manager (EM) at Zappi. What this change has meant is that I’ve gone from mostly worrying about my work and myself as an IC to being responsible for multiple business domains and a team of 3 developers as an EM.
In this post I’d like to give a breakdown of what this journey has been like by touching on some of the lessons I’ve learned as well as the challenges that I have faced along the way.
Hi, I’m Ben and I'm an introvert 👋 “...Hiiiiii Ben”
Anybody who knows me well enough will know that I’d be the last person to jump at the opportunity to willingly engage with other human beings (having to talk to other people? oh the horror! 😱). Why? Because, I’m an introvert by nature and quite a highly strung introvert at that.
I thrive when I’m in my own controlled environment, I feed off my own energy and I live in my head the majority of the time. I’m never the loudest person in the room, I absolutely detest hearing myself talk, I hardly ever have super strong opinions that I’d be willing to die for and I avoid interpersonal conflict as if it was the plague… because… well… it is 👀
OK, so why Engineering Management then?
Firstly, I’m an introvert. Secondly, it appears that absolutely everything makes me anxious, and thirdly, I don’t particularly love the idea of dealing with people, if I can avoid it. So why would I opt to take up a role in engineering management then?
Well it’s simple really. I believe that discomfort accompanies growth and that there is no progress without change. As someone who has been in the tech industry for more than 10 years either as a co-founder, director, consultant, IC or team lead; and as someone who still has a burning itch for startups, entrepreneurship and business, it made perfect sense to me that engineering management be the next step of my career at Zappi.
A bit more info about Zappi and my team
Organisations across multiple verticals use Zappi to gather insights from countries all around the world, through a variety of market research tools that we provide on our platform.
We currently have about 15 engineering teams across the company, with each team being comprised of between 3 to 7 team members. My team is called The Rollout Team (yes, Ludacris is our mascot). We enable our customers to “roll out” their market research tools to different countries, in order to gather insights from different audiences. Our main technical focus is survey localisation and providing a framework for flexible research categorization.
We are currently a team of 5. An EM (that be me), a PM (Product Manager) and 3 developers. 1 of our developers is based in JHB, with the other 2 developers along with our PM based in London. I used to be based in Cape Town but I am currently staying in Eswatini. I have been working completely remotely for the past 2 years, making occasional trips to our offices in Cape Town and London, in order to spend time with my team at hackathons, conferences, company events and the like.
Zappi, being the maturing startup that we are, has gone through a Domain Driven Design (DDD) awakening over the past two years. This structural renaissance has led us to disband old teams where necessary and create new teams, with the intention of having clear, well-defined, concerns, responsibilities and boundaries split between each team. So while the Rollout team itself is new, the business domains that the team is responsible for are not.
Lessons learnt
While transitioning into engineering management I have come across a few situations that are quite new to me. I obviously haven't figured everything out just yet, as each week brings its own unique set of obstacles, challenges and learnings, some of which I have outlined below.
1. Revise how you define and measure success
The first lesson I learnt fairly quickly while making the transition from IC to EM is that one needs to revise how they define and measure success. Needless to say, this process has been quite tricky for me.
I’ve gone from my old life as an IC where I would happily close my laptop on a Friday evening after a super successful week of merged PRs and multiple deployments to production, to my new life as an EM where I go to sleep every other day stressing about whether or not I am doing a good job and meeting the expectations that my team and company have of me.
See, as an IC, my feelings of success were highly correlated to my sense of productivity and output. A successful week for me was finally getting out that PR, solving that annoying bug or making headway on a big feature. Measuring this success was quite easy because I could count the number of lines of code that I wrote, the number of PRs that I submitted or the number of features I developed and released. However, as soon as I crossed the chasm into managing others, naturally writing less and less code overtime, I found that my output was not quite as measurable any more and that my definition of success needs to be completely different to what it was before.
As an EM, some of my main focuses are establishing a vision for my team, maintaining team health and ensuring that my team members are continuously growing and being constantly challenged. Unfortunately, I still haven't figured out how best to measure how well I'm doing this.
Not only have the goal posts shifted but the game itself has changed completely and it's pretty clear that what brought me here won't take me to where I need to go.
2. Manage your time and learn to prioritize
With the responsibilities that come with my new role I’ve found that instead of doing 1 well defined piece of work over the course of the day, I can easily find myself jumping between multiple different matters that require my attention. Spending the entire day switching between each of them and then at the end of the day feeling like I did absolutely nothing at all.
As an IC there were periods where I would have, on average, 2-3 meetings (not including daily standups) per week, allowing me to have multiple hours of my day dedicated to uninterrupted coding (#nostalgia). Whereas now as an EM I find that I often need to make animal sacrifices to the Google Calendar Gods just to have half a day where I can focus on writing code without any distractions.
Upon realizing that my time is now at the mercy of many more stakeholders, I have tried to take a more proactive approach with how I schedule it. Blocking out hours in advance for “focus time” and playing a more active role in managing where my time goes. In addition to this I have also learnt that not everything that comes my way needs my immediate attention. It’s ok to handle it tomorrow, next week or even next month, depending on where it sits on the importance vs urgency matrix.
3. Trust your team and practice “letting go”
An aspect of engineering management that I am still coming to terms with is the concept of taking full responsibility for the delivery outcome while being semi-detached from the actual implementation journey itself.
As the highly strung, anxiety-prone, perfectionism-oriented, Type A individual that I am, the process of “letting-go” and trusting others to get the job done is definitely not one that comes naturally to me.
In my experience as an IC I would pick up a Jira ticket from the To-Do column, work on it from beginning to end, deploy it to production and then move on with my life (granted this is an oversimplified breakdown, but you get my point). Whereas with being an EM, the onus is on me to ensure that the Jira ticket is in the right state to begin with. I need to ensure that the team is aligned on what the outcome we are trying to achieve with this piece of work is. I need to support my team as they work on it and I need to take full responsibility of the when and the how of the delivery of the work.
However, while doing this I cannot and should not be involved in every line of code, commit or deploy. At some point in the process I need to let go and trust that my team will get the job done. Being present enough so that they don’t get blocked or end up going down the wrong path unnecessarily. Yet being distant enough such that I give them the space to solve problems, be creative and have a sense of ownership and autonomy with the work that they are doing.
As if this process isn't nuanced enough, I’ve also come to realize that people management is not a one size fits all approach across the entire team. Different members of my team require different levels of attention and engagement during different periods of the implementation journey. It's my responsibility as an EM to figure out where each individual needs to be met and to make sure I meet them there.
4. Build authentic relationships and foster psychological safety
Over the course of my journey the one thing that I can say with 100% certainty is that relationships are everything (as the crowd snaps their fingers, and one random lady in the back yells “amen”).
As an EM you need to have good relationships with your PM, your team, EMs/PMs/QAs/developers in different teams, the group engineering managers, the head of engineering, as well as all of your team’s stakeholders across the rest of the business. Keeping in mind that building these relationships is not just about grabbing a drink after work or exchanging a few Slack messages, no, it’s also about being authentic, transparent, honest and vulnerable.
When building relationships with your team, you need to try your best to understand how each person thinks, what makes them tick, what motivates them, what frustrates them as well as what their strengths and weaknesses are. In order for you to truly accomplish this it's essential that you leave your ego at the door and let go of any facades that you may be making use of. Why? Because, you can't expect people to be authentic with you if you are not authentic with them.
Now I’m not suggesting that every team standup becomes a therapy session. I just feel that the team and the workplace in general will be a lot better off if we are all just a bit more real with each other.
But EM Ben, how can we be more real?
Well it’s in the little things really. I.e If you weren’t able to focus at work yesterday because of XYZ then just bring it up in your standup. If you need to take leave next week because you have a Drs appointment then say so (without needing to divulge anything further). If someone asks you how you are doing at the beginning of a Zoom call and you are actually quite tired and feeling a bit out of it, just mention it. And when there is a difficult conversation to be had, either as a team or on a 1 on 1 basis, tackle it head on instead of brushing it under the carpet.
Sure, these are a few random, generic, out of context examples but the point is that being a bit more honest, authentic and transparent can go a long way in building strong relationships based on empathy, understanding and trust.
Final Thoughts
As someone who enjoyed and excelled in the STEM (Science, Technology, Engineering, Mathematics) subjects throughout school, I often get frustrated at the areas in life that don’t have a rubric/answer sheet for everything (because then I won't know if I did it correctly or not 😭). If you couple this with my perpetual anxiety, introvert tendencies and my extremely high level of self-criticism, it's easy to see how taking up a role in managing people can be quite challenging and nerve wracking at times. I’m literally always concerned about whether or not I’m doing or saying the right things. ("Damn maybe I should have done it this way, or that way, wait why did I do anything at all, OMG was I too forward? aaaaaaaah, now everyone thinks I'm incompetent 😩💀").
In order to pre-empt this stress I’ve done my best to read books and articles on the topic of engineering management and people management in general. However, if there is anything that this journey has taught me it's that no matter how many books you read, how many podcasts you listen to or how many videos you watch, the majority of the learning can and will only really ever come on the job.
With all that said, the nuggets of wisdom that I'd give IC Ben of a year ago, before he embarks on his EM journey is that he needs to have:
- The right mindset to tackle the challenges that come his way (#growthMindset gang gang),
- The right support structures to lean on in the times of need (other EMs, a manager, a coach/therapist), and
- Enough patience, self-love and empathy, so that he is not so hard on himself when things don’t work out the way he expects them to.
Alright that's all from me. Once again, I really hope that my journey helps you make sense of your own 🙏🏽.
Some books that have helped me a long the way:
- Managing Humans
- The Making of A Manager
- Outcome Over Output
- Quiet: The Power of Introverts in a World That Can't Stop Talking (for my introvert gang out there)
EM Ben out ✌🏽