Don’t Delegate, Lead

I dig this article on delegation, implying you should not delegate, and instead lead by getting out of people’s way so they can tell you want to do. It made me think about why I like being a Tech Lead.

https://longform.asmartbear.com/delegation

I’ve been on various teams in my career, from single person freelance, sub-contractor where I was the only UI guy and the rest were back-end, to consultant amongst a dozen+ helping a client, to employee on feature teams, startups, scale ups, and contractor or sub-contractor for startups and scale ups. What was consistent in all of them was I would learn from people. Some were just 100% brilliant, where others would occasionally have moments of brilliance that you had to look for because we were all locked in because of deadlines or stress or just being super busy and no time to chat.

One thing I started to notice was the better I got, the easier it was to get out of people’s way. For example, in the early days, if someone really felt passionate about some architecture or coding approach, I used to get nervous, usually because I was projecting my insecurity about being held accountable for something I couldn’t fix in the case of it breaking or just not getting done on time. As a contractor/consultant, this can mean you just don’t get paid, and don’t pay your bills/rent/mortgage, and possibly get a client who will give you bad press, so it was quite hard to suppress emotions.

Over time, though, I started to get good where if something broke, I could fix it. If something broke, and I had never seen the code, I’d read it and understand it. If someone spent a week building something, and it was a mess, I could spend 2 days cleaning it up or rewriting it, eventually learning how to pair with the team to speed up & improve this.

This unlocked a lot of positive abilities. I no longer was afraid. I became a lot more open to wild, new ideas or approaches. If a junior/mid-level engineer wanted to do something crazy, I’d ask a few key questions, and then encourage their passion and let ’em rip. If they got into trouble, I knew I could help them. I started learning about certain guardrails to help these explorations be safer and more fun for everyone. Instead of risk mitigation, it became “what can we learn today and how can we have fun?”.

Now, while I accrued a lot of experience, the one nice thing about tech is you are surrounded by people who just start off, on day 1, being smart. So it’s always been a 2 way street; I teach ’em the fundamentals, things to watch for, and lead by example. They in turn teach me new things they learned, or different versions of techniques, or something from a past career path. Most importantly, they teach me how to be a better teacher. If you do this long enough, you’d watch many get to your level and eventually surpass you. I always saw leaders, the ones I liked, continue to push someone higher. If you look, often no one is pushing them; they are just selflessly helping others. Often that means getting out of their way and letting the other person cook. Those are the leaders I want to emulate.

I’ve been a Tech Lead for awhile, and I’m old enough to remember when many in the industry were juniors, and now some are Directors and VP’s, while others are the same, just an insanely leveled up version of themselves. The age helps because I can see the fruits of the labors. 100% of the time it was the person’s natural desire to get better, no doubt, but I love that I could be a part of their story where “Jesse helped”.

I try to remember this as I’ve had experiences where I felt a dictator approach was appropriate. Meaning, I know best, we’re going to do this. In Freelancing/Consulting solo on some projects, that’s the de facto way to handle some clients since they literately hired you to tell them what to do. However, in a team, democracies can get things done, and if you are polite, respectful, and honest, a vulnerable team builds trust, and this allows people to just do their thing and the work gets done right. Balancing that has been my favorite challenge. I never liked people who dictated ways to do things in code, but on the flip side, I recognize some devs just never knew certain problems had a name, and a pattern for ensuring they don’t happen. Sometimes, even if you explain that, a dev needs to experience those problems for themselves. They deserve that learning experience, but unlike many of mine, I want to ensure they have safety nets, including me, to be there in case things go wrong. You can allow others to learn with a small blast radius and way way less pain.

Over time, you watch many devs do 1 of 3 things:

1. grow to take on more and more responsibility, often going high up the reporting chain
2. changing roles as they discover they like managing more, or leading product/business more, or perhaps staring their own company
3. same as me; wanting to be close to the work, wanting to do more of it

There is a part of you that feels a little insecure when you start this; like why am I not some high level executive, or why haven’t I gotten bored and wanted to change my career path in tech? Over time, though, you “learn yourself”, what you like, and what your goals are. I’ve always enjoyed working with the juniors and the mid-level devs; teaching, having them teach me, and experimenting with ways to help them grow. I still get, and take opportunities to help more than just my team. Ultimately, my impact has always been the intimate communication for the sake of growth of a small group of people I have daily access too and being a Tech Lead allows me to do that. Maybe someday I’ll see and understand the allure of being a higher role than I am currently, but for years, I’ve enjoyed working on teams where I eventually get to the point where I’m not needed on that team because they become awesome. I believe they became awesome because they started as awesome, just little to no experience and I helped point them in the right direction and helped them lessen the pain of failures; basically what I always wanted people to do for me in my career. So they would of leveled up without me, but after seeing bad leadership and management in my career, I want to ensure their journey has good leadership and we have fun, and there is no way they can fail as long as I draw breath.

Keep in mind, leadership/management up the reporting train wants people to treat teams like that. If you take initiative, and ownership, of people’s growth, you make the team better, the software better, and the company better. That’s the job sometimes.

With age comes perspective, and as human programmers, we see patterns, and the pattern I see is that eventually, all those fellow devs grow, and eventually don’t need you. This can be hard to accept. You want the learning journey to last forever. You want to feel valuable to them forever. Some seek you out in the future to work with because they value your personality, attitude, knowledge, or just extra coding muscle. What I’m talking about specifically is they don’t need your leadership anymore; they’re at a point where they can lead their own team, or even teams. Some will still seek your advice from time to time, so it’s not 100% “done”, but you just need to emotionally prepare yourself that it’s a journey to love and the ending can be bittersweet. You want to, and should be, happy for their growth, but recognize that eventually they’ll no longer ask for help with a unit test, or why primitive obsession is a thing, or how you break up a PR. The best thing you can do at that point is get out of their way even more than you use too.

That could mean never talking in a meeting, or allowing them to take the initiative on “all the things”. You want to provide them space to be able to do that. There will always be work, and thus there will always be things for you to do. So sometimes you’ll be doing way less mentoring, BUT you can always still help in the normal ways even if they’ve grown beyond you; helping on PR’s, thoughtful comments on ADR’s, or networking on people who may fit a role for their team. The leadership and mentoring may change, as will the intensity, but it’s still needed, just a different form. You can still play a part in helping them, and often times that means getting out of their way, and trusting them to sometimes tell you what’s next.

You’ll often get a hint they’ll rise to this level when in the early days, they have a quick grasp of the business problems, or vast experience in a particular tool, possess a wonderful communication ability, or some niche project reveals their inner-genius. That should not intimidate you, but instead excite you to know you’re training not only potentially your replacement, but your future VP. Keep in mind some people don’t see their potential; it’s there, but for a variety of reasons, they don’t. You can be the simple key that unlocks it. I say simple to imply that small efforts on your part can make a big impact. I’ve also seen the opposite; wonderful people put in positions where leadership didn’t see that potential, and never found ways to unlock or give them opportunities to shine. You should view that as a duty to ensure those negative outcomes never happen.

I’m a self taught programmer with an art degree amongst many many people who got good grades in high school and got MBA’s from Stanford. I’m used to being around people way smarter than me. You’d think “How can I help these people if they’re so much smarter than me?” You should remember that your experience is valuable, and your desire to help is valuable.

I also have built up my confidence over the years by many small wins that accumulate over time. This is how I can feel secure in this environment, and at the same time be vulnerable, learn, and enjoy it so much. I want to build cool stuff with smart people, and I want those smart people to succeed, and they know that’s how I feel.

Reiterating, your experience is important, that’s why you became a Tech Lead; people trust your ability to “know where the team should go next, or what to focus on next”. You have to figure out what’s a suggestion vs. what’s a target that isn’t negotiable. You don’t have to do this alone, either; managers can help, fellow IC’s can help, and searching the internet for articles like these can help. Just always defer to assuming benevolent intent, and believing in the capabilities of others. Emulate leaders you admire. Make sure you’re having fun, else it’s not worth it. Learn yourself as to “why” you’re doing this.