Numbers & Nurture

Transitioning from a maker to a manager role is a significant shift that requires adaptability, new skills, and a change in mindset. Paul Graham’s essay on the Maker’s Schedule vs. Manager’s Schedule has been coming to mind recently. I’ve been reflecting on my personal transition from a “Maker” schedule to a “Manager” schedule. You will often hear a split like, 50% manager, 50% maker, 60/40%, but it’s not that simple. It is a unique dynamic, managing a team of truly top performers and keeping up with my own coding responsibilities. I thought I would give some general thoughts:

1. Role Fluidity – moving from purely “Maker” schedule to needing to manage really puts these two schedules in contrast. I see it happen personally to myself every day. I needed long, uninterrupted blocks of time that allowed me to dive deep into my work and lose myself in lines of code. That’s great, but it’s nearly antithetical to what managers need. Managers want quick check-ins, very regularly that help keep them abreast of what’s going on. Managers need to go into their next meeting with their boss and know where every project is in it’s pipeline. Everyone is seeking clarity and it’s the engineering managers job to make it simple for everyone.
2. Own mistakes running – Mistakes and misses just feel worse when you’re looked at to be in charge. I feel like I let the team down, both my teammates and my bosses. It’s also just assumed that as you are a manager your abilities jump, but I am still human who’s improving. I have to remember to take the feedback in stride and learn as we continue to drive forward. Don’t let it slow the team down, which leads to…
3. Delegation Decisions – It was hard to start assigning multiple things to other developers initially. Usually, I would just handle it, but my time is limited now. It’s been a journey to let it go through triage and trust my team to handle it. Recognizing that you don’t have to do everything is key. As a leader, it’s crucial to delegate tasks effectively, trusting your team while still maintaining quality.
4. Manager time is for fixing your weakest process – I found the with my manager time I was able look up a bit more and really find gaps and weaknesses in our processes. Things I just sort of dealt with as an engineer. It was quick to see spending dedicated time to making developers’ life easier is going to help get code through all of the phases needed to be delivered much faster.
5. Feedback loops – Open channels for feedback are essential, not just for code reviews and technical discussions but also for management practices and leadership style. Encouraging the team to provide constructive feedback on your performance as a manager helps identify areas for personal growth and improvement. By actively seeking and incorporating feedback, you demonstrate a commitment to continuous learning and show your team that their opinions are valued.
6. Context Switching Challenges – Transitioning between the maker and manager roles can be mentally taxing. As a maker, you’re focused on deep, uninterrupted work. As a manager, you’re constantly shifting gears, addressing various issues, and communicating with multiple stakeholders. Learning to efficiently switch between these two mindsets is a skill that takes practice and patience.
7. Adapting Communication Styles – As you transition into a managerial role, you’ll need to adapt your communication style to effectively engage with different stakeholders. This may involve translating technical concepts for non-technical audiences, articulating project status and challenges to upper management, and providing clear guidance and feedback to your team. Developing strong communication skills is essential for successful leadership and collaboration.