Embarking on a career in engineering management is often a journey filled with high aspirations and big dreams. As young engineers transition into leadership roles, they bring with them idealistic visions of how to lead teams, innovate, and drive change. However, the path from idealism to realism is a transformative one, marked by challenges, learning curves, and the need for adaptability.

In this article, I shed light on my initial, somewhat naive, expectations of engineering management and contrast them with the actual experiences I have so far encountered in my role as Lead Developer at Unity5. It's essential to acknowledge that every company has its distinctive characteristics and ways of working, so you may encounter variations of what I detail below. Nevertheless, I aim to provide you with valuable insights that can serve as a guiding framework if you're contemplating going beyond the code and into management.

Here's a closer look at what I initially expected versus what I've learned through experience:

Expectation: To feel confident in all aspects of my role I would require sufficient management training.
Reality: Although I did participate in a one-day management workshop, which offered some valuable insights, it primarily reinforced that becoming a comfortable and effective manager would depend more on gaining experience rather than formal training. The realisation that it's acceptable not to have all the answers, has given me the confidence to fully embrace the role knowing that whatever happens, I'll be more prepared for future challenges.

Expectation: My workload would change from mostly technical duties towards mostly managerial ones.
Reality: Aside from conducting quarterly performance reviews and holding regular one-to-ones, my daily tasks have remained largely consistent. I continue to dedicate most of my time to feature development, code reviews and deployments. I'd estimate that on average my workload is split between roughly 80% development and 20% management each week.

Expectation: There might be a change in the dynamic within the team as I move from being a peer to a manager.
Reality: Becoming a manager brought about a shift in the team's dynamics but fortunately, it was a positive one. As we transitioned away from a flat team structure, team members began to feel that their voices were being heard more effectively and that they were receiving more personal attention. This has led to an increase in the engagement and job satisfaction of those in my team.

Expectation: I would have the time to think of big-picture ideas and processes.
Reality: Due to my continued involvement in product development, to get the time I need to think about things on a larger scale, I need to carve it out and reserve it for myself. As such, I typically allocate the last hour of each working day for "focus time" so that I can work on the things that are important to me.

Expectation: I would be involved in a lot more meetings.
Reality: A common cliché of engineers turned managers is that they are taken out of the code and dropped into a neverending cycle of meetings. However, I've found that the frequency of meetings I attend doesn't significantly differ from my time as a senior developer, though this will vary depending on the company.

Expectation: Working longer hours would become more the norm rather than the exception.
Reality: While I occasionally work outside of regular hours, it's not something I do regularly. That said, I can understand why I initially thought it might be necessary and why other managers may feel compelled to do so. If you find yourself unable to safeguard your time during working hours to focus on essential tasks, working outside of regular hours might seem like the only option. However, this just emphasises the significance of allocating dedicated time for yourself and for tasks that only you can do.

Expectation: I would more easily be able to bring about change.
Reality: Even within a fast-paced environment, introducing change can pose challenges. Not only does change necessitate questioning the status quo, but substantial changes also depend on gaining the support of others. In the end, it's not merely about enforcing change but rather about influencing it. This is something I didn't completely grasp until I stepped into a management role, and I acknowledge that I may have been somewhat ignorant of it beforehand.

Through reflecting on my journey into management and writing the above, it's clear that my initial expectations didn't align with the realities I've encountered, but in a surprisingly good way. Numerous concerns I had have been addressed, and my initial negative assumptions have been proven wrong. I am now a year into my new role and the position still provides me with a satisfying and meaningful challenge, offering opportunities to enact change within both the team and the larger organisation. While, in hindsight, I might have approached some aspects differently, I don't regret my decision to go beyond the code. I hope this introspection helps you if you are considering doing the same.