CultureThe epiphany: From Individual Contributor to Engineering Manager (and back)
Omar Sotillo Franco
15th November 2021 โ๏ธ๐ฆ
Winter came (intense drinking of Gluhwein to bury my sorrows and darkness), and probably a new variant of the virus was wreaking havoc somewhere and scaring many. However, my body was ready for the biggest challenge of all.
In the fight where many perished (spoiler alert: so did I), I had accepted the challenge - The impossible job: becoming an Engineering Manager ๐
Mamma! bring the greenย suit of the firstย communion out! ๐ด๐ป
What some described as the impossible job was going to be my new provocation, my next winter season extra challenge, and my next excuse to not leave home in winter๐งฃ๐ You know, I am from Andalucia, Spain, we like to keep it dramatic ๐ช๐ธ
After being suggested by my manager as the one to help with the managerial duties due to his parental leave, the moment arrived. It was time to open the wardrobe and wear the magnificent SUIT๐ด๐ป(I need to get one for an upcoming wedding though ๐คท๐ป)
From wearing a single hat one day (๐ฉ Senior Software Engineer), I jumped to becoming a new team member with weird tasks and many hats:
- ๐ the team builder / grower / recruiter / retainer of talent
- โ๏ธ the psychologist / supporter / listener / actor
- ๐ฉ the strategist / duo manager / technical seeder
And what a heaven of a ride ๐ During those 6 months I experienced what I consider an epiphany ๐ป๐ค
Epiphany
(1)ย a usually sudden manifestation or perception of the essential nature or meaning of something. (2) an intuitive grasp of reality through something (such as an event) usually simple and striking.
My โeventโ spanned some time, the path (โder Weg ist das Zielโ ๐ถ๐ปโโ๏ธ ) - enjoying the process and taking as many lessons as possible from this opportunity.
My events and realizations ๐ฟ
1. Super technical engineering manager ๐ฆธ๐ป
"....but, I need my manager to be the best technical lead!" - Omar (me)
One of the biggest concerns I had while starting this position was about how technical I needed to be, and how much coding I was gonna do. And oh mama how worried I was! ๐ฑ
I always envisioned attaining the technical depth of most of my technical leaders one day, and I did not relate sometimes with the more managerial ones. So I was a little biased against myself. After all, we are our worst critics I guess ๐คท๐ป
We started with:
- a team of 6 great souls and the newest person had been on the team for 4 months ๐งโ๐
- most of them were far better engineers than me ๐ช๐ป
- and I was also the youngest on the team ๐ถ
My impostor syndrome went brrrr ๐... Although, everything was much easier than my dreadful mind thought at first, mostly because I had great support from the team, other managers, and the CTO... but you know ๐๐ปโโ๏ธ๐จ๐ง
After these 6 months, I realize that in order to be a great EM, it's incredibly helpful if you were a software engineer in the past, but it is not the most relevant thing. Being priorly a Software Engineer provides you empathy and understanding, which are super important, as you get to know about the reasonable and unreasonable challenges/risks.
The most interesting challenges come in this position in the end not from the technical or creative aspect of the software, but more from steering the team on the most effective and right path, as well as the promotion and growth of your team.
1.1 Level of technical maturity ๐ด๐ป
The level of seniority of a team plays a huge role in what kind of EM you need to be. There is never a silver bullet for all the teams, each team is different and hence, has different needs ๐ฅ. However, from the exposure to other managers and my experience, I garnered the following:
In leading a more senior/mature team, the team members will be the technical leads and you can trust complete technical design to them. What is your job in a super senior team? I believe it is:
- bringing them the right projects and interesting challenges to work on
- increase the impact + visibility they can have globally by satelliting ๐ around other teams and sponsoring them
- enabling the discussions, pushing for impact and effective analysis, and empowering trade-offs
In leading a less senior/mature team you will be more of a supporter and technical seeder ๐ฑ (defining expectations and starting big implementations). You might need to be focused on:
- more detailed strategy proposals and phase work
- clearer technical designs: defining scopes and expectations
- and mentorship: I found a lot of joy in this area as it is crazy how fast people learn and reach their full potential within months via sponsoring and a cool learning path (especially people coming with completely different stacks which we always encourage in FactorialHR)
Both scenarios offer different lines of challenges on the โpeopleโ path and paths to growth, they are also equally attractive ๐ฅฐ
1.2 Coding time diminishes โจ๏ธ
The IC schedule requires big chunks of uninterrupted time so concentration goes brrrrr (I need to stop the meme ๐), while the EM schedule looks more like a Spanish feria, ๐ช where you meet some random people (or team members) with valid/invalid requests and so on. Many times, you just want to sit and focus on what brings you joy (in my case team support and coding).
I always found the time to do some self-coding but found that I had more impact during pair programming sessions, and contributed to the teamโs objectives and culture, as opposed to fewer independent tasks. Sometimes, I can assure you, my mind did not know what problem it was solving, ping ๐ฏ๏ธ๐งฝ pong ๐
2. Energy control ๐ฅต
No, we are not speaking about the "things used to borrow happiness from the future at a high-interest rate ๐", but how you handle the amount of gas you spend on each task.
I heard about this position as:
- super intense - especially as an outward communicator of the team
- way riskier - "With great power comes great responsibilityโ - Tobey Maguire (the best spiderman ๐ท๏ธ)
- more mouths than churros - there will be always more complex challenges than souls, and time cheating is not always the way.
The amount of stimulus you receive in the EM position compared to the IC role goes up by about 1000%. For a mind like mine which is super one-tracked and cave-oriented, I saw some signs that led me to take some actions โ I asked some of the managers how they were approaching their availability and execution load (โ)
It was at this point I heard from a friend and another manager about stoicism (alert hipster intensifies ๐ฅธ) and based on his recommendations, I got into the trend of 2021 (...trying to forget the covid๐ฆ and winter โ๏ธ)
Eudaimonia, also spelled eudaemonia, in Aristotelian ethics,ย is the condition of human flourishing or of living well
How did I relate Eudaimonia to the EM duties and how did I keep balance and focus on the important chore of the role? โ Letโs go! ๐ง (stoicism is just an excuse to talk about some topics ๐ค)
2.1 Arete: Express yourself at your highest in every moment ๐
The arete of something is the highest quality state it can reach. Using arete as a principle for living life means that you are focused on the quality of everything you do and experience. Avoid actions that lack arete. Take actions that focus on the arete.
Keeping a state of +100% intensity and energy all the time could lead to burnout ๐ฅ. Knowing when to slow down, your boundaries, and chill is important. This is why I looked into my calendar schedule and analyzed it. Why? To find and visualize where my energy (early-bird here) and time were required the most and focus on organizing meetings based on it. In my case:
- I wanted to be +100% on 1on1s, team ceremonies, pair programming, and support.
- I chilled way more on average with hiring + management chores (write-ups) + personal coding and more global topics.
It is awesome to be able to do everything at 100% IMO, but I see the extra energy effort deeply affecting more passionate people in the long run. In this position, I believe (as with doctors) it benefits sometimes when you are able to detach personally from some of the stories youโll, and not relate so close. I will use a lot of this learning when going back into the IC role as it will help me still handle expectations and strategies better.
2.2 Focus on what you can control ๐ง๐ปโโ๏ธ
Often you suffer in life because you focus and worry about events that are not under your control. Some things will be, focus on those. Others wonโt: shut down the doors of your mind to them.
I tried applying the following :
- โIs this a valid problem?โ: You will be requested by many souls to solve the most interesting challenges. You need to validate with your product manager if these are valid requests and after that respond to the requests with a โYesโ or โNoโ: If a No!, do well to let them know the whyโs ๐
- โCan I do something about it?โ: If Yes! set the engineering wheels turning. ๐ If not, delegate to a proper team or raise the issue to other engineering managers.
With this approach of always coming to the end of a request with either a team answer, an action item, or a no with the whyโs, I found freedom in my mind as I was closing and forgetting about those topics.
This helped me A LOT in the initial steps of being an EM, for example, with requests in 1on1s from team members that I did not know how to solve. They were valid requests, therefore not discarded from my mind, but I could not do anything or did not know how to, so I escalated them and told the team member that a specific person is on it or we are looking into the problem.
3. Delegating, trust, and rewards management ๐
One of the resources we have for engineering managers in FactorialHR, states the following:
โHumans get together to achieve hard tasks that they can't finish by themselves. An individual can push the limits of what's possible, run faster, climb the highest mountains, and whatnot, but there is one thing no one can get around, time.
Humans gather together to cheat time. Generally speaking, unless you are building cathedrals, humans want to see their projects finished during their lifetime, and it is precisely that immortality longing that pushes us to create organizations.โ
Your job as an Engineering manager is mostly about planting seeds ๐ฑand no longer being the one watering them (or little). This causes a drastic change in the way you will receive feedback and inputs based on your actions.
Rewards are no longer immediate. Most of the tasks in this position will be about helping the team grow and technically finding the right and effective way to solve complex challenges. These are not happening from one hour to the other.
Each project will be unique, and each teammate you trust will have their own set of strengths, areas of expertise, a network of support/engineers, and potentially some skills they have yet to learn. Trust them! ๐ง
3.1 Rewards management ๐ผ๏ธ
โPopper vs Edible weed. Individual contributor vs Engineering Manager. Fast and less risky rewards vs long-term and more risky plantations.โ - Omar (me)
From my experience as an EM (as well as that of other managers), one of the most difficult challenges when coming directly from an IC role is accepting the feeling that success is no longer tied to your individual actions, but to the team's actions.
On the 1on1s with my manager, I did bring up the topic of visibility and the personal sense of delivery, as an area of improvement which I did not know how to go about. I could not see that I was doing good (or as well as before) because I was not programming as much, and nor did I see results coming directly from me. He always told me something ๐ฅ
โYou will be planting seeds and preparing the ground around them so that the harvest is the shortest and most effective one. The harvest should be a team success and you should be feeling proud of thatโ - Genar - best manager/hacker, better human ๐ต๐ป
It is easy to be said, but difficult to go against your mind. After deeply thinking about the whyโs of my not being joyful, I found I was virtually seeing myself being 100% focused on some of the interesting technical challenges both teams were working on, and how much more impactful I would be as IC on those challenges.
TLDR: Technical challenges were more appealing to me than people/strategy ones ๐
I could not solve this area and this led to me deciding that I wanted to go back to the IC track ๐ข (awesome that FactorialHR allows it ๐).
3.2 Global reach and sponsoring your teammates ๐
The amount of information, challenges, areas, and projects you are presented as an EM are more regularly presented to you than as IC ๐๐ปโโ๏ธ the exposure of global org reach is really interesting and definitely one area I will miss a lot.
This position is beneficial if you are like a rocket ๐ in the universe (org) satelliting around different planets (teams) without ever landing on any but youโll see the roadmap and concerns each team presents (and your team might help - especially as a platform team).
It is important to see which ones you want to participate in as workgroup and sponsor your team members in the areas they will shine or are interested โจ While investigating how to mentorship in more global concerns and more hands-on exercise learning path, I came to this beautiful article, which states the following
Studies have shown that women (and nonbinary folks) areย over-mentored, but under-sponsored. As Herminia Ibarra, professor of organizational behavior at INSEAD and coauthor of the HBR articleย Why Men Still Get More Promotions Than Womenย explains,
[in mentorship], the connection to actually getting promoted and actually getting developmental assignments, has been kind of dilutedโฆ [Sponsoring] has to do with fighting to get somebody a promotion, mentioning their name in an appointment/meeting, and making sure that the person that youโre sponsoring gets the next assignment, and gets visible and developmental assignments.
In FactorialHR, we deeply push the diversity lines and I felt I needed to be in that position so my team members were exposed to the same info I was getting. What I did was understand each personโs kind of work style or interest area, and call their name!
Ex: One soul was super technical and interested in tooling - I always mentioned to him the challenges they were talking about and if he was interested (learning time booked for that) or commented his name in threads. Another soul was interested in culture and she is now the leader of this awesome blog!
(Illustration byย Catt Small)
4. Career growth
Enabling but not enforcing growth. One of the mistakes I made was imposing learning time weekly. I deeply believe that if you need to enforce learning, you have failed as an EM.
I remember my university studies as times I was forced to study things I was not probably interested in (or little), but the dynamic that someone was leading my learning path did not help. Why did I want to do this again? ๐ซ (as I said always picture yourself as your own manager)
4.1 Learning time and resources โ
While speaking with another awesome Engineering director (Oriol Gual) about this, we came up with a beautiful process to investigate not only resource-based learning but projects and hands-on exercise. From here we found that learning should be a personal path because your manager will always want you to go forward.
I switched my methodology to understand why they were not using the time I assigned them to grow and find the reasons that were blocking them from using it (change of personal priorities, personal needs, project needs, resources feeling ).
Most of the time it was because they finally found enough expertise of happiness in the knowledge they gained, so it was a matter of finding together the best resources to go one step up or next area.
4.2 Individual learners ๐ง๐ปโ๐
It is also important to identify individual learners which won't require your support as they will use the time requested to acquire understanding and lead their growth. Those will impact globally as well, as they also have quite a strong problem-solving mindset. I usually empowered them by sponsoring (in more global or architectural challenges) or bringing the right daily challenges in front of them.
4.3 Giving feedback is easy, but giving GOOD feedback is not
It is especially challenging when communicating concerns that need to be worked on. It is easy to compliment and give rewards (which happened fairly easily as most of the team members were doing good! ๐ฅ), but one of the most important challenges is how to effectively, communicate improvements and the urgency of the challenge to be worked on. Bad feedback helps no one and just creates roughness.
I failed at the start by doing compliments sandwiches. I now believe in the need for being direct, objective, and constructive about what needs to be worked on (how difficult that is!!!), and how important/critical it is, and let them set a plan/objective to fix it. ๐๏ธ Help them to reach that point and validate them by the reaffirmation of their plan.
This is something that will be improved by experience and finishing meetings and doing a recap of what you will take home (we are all at home I guess hehe ๐).
For me, 1on1s are the best opportunity to talk about blockers, team morale, and the status of the growth of a person. This is a huge topic(haha ๐), and I will need 20 more blog posts to talk about it, it definitely was one of the parts I liked the most about the EM position.
5. The duo! ๐ Product maker AND Engineering manager
Probably one topic I heard quite often during my professional experience -> Product wants to go one direction and Engineering in another. I had in mind that it was gonna be a challenge aligning with โproductโ, or it was going to be an interesting conflict of interests.
It was not. You're in the same group + want the same outcomes. You manage different parts of the team (EM = people + tech, PM = roadmap + delivery), but you both need to succeed. This means you have each other's backs (not literal ๐) but most of the time you have to find a consensus and understand the whys, shortcuts, or tradeoffs ๐
5.1 Help and support ๐๐ป
One thing that can help is sitting together and understanding what your duties are as an EM and his duties as the PM. Brainstorm on everything you have to do as the manager of the team and split it between both of you(not leaving all the roadmap and strategy work to them). This definitely helped! ๐ฏ
This part is interesting as it allows you to be part of the next steps of the product or blocks you are working on, and envision the design proposals more for the long term. ๐ Those brainstorming meetings are super interesting! ๐
Get involved by being available for brainstorming, bringing numbers, tech concerns, and timelines. Be the first one to review their suggestions and provide early feedback to iterate fast.
5.2 Technical debt and concerns ๐ค
Quantification and impact analysis of tech debt.
Something super cool in FactorialHR that the DX team is doing greatly is visualizing the tech debt in a matter of architectural or code infractions. We have a metric called CodePain ๐ (probably worth a blog post :P), which represents in the bigger picture, the slowest, more clunky, and risky code you delivered. Taking into account this metric, quality and the possible business impact it can have in the long term from deliveries is essential.
5.3 Empower engineers and PM communication ๐ฃ
Don't be the bridge/bottleneck (it will probably save you tons of time). The best meeting times for me were the meetings I did not have to attend. Leave those meetings to your engineers and trust them, maybe you can ask later for a private update about how it went + ask to update the design documents. They will probably know more about the details than you.
For example, we created a Platform Identity team to work on authentication and permissions. The main challenges were about authentication which one person in the team had clear expertise and focus. I left those meetings to him and he rocked them!
5.4 Enhancing written and async communication ๐
The shortest pencil is longer than the longest memory - Mark Batterson๐๏ธ
In one retro one person commented once that every answer you provide to a question should be a direct link to our Notion pages. Top tip!
Leave the PM and the engineers to be always involved in every process -> it is about ownership, and ownership helps maturity, growth, team culture, and understanding.
This is one of the reasons why most of us are T-shaped engineers. It helps communication and emphasizing with other team members as you know the caveats/problems of different football fields โฝ and allows your expertise to unblock more global concerns.
5.5 Bringing it personal ๐ค
The duo: the couple! ๐ I benefited from having more personal conversations and relationships with the product maker. Have coffees, daily end-of-the-day talks, random life chats, 1on1s, and ask how they are doing! Become a partner. Understand the impact and needs.
I was lucky enough to have an amazing PM partner (Samu you are great) and learned firsthand how to nurture and structure the relationship for success.
It was a fun play between two people trying to make the team and clients happy ๐ซ
Going back: Conclusion ๐ค
That is all ๐๐ปโโ๏ธ I hoped you enjoyed my path and the lengthy blog post haha ๐๐คท๐ปโโ๏ธ . From all of this experience, my epiphany (the path) - I found joy, I grew and I encountered challenges I was never gonna be exposed to if it was not because of this position, and I am alive (most importantly)! ๐
I will start applying these managing Up concepts, which I found really rewarding when one of my team members did any, more personally.
It is a beautiful position, youโll see people grow, shine, fail, be emotional... be humans! and humans are beautiful and interesting ๐ , but yet it is also a time to fight against the stubborn robots and technical/creative challenges ๐ค
Thanks to FactorialHR for this opportunity, but more importantly to all the team members that made it easy, enjoyable, and simple ๐
โA society grows great whenย old men plant trees in whose shade they shall never sitโ - A greek Engineer Manager ๐ฌ๐ท๐ฆ