As I looked over my work and considered possible tasks to delegate, I realized that I was nowhere near ready. The main reason was that most of my work process was tailored to my strengths. This meant I was very good at doing my own job in my own way. However, it was not a given that someone with a different background than mine would be able to use these same techniques. I was like the local who uses only back roads – I could get from A to Z faster than anyone but had no ability to give an out-of-towner a simple set of directions on the main streets. If I was going to delegate my work, I first needed to re-engineer my process so that I was doing my own work in a more teachable and replicable way.
So, instead of relying on mental math, keyboard shortcuts, or accumulated experience to intuitively accelerate my work, I became more methodical. I created simple formulas and macros to do calculations, trained new hires on how to use the keyboard instead of the mouse, and wrote up process documents or FAQs to help transmit my institutional knowledge to others in the team. I started creating simple checklists to guide my work instead of relying on my memory to keep track of the steps.
Without making these adjustments, I think I would have quickly hit a (very low) ceiling as a leader. I would have spent so much time training people to do things exactly as I did that there would be no time for anything else. Also, the initial learning curve would be so long that it would take months before I could delegate anything to anyone. Finally, since the work process would be extremely detailed and unnecessarily complex, my efforts to monitor performance would surely have veered into the unappealing territories of meddling and micromanagement.
I, like most successful entry-level employees, had taken great pride in how well I did my work. However, merely achieving results wasn’t good enough for me – I wanted to do things my way by using the unique set of skills I had. This meant I exercised my limited autonomy to tailor the work process to fit my abilities. I did not consider the future of the team and come up with ways that someone with different abilities would be able to replicate. Instead, I structured the work so that I felt valuable any time I did something well.
Leadership is a different beast. Good leaders simply get the most of out of the team. It just does not matter how it gets done. If having someone else take over my favorite project meant the team benefited, then my job as a leader was to delegate it. When I realized this would eventually apply to every single task I ever had to do, I understood the importance of simplifying my own work so that it could be replicated by anyone else I might bring into the team in the future.
Footnotes / an origin story
1. Or, the birth of…The Business Bro?
Part of the reason I turned to management was that I thought I’d reached a natural maximum in terms of my SQL programming opportunities. I was by no means a finished product in terms of programming but my analyst role did not include feasible ways to grow into the next phases of a developer’s progression (database administration or front-end software deployment) without first delegating away all of my original role (which meant I would need to become a manager, anyway).
