Engineering Manager and Software Engineer at Patreon, Good Eggs, and Google, among others
December 03, 2018#android #front-end #remote #web
My academic background is in Electrical Engineering, and a program called “Dependable Computer Systems”, which was an amalgam of computer security and fault tolerance stuff. In my career I’ve always worked as a software engineer generalist, mainly on the server side, although not exclusively — I’ve dabbled in web frontend and Android development as well. My most recent full-time management role was as a Senior Engineering Manager at Patreon.
Currently I’m taking a little bit of a break from full-time employment, and doing some contract work. My current main project is helping the folks at Percy (https://percy.io) build more SDKs for their service.
It happened while I worked at Google, which was my first full-time job after college. I was a senior software engineer at the time, and had been in a couple of technical lead roles. My direct manager at the time, who managed my immediate team along with a few other such teams, asked me if I would be interested in stepping up to also manage the people on the team, in addition to serving in a technical leadership role. I said yes.
The transition was both unexpected and perfectly natural. I had not been thinking about a people management role, and I was a relative newcomer on that particular team. But once the opportunity was on the table, it felt like a logical progression in the kind of work I had already been doing — providing technical leadership, but also increasingly pointing out ways in which we could be working better as a team, improving group dynamics issues, mentoring others.
Currently I’m working on a project that has me working in code most of my day, remotely. I communicate with my teammates mainly over Slack, and I spend on average about an hour each day on video calls pairing and doing live code reviews, and discussing next steps.
In my most recent role as a manager, I spent my day almost entirely in meetings.
Many were one-on-one meetings with direct reports, where I would listen to what’s on my teammate’s minds, coach and support them in whatever challenges they’re facing. In those meetings I would also share news about the rest of the organization, and answer any questions that came up. Other one-on-one meetings would be with other engineering managers, coordinating teams and co-managing folks that might be working across more than one team.
There were also a few standing group meetings per week, mostly with other engineering managers, but also with the product management and talent acquisition teams. We were hiring very rapidly, and one of my duties was as a hiring manager, so I also spent several hours per week interviewing, participating in interview debriefs, making hiring decisions, reviewing resumes and helping set up job postings.
Finally, there were meetings with my immediate team: daily standups, sprint planning, retrospective, meetings with the team product manager and designer to prepare for future work, discussions of any issues that arose on the team, etcetera.
My non-meeting time was devoted almost entirely to reviewing and writing documents — proposals for improved processes, planning and sequencing for engineering deliverables, job postings, design documents. I would also spend some time looking over the code reviews that were being exchanged on the team, and following along with any discussions that arose in the team Slack channels.
I would say about 50% of my time was devoted to the work of my immediate team, and the rest was spent doing larger organizational work.
As to what motivates me to do this kind of work every day, I’d say the biggest drivers for me are seeing people grow and observing a team become stronger and more effective, sprint after sprint. Seeing all our collective work come together as we make progress towards whatever we’re building is hugely satisfying.
One of the biggest challenges in rapid-growth startups is that leadership — founders and C-level folks — often want to introduce significant changes to the organization very quickly, faster than the average person can absorb. It becomes a big part of the job of managers like myself to support everyone through the changes, helping our teams understand the rationale behind the changes and the broader context.
Perhaps the most surprising thing to me is how much of the work of management really just boils down to listening to people and genuinely caring. Small things done consistently, like hearing an administrative request in a 1:1 and promptly following up on it afterwards, make a big difference in terms of building trust and creating a sense of support.
The most helpful advice for me was to regard a management role as a different profession from software engineering. It helped me approach management with a more curious mindset, which was helpful for learning the ropes and also to develop a critical eye towards how we manage.
To those considering the switch, I tell them to be very clear that management is a different job from software engineering, and that they should ask themselves carefully if they are ready to make that move. Every engineering manager I know mourns the fact that they don’t code on a daily basis anymore, so you have to ask yourself if you’re ready for that, and if this is truly a path that you want to follow. I also recommend not to overthink it — the move is lateral and not irreversible, especially early on in your management career. You might not know if this is a good fit for you until you try it.
For those that are new to the role, I also start with a reminder that this is a different job than the one they used to have. Some of the strengths that made you a good software engineer or technical lead can become a liability when you are a new manager. You have to be willing to learn many new ways of thinking and being at work and with your team.