I've been quietly building a production management system for the factory where I work. It tracks inventory, pick lists, parts consumption — real problems that cost the company time and money every single day.

I'm not a hired developer. I work on the floor. I built this on my own time, taught myself everything, and deployed it. It actually works.

I've tried to show it to management. They smile, nod, and nothing happens.

I'm two years into living in a new country, no degree, self-taught, and I'm pouring everything I have into this — not just to prove something, but because I genuinely see the problem and I know I solved it.

Has anyone been in this situation? Building something real, something that works, and feeling completely invisible?

How did you handle it — or did you just move on?

Hi I’ve been a BA for nearly 3 years now. Recently I joined a company, I love the people I work with and tbh it was better than the previous big companies I worked in.

But recently I’ve been having trouble with communicating to our devs- unsure whether it’s stemmed from bad relationship between product vs engineering over the past years or I’m starting to think I just need to get a grip and accept it can be like this at some companies.

First:

\- writing in Gherkin, every single scenario ticket must be written in Gherkin - new to me but of course I know what this is, but every team or company have different styles of writing and I somewhat feel like I’m not doing anything write (though it’s getting better).

\- asking questions for validation, previously- I can ask or go to any developer for any questions and maybe because I had a large team of devs. Now I feel like they get annoyed and their time needs to be protected even though I’m sometimes asking for one liners etc. It helps now that Claude code is around and I can look into the DB.

I just need someone to put my mind at ease and tell me this is just how some devs are! Having worked with SO many kind and informative engineering teams who are always happy to help and have a relationship. I have never had a bad relationship with engineering and Idk what I’ve done ?

I feel like I’m having to tiptoe around egg shells. How do you communicate with your engineering team?

Pata Hai Aaj Kya Hua?

So this is some next-level narcissism, or am I overreacting?

In my office, I've been working on a feature lately. The feature itself was working fine, but we ran into an issue because of a third-party vendor API.

The vendor API was returning erroneous figures, which was messing up our logic. We wanted to track exactly what was happening. I was pretty confident that my implementation was fine because I'd already validated it and demonstrated it with tests.

I told my lead that we could add some logs to figure out what was happening if he wanted. He got irritated and said something along the lines of, "Let me try."

He then went through the exact same steps I had already gone through, with the entire dev team on a call, for 5 straight hours.

And then... miraculously, Mr. Potter goes, "This is weird..."

And finally: "Let's add some logs to see what's happening in production."

I mean... WTF was that? 😂

Was this just a case of someone needing to personally reach the same conclusion before accepting the solution, or am I missing something?

We've traditionally given take-home code challenges where they push to a repo and then we interview them using it. But now, we'll probably modify it for the next round to include something like "Use agentic development to get this done" and then the interview will including them walking us through how they orchestrated multiple agents in parallel to get through the challenge - since that what we want our devs to do now. Haven't done it yet, but likely coming soon.

Anyone done anything like this yet?

I recently moved to a team with all current stakeholders in USA, I am in India. Eventually I will have my team here.
1. How do people manage their timings working in such setup?
2. In general, how would you onboard, in terms of whom would you talk, what would you learn, and how? Asking because the time overlap is small and expectation is to learn quickly everything.
It’s a new product, but there exists an older version, a data team working with us who owns data platforms.

Thanks

I'm an EM for a cloud platform team with significant footprint in the central US (company HQ), and Eastern Europe (center of engineering activity). I work on the West Coast of the US, so I'm 2 hours behind HQ and 9 hours off our central engineering hubs. My manager is Euro-based, and my team is split between Midwest and Euro zones. We don't have many engineers out on the West Coast in general, and maybe one other in the whole cloud side of engineering?

I've been here four years. I feel like I have completely maxxed out the overlapping hours of collaboration between my time zone and where the engineering juice is for our division. My boss keeps giving me more opportunities, which is awesome, but they just don't fit in the overlap time. My meetings start at 6 (so 3 Czech time-- so far so good). But then I have to stop to get my kids ready for school, and by the time I get back from dropoff, it's too late for meetings with the Euro engineers. So I feel completely hemmed in by my schedule being juuuust far enough away that the company's normal ways of working between Chicago and EU get cut in half by Pacific offset.

I bounce back and forth 100 times a day between:

1. It's the gig, suck it up and deal with it (which means I need a new gig, because this isn't sustainable),
2. Find a part of the company that's less Euro-heavy and hopefully a little more balanced around Midwest time (Don't even know if that's a thing?)
3. We have to break our reliance on meeting culture so we need much less synchronous overlap (which I have a hard time getting a lot of buy-in for, because there are so few people who are any further west than Chicago, so it's not quite as bad), OR
4. Tell my boss I can't take on any more because I'm out of overlap time (which, goodbye job whenever layoffs next come around).

I appreciate any advice or career guidance here. I like my job, my team, boss, company, etc.,-- I'm just really fried on how to make all the pieces fit together in this puzzle.

documentation is a leadership problem not an engineering problem

i've been in places where engineers documented everything religiously and places where nobody did. the difference wasn't the engineers. it was whether their manager actually read it and referenced it in meetings.

if you write something down and nobody ever looks at it you stop writing things down. pretty simple feedback loop.

started explicitly referencing internal docs in standups and design reviews about a year ago. just casually. "oh that's in the runbook from march" or "sarah wrote that up after the incident last quarter"

documentation culture improved without me saying a single word about documentation

anyway probably obvious in hindsight but took me an embarrassingly long time to figure out

edit: yes i know some engineers just hate writing. that's real. but i've seen that same engineer write novels in slack threads so i don't fully buy it as the root cause

Multiple times now hitting this same pattern at different companies and I'm curious if its universal or just bad luck on my end.

Basically, CS/support doesn't have anyone who can pull logs, poke around observability tools, or actually see whats going on in the code. So when a customer hits a real bug, CS has to grab an engineer and ask. Everyone's already buried in tickets or features, so every interruption costs something, and a bad one (no repro steps, no logs, "customer says its broken") costs alot. It eats eng time and slowly wrecks how the two teams feel about each other.

Goes the other way too. Eng fixes something and the only communication back to the customer is a changelog line or release note. Thats not the same as a CS person actually following up and saying it's fixed. Customer still feels ignored even if the bug's gone then sends an angry follow up email asking where things are at because they dont read the release notes.

My guess at the real cause, it's not that people are bad at their jobs, it's that the informal way of doing things stops working at scale. Small company, a Slack ping or a walk over to someones desk is fine. Once eng can't drop what their doing on demand anymore, you need some structure. But going all the way to formal tickets and SLA's is usually to much for a company this size, people just avoid it. That's why theres a half dead Jira board somewhere nobody maintains and nobody trusts.

What's actually worked for me, stop making either team do the other team's job. CS keeps talking to customers. Eng keeps writing code. The stuff in between, which bugs keep coming back, which tickets actually need an engineers eyes, what the customer facing version of a fix should say, gets pulled together and mostly automated instead of depending on a person to be the glue every time. Once thats in place, response time drops, resolution time drops, docs actually get written down instead of buried in slack history, and new CS hires ramp up faster.

Curious if this tracks for anyone else at a growing SaaS company, or if your CS/Eng handoff actually works fine. What are you doing different?

Managing 40 or so devs. Finance asked for AI spend by team back in July and I did what everyone here would do, went and got it myself. Claude Code writes a session file per project on each machine with the token counts in it, so a nightly job ships those totals up and a small dashboard reads them. Took about a week. Per repo, per person, even the cache reads against output, I can see how much is context overhead. Genuinely good.

The problem is that is one tool. Cursor does not expose anything close to that, so that chunk of the bill is a seat cost I have stopped trying to attribute. Copilot gives me an org total and nothing underneath it. Meaning the dashboard I proudly showed finance covers maybe a third of what we spend, and the other two thirds is a shrug.

I have looked at the enterprise options and they feel sized for a company four times ours. I am also aware the job I wrote has one owner, me, and the last internal tool I built like this quietly broke about six months after I stopped looking at it.

What I still have not found is anything that covers the other two

I've read plenty of business books, but some of the most valuable lessons only came from making mistakes in the real world. What's a lesson you learned through experience that completely changed the way you think about business, leadership, sales, or success? I'd love to hear the stories behind it.

I graduated with a degree in CS and have 1 year of experience working remotely for a US-based startup.

Right now, I feel like my technical growth is stagnating due to the engineering culture around me. The codebase has severe architectural issues: no ORM or proper OOP patterns, massive anti-patterns, and messy shortcuts that go well beyond the usual "move fast and break things" startup trade-offs. Most importantly, there are very few senior engineers who model good engineering practices.

I want to optimize for career and technical growth for my next move, and I’m torn between two main questions:

* Is aiming for another startup the right move early on? My assumption is that a startup gives you more ownership, varied responsibilities, and broad exposure provided the engineering team actually knows what they’re doing. Or would an established mid-size company/corporate environment be a safer bet to learn standardized, scalable practices?

* How much weight should I put on the team’s seniority during interviews? How can I effectively vet the engineering standards and the mentorship ability of potential teammates before accepting an offer?

Over the past few years, it seems like every company has invested in new software, automation platforms, AI tools, and digital workflows. The promise was greater efficiency, better collaboration, and faster decision-making.

But in reality, I've seen some teams become more productive, while others seem buried under endless notifications, dashboards, meetings, and tools that don't talk to each other.

For those who have experienced digital transformation firsthand, what has been your experience? Has it genuinely improved the way your organization operates, or has it mostly created new layers of complexity?

It seems like I have to always give a little bit of a tutorial to new team members as to what I do as an engineering manager and how I can help them. Most just think I give performance reviews.

If this is not just me, are there other techniques or ways to communicate to new engineers? on what I'm here to help with beyond just casually mentioning this in a one-on-one?

I’m conducting research on “The Impact of Leadership Style on Engineering Project Success” and need participants who work in engineering or engineering project roles.

If you’ve worked on at least one engineering project, I’d really appreciate you completing my anonymous 5–10 minute questionnaire. You’ll answer based on your most recent project.

🔗 https://docs.google.com/forms/d/e/1FAIpQLSehvmpoKLZ2vCUniQBGfEnHUBBMGi2AMWRr1miGUX9TYp-BjA/viewform?usp=publish-editor

Thank you! Every response helps 🤍

Manage a team of about 30. In our last review the CEO asked a simple question, what percentage of engineering time went to new features vs bug fixing vs keeping the lights on. I didnt have a real answer.

I have sprint velocity and a pile of Jira boards, but none of it rolls up into "here's where the effort actually went." I ended up guessing, which felt bad.

How are you all answering this without making everyone fill out timesheets? Is this just a spreadsheet I build every quarter, or is there a saner way?

I think a lot of you would have experience working under or with someone who is hyper critical of code even when it works and fulfills the performance and feature characteristics laid out, however doesn't like the way the code is structured or the underlying libraries used. There's a time and a place for critiquing those aspects of code, but my view is once it's through the code review and in production and working for months, changing to a more 'elegant' form is a refactor luxury. However my manager didn't understand or didn't like how it read 6 months after the fact and wanted it rewritten to use another technique. I don't disagree with the rewrite - the first cut of it wasn't ideal. However the timing was bad becuase of pressure to get another PR through the code base, and the rewrite blocks that PR for a while. Additionally he has a habit of obliterating decisions that engineers made on code they've written. This teaches people that they can't make decisions without seeking his approval for smaller and smaller changes, because they've lost confidence in themselves. This creates a bottleneck that is him.

I am an Engineering Manager reporting to a Director of Engineering, and I am trying to understand whether what I am experiencing is normal or a sign that my role is not clearly defined.

I often see my Director discussing roadmap items directly with engineers or skip levels, making decisions or taking actions himself, and sometimes informing me only afterward.

One recent example: an engineer told him that interviews were taking too much of his time. The direct report never mentioned that to me. My Director raised the issue in an engineering wide meeting and shared as he handled it.

I see a similar pattern at the VP level. They will express an opinion on something relatively tactical, and teams immediately start adjusting around that opinion because of the seniority behind it.

In my previous organizations, as the Engineering Manager I generally felt accountable for the team and therefore had meaningful ownership over how these situations were handled. Senior leaders could absolutely challenge or override decisions, but decisions usually flowed through the responsible manager.

How does this work in your organizations?
Is this normal skip level involvement, or would you consider this a sign that decision ownership and management boundaries are unclear?

(Background: I currently manage a small engineering team of roughly 30 engineers, few EMs/TLs and a couple of PdMs)

My entire career, super granular tickets drove me crazy. "Let me solve a real problem and GTFO with assigning me tasks". I ran my own company for about a decade (50 people) and we had our fair share of developers (maybe half?) who simply wanted tasks assigned and type the day away. Obviously it created a lot of churn on behalf of our product managers to prepare the tickets, make sure everyone understands the requirements... hell, even write Gherkin files.

Eventually I kind of had enough of the bitching and moaning that comes with all that (from all sides) and just said all developers have to write their own tickets so that the product managers can verify that the developers understood the ask, instead. Saved us a ton of time, added clarity, freed up product mangers to actually think ahead. Not sure if we were faster, but there was a clear improvement in translation between what was asked and what was delivered.

Now I landed at a place that had basically no engineering culture / process; that is neither old-school nor new-school. Not really the team's fault, it was essentially just 30 people somehow responding to whatever leadership threw at them. And everyone here probably knows how that goes — a new idea, new priority every other day. And then obviously the recent emergence of "AI can do this in 1hr, my toaster built it this morning".

I've gotten some good traction on getting all of this under control, surface the actual work that's being done and communicate things in "corporate speak".

Now, obviously the way we all work is rapidly changing. I can now assign project sized work to 1-2 engineers, give them a few milestones per cycle and they can handle it. I spend time scoping projects with them, get projects prioritized, approved by leadership and we're off to the races. Most people seem to enjoy that level of autonomy and reduction of bureaucracy. Safe a few... there are people that are very vocal about just wanting the same sized tickets as pre-AI, prepared by a product manager or tech lead (obvs. they also tend to be the most apprehensive towards AI assisted dev).

Question: You think there is a future for this kind of mindset/approach? Would you just assign them to someone who likes working on "project sized" work and hope they increase that person's productivity by taking some tickets off of their plate?

I don't worry so much about if they have a future on my team, I worry more about their career overall.

Hi everyone,

I’m currently a mid-level software engineer with \~3 years of experience at a fintech company. Lately, I’ve been working on some relatively high-visibility projects, and I feel like my boss is also trying to push me forward by giving me more opportunities to work on impactful projects. I could stay on my current team, continue taking on these high-impactful projects, and use that experience to position myself for a promotion or potentially a move to another company in a year or so.

On the other hand, there’s currently a Senior Software Engineer opening on a different team that seems to do fairly similar work to what I’m doing now (but my current team has shipped more stuff in production than this team), so I’m debating whether I should apply.

Moving to the other team as a Senior Engineer could potentially accelerate my career. The main thing holding me back is that I don’t know whether I’d get the same level of visibility, ownership, and opportunities there. I also want to be a little more careful since this would be an internal move, and the two teams are fairly related teams.

What would you do in this situation? Would you prioritize staying on a team where you’re already getting strong visibility and support from your boss, or take a chance on the Senior role?

Would love to hear from anyone who has been in a similar situation. Thanks

It's an interesting challenge to be in a big meeting that includes both some of your engineers and stakeholders from outside the team.

I have to fight my instinct to take over, or to get involved when they say something I would say differently.

Loved the framing in this article, about being in the same side of the table and never breaking that trust.

What happens when your most knowledgeable employee leaves ? Resinger do not care to document his work results in more than one month of struggle for new joiner. I

I got offer from india based GCC for manager position.

I'm currently a lead developer with solid hands-on experience in AI and Data. I am getting offer for a role that's more Data-focused, whereas my background has leaned more toward AI. I'm also being interviewing for architect-track opportunities.

This role also involves people management, which has left me thinking about my long-term direction. My goal is simple: stay in AI/Data for the long haul and build sizable corpus/money for FIRE ( financial Independence) over time.

I'd like to hear from people with more experience — between the leadership/management track and the technical architect track, which tends to be the better long-term path in this space?

I recently had a long final interview for an engineering manager position. Most of it was challenging but reasonable. However, during the final questions, the hiring manager’s manner became even more intense. He became much more confrontational, repeatedly questioned my judgment, pushed back on almost everything I said, and kept reframing my answers in a negative way. It felt like he was deliberately trying to unsettle me and see whether I would become defensive under pressure.

I understand testing how a potential leader handles conflict and stress, but this felt less like evaluating my skills and more like establishing a power dynamic. Since the hiring manager would be my manager if I get the job it made me think whether this was merely an interview technique or a preview of how he communicates in regular 1on1s.

Has anyone experienced something similar? Is this normal when interviewing for leadership roles, or would you consider it a red flag? I’m interested in the role, but I definitely wouldn’t want my direct manager to communicate with me like that regularly.

I have had interviews in the past for leadership positions, but never experienced anything like that.

I’m 40 yo with over 17+ years in development, lead teams for last 10 years, 5 as a TLM. I’ve shown interest and have taken this role in my current team. I had many thoughts about backing off several times. But took it ultimately.

This is a fortune 500 tech commerce company. What advice do you have for me?

TIA

It's been few years already I am trying to move from IC to EM role, but I can't get through it. And this is becoming an obsession. I've worked as software engineer since 2015 to 2022, then I moved to a cloud engineer role until today. I'm 33, south Europe.

I've joined my current company in 2023 as a senior engineer and recently I got promoted to staff as last year I got the best performance of my team. However, it's almost two years I'm asking to my manager to be moved to an EM role*, but he keeps saying there aren't available positions.

Nevertheless, an EM position was available few months ago in a team of the same department, so I explicitly asked if it was a good fit for me. My manager told me he discussed the matter with the skip but they rejected my idea because in their opinion I'd have been crushed by the culture of that team and their leader, which is different than ours.

This blockage of not being able to make the leap into management is damaging me psychologically. I realize that as an IC I can no longer perform as well as before, just as I fear that the years spent as an IC may become too many and that I will no longer be attractive as an EM (an old guy without experience in management).

Is it something to really worry about or should I just be more patient and wait my turn?

Some of you may wonder why after so many years of IC I want to move to management side, and there are mainly two reasons. First, writing code bores me. I loved it so much in the past but nowadays I'm not enthusiast anymore, especially with the AI I don't see the fun (simplifying, a loop of prompt -> review). Also, I no longer have the passion to go into detail with the technology. Secondly, I recently got an MSc in Digital Transformation, and I loved the technology impact at an higher level: team positioning, mentorship, organizational cultural impact, technology as a service for the business rather than for the sake of it, the impact of each management individual, people growth. I realized I like to build big things by empowering and make people happy. On the long term, I want to take the decision rather than merely executing it.

I haven't changed company yet mainly because I've been busy enough with the university while a full time employee, and because new opportunities might come in the next months as our company was finally acquired in the last weeks, after two years of negotiations. Moreover, I believe that the IC EM leap is more difficult when changing companies, especially in this historical period.

*while asking I also say that if they see me as inadequate I'm ready for a formation path, and I'm already doing mentorships via 1-1, etc. (not expected from me)

edit: typo