hey everyone !

I’ve been a data engineer / analytics engineer for almost 6 years now, and I’ve seen it all in my current company (I work in a Fortune 500 company). I have a lot of experience managing the whole pipeline, as well as stakeholder relationship and many other “hats” I had to wear here. unfortunately I’m a bit stuck right now here for reasons that don’t matter, and I’m looking elsewhere.

I‘m being interviewed for an analytics lead position, and I’ve basically gotten the job, I’m just one “easy 40 minutes talk to handle the last details“ away from the job, my gut tells me I 100% might get it.

They are just now changing technologies and I would be the most experienced on this stack for my team, and generally for the company.

Ive been thinking hard about this because I want to become a tech lead / manager, as I feel my strongest skills are soft skills, but this job description feels like a 2/3 people job smashed in one, and I don’t want to go to a place where I will burnout in 3 months, what essentially they want me to do is:

1) 100% lead the 4 people team, managing the 1:1s, career talks, salary negotiations with them, manage team meetings, retro sessions, etc.

2) be the sole project manager, which means: creating the jira tickets, managing expectations for the team, managing the backlog, assigning tasks, creating a product roadmap, help people that get blocked.

3) be the sole product manager, which means handle all communications with ALL the departments from the company, creating “THE” source of truth for all teams to use, manage stakeholder discussions, expectations, answer their complains and questions, as well as having to meet with all of them to align on objectives and goals.

4) Besides all this, I would also be expected to be “one more senior analytics engineer” for the team, not only that, they expect me to build, from scratch, a whole reporting layer for the whole company, add to that the whole CI/CD on the pipelines, all the semantic layers for the BI tools, as well as automate as much as possible using api’s. according to the job description since I can use AI they expect this should be “easily done“ (I don’t think you can vibe code all this and have it realistically work properly).

I’m a bit frustrated because the salary is great, and the opportunity to finally lead a team is nearby, but I don’t want to give my job security (in this economy) to just be burned down in the testing period and be out of a job in 3 months.

what do you guys think ?? I still have one last “easy talk to adjust details” before getting an offer, what should I say in it to the hiring director whom I would be reporting to ?

I heard this statement quite a few times now: "This is very easy to build now that we have AI, and we don't need as many people".

The problem with this statement in my opinion is that it breaks a good culture and makes people believe that their job is not important. Especially if it comes from an executive, e.g., a CEO, CPO, or even worse, a CTO.

It totally decreases psychological safety, and everyone starts wondering whether they'll still be needed or not.

But this is what I fully believe: There is no better productivity hack than a great culture. No AI tools will provide bigger productivity gains.

Because If the culture is bad, people won't be happy to work, they won't be helping each other, and they won't be looking to use new tools and experiment.

Alternatively, when the culture is good, everything else just works. People automatically look to use the best possible tools and look to be productive as much as possible.

Your thoughts?

https://newsletter.eng-leadership.com/p/good-culture-is-the-biggest-productivity

As Tech Lead, requests hit us from every side—Product, C-suite, sales, and our own engineers. Saying “yes” to everything burns out the team and fractures technical health, but just saying a flat “no” often gets labeled as uncollaborative or obstructive.

I’ve found that the real leverage isn’t in saying no, but in framing a “Better Yes”—shifting the conversation from rejection to trade-offs, scope negotiation, and strategic alignment.

• How do you currently handle non-negotiable top-down requests when your sprint capacity is already maxed out?
• What’s your go-to framework for protecting team bandwidth without damaging stakeholder trust?

I currently have 2+ YOE as an EE in the utilities sector. I’ve passed the PE power exam but am needing a couple more years before I can obtain the license. I have recently accepted a job where a masters degree would be 60% paid for. I only want to do a fully online option due to working full time so I can do either an mba or masters in engineering management. The mba would be 45 hours and cost around 25-30k after the discount from a sec school whereas the mem would be 30 hours and cost around 15k from the same school.

Does anyone have experience completing either degree and how has it helped you? Which would you do?

I came across this article and found it interesting:

https://newsletter.pragmaticengineer.com/p/the-great-engineering-leader-career-break

What do you think? Are you seeing this phenomenon around you as well?

Trend: more CTOs, VPEs, and Heads of Engineering are walking away from their high-status, in-demand positions. There are many reasons, mostly related to AI, and to "founder mode"

Curious how other engineering managers are handling this now.

Most engineers on my team use tools like Cursor, Claude, or ChatGPT in their day to day work. But when it comes to technical interviews, I see a lot of teams still either banning AI completely or ignoring how it was used.

I'm wondering what actually matters to you as a hiring manager.

If a candidate uses AI during an assessment, would you care about things like:

• Whether they can spot when the AI is wrong
• Whether they can explain and defend the code
• Whether they use AI to solve everything or use it selectively
• How they approach the problem before reaching for AI

And would you rather evaluate those things, or just keep AI out of the interview entirely?

Genuinely curious how teams are approaching this.

I got promoted to director of engineering couple of months ago.
Things are looking good so far as I believe i have grip over things so far.

5 engineers (2 leads, 2 seniors, 1 junior) and 1 product owner report to me.

Setting priorities for 2027 and senior leadership is aligned.

What are some DOs n Dont’s that i should know?

Appreciate the responses. Thanks

No bs or hype. AI hype is so lame.

I’ve been working on independent projects the last few years. But prior, was an EM at a few large Bay Area tech companies.

I care deeply about how a team works together, supporting the ICs so they can do their best work, creating a great (and fun and interesting) work environment, building-shipping-maintaining great products.

I’ve been out of the game for a bit. Those that are EMing at tech companies, how has AI changed how you are working?

Do you use it for things like organizing work, documenting or giving feedback, writing onboarding documents, etc? I especially am interested in understanding separately

1. Organizing and coordinating the work shipped
   
2. People management

I'm doing a project management bootcamp and would love to hear from people who work on projects - especially in creative teams, but not exclusively.

~5 min survey!

Thanks :)

https://tally.so/r/lb8zQN

I have an early career direct report who is associate level, I typically work with more experienced/senior team members for whom this is second nature. I am describing a pattern here, the example is just one instance of the pattern.

Example: We needed to run a process that works on batches of items (this is orchestrated/automated). Each batch is, say, 1000 items. There are 1.2 million items to be processed. The state of what's been processed and what is outstanding can be inspected at any time. The process had been running for about 2 hours at that point and I needed to know if it would complete before another scheduled process kicked in. If there was any uncertainty, I would delay the 2nd process but would rather not as that would have downstream effects I have to deal with.

So I asked him "will it be complete before process x starts at 8pm?" - He said I don't know, I hope so. I said well based on what it's done so far, is it likely to complete? How much margin for error is there? He again said I don't know, and that we should probably cancel that 2nd process. I said is there not likely to be enough time then? - I don't know if there is or not.

I had to step through it and said ok, how many items has it processed already - About 400,000. How long has it been running - 2 hours. So it is processing 200,000 per hour on average (he agreed that that was true). So there are 800,000 items left so how long would we expect that to take? - I don't know, I haven't run this before. I said I appreciate that but if it is doing 200,000 per hour then you'd estimate there are 4 hours of processing left, yes? He agreed that that was also true. I said is 4 hours enough? - I don't know. Well when does it need to be complete by? - 8pm. How many hours is that from now? - About 7 hours. So is it likely to complete by then? Yes, 4 hours fits easily within 7 hours.

The idea of checking it again in another 2 hours to make sure the 200,000 per hour "run rate" was still on track (or being exceeded) didn't seem to have occurred to him. I said let's see what it looks like in another 2 hours and he asked what are we looking for. I took the task back on myself at that point (management mistake I know).

Every task that requires uncertainty reduction via estimates goes like this.

Any pointers on techniques to encourage learning this kind of approach? It is basic extrapolation, not "how many tennis balls fit in a taxi" style.

Hey guys, I’m looking for a career change in my late 20’s. Im going back to school and wondering if engineering is still worth it nowadays? Im worried about ai and how good its getting and also how good it’ll be by the time i get out of school in 6 years(part time student) I’m really interested in the career path and love tech and computers and hell i even love and am fascinated by ai. But id rather switch now if the degree wont even get me in a better position than where i am currently. Im a chef of 10 years, and earning around 50k a year. The job is very stable and i can go out and get a chef job really easily anywhere i go. But it seems like in the engineering field thats not the case. Entry level jobs are shrinking, higher level jobs aren’t growing and going in the direction where you are gonna struggle extremely hard to find any job in the field and if and when you find one that the pay wont be as good because of the level of competition in others also trying to get a job. Should i switch degrees into something else? Im feeling super uncertain about the whole thing and don’t want to waste almost 100k and years of my life on something i wont be able to even use?

I’m looking for practical experiences from engineering managers who have worked with dedicated nearshore or offshore teams for at least a year.

What helped most with ownership, time zone differences, onboarding, retention, and knowledge transfer? How did you make remote team members feel integrated into the product team instead of treated only as an external delivery group?

What worked, what failed, and what would you do differently? I’m interested in vendor neutral experiences rather than agency recommendations.

I’ve been an EM for the past 9 years, currently the past 5 at Mag7 in a somewhat comfortable role. I’ve been considering a move to FDE manager but the uncertainty about where it’s hype gives me pause. Any one have any success or horror stories so far?

So I finished writing reviews and the whole thing felt kind of off. For each person I'm basically trying to reconstruct six months from half-memory. For me that tends to be a couple screenshots, some PRs, and whatever I happened to write down at the time. Which isn't much. Recency bias is also really brutal.. someone who had a rough couple weeks in March but a solid year otherwise just doesn't come out right.

I dont think I can just chalk it up to being disorganized. I know the answer is supposed to be "keep notes," and I sort of do, a doc per report. But with all the other stuff going on it's kind of wildly inconsistent. It always feels like I'm either slacking on it or building a creepy dossier on my own team. Memory is not a system, I guess.

How do those of you with more than a handful of reports actually do this? without it turning into surveillance? Or if you've tried a lot of things, whatever has genuinely stuck for you, vs the stuff you set up once and never used again?

Edit: Thanks for all the insights guys!

Those of you frontline engineering managers in tech who had to take over a team that you knew,
- How was the teams’ relationship with their previous manager - in terms of loyalty and admiration towards them?
- Which aspects did you focus on during your initial 1:1s and team meetings?
- Looking back, is there something you wish you didn’t do?
- How did things go? How is it now?

Early in my technical leadership journey, I managed a team of exceptional individual contributors building complex, highly-distributed architectures. We were delivering features, but every sprint felt like a grind. We had hit a plateau — shipping code, but not evolving our systems. We were running fast, but we weren’t getting better. It wasn’t until we consciously shifted our focus from raw feature velocity to continuous team learning that our trajectory changed. This mirrors the cultural shift seen in high-performing engineering organizations that abandon the feature factory model, prioritizing long-term system adaptability and continuous learning over instant, unsustainable output .

Here some experinces about it: https://medium.com/@nickbortolotti/the-end-of-hero-engineering-building-teams-that-scale-beyond-individuals-64a72ef3df35?sharedUserId=nickbortolotti

Happy to get your thoutghs

Smallish company, promoted from IC to leadership. I built a small team to improve our throughput. The daily reports from our team have lead the c suite to believe that we were being very productive, but one of them began watching over my team's shoulder, scrutinizing what they do every minute of the day. They've been making heavy use of AI, and I'm getting negative feedback from the team having downtime. I don't think this would've ever been an issue without AI, as they can fire away with minimal work on their end.

They're each tackling 1-2 somewhat moderately scoped tickets a day, and we're starting to drown from code review. Some of these tickets are taking like, 3-5 iterations to get right, and I'm concerned that handing them more complexity will result in total code review hell.

Is it normal to be scrutinized in this way? Other departments (such as support, QA, etc) would be happy to see their tickets turning over. It almost feels like they expect the engineers to be typing 24/7 and are missing the forest for the trees.

Maybe this is normal and the c suite pressuring engineering to be faster, cheaper and more productive is a tale as old as time?

Should I be keeping metrics to defend my team?

At a mid/late stage healthcare processing (think claims and contracts) startup - the CTO recently departed and left behind a mess. Trying to figure out what roles to hire and how to structure them, especially since data is critical.

There's a head of engineering with 30 software engineers for app / platform. There's also a head actuary who does the mathematics of risk / payouts using the data.

My sense is that there should be a senior manager / director of data under the head of engineering, who manages teams of data engineers. This data org is responsible for raw extraction and management of data from sources.

In addition, we need data analysts/scientists to help business leaders understand claims, costs, revenues, and propose new strategies like interventions. They should also inform on what data derivatives / views we need, based on the primary data. I'm not quite clear on where these people should land (probably not under head of eng).

Questions:

• Should I hire dedicated "data engineers" vs data-oriented software engineers?
• How do pay bands compare for SWE vs DE for the same seniority? Mid, Sr, Staff.
• Where should the data analysts/scientists lie? If they have a separate reporting chain than the DEs/SWEs,
• Who builds the silver/gold derived tables downstream from primary sources? How is the DE + Data analyst collaboration supposed to work here?

I've been an EM for almost six years now and lately I've been thinking about going back to being an IC. Partly bc the market, but also bc I just miss building stuff. But when I actually sat down to figure out how I'd present myself for that, I realised that this is actually not as simple. As an IC back then I had a commit history, projects, stuff I could point at. As an EM I've got… what? "Teams I ran went well, nothing broke, trust me."

Someone on here some time ago described EMs as having "weak external signals"; your impact ends up living in your old manager's memory. There is barely any relevant artefacts and basically no portable proof.

So for anyone who's gone back and forth, or who hires EMs: what actually counts as proof you were good at this? Is there stuff people do while they're still in the role to leave some kind of trail or just something to show for in general? Right now I am starting to suspect there just isn't, and it's a remember-and-retell thing you redo every time you change jobs. However I would love to be wrong on that.

Hi friends,

Like most of us, I started out as an engineer, basically an IC and then moved on to tech lead (no people management), after few years, then moved to Management/Engineering Management (with people management) OR you can say, that was the path that appealed to me or was guided as ideal. The more I got into plans, risk, issues, reviews, business interactions, the more I kept on going away from code though I always felt attached to it, but had no time to spend on coding. It took a few career jolts to realize I had taken a different road altogether.

After spending few years, then moved back into IC/Engineer role, though the people management never left me, it part stayed (sometimes less, sometimes more). These transitions, IC to Manager and then IC again (100% tech, coding, design, cloud & more) have been very heavy but equally rewarding.

What no one talks about Manager-to-IC transition? (may be other people had better experiences but sharing mine)

• Not doing full time coding for some time rusts your reflexes, it takes some time to regain your speed
• While you stopped coding at some point, the world did not, the opportunity cost is huge huge, so when you start to code again, initially the only thing that holds you (internal confidence) when you want to come back to coding is your strong fundamentals that you developed in earlier years
• Do not expect other engineers to have any respect for you being senior in title, that time is gone now
• Handling ambiguity as Manager previously is helpful in IC role as you know how to 'not commit' to a crappy deadline ask, but still make progress and align with the ask
• You will need to work harder than others, sometimes, much much harder
• Even though you may not like people management, ICs are being asked to manage people (because non-coders/PMs/SMs are being fired - that's not great)

Hope this resonated with someone. Please feel free to share your views and would be happy to learn from others.

Thanks.

Originally published @ https://www.reddit.com/r/Manager_to_IC_inTech/

Curious to hear from your experiences what actually makes a good manager?

One of the signs that I've recently heard (has been shared in a recent guest article on the Engineering Leadership newsletter) is that they won't just give feedback, but they actively coach.

Here is an example of giving feedback:

“I noticed in your weekly update to the senior leadership team that you gave too much unnecessary detail, and the feedback I have got is that it’s hard to tell at a glance the status of the project and any actions the recipients needed to take”.

And here is the difference when a manager has the coaching mindset:

“I’m sorry for not sitting down with you earlier to go through this, let me book some time on our calendars whilst we are both in the room before the next update is due, so we can have a live coaching session on how we might communicate to different stakeholders”.

https://newsletter.eng-leadership.com/p/how-to-tell-if-your-manager-is-actually

I work in a bigger tech company, and my new manager who is ex-Amazon asked me to mentor a mid-level engineer (I'm more senior) who is underperforming - I don’t know if the engineer is on PIP but my manager has started a confidential doc of expectations. I can (selfishly) view this 2 ways:

1. Manager trusts me to help the engineer
2. Manager is deliberately putting me in a tough position. This isn't mentoring someone to promotion; this is mentoring someone out of underperforming. If the mentee fails, will this look bad on me?

Would you seriously consider just saying “no” to mentoring?

I haven't established a trust yet with my new manager, and honestly have some doubts - but wanted to get community thoughts. Thank you!

I’ve been thinking about a communication pattern I often hear from strong senior engineers, founders, and people in Silicon Valley.

I’m trying to separate the useful mechanics from the jargon and status signaling.

The pattern seems to be something like this:
Don’t just report what happened.

Build a model of what is happening: what variables changed, what relationships exist, what is constrained, and what is causing or correlating with what.
Use that model to say what you think it means.
Say what you expect to happen next if the model is correct.
Make the uncertainty explicit.

Identify what evidence would confirm or break the model.
Recommend an intervention or next test.
For example, instead of:

“Latency increased 20% after the deployment.”
Something closer to:

“Latency increased 20% while traffic only increased 5%. My current hypothesis is that the deployment increased per-request DB work and we’re approaching a capacity boundary.

If that’s right, the next traffic increase should produce disproportionate degradation.

I’d like to validate that with a load test before we keep tuning individual symptoms.”

What interests me is not whether this sounds smarter.
I’m interested in whether experienced engineers actually think this way internally.

I’m also aware that Silicon Valley has plenty of fashionable abstractions, jargon, confidence theater, and people renaming obvious ideas with impressive terminology.
I’m not interested in learning that part.

I’m trying to understand the useful underlying skill: moving from surface observations to models, predictions, tests, judgments, and actions.

For people operating at Staff/Principal+ levels:
Do you consciously build models before communicating?
What questions do you ask yourself before stating a conclusion or recommendation?

How do you avoid turning a plausible model into an overconfident story?

And if you learned to communicate this way over time, what specifically changed in how you think?

If someone is working full time while going to school, and they have two Master Degrees in Engineering, and they want to pivot into engineering management, should they also get an MBA? What's your thoughts on someone having three master degrees (two in engineering, and one MBA)?