About a year ago, I was hard at work coding new product features when my manager invited me for a one-on-one. “Bruno,” she said. “Good news! I’m pregnant, and I’m going on parental leave. I want you to take over for me as the interim engineering manager. What do you think?”

My initial answer was no. I had been a people manager before at other companies. I’d also stepped in for managers during my time at Atlassian, though never longer than a few weeks at a time. I enjoyed being a team lead and got a lot of professional satisfaction from it, so I knew I could do the job, but I was happy in my current role as a senior engineer and wasn’t looking for a change.

But I also felt like it would be an excellent opportunity for me, and I loved my team, so why not do my part to guide them through this period to the best of my ability? After a week of reflection, I said yes. Now, on the other side of the experience, I’m incredibly grateful for the lessons learned. Being a manager is hugely different from being a developer. I needed to exercise a whole different set of skills and came away with a deeper appreciation for the work people managers do.

Here are four things I learned from leading a team of developers for six months.

Managers do a ton of invisible work

How to embrace the human side of leadership

Managing people means so much more than showing up for one-on-ones with their team. So many moving parts need to be managed to keep the whole machine running. Constant monitoring, assistance, reporting, syncing, and documentation strains your schedule. At times, I felt like I never stopped working.

And managers have a lot of meetings. On the rare occasion, when there were no meetings on my calendar, I felt a bit lost. The way I organized my time was radically different from a developer workflow, where you have a definitive set of candidate tasks you can work on to optimize your time. While you’re waiting for your code to compile, your tests to run, or that build to finish, you can review other people’s pull requests and code changes, work on another task on the Scrum board, or help improve the operational excellence of our products. For managers, there’s often no clear path to the next best task.

Once I got the hang of it, I usually filled my free time getting as much context as possible on what the team was working on. I saved some time daily to review the technical pages they updated in Confluence (you can follow specific people in your Confluence feed). It helped me understand where I should focus my attention to help someone get unblocked.

Scrum makes managing easier

The agile methodology is, in a nutshell, a project management approach emphasizing intense collaboration, fast delivery, and quick customer feedback. Scrum, in turn, is a framework – a set of practices and rituals – for delivering work. I’m passionate about these practices, and even pursued a Scrum Master certification a few years back.

The certificate itself doesn’t mean a lot to me now, but the lessons and the understanding of how self-managed teams should work are still at the forefront of how I work. While I occupied the engineering manager role, my focus was on keeping everyone unblocked, focused on shipping customer value, and on top of their tasks. I saw myself less as a manager and more as a facilitator, while prioritising:

  • Following up with other managers from other teams on cross-commitments for projects
  • Helping the team find other points of contact with other teams to get tasks unblocked
  • Helping individuals prioritize their work
  • Encouraging the team to escalate blockers to me (and fix them)
  • Escalating issues with my own manager (or their managers) when I needed help to unblock myself

One-on-ones are incredibly useful

7 tips for better 1-on-1 meetings

When I joined Atlassian, I was shocked to learn that my manager would host regular one-on-one meetings with me. The meeting would still happen even when I felt I had little to share. In the beginning, I wondered if it would be too much.

But I was so wrong. I only fully understood the actual value of a one-on-one after I started acting as a manager. One-on-one meetings are a fantastic way to help everyone remain focused on the team’s goals, share knowledge, answer questions, and give quick-turnaround feedback.

But it was also a chance for me to ask for help. While managing roadmap work and determining who would work on which project, the developers had project information I could potentially be missing and suggested solutions I hadn’t thought about before. Managers are not necessarily the single source of truth; my dev team often had better answers than I did. One-on-one syncs are a great way to surface those solutions.

Managers must practice empathy to help teams grow

As I mentioned, I hadn’t planned on being an engineering manager (at least not anytime soon), but I wanted to ensure my team had the support they needed.

Part of being an engineering manager is understanding the ebbs and flows in our personal and professional lives and how they affect our work. As part of my role as a manager, I kept this awareness top of mind, and spent time reflecting on how to support each individual in their work environment. If someone is not performing well, there’s usually a reason. If you understand the individual’s circumstances, you can better help them.

I made sure the team felt comfortable enough to share as much as they were willing about their moments in life so I could think about how to assist them better. For example, If someone is going through a difficult time with their family, giving them a big project to lead with many responsibilities might not be the best move. If you, as a manager, have this mindset, you can avoid much burnout in your team.

What am I taking back as an individual contributor?

After six months as interim manager, I moved back to an individual contributor role with much more clarity and appreciation of engineering managers. Months later, these are the things that are sticking with me:

  • Focus: Work never stops coming in, and time is limited. it is essential to be deliberate in choosing what we spend our time on and ensuring we prioritize tasks that bring customer value.
  • Communication: I’d been an overcommunicator before this experience, but being a manager reinforced the importance of keeping everyone in the loop, early and often.
  • Documentation: Especially at a highly distributed company, documenting decisions is crucial to avoid repeated or unnecessary meetings.
  • Stakeholder feedback: Being concise and to the point with project progress is so important. At Atlassian, we use Atlas to keep folks in the loop about our projects.

If you are also a software developer with a passion for teamwork, mentoring, and project management, I highly recommend acting as a manager, even if just temporarily. The experience broadened my perspective and understanding of how much every person’s commitment and passion matter to unleash the power in every team.

Four things I learned as an interim engineering manager