I can finally admit it: I was terrified! About three years ago my boss offered me the position of Android Development Manager. There was a flurry of thoughts that ran through my mind:
- Am I ready for this?
- Will my peers respect me as their boss?
- I’m not good with other people’s “personal” problems
- I love programming, I don’t want to lose my skills
- …
You get the picture. Despite those thoughts, I reluctantly accepted the offer and within weeks, I quit. I wasn’t ready to be a “manager.” I went back to an individual contributor role and things were “normal” again. At least for a while…
Fast forward to today, I’m the Software Group Lead (Engineering Manager) at my company. I love my new role and the challenges that it brings. Each day is different from the next. You may be wondering, what happened to change my mind? Well, to be honest, it was a gradual process. There was no lightbulb moment, no ah-ha, just small adjustments in my thinking.
If you’re a Tech Lead and you’re wondering: Is management for me? What’s the difference between the two roles? How do I even move into management? I hope this helps.
Life as a Tech Lead
As a Tech Lead, I spent the majority of my time coding, which I loved. I was actively developing features for our mobile app. Coming up with the architecture, introducing new libraries, improving test coverage. That was my life.
The rest of the time was spent mentoring and pair programming with other developers. I did go to meetings, but not that many. And the ones I attended were focused on technical capabilities of the app, timelines for delivering specific features, and standard Agile team syncs.
Being a tech lead was nice, but I often felt like I had more to offer the company. I had ideas on how we could better structure meetings, recommendations for improving the user experience in our products, suggestions on how we could work to improve the team’s collaboration. I wanted to have a larger impact.
Taking Baby Steps
I started managing just one person. That worked well for me. I could still keep up my responsibilities as
I couldn’t just say the same things and ask the same questions to have the same impact.
After about another year or so, my little team grew. I now had two direct reports. Ok, no big deal I could add another weekly 1-on-1 and pair programming session. Everything would be fine. But it wasn’t that simple. Each person is different. They need different levels of mentorship, coaching, and support. I couldn’t just say the same things and ask the same questions to have the same impact. I had to become better.
Being the pragmatic person that I am, I decided that I would learn about managing the same way I would pick up a new software framework. I signed up for newsletters, subscribed to podcasts, read several books, and joined a management Slack group. I went all in!
Here are a few of my favorite resources:
- Coaching for Leaders
- Ask a Manager
- The Culture Map
- Radical Candor
- The Manager’s Path
- The Making of a Manager
Then little by little I would put into practice some of the new things that I was learning. Like the types of questions to ask during a 1-on-1 or how to structure a meeting when a decision needs to be made versus one where the desired outcome is a list of next steps. It felt great to watch my efforts pay off.
For example, one issue I noticed is that folks would ask me the same types of questions again and again. One, in particular, was related to unexpected API responses in the mobile app. I would go check our API logs in SumoLogic, run a few queries and come back with the root cause. This was bad for several reasons.
So how did I handle it? Once I learned that effective leaders ask questions and help guide people to solutions, I changed my approach. First, I lead a video meeting, which I recorded, where I walked through how I debug API issues with SumoLogic. Then I uploaded the video to a shared drive and placed it on a Confluence page. Now anyone could have access to this information. Next, I thought about the most common cause of confusion: u
And then I waited. And sure enough, the question came again. This time my response was: “What have you tried? Did you check SumoLogic already?” The reply: “No, we haven’t. We’ll do that now.” And that was it. I didn’t hear back from them again. Later on, that afternoon, before I could check in, I saw that the issue had been addressed. I was really proud of my team and myself. They had the tools to handle the issue on their own. And I had the willpower to resist jumping in. This is just one example of many that highlight my shift in thinking.
Life as a Manager
As an Engineering Manager, my time is more fractured. Unlike a Tech Lead, I spend much less time developing features for our applications. Getting use to this shift has honestly been a bit emotional. I’ve needed to learn a new way to feel accomplished at the end of the day. I reflect on positive interactions with my colleagues, a great 1-on-1, a well-timed question in a meeting. These are the ways that I measure my success now.
The majority of my time is spent mentoring other developers and participating in meetings. Previously, as a Tech Lead, I focused my time on helping the more junior Android developers level up. I shared tips for increasing their productivity in the IDE, showed them how to debug issues more effectively, asked questions to challenge the way they approached developing new features. But this was all focused on Android development where I was the expert.
However, I now also manage Quality Assurance Engineers and Ruby Developers. They’re the experts in their domain, not me. I had to approach mentorship from a different angle. I now focus on how I can help unblock them, provide connections to other people in the organization, share career development advice, and more. I also spend time learning about their particular technical domain so that I can relate better to issues that they bring up. I took a course on the fundamentals of Quality Assurance and saw immediate ways that I could use the information to assist the QA Engineers on my team.
Side note: Keeping a Weekly Checklist has helped me to avoid feeling overwhelmed by the increase in responsibilities. It also gives me a sense of satisfaction when I check in on Saturday and see what has been accomplished.
The meetings I attend are focused on short and long term strategy, cross-team collaboration, and project status updates. I enjoy this shift because it allows me to tap into the whole spectrum of my experience and knowledge of the industry and people. Previously, my technical acumen was the main highlight. Now, I have the opportunity to share ideas and solutions around business process, strategy, communication and more. Being a manager allows you to “bring your whole self to work” as they say.
My key responsibilities are the following:
- Weekly 1-on-1s
- Supporting direct reports
- Developing our cross-platform solution
- Writing both technical and process-oriented documentation
- Recruiting new hires
- On-boarding strategy across the Software team
It’s a lot. Priorities shift often at our start-up and being flexible is the key. One month, it’s all about hiring. The next, we need to focus on our cross-platform solution. To keep up with the changes, I don’t become overly attached to any one thing. Instead, I make sure that what I’m doing is always aligned with the business needs.
This is the path that I’m on right now. I got here somewhat kicking and screaming. My original idea of what management was about, was way off. I didn’t know what I didn’t know. And even now, I’ve only begun to scratch the surface.