There’s a story we tell about advancing in our jobs. We start out inexperienced, kind of dumb or lucky or something. Then something happens to us and we learn from it, and then learn again, and then learn some more, and that all adds up to us being “senior.” It’s a ramp we climb over time and we only get better as we get more experienced. If we learn the right way and we’re naturally talented or whatever, the ramp is steep and goes up high. If we do the wrong stuff then we stay where we are or slide back down.
Of course that’s horseshit. Yes, learning is awesome and there are things we learn that make us better and better. I experience advancement much more as a sawtooth progression, though. Unlearning what you used to know is as or more important than learning.
Early in my life as a manager, I worked at a company that was, to say the least, chaotic. It was early in the life of the Internet industry (1996), and everything was exciting and amazing – who called us? what just happened? is that who I think it is? that’s awesome! – and the waves from all that tossed the internals of the company this way and that.
When a need would arise, people from other groups would go find some engineer they liked and ask them to do a project of unknowable length as a favor. Engineers would stay up all hours or drop the ball or get some other request, and the output of the group was seemingly random. You dropped the project for MassiveCompanyA in order to deal with a request for SomewhatLessMassiveCompanyB? Why? What were you thinking? There was always a more MassiveCompany coming in the door, and yesterday’s hotbutton was today’s backburner.
I became manager for more and more of the engineers, and soon I adopted what would be the style I used for my time there: the Bottleneck Manager. If you need something, come to me, and I’ll assign it and track it and make sure it gets done. If we can’t do it, I’ll tell you “no” and my word is final. If you talk to anyone else, I’ll come yell at you.
And it worked. Things got better. Projects shipped more reliably. Engineers were happier and felt taken care of. Everyone else disliked it but admitted it was better overall. Engineering became a black box with a single interface, and I stuck with that for almost a year, getting promoted every few months. I was miserable (I changed my email signature to “Director of Bottlenecks” after a while, and got chewed out by the CEO for that attitude), and I left the company as soon as I could. The bottleneck approach, though, was probably what that company needed at that time, and what I could provide with the skills I then had.
At other jobs in the future, I’d occasionally reach for that model in response to behavior that felt reminiscent to me. Oh, that marketing person called that engineer directly and threw their work for a loop? BRING ME MY BOTTLENECK! In different environments, without the same pressures, that model completely sucked. If I stand back and give advice to my younger self, I’d never suggest bottleneck management now. Don’t you trust your employees? Don’t you care about the needs of other groups? Don’t you care about your own time management? Isn’t more communication better? And so on.
Bottlenecks go against everything in my style today. Today, when a board member has a complaint about our Android app, my response is, “Tell the developer yourself.” And they do, and the developer loves hearing the feedback, and learns over time not to dismiss it but not to overreact to it, either – a skill every developer needs for all sorts of feedback.
I don’t think I would still be an engineering manager today at all if I’d stuck to my bottleneck approach. But I don’t think I could have been as effective, those many years ago, with another approach. I didn’t have the confidence, nor the ability to teach, nor the ability to rally people around an idea, to do anything else. I chose the approach that was right for me and right for that company and used it well, and fortunately that match worked out okay. But to keep going, I had to leave behind what worked for me there, unlearn the habits and instincts it taught me, and learn a new approach for a new place and a new situation and a new me.
I think the best thing you can do in any situation is start fresh, make yourself a novice again. Look at your style and skills in your last situation and understand them as adaptations to environmental pressures. Ask yourself what is different in the new situation. Ask yourself what worked and didn’t work last time, and name the skills and techniques you want to unlearn. Write them down as a “To Not Do” list. When you see something in the new situation, listen to your instincts for how to react, and then consider them. Are those instincts right here and now?
Don’t wait to change companies to unlearn things. Do it when you get promoted. Do it when your company changes (wow, we went from 50 to 100 in a year! Um…what should I unlearn?). Do it when new peers show up, or a new boss. Of course people get used to who you are, and retraining that within a company or role is harder than when you change companies altogether. It’s okay, though, to tell people you’re doing it. “What we’ve been doing isn’t working. I’m going to try something new. Here it is.”
Advancement is not a collection of skills. Advancement is an awesome ability to adapt to a new situation. Experience is a toolbox to help you do that – but any new job, any new role, any environmental change should make you question whether the tool you know and rely on is still the right tool for the job. Think of your skills as disposable, and actively work on unlearning the ones that were right once but aren’t right now.
[Written for a friend who was recently promoted. Congratulations, friend!]