A year ago, all engineers at ShopBack reported directly to the CTO. We had no Engineering Managers (EM), no team leads, and in other words - no structure. Recognising this as a rising issue for a start-up with a 250% year-on-year growth rate, we hired a VP Engineering to put a proper structure in place. Introducing engineering managers was a paradigm shift he proposed which had an outsized impact on the engineering team.

We grew from:

• Zero to seven EMs
• One to three engineering centers
• Fifteen engineers to more than fifty engineers

The biggest game-changer for me was my role switch from Senior Engineer to Engineering Manager within a week. In this post, I would like to share some of my learnings over the first year of transition, especially what I wished I understood before I started down the path of management.

Roles and Responsibilities

Every organisation has its own definition of an EM's role. It is important to understand what is expected from an EM, so be sure to check-in with your manager and peer EMs. There were no in-organisation reference points when I made the switch, so I worked with our VP to define the core roles and responsibilities of an EM at ShopBack.

Reasons Not to Switch Tracks from Technical to Management

Don't do it if you consider it a promotion. In the many tech companies I have spoken to, management is a parallel track to the technical individual contributor. As an individual contributor, your core responsibility is your code. As an EM, your core responsibility is people. No matter how much of a rock star you are at coding, you will return to the junior level in the department of management skills. for lots of the core skills of management. The drop in efficiency and effectiveness is actually most pronounced if you feel super productive as an individual contributor. At ShopBack, track changes don't come with compensation or benefit changes, so realistically speaking, there is no reason to see it as a promotion.

Having the right motivation plays a huge part in any switch in responsibilities, and becoming an EM is no different. This helps you push through the tough adjustment phase. No one wants to work for a manager who wants to do everything except become a better manager, so please don't inflict that pain on your team.

Also, don't do it if you want to micromanage or control your team members, or want the authority to correct bad behavior. There are other ways to solve that problem that doesn't involve switching your day-to-day work entirely. Feedback is a gift, and sharing it makes a world of difference. The mindset of improving how your team functions, rather than giving up and trying to do everything yourself, is a key trait of a leader and a team player. Having a fancy job title doesn't make you a leader, and being the manager can in some ways make it harder to lead as people tend to build some distance between themselves and their managers.

Reasons for Considering a Switch

If removing blockers, helping others to grow, building alignment across cross-functional teams, and resolving conflict is more fulfilling than writing code and solving technical challenges, then the management track is something you might enjoy. Removing yourself from the critical engineering path allows you to focus on rallying the troops to chase big hairy audacious goals for the business/product.

As an ex-cofounder, I've always had an interest in building teams and improving processes. Being an early engineer, I participated in the design of many of our systems, had a decent rapport with most stakeholders, and a good grasp of our business challenges. I saw switching as the best way I could improve the organization.

If you're still keen on exploring the position after all that, we need to make a plan. Now is a great time to start enjoying planning, because you'll soon be making more plans than you ever thought possible. Your plan is critical for you to understand your own performance. Without coding, you lose the feedback loop that has powered your entire career, and your transition plan helps to replace it somewhat.

When I switched over, I set 90-day goals for myself. At the end of every quarter, I would do a retrospective with my manager to make sure my priorities and focus areas were aligned with the team's needs. My first 90-day deliverable targets looked like this:

1. One on one every 2 weeks
2. Construct individual profiles for each engineer
3. Publish sprint process documentation
4. Coordinate the team reorganization
5. Formalize the interview process

When you decide on your plan and run it by your manager, you're ready to start! These are some concepts that I found helpful for my first year on the job.

Establish Your Priorities

I believe that an engineering manager needs to put the company first, team second, and individuals third. It is key for managers to build alignment between company objectives and individual goals. This is the complete reverse of an engineer's priorities, where you focus on yourself and your work first, help your team members second, then worry about the rest of the company last. Naturally, this will vary based on the company size, work, and business environment. ShopBack engineering managers are there to help the team focus their efforts on achieving business objectives, and act as a force multiplier for engineers and stakeholders.

The next scope for prioritization is what is important to you as a manager. Everyone has their own style, and every team member will have their own needs. A team of 4 fresh graduates working on a product without product-market fit has vastly different needs from a team of 8 veteran engineers maintaining enterprise systems on a global scale. If you want to be a tech lead who does one-on-ones and performance reviews, then you would prioritize one-on-ones, and code reviews over hiring and culture building. It helps to be clear what kind of manager you want to be, and revisit that definition as you go along because you will constantly have all sorts of work clamoring for attention, and you need to avoid spreading your efforts too thin. As a manager, your job is to become a better manager.

In my first quarter, my priorities were to formalize our sprint process and help the team adjust to the new organizational structure. We chose to do this as engineering managers were a new concept in our company so getting comfortable with it was critical. In the second quarter, my priorities shifted to hiring. I spent 70% of my time talking to candidates, and the rest on the practices we established in the first quarter like managing sprints and one-on-ones. Identifying the most valuable thing you can be doing for the company at any point in time is much more important as a manager due to the sheer breadth of scope that you have, and accordingly, falling down the rabbit hole and tracing a heisenbug instead of focusing on your primary objective has amplified negative impact on the team and the company.

Find Mentors

As a newly minted manager, you need to start talking to other managers. These don't need to be engineering managers; managers of other teams are able to give you insight on how to handle various people problems, and engineers turn out to be people too so it helps to get insight from people in other departments within the company. Approaching these people within the company is relatively easier since they would have some context on the business challenges and company culture. It's the same as when we first started out as engineers; find the smartest person nearby and learn everything you can from them.

I started by talking to the managers in ShopBack who have experience building successful sales/marketing/business development, teams. As the company continued to grow, I connected with our veteran engineering managers in our Taiwan and Vietnam offices to tap on their vast experience.

Have Regular One-on-Ones

One-on-ones is perhaps the strongest tool in a manager's arsenal and is the perfect environment to manage people. Don't just do this with your direct reports, but also the people you collaborate with the most: your fellow engineering managers, product counterparts, business stakeholders, platform-ops people etc.

I did this with my direct reports every two weeks for the first 3 months, before adjusting frequency and duration based on the individual. When my team was new to the practice, our first few meetings were super awkward and the general sentiment was that there was nothing to talk about and we were having it too often. We kept at it, and after trying various ways to start conversations about various aspects of their employee experience, the conversation started flowing. By the end of the first 3 months, the value of these sessions became clear and the awkwardness had faded away.

Set Expectations with Stakeholders and Direct Reports

It's important to be clear with everyone you are working with about what to expect after your role change. Your team members are now your direct reports, and expectations should be reset. Being very explicit helps head off any confusion about whether they can still ask you for code reviews or involve you in technical decision making. Write a manager readme for yourself to keep yourself honest, but every individual team member will have different needs and communication styles, so do work with each person to align on what works for both of you.

In my first one-on-one, I run through the mechanical aspects of the relationship: meeting frequency, communication response times (email, slack, texts, calls), approving leaves and claims, feedback channels, and my responsibilities as an engineering manager. Each manager and each company is different, so it's simpler to lay these out early and make adjustments if they want. The rest of the meeting is for getting to know each other, getting a general sense of how we would work together, and addressing any concerns.

Keep a Daily Journal

It's easy for an entire day to go by without feeling like you've done any actual "work". It's a stark contrast to engineering, where there is a commit history or user stories to keep track of all the things you are building. My daily journal consisted of a couple of words about each interaction I had throughout the day. During the process of recalling and reviewing, I would often discover something new about the person or the issue that I missed in the heat of the moment. Having these in written form helps recall massively because our team is constantly growing, and it's quite difficult to remember everything about my direct reports, peers, and stakeholders.

Always Be Learning, Always Be Trying to Have Fun

Starting a new role is undeniably painful, and I coped by setting modest goals, tracking my progress and celebrating anything that resembled a win. Nobody wants to work with a manager that hates his job. For myself, I always had the option available to switch back to the technical track, and that safety net allowed me to all-in on learning how to be a manager.

Just like how you never stop exploring new programming languages and design patterns, you should never stop your education as a manager. There is a wealth of writing on the topic so it's good to start there. My starting recommendations would be:

• The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier
• Managing Humans by Michael Lopp
• High Output Management by Andrew S. Grove
• Peopleware by Tom DeMarco and Tim Lister

TLDR: understand what makes you happy, make a plan, keep track of your progress, talk to people, care about your teammates, and have fun!