There are a couple of things I struggle with in the transition from developer to manager. I suspect many other professionals who are making the same transition are struggling with the same issues even if we don’t talk about it openly. This is exacerbated by companies not really supplying any training to new managers, leaving us to figure things out on our own – reading books and article online. Of course, finding the worthwhile materials to learn from is a chore in and of itself.
So what issues am I struggling with? I struggle a lot with telling other managers no and relying on other people to do things.
As a developer, I was always the guy who could and would accomplish anything. I cut my teeth and built my career in small companies without a lot of resources. This bred into me a “can do” attitude – I can build you any application out of sticks and bubble-gum no matter how slim the resources are. I could also ruthlessly triage features in order to meet business deadlines and communicate that clearly.
The one thing I was unprepared for in moving to a larger company, and as a manager, was telling other people – and other managers specifically – “no.” Moving from a world where launching a quality app was the sole goal to a world where I have to filter and prioritize requests and demands from multiple departments is something I mentally struggle with. My instinct is to say yes to everything but that hurts my team and just isn’t realistic.
How do you balance demands from DevOps, Security, IT and the new features that you’re expected to ship? You just have to learn to tell them no, or in manager speak “I will ticket and prioritize your requests based on business priorities.” This can be tricky because some department managers will try to apply pressure to you through hierarchy or they’ll try to attach their own deadlines to their requests so that you feel obligated to meet them…you just have to learn to push back against this kind of manipulation.
Now, I have to caveat this with a warning – you can’t just push back on everything. You have to have a real sense of what the priorities of upper management are and you have to be prepared to defend your push back. How do you defend it? You just explain the realities of things: We have X bandwidth, if we take on Y additional tasks right now then then your priorities and business informed deadlines will be missed. What’s important is knowing what the business priorities are and pushing back against anything that significantly impacts that…but also being able to explain that in a way your upper management can understand and support.
I also try to be diplomatic and not deny anyone totally. If they come asking for the moon, I’ll cherry pick some low-hanging fruit and slip that into an upcoming sprint. I can’t/won’t do everything you’re asking for but I’ll try to give you something.
Typically I do this by trying allocate 10-20% of my team’s sprint to these “non-business priority tasks.”
The other thing I really struggle with is trusting my team to do things. It’s a huge transition to being the guy who does things to being the guy who gets other people to do things and I don’t think I appreciated that when I was developer.
As a developer, I was in near absolute control of my own work product – I code make sure my code was bug-free, performant and maintainable all on my own. As a manager, I don’t have control over any of that…I’ve got to hope and trust other developers to do their work and do it well. I can create and tweak processes. I can coach. I can monitor but ultimately I can only snowplow a path to a good product — I can’t actually make it happen directly as I could when I was a developer.
I’ve gotten a lot better at this. Having good one-on-one meetings has helped a great deal and more closely monitoring situations before they get out of control has also helped. As a corollary to this, I’ve also had to learn that different developers have different strengths and weaknesses…and how to assign work based on those strengths and weaknesses. Some developers are wrecking balls who create more bugs than others, other developers will panic and quietly shutdown for days if they don’t understand something, some handle stress well and some need to be sheltered. Some are good at solving problems on their own and others ignore problems so they don’t have to solve them. Everyone is different and learning their capabilities is key but it also takes a lot of time and attention.
What am I good at? Well, for the first year I would say that I was struggling just to keep the wheels on the bus but I found myself starting to focus on our processes (or lack thereof). I started focusing a lot on trying to bring process and sanity into our workflow. That’s a bit like programming in the sense that it’s ‘systems thinking’ but also clearly in the realm of management. That’s been a great bridge into the world of software development managing. I’ve made tremendous improvements to our processes that decreased bugs and increased output and reliability…and continue to do so as time and resources allow.
I’m also reasonably good at managing up and down. I understood from the beginning that my job was to make sure that my boss wasn’t blind-sided and that my job was also to protect my team as much as possible from the insanity of those outside the team. I can’t do the latter 100% of the time because of the realities of communication but I do a pretty good job of it.
What else can I improve on? I’m not great at hiring yet. I can interview developers extremely well but interviewing people for positions I’m less familiar with is something I struggle with. I’m not great at detecting when people are BSing me when their domain/career knowledge is in an area I don’t know a tremendous amount about.