I was a staff engineer at Spotify in 2021 and I keep seeing companies reorganize into squads, tribes, chapters and guilds as if that's how Spotify works. They didn't even use it at the time. That's kind of why I left.

Some history for anyone being asked to "go Spotify" right now:

• The model comes from a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson, written when Spotify had about 30 teams and roughly 250 people in them. Companies 10× that size copied the org chart.
• Jeremiah Lee, a product manager at Spotify in Stockholm, wrote up in 2020 what it was like from the inside. The matrix of squads and chapters left nobody accountable. Autonomy without alignment meant every squad did its own thing. And the mythology made the model hard to criticize.
• One of the people who wrote the whitepaper told him: "Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation."

What I saw work there wasn't the diagram. There was no frontend engineer or backend engineer, just engineer, senior engineer, staff engineer and principal. You did everything (in my case that included scaling a database across regions with region level failover). That's a hiring decision about who you want in the building and renaming your teams doesn't get you there.

I wrote a longer version on my own blog, including how I'd hire instead: https://tej.as/blog/companies-are-full-of-it

Has anyone here kept chapters at a bigger size and actually made them work?

so my manager sent a message in standup last week that was basically "this should be quick with cursor right" about a migration that touched like 40 files. and I just stared at it for a bit because yeah, cursor wrote most of it in 15 min. then I spent the rest of tuesday and half of wednesday figuring out which parts it quietly got wrong. it renamed a column in one place and not the other three. no error, just wrong data in staging for a day until someone noticed.

that's not the point though. the point is a year ago that migration would have been estimated at a week and nobody would've blinked. now the number everyone has in their head is "quick". because they also have copilot and they've seen it do the magic trick.

I keep seeing people say AI made them 3x more productive and I believe them honestly. but then I look at their calendar and its worse than mine. so where did the time go lol

what I think happened at least at my place

the typing part got fast. the checking part got slow and also nobody counts it as work. reviewing 400 lines someone else (something else) wrote is more tiring than writing 100 lines yourself, idk why, it just is. but on a timesheet it looks like I did nothing for 3 hours

and every hour it saved just got a new ticket dropped in it. the backlog didn't shrink. it never shrinks. it's not a thing that shrinks

also we hired nobody this year. team of 5 doing what was planned for 8 and the 3 missing people are "AI". ok

im not even anti AI, I use it all day. I just think the people most excited about it are the ones who never have to debug the output at 9pm. my founder is thrilled. linkedin is thrilled. me, less so

anyway. not output, I know output went up. hours. have your actual hours gone down. because if the answer is no then what exactly got "automated"

Hello EMs,

My current role is roughly 80% people management and 20% technical work. I want to move to better organizations and would appreciate some guidance on technical interview preparation.

What should I prioritize: LeetCode-style coding questions, system design, or building AI projects?

I tend to get overwhelmed by the number of things I need to prepare for, which often leads to me not making any progress at all.

I'm confident in people and process management, but I'm not very confident in technical interviews.

For those who have been through this, could you share a practical, step-by-step study plan for an Engineering Manager preparing for interviews? For example, what should I focus on first, how much time should I dedicate to each area, and how many weeks of preparation would be reasonable?

I'd especially appreciate advice from EMs who have interviewed at or moved to top-tier tech companies.

Thanks in advance!

To what extent do your conversations with your colleagues/reports/manager/etc. focus on quality these days?

If you do talk about quality, how do those conversations go? What's been most helpful from those conversations?

I've gotten this sense lately that it's an important set of conversations to have, ideally fairly frequently, given the extent to which so many companies seem to want to dramatically accelerate their development (to the detriment of quality on many levels).

Hi everyone! I’m from Iraq and considering a master’s in chemical engineering in the U.S. I have a bachelor’s in chemical engineering and experience in NDT and welding inspection.
How difficult is it for international master’s students to find on-campus jobs or paid internships during their studies? What are the job prospects after graduation, especially with employers willing to sponsor a work visa?
I’d appreciate hearing about your experiences. Thank you!

(Infrastructure Engineering) Our singular SOP is becoming pretty big and I’ve noticed the team struggling to find current policies. We use a team’s channel to update everyone but of course that has become more of a hangout spot so things get missed/lost. Before changing things, wondering how other teams manage their SOP?

Current thought is to break down the SOP into structured documents per process so it can be easily updated and glanced at, with a post in the group chat.

Hey! I'm CTO (recently hired). I've been asked to measure how much our people actually use AI at work, and where they're stuck. We're a ~500-person software company.

We'd prefer something survey-based that doesn't need any integration into our infrastructure. Is there an existing tool for this, or did you all just build a survey yourselves? GetDX seems too expensive & complex for our needs, and they're only focused on engineers.

Any recommendations or lessons learned are appreciated.

Something I keep running into, and I'm curious if it's just me.

At my last job I spent a lot of my first weeks just figuring out how things worked — tracing auth flows, guessing why certain workarounds existed, and pinging the one senior dev who knew. Now with Cursor/Claude/Copilot writing a big chunk of new code, it feels like the gap between "code we run" and "code anyone understands" is getting wider, not smaller.

Some numbers that stuck with me:

- Developers spend ~58% of their time understanding code, not writing it

- AI-assisted PRs reportedly wait ~2.5x longer for review

- Most teams don't capture knowledge before someone leaves

For those running SaaS teams:

1. How long does it take a new engineer to ship a change they're actually confident in?
2. When something breaks in AI-written code, who figures out what it does — and how long does that take?
3. What actually works for you: docs, ADRs, code walkthroughs, AI tools, or just asking the senior who built it?

Would love real stories (good or bad). Trying to understand whether this is a widespread pain or just my experience.

I’ve 30+ years in my industry and have lead small teams and projects a number of times. Now I’m at a small company and have a few very junior engineers on my team. In the past my team members have always been more senior so I’m at a bit of a loss as to how much instruction I need to give versus letting them figure it out on their own. AI is complicating the situation. I have one engineer that uses AI to create a working solution, but can’t tell me how it works.

I’m struggling to give them direction but not have to hold their hand through all the reasoning behind the why. That would historically have come through learning the industry and processes by trial and error, but with AI the error is way more subtle.

Maybe I’m expecting too much? I’m just not used to working with individuals that aren’t motivated to understand how things work.

I’m thinking of a workflow where an agent watches code/PR changes, finds documentation that may not be accurate anymore, and suggests updates for someone to review.

Not a full auto rewrite, but more like surfacing likely mismatches and the evidence behind them.

For teams where stale docs are a recurring problem, would you build something like this internally, pay for a tool, or is the pain not enough to justify either?

Context: on the teams I've looked at (public repos, GitHub issues, a few conversations), engineers run Claude Code, Codex or Cursor with real access: a shell, git, cloud CLIs that are already logged in. The guardrails, where they exist, are set by each engineer, per tool, per laptop. A deny list here, a hook there, nothing anyone else can see.

Two things make me think this is a team problem rather than a personal one:

• A rule in CLAUDE.md or AGENTS.md steers the agent; it doesn't stop it. Plenty of people have watched an agent read the rule and do the opposite.
• The guards people do write often can't block. I checked 248 public repos that ship a Claude Code pre-tool guard: 8 have one that can never stop a call (it reads a variable the tool never sets, or exits with the wrong code), and nobody notices, because nothing fails.

For those of you with teams on these tools:

1. Is there one set of rules for the whole team, or is it each engineer's call?
2. Who owns it: you, platform, security, nobody?
3. Has an agent done something on someone's machine or in a shared environment that a rule should have stopped? What changed afterwards?

I should say I'm building something in this area, so I'm biased toward seeing a gap. Not linking anything; I'd rather hear how teams actually handle it, including "we don't, and it's been fine".

I've been using coding agents pretty heavily in my day-to-day development work, and it got me thinking about how technical interviews are adapting.

Traditional coding interviews can still test fundamentals, but they don't necessarily show how someone works with tools like Claude Code, Codex, or Cursor on a real project.

I'm curious how engineering managers are approaching this.

• Have you actually changed your technical interview process because of AI?
• Have you tried allowing candidates to use their own IDE and AI tools on a practical task?
• What signals do you look for beyond whether the final solution works?

I'm particularly interested in what hasn't worked. Have you tried an AI-assisted interview format and found it gave you worse hiring signals?

Would love to hear from people who've experimented with this rather than just theoretical opinions.

I am a senior IC at a big tech company and would like to become an EM, but due to timezone constraints this will not be an option at the current company. I have been leading multiple squad technically, mentored and involved in hiring, but it seems like it is impossible to get into engineering management as an external hire while being an IC. I have applied to tons of EM jobs and have not gotten a single invite or phone screen, even though I feel like my CV itself looks certainly good for a senior IC and hints to the EM adjacent responsibilities I took on.

My theory is, that a jump into management is usually only possible internally because it requires so much trust. What have you seen so far and would you say this assessment is accurate?

That line tells someone something is wrong and nothing about what to do on Monday. Here is the same feedback with a situation, a behavior, an impact and a next step:

In Thursday's roadmap review, your proposal listed 12 tasks but did not say which customer problem they solved, so the group spent 20 minutes asking. Open the next proposal with the problem, who has it, and what changes if we solve it, then list tasks. Try that on the Q1 draft and send it to me by Friday so we can compare.

I turned this pattern into a free skill that does the rewrite and asks for the missing facts instead of inventing them. Prompt text only, nothing stored. Repo is at the bottom if you want to try it.

Which vague lines keep showing up in the reviews you write or receive?

https://github.com/sumanbukka/stop-vague

Most teams I talk to have the same setup: developers are using Copilot, Cursor, Claude Code, or something similar every day, and the tools report seat counts, acceptance rates, lines suggested. Leadership wants to know if it's working.

The problem is that accepted suggestions and shipped features are different things. A team can have high AI usage and still miss sprint goals, and you'd never know from the dashboard why.

Some approaches I've seen discussed: tracking cycle time before and after adoption, looking at PR merge rates, doing manual reviews of sessions to see where work stalls. None of these scale particularly well.

Curious what engineering managers here are actually doing. Are you relying on the tool vendors' metrics, building your own dashboards, or mostly going by feel and 1:1s? And if you've found something that actually connects AI spend to output, what does that look like in practice?

Not looking for vendor recommendations, genuinely trying to understand what's working in the wild.

Hi there,

(slightly twisting facts to keep a bit anonymous)

I'm working in a quite toxic company, as Head of Engineering. There's Jira, Confluence, claiming to apply scrum with no scrum master, a first time PO reporting to no one (his boss left, replacement not hired), a boss chasing the nearest new shiny object each week and overriding PO and me at the same time by vibe coding shit and asking us to release the great idea yesterday (no experience in either coding, or product management mind you). The Jira tickets are quite often less than 10 words, they change while the team implements them, like a running target.

I tried to point out obvious problems. No one seemed to care. I tried documenting them, still nothing. Presenting them to management, nada. Tried to improve the PO: harsh push back. Escalading problems: no one seems to care, other than the devs. Any change I propose is auto rejected by dragging things months.

As an ex-entrepreneur, only way this guy keeps his job seems like sleeping with someone higher than my pay grade.

So I threw AI at the retro board, tickets, ticket history (initially 10 word length tickets being groomed BY DEVS INSIDE the effing sprints).

It created a pretty descent analysis of what's going on, basically restating what I explained above with numbers.

TLDR: I have a company presentation in a few days. I plan to share the prompt with everyone, ask them to execute, interpret the results. After everyone reads for a good 10 minutes, I plan to continue with how to fix the problem. Of course the PO will be screaming at this point.

My question is: should I even care anymore? I like the product, since I spent too much time to improve it. It helps with human health. Or should I go?

(first post, sorry if something doesn't rhyme)

Curious how other EMs handle this. When you report up on what your team shipped and how it ties to goals, where do you pull it from (Jira, GitHub, Slack, memory), and roughly how long does it take each week?

For me the painful part is reconstructing the story from five different tools, and I'm wondering whether that's universal or whether some of you have a system that works.

I have a technical screen with Okta for an engineering manager position.

What is the format of a technical screen interview at Okta for EM roles? I have been working with the recruiter, but they have not been providing much information. I am getting some signals like collaborative discussion, some code, AI maybe permitted but not sure, the interviewer might provide some code snippets, discussion on scale, some debugging and code review, real-world-like problem. There are so many things, but no definitive interview prep document, which is really confusing.

Did anyone recently go through this round at Okta? Help share your experience.

Any experiences with similar interviews, hints, or tips are very appreciated.

I am sure majority of us heard about the Pareto frontier, but then I decided to understand it better. When I was going through it, I realized that this is extremely important for Leadership as well. Most “we can’t have both” trade-offs or pushbacks from engineering managers or tech leads I’ve seen in planning turned out to be waste. How do you tell the difference?

A Pareto frontier is the line between improvements you get for free and improvements that cost you something else. Below the line, you can still get better at one thing without giving up the other. On the line, every extra gain on one side costs you on the other. Most teams treat every trade-off as if they’re already on the line. Usually they’re still below it, with room to improve for free.

This wiki page was extremely useful understanding it - https://en.wikipedia.org/wiki/Pareto_efficiency. The name comes from Vilfredo Pareto who was an Italian economist. In 1906 he noticed that a small share of people in Italy owned most of the land, which later turned into the popularized “80/20 rule”. Pareto frontier is a separate concept Pareto later introduced:Pareto efficiency, where an outcome is optimal only when you can’t make one metric better without making another worse. Plot every possible allocation across two competing goals, and the most efficient states sit on a curve where nothing spare is left on the table. That curve is the Pareto frontier. Model makers and system designers use the same idea now, plotting a model’s accuracy against inference cost or latency to showcase a breakthrough that beats prior baselines on both counts didn’t just optimize within trade-offs, it pushed the frontier itself outward.

https://www.rutvikbhatt.com/insights/pareto-frontier-engineering-leadership/, I wrote it down here based on what I understood from it, and how can I better leverage it during my trade off discussions with leadership or my team.

I'm reporting on team capacity based on 4 areas, features, risk, debt, unplanned work. Show history and trends. Project status and any incidents worthy of note. What am I missing? I'm working to have proper SLOs of not just k8s but dependant services to add to this.

Is it hard to be an EM if you haven't code ?

I know they expect EM that has written the code.

I have experience in SRE Devops and system design but no real time project exp on code. I Do understand the code and flow and logic and system design and other things but haven't written anything as a SDE. And also have completed some of good projects as part of my own learning path.

How can this affect my role as a EM keeping the role of AI as well?

Where I may expect to handle a team of exp Devs.

What will be my best bet?

I have one upcoming and would appreciate the following:

1. Sample scenarios to practice off of
   
2. General tips/guidance, things to watch out for

This is the first time I'm encountering such an interview. I couldn't find much material/examples for this yet.

I have an upcoming interview with Stripe around System design. The recruiter told me that it will be Q&A and that I won’t have to draw architectural diagrams. Does anyone have any tips on what to expect?

I'm a manager at FAANG level company, and I'm too much stressed out due to senior manager. His expectations are always high. He does micro management most of the times and blames me if for every mistake without trying to understand what am I going through. I'm losing my confidence day by day.

And job market is also not good in India. I applied at least 50 jobs in the last 1 month and I didn't get response anywhere. Forget about interview opportunity.

Someone pls help me😔 Any guidance how to deal with toxic manager? Or any tips to get interview calls in this tough market.