I cringe at the idea that beyond a certain level one stops writing code.
You never stop writing code, unless you truly just don’t enjoy writing code, and if that’s the case please don’t manage engineers.
You do eventually stop shipping critical code, because at a certain point your managerial leverage means there are many other more productive ways to spend your time.
But the day you “stop writing code” is the beginning of the end of your effectiveness, because when your job is augmenting the impact of others, you need to have a deep familiarity with their daily experience.
Consider that any manager who “stopped writing code” five years ago has (probably) never had the daily experience of being a fully remote developer in a fully remote organization, with all the collaboration challenges and focus opportunities that entails.
And a manager who “stopped writing code” two years ago probably doesn’t get how the process changes with the assistance of LLMs, what they can dramatically accelerate and where their limitations introduce risk.
Never stop writing code. Never stop building a local version of your code base. Never stop using your internal build tools and dev environment. Never stop watching production logs and chasing down the occasional bug.
_Do_ stop assuming your code is production-ready. Do stop commenting on code reviews. Do stop assuming that the code you write has meaningful value (except as a way for you to keep your situational awareness.)
Most importantly, stop letting “writing code” be a source of stress or an obligation, and start having fun again doing it. Your organization will thank you for it.
Additionally, code is an excellent tool; leverage it even if you don't ship any code.
One of my friends, a senior director in a reasonably large corporation, still manages his various financial data pipelines for analytical purposes using code, writing stuff in Python / Pandas / SQL. I bet it gives him a much better visibility into what he wants to discern in the data.
>“The Path From Director to CTO: How to Follow It or How to Mentor It”
Well that sets the tone for me :)
There are two types of programmers, people who love the work, people who love the $. In my experience, most people in it for the $ are the worse programmers and always stressed out. If you love the work, you will end up having a fun career
If you are in it for the $, then this article is for you. Me, when I started out programming I took a 15% pay-cut because I wanted to do that. I am still programming decades after my first job.
Kids, do what you like, try not to take a job just for the pay. All you will do is pile stress on to yourself you could have avoided.
In Italy if you want a decent salary after 40 you have to move to a manager position. I truly like coding, but recent organizations changes lead to a change of role for, leading a team of 8 I have no more time to code. I'd like coding also because it's the easy part of the job for me, but a 15% pay-cut is huge when you are making, e.g., less than 40k/year, which average for a programmer in Italy.
You can love the work and be unemployable through no fault of your own (employers simply considering you too expensive, too much experience, “culture fit”, whatever). Maximize comp, get freedom, code for the love of it. Wealth is options, options are freedom.
Lots of people who have had their career they love cut short because young people are cheaper, outsourcing, incompetent management, market changes, etc. Ensure you can do what you love on your terms.
I’m about two years into a part-time technical leadership role. I know I need to give these things time, but it doesn’t seem to be sticking.
I can’t remember the last time I looked forward to work. It is hard to feel ownership of the stuff that is being built under me. I’m unsure if the actual value I bring in this role. Sometimes it feels more like parenting than building things.
Everyone’s all gung-ho about me “growing” and “leading,” but sometimes I think that’s the case because it means fewer things for them to worry about vs it actually being my next step of growth.
It isn’t all bad. But for a long time it felt like I screwed up my career. I suspect I have a deeper disdain for the corporate ladder after seeing that this is effectively my ceiling.
Well, yes, it may be more like parenting. Instead of building things by hand, you help other people come together and build things. However good one may be in any craft, anything sizable can't be built as a solo project, in a reasonable time.
So, regarding the value you can bring, some practical ideas.
- The big picture. "Individual contributors", each building their own piece, often lack the context of the bigger thing where these pieces should fit. They usually want to learn about it, but have fewer opportunities than you do. Show your fellow engineers the bigger picture periodically. They will be thankful, and everything will fit together better. Equally, ask your higher-ups to regularly share their big picture view with you (and your peers). In a few places I've seen where this was done regularly, it helped a lot.
- Expertise. Having worked on this and that across the system, you know various nooks and crannies other people may not yet. Make yourself available to answering questions like "how do we do this obscure thing".
- The interconnect. People who are building a large thing need to interact, but often they don't know who to interact with. You, at your position, have a better idea who knows / controls what. Help people find each other, and understand how they could cooperate. (At times, such activity constituted more than a half of my work day.)
> If a technology comes up in a meeting or 1:1 that you don’t know, add it to a list of things to research later. Then, dedicate time in your week to go through that list and learn about the technologies on your list well enough to have your own opinions about them. This practice allows you to have further discussions with whoever mentioned the technology.
> If you get interested in what you learn about the new technology, you may want to keep trying to understand it better; you may read more or embark on a personal project using it to gain more practical knowledge. As I said, it isn’t that you must stop coding. It is that, eventually, it shouldn’t be your day job anymore.
One thing that gets elided in a lot of "servant leadership" style chatter is, as a manager, you have permission to be straight up selfish. New leaders often struggle falling back into their old "inefficient" patterns of learning things but you have a team of resources at your disposal now.
You can just straight up ask a member of your team to prepare a bunch of background on the new technology and book a solid hour for them to personally tutor you through it. Sad to say but your time is more valuable than theirs and it does them no good for you to struggle at the other parts of your job because you're too modest to use your vested power. Often, teammates are actually happy to take the burden off your plate, if you poll ICs about gripes about their manager, one that comes up a lot is they wish they could get a few solid hours of the manager's time so they can educate them properly on a technology concept.
If you look at leaders as they move up the chain, one mark of who gets to the next level is who has learnt to be "selfish" enough to really leverage the resources under them. People are often under the misapprehension that these leaders are just sociopaths or heartless but if you actually ask them, it's not comfortable for them either and it's something they've had to learn but it's necessary mathematically to get any work done as your span of control increases.
There’s no content here. Just a link to a site that requires an account.
Try scrolling further down the page, you should find the content lower down.
You have to scroll down a quarter of the whole page and it's a pretty darn long page to say the least, this is just spam advertising with a small bit of content appended.
Sounds like most of the web these days, sadly