Back in the olden times, when I used to do a real job, I spent my time writing code and making awesome things. Nowadays I am post-technical which means I mostly talk to people, sit in meetings and play with spreadsheets. Making the jump from operational work to a leadership position is not easy, so I thought I'd write about some of my experiences in the hope it'll help someone making a similar journey.
One of the hardest parts I found of moving to management is understanding what a good and productive day looks like. A reason people find programming so compelling is the process of breaking down problems into small, achievable chunks then completing them in a short period of time. At the end of the day you can look at your work and say "I had a good day - I made that". This is a tight emotional feedback loop which triggers positive emotions and makes us happy.
Moving into management breaks this loop as, initially at least, much of the work is variations on supporting the people making things. It's important, but not as immediately rewarding - especially since most of it is never really "done", it's forever maintaining things. It's very important to learn how to limit maintenance and support work or it can easily become all-consuming - especially since if you know what you're doing everyone will want your involvement. Taking on too much is particularly tempting early on as, if you're anything like me, you'll want to do something concrete and maintenance work looks like a short-term deliverable that will help justify your existence. This can easily fill your time and you'll be unable to do anything else - anyone who has suffered under a reactive, passive manager will know where this road leads. One of the most important questions I (accidentally) asked early on was "how do I stop being so reactive and start taking control of my work?" The answer was long and difficult in practice, but the theory was simple - be discerning about what ended up on my plate.
In the early days of management I was given things to change, handed down from On High. They appeared in the form of business needs, which needed translating and socialising before anything could be done. The basic but important questions to get through this were: Why is this change important? What (hopefully positive) effect will it have on the people I'm looking after? Why do the operational people want or need to care? It's very important be able to champion whatever is going on and there were definitely times I found myself unable to express clearly the case for change so I spent long hours talking to people and going back through decisions to regain that context. "Why" is a very important question - you're going to be asked it a lot, so you really need an answer ready.
When it comes to communicating change, the key tips are to keep the message simple, keep saying it and listen to feedback at least twice as much as you talk. In fact, "listen a lot" is my strongest single piece of advice for making moving into management or indeed any leadership role. As a rule of thumb, the more authority you have, the less you should be talking.
These basic experiences about managing change have come up again and again, however the steps take a long time and frequently loop around while appearing to go nowhere. This brings us back to the original question on how to get some sense of accomplishment from management work. Fortunately, for me the answer was also the answer to the questions "how do I effectively deliver anything?" and "how do I show the organisation I'm doing something useful?" and comes in the form of work objectives. Everywhere I've worked has required objectives written in the SMART format. As a manager thinking about these in detail suddenly becomes very useful as they force a scoped deliverable in a known timebox and defines a "done" state, which lets me know when I can stop thinking about something for a time. This isn't particularly insightful, but it's easy to skip over when the pressure is on. I've made that mistake several times, but taking proper time to think and plan deliverables and end states has never been time wasted.
Much of the above is about scoping management work in completable chunks, and therefore bringing it back to the more familiar patterns of product delivery. At the same time, I did have to get used to the new cadence of work. Plans and changes can take a long time to seed and grow and I frequently have periods when it feels like everything is just a slow grind. Then every so often the work comes to fruition and several things bloom at once. The feeling is different from cracking a difficult technical challenge, but no less powerful. However it is far less frequent.
There are other fundamental changes to watch out for when making this switch in role. It's important to get used to making decisions. In a leadership or management role you can't hide at the back, or as a voice in the crowd. In order to be comfortable making decisions, I had to learn the detail of how I make a decision (how much information I need, etc) so I could justify it to others if the need arose. Learning how to make a decision is an art, and a very important one when taking up a role where making decisions is basically the job.
Part of that is understanding the limitations on the decisions you can make. What are the limits of your authority? When do you need to escalate and (just as important) when do you not need to? What does and doesn't the organisation let you do? This last is worth gently pushing and questioning as I've found the organisation will be used to giving you the same authority as your predecessor took and that is not necessarily the same as the answer to the first question about limits.
To frame it differently, I see learning what I can and can't do as learning the rules of the game. I don't have to use everything, but it's helpful to know where I can reach out and when I'm in danger of doing something wrong. It also helps me take ownership of the things I'm doing. A manager who doesn't do this and passes on messages from their superiors just looks weak and ineffective and that is awful for the morale of those who depend on them.
Final tip for now - it's important to find a team of people you can trust. Everyone needs support but you can't sit in a pub grouching in the same way you used to. Finding a leadership team is very important for getting things done, but you do need to be open to this team changing. There is a very real danger of building a clique and alienating people, denying development opportunities to new and growing people and causing problems via your own biases (both conscious and unconscious). At the same time, those kept close need to be able to grow and sometimes that means them moving on into their own space.
So, the summary. It's a mental shift going away from technical work and something not to everyone's taste. If it's happening to you, I hope something here has been of use.
