The memory forking seems like a cool technical achievement, but I don't understand how it benefits me as a user. If I'm delegating the whole thing to the AI anyway, I care more about deterministic builds so that the AI can tackle the problem.
Today, I don't think the tools are good enough to make a material difference. It may help a bad engineer tread water, but it won't take you from good to great. It may save you time writing basic boilerplate and individual functions, but I suspect 99% of engineers don't struggle with that. What's hard about our jobs is knowing how to orchestrate the whole thing and put structure around complexity. AI can't do that yet.
When I use it personally, it feels like a harder context switch trying to describe in english what I already know how to code. Then I still have to review the function to make sure it's accurate. It feels like a waste of time and an additional context switch.
Whenever the AI gets better, we'll have to use it to be productive I have no doubt. But the pool of engineers will change too - there will be a categories of engineers who can't debug the AI output and who still write crazy prompts.
Maybe I'm old, but I'll only be worried about AI when it can write and maintain a full app with no human intervention.
I don't think AI poses a risk when it comes to setting engineering priorities and building the roadmap. If it could do that, it could probably just build the entire system anyway.
EMs are there for the human aspect of engineering, so I also doubt it will impact hiring or EM-engineer ratios.
I do expect the bar to being an EM to be higher as the job will be more technical and less project management.
I'm currently working through an analytics architecture and I'm having to defend against "why aren't you using postgres" when I'm talking about olap dbs.
To be fair, these are the only examples I can think of and I only learned of these as I'm standing up new data infra using starrocks.
1. Org of 1000+ engineers has no shared services. Each team does CICD themselves and in different ways. Each team has different patterns for sharing data. The SREs we do have only setup/monitor alerts, we have no automation and the engineering teams are responsible for their own infra.2. My team is 90% contractors. They've been here for years, but constantly complain about the legacy...
On product work, we do an oncall rotation of 1 engineer per week that triages issues and handles prod outages. This may solve for your 'help desk' type work.
If this is the direction you want to go, the only way I can think of determining this is by telling the contractor to use a github account you control and then monitoring the logged in sessions.
It's less about taking on roles and just doing what needs to be done. Everything is a partnership in building the product, so I help where I'm needed most. When our hiring pipeline dried up, I'm the one doing outreach. When our test suite needed enhancements, I'm writing demo code to show best practices. When an upstream service pushed breaking changes, I'm the one pushing for process/communication changes.
Granted, my current org is a little bit of a mess, but every place I've worked at needed me to flex because it gives my team the ability to do what they do best - code. And since I'm fixing processes and not a bottleneck, I have a stronger case for promotion too.
As a manager, you have the freedom to set your own schedule and run your team the way you see fit. I don't know if I'd recommend that when you first start out, but you're judged based on the outcome - generally. Some managers still do 50% coding, which is fine, but I think those pitfalls need to be considered carefully.
Once my teams get to a self-sufficient status, we're able to take on more responsibility and do more "innovation" type projects. That's "success" in my mind, but it takes time to get there. Up until that point, I do whatever I need to.
The time off itself was great. I struggled to get away from needing to feel productive, but did explore some new tech and played some games. I would recommend a small break to anyone.
You would think being in management would make reentry harder, but I got a good pay bump and switched industries. The market is definitely hot. I also didn't get questioned about my time off. I framed it as "taking care of family" and that was the end of it.
I tell this to my newbies too - make sure you're developing good work habits. If this break is the result of the pandemic, do it. But if you're doing it to get away from work after only a few years of experience, be careful because unsustainable work habits don't go away.
I've found it an incredibly hard behavior to manage with no good outcomes. People acting in good faith just need to align on the allowed variance and the issue's done.
I've been doing interviews with Series B-D startups and one issue that seems to recur is a lack of management experience. Generally, an engineer gets promoted to some level of management, but never learns how to manage. Hard conversations aren't happening, feedback isn't constructive, and the people aspect is left to fend for itself. That's all on top of standard organization challenges like...
My first 2 years of managing was hands on, probably 50% coding. I had a small scope and the energy to do people things while also doing coding things. What I found was that this doesn't scale and that if I ever wanted to lead larger initiatives and have a bigger impact, I'd need to give up coding. During this period, I burnt out trying to grow both technically and managerially. The context switching required of me was too much.
When I got to a position where I could do people management 100% of the time, it was transformative. In the same way we think about coding - what skills do I need to develop, how can I optimize XYZ, is there a better pattern for this, etc - I now started to think about management. Part of this is that I joined an org that truly valued management and was able to be mentored and allowed to develop my skills.
Now as a director, I insist that my new managers don't code. There is a period of time where you need to focus on management and nothing else. Later on, I don't care if you want to get into the code, but at that point, no one chooses to.
It does seem like the industry is split on where a manager title exists and if you're hands on. Regardless of which way you go, you'll find career growth imo. I would consider if you feel like you're being the best manager you can be though.
It kinda sounds like you're saying that the work isn't organized. That people just jump in and tackle problems as they come up.
"Hey, I feel like I'm doing a lot, I want to do more, and I'd like to make more money. Can we talk about it?"
Prepare what you feel is a reasonable title/salary and any documentation you can give on that. From what you have written, I'd ask for Lead Engineer and see if you can find a salary range online. You could even suggest that your boss asks the bigger company what their pay range for the title would be. Also, this needs to be a realistic number. Don't look at Google salaries and expect to match.
The worst way to approach it is a "I want X, give it to me". If you want to put more pressure on it, mention the LinkedIn offers you're getting - "Hey, recruiters keep reaching out to me on LinkedIn and the salaries are pretty high. I really want to stay, can we talk?"
The big take away needs to be the value you have brought to the team and will continue to bring.
There's only a few times I've ever straight denied a request like this. 1) We just did raises and they want more, but don't deserve it. 2) They were at the company for <6 months and their current pay was above the median. Especially when your responsibilities have grown, this should be an easy conversation. The hard part will be getting a good number.
Best of luck.
Before, one person would receive and coordinate work among the team - the tech lead. After, we had a rotating roster of people who were interested in solving problems that would act as a tech lead. This was in coordination with our Product org.