Blogged Answers: Coder vs Tech Lead - Balancing Roles
This is a post in the Blogged Answers series.
Kyle Shevlin recently put up a Twitter thread describing his struggle moving towards doing "non-code" work as part of a leadership role:
I'm reaching a point in my career where in order to step up and move forward, I have to do more things I don't enjoy or even fundamentally disagree with doing. For example, in order to tech lead, I need to make more "non-code artifacts", like specs and diagrams.
I'm struggling to get myself on board with this. I don't like bureaucracy, don't like tedium, I like just having an idea and going with it and figuring out the details as I go; which is fine when I'm lone wolfing stuff, but not helpful if I have to delegate and lead others.
I get this and agree with it even. I agree in order to lead it's my responsibility to set a foundation for others to succeed, but boy, does the rest of my mind reject this. I constantly want to procrastinate and avoid this work in favor of other work.
I think what bothers is me is I know to achieve some goals of mine I have to learn to lead others technically, and I'm just wondering if there's a way I can do it that minimizes these things I don't enjoy while still being kind and good to the people I'm leading.
I want to be a good leader, I want to effectively help others get stuff done, am I just doomed because I don't enjoy things like writing specs and tickets/issues for others? Give me your tips on tech leading.
I wrote an extended response thread, which I'll repeat here:
I'm not sure I have "tips", per se, but I've gone through a lot of that evolution myself in the last couple years.
In early 2017, I had to fill in as acting team lead for a few months.
I learned a lot about how the parent project works...
and that I never want to do that again
Within my small team, though, I'd effectively been "acting tech lead" already, and even more so afterwards. I'd picked our tools, knew our codebase, designed new features, onboarded new devs, did code reviews, directed traffic, and still stayed hands-on.
I loved it.
Early last year, we re-org'd to "feature teams" instead of "app teams". Chaos ensued. In that, I pointed out that no feature team owned any "common code" (app login, infra, choosing comp libs, teaching practices).
I pointed this out to management, repeatedly.
A few weeks later, management turned around and said, "We're going to start a new 'UI and Infra Services' team. Congrats, you're leading it!"
I agreed, but was scared I'd signed up for something that was nothing but meetings, all day. That would have crushed the life out of me.
Fortunately, it turned out well. I already was recognized as our web dev expert. I got to push adoption of tools and tech, train folks, prioritize prototyping and research tasks, and WOW did I answer a lot of questions and do a lot of code reviews :)
At the same time, I was able to stay hands-on. I researched stuff like Cypress and OpenAPI schemas, set up CRA projects, built reusable code for the feature teams, prototyped some features, and wrote internal docs giving guidance and patterns to follow.
I guess my points are:
- it is possible to balance being a leader and being "hands-on technical", but you do kinda have to get lucky with your situation
- It is a tough balancing act. I wanna have my headphones on and write code all afternoon, but it's not best for the team
I have had to sorta sacrifice some of my own enjoyment of coding, in order to enable my team to be more productive.
At the same time, I do love the "tech lead" aspect. I like teaching, training, explaining, directing. (Maybe not "reviewing"? as much, anyway)
So I don't have a magic wand or "here's the right answer" solution to your questions, but I can say that it's at least potentially possible to balance the tech lead side and the coder side, if you can manage to find the right role and environment that lets you do that.
(Unfortunately, "the rest of the story" has a sad ending. The project I was on just got effectively canceled, killing the new dev work that we spent all last year preparing to do. It was good while it lasted...)
This is a post in the Blogged Answers series. Other posts in this series:
- Aug 08, 2023 - Blogged Answers: My Experience Modernizing Packages to ESM
- Jul 06, 2022 - Blogged Answers: How I Estimate NPM Package Market Share (and how Redux usage compares to other libraries)
- Jun 22, 2021 - Blogged Answers: The Evolution of Redux Testing Approaches
- Jan 18, 2021 - Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
- Jun 21, 2020 - Blogged Answers: React Components, Reusability, and Abstraction
- May 17, 2020 - Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior
- May 12, 2020 - Blogged Answers: Why I Write
- Feb 22, 2020 - Blogged Answers: Why Redux Toolkit Uses Thunks for Async Logic
- Feb 22, 2020 - Blogged Answers: Coder vs Tech Lead - Balancing Roles
- Jan 19, 2020 - Blogged Answers: React, Redux, and Context Behavior
- Jan 01, 2020 - Blogged Answers: Years in Review, 2018-2019
- Jan 01, 2020 - Blogged Answers: Reasons to Use Thunks
- Jan 01, 2020 - Blogged Answers: A Comparison of Redux Batching Techniques
- Nov 26, 2019 - Blogged Answers: Learning and Using TypeScript as an App Dev and a Library Maintainer
- Jul 10, 2019 - Blogged Answers: Thoughts on React Hooks, Redux, and Separation of Concerns
- Jan 19, 2019 - Blogged Answers: Debugging Tips
- Mar 29, 2018 - Blogged Answers: Redux - Not Dead Yet!
- Dec 18, 2017 - Blogged Answers: Resources for Learning Redux
- Dec 18, 2017 - Blogged Answers: Resources for Learning React
- Aug 02, 2017 - Blogged Answers: Webpack HMR vs React-Hot-Loader
- Sep 14, 2016 - How I Got Here: My Journey Into the World of Redux and Open Source