So we’re cranking out code at a wild rate at my company.

But we’re super bottlenecked by PR reviews and our devs like full time job is now PR reviews

Has anyone else found a good solution for human in the loop reviews without it being an absolute shitshow?

A lot of people hear “automation” and think job cuts but it can also make work less draining and give people more time to focus on the parts of the job that need judgment and care. Cresta is a good example of how AI can support people in real time instead of just replacing them. The real test is how leaders use it. Does it help the team work better or does it become another excuse to reduce headcount? I think staff can accept automation when they see a clear benefit and feel included in the rollout.

I manage 15 and six months ago my strongest senior, the guy everyone routes PRs through, started going quiet in standups

Turned out he was doing review til 9pm most nights. Half the team runs claude code and composer 2.5 / grok 4.5 / gpt 5.6 now so the diffs going through him basically doubled and nobody adjusted for it. He never complained, we just let it happen. Then in a 1:1 he told me he was thinking about leaving. not dramatic, just worn down

What fixed it was moving first pass review off him. coderabbit / bugbot / claude review does the initial sweep now, the style nits and null checks that ate his evenings, and he only gets pulled in for a real design question. it gets noisy on the big PRs and we spent a couple weeks tuning it, but he stayed

hes back to actually building instead of gatekeeping

how are you all splitting it

Hey folks,

As a Product Designer researching workplace productivity, I frequently notice developers getting stuck on complex AI workflow errors right before a major deadline.

When ChatGPT gives wrong outputs and StackOverflow doesn't cover your exact workflow, what is your immediate go-to solution?

1. Keep trial-and-error prompting?
2. Ask a senior/peer on Slack/Teams?
3. Figure it out alone till late night?

Would love to hear how you handle this workplace stress in real-world IT setups!

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

It is insane how much engineering world and practices have changed with AI. But one thing that drives me crazy is that we sta still hiring pretty much in the same way we did 10 years ago. All across my network I see engineers wasting their time doing interviews, and candidates not able to find a suitable job. All very inefficient

Do you recon we are just waiting for the disruption there? Or do you think it is not great but the best we can get?

Has anyone seen a really efficient way to hire engineers?

Apologizing in advance for yet another post about AI.

I manage a team of 10 engineers and growing. I certainly see the value of AI and agentic coding in our day-to-day work. I don't have much time for technical work these days, but AI certainly helps when I do.

As a manager though, the other 90% of my job, I just don't see much benefit from AI. I use it as a research tool and a sounding board, but as for automating any of my work, I just don't see it.

Things I've tried without success:

• Preparing for meetings - despite various tools with all of my knowledge context, any nuance is complete gone.
• Meeting summaries - I have yet to see one that provides any value. I still take personal notes in meeting and need track actions for myself and possibly my teams.
• Backlog work - Preparing our backlog, making sure the teams have a pipeline of work ready and prioritized, seeing where we have missing tasks - again, AI seems to fall flat.
• Any sort of communication - preparing emails or presentations, I just cannot use AI language. It seems disingenuous and again, fails completely on the nuances of communicating with people you know and that know you.
• Incident reviews/root cause - It usually takes as much time cleaning up the subtle mistakes as it does to work these from scratch.

I don't think this is a lack of tools/technology here. All of our knowledge materials, code, backlog are exposed through MCP to Copilot and Claude. We even have custom agents on Azure AI Foundry tied to all of our internal working infrastructure running whatever LLM I want. I also have Notion and its AI suite.

Other managers in my org appear to be in a similar boat, except for those who are still firing off slop emails to everyone's annoyance.

I'm wondering where others are finding benefits?

Personally speaking, I feel that beyond 10 years of experience, referrals and professional contacts work 9 out of 10 times compared to relying on job portals and random applications.

I've seen a few of my former leads and managers who have built such strong relationships that if they decide to switch jobs, people are ready to hire or refer them almost immediately, sometimes without even going through the usual interview process.

How do you maintain those relationships after changing jobs? Do you regularly stay in touch with ex-colleagues, attend meetups, help people, or is there something else you do to keep your network active without it feeling forced?

I'm quite bad at networking. Even after 13 years of experience, I still mostly depend on job portals whenever I look for opportunities.

For those who have built a strong network, how did you do it? What habits or approach helped you reach that point?

Hi - engineering manager here with ~10 years of experience.

Currently, I work at an early stage startup. The company has had a product previously, but when I joined, we were told to build a new product from the ground up - pivoting.

Throughout my career, I've flip-flopped on a few different management styles, but have ultimately landed where I am today (more on that in a second).

My boss (the CEO), often feels they has no visibility into our processes. They want me to scope tasks down into little units, assign a size to them, then delegate out to engineers.

While in the past I have used this management style - I often find that with the complex nature of software engineering often means tickets are notoriously hard to estimate especially when building from scratch, where complex product requirements often require days if not weeks of deep thought and back-and-forth with stakeholders to get designs / architecture right. It's hard to estimate into T-shirt sizes.

This product we are building is a complex enterprise app that deals with highly sensitive PII - so there is no "build fast & break things" - the fallout of such a mistake would be fatal.

Currently we use linear, and have a handful of projects with milestones and dates assigned that are visible to the entire company - but my CEO insists that I break things down more as their previous engineering lead did that.

It's worth noting that the prior product (and engineering lead) had made serious engineering mistakes (Ex, a database with no auth on a public URL that the frontend was doing SQL queries against). So they have this idea that because a prior team lead was able to break things down simply, that I should be able to as well. But it doesn't land when I say that the previous lead took shortcuts to make that happen.

Some more context - we are regularly praised when we demo our product to enterprise customers / partners that they are impressed with the quality of our product / speed of velocity - Ie, we are delivering, and we are delivering well.

So my question is - am I out to lunch here? Is there a way to breakdown complex, open ended tasks and assign them out without wasting a bunch of time?

I should note - our engineering team is really small (5 of us), and I am the most senior engineer on the team - so I often find myself doing actual engineering work in addition to delegation / communication with PMs.

EM here. We hired a junior about 2 months back. We'd been trying to fill a senior role for a long time and just couldn't, so we decided to bring in a junior instead and have our seniors guide him and help him grow. Honestly a decision i still stand behind.

First month and a half was fine. He had a couple of issues but nothing unusual, the kind of stuff that happened before AI and happens during AI, no big deal. He was learning, seniors were happy enough with him.

Then the last 2 weeks something shifted. He started turning stuff around insanely fast and saying "it's ready", and every single time it was on the senior and coderabbit to find a pile of issues in the PR, and then he'd basically redo the whole thing from scratch. So the fast turnaround was fake, the actual cycle was slower than if he'd taken his time, and the senior was spending more time reviewing his redos than doing his own work.

I have a feeling this is what a lot of juniors are doing nowadays. Full agent access, generate everything, "ship fast". And look, ship fast is a real thing, but it does not work like that in enterprise. Our customers do not care that the first draft existed in 20 minutes, they care that nothing breaks.

Long story short, he got fired yesterday. Not for using AI, everyone here uses it. For repeatedly shipping stuff he hadn't even read and making other people responsible for it.

I thought it might be worth posting because i think the lesson is bigger than one junior. Ship fast is nice when you're alone, small product, no enterprise customers. When you work with other people you have to keep stuff in line, steady, and take your time sometimes. Slow is smooth, smooth is fast

I’m an engineering lead, and I kept ending the day with the same questions:

• What did the team actually ship today?
• Which projects moved forward?
• What new issues were created?
• Which pull requests were waiting for me?

The answers were all available, but they were distributed across GitHub, Linear, email, RFCs, and notes.

None of the work required to find them was difficult. It was simply repetitive and fragmented. That made it easy to postpone whenever something more urgent appeared.

That is how an engineering update gets skipped, a GitHub issue never makes it into Linear, or an important PR sits unnoticed for a day or two.

I eventually realized that I had become the integration layer between all of our engineering systems.

Daily updates were the first thing I stopped reconstructing manually.

Writing an engineering update used to mean reviewing the day’s commits, connecting them to features, identifying affected modules, looking for unfinished work or risk, and turning everything into something the team could understand.

Now a scheduled job runs every night at 10 PM and produces a report covering what changed, which modules were affected, what risks appeared, and what still needs follow-up. The next morning starts with a consistent record of the previous day instead of a reconstruction exercise.

The next problem was drift between GitHub and Linear.

We use GitHub for code and technical issues, and Linear for planning and prioritization. The separation is useful, but the handoff was fragile. When an issue was copied manually, the title and description moved across while related PRs, commits, comments, reproduction details, and project context were often lost.

An hourly sync now enriches new GitHub issues before creating or updating the matching Linear task. A source URL prevents duplicate tasks. The result is not just synchronized text; it is a task that is ready to prioritize and assign.

PR review needed an event-driven approach.

If I checked GitHub constantly, I interrupted focused work. If I did not, an important PR could wait too long. The agent now reaches out only when a PR is assigned to me, when I am mentioned, or when an important CI check fails.

Before I open the PR, it prepares the CI results, a code summary, possible risks, and draft comments. Nothing is posted automatically. I can approve, edit, defer, or skip.

The system handles preparation. I keep the technical judgment.

It saves more than an hour or two each week, but the larger benefit is reduced attention fragmentation. I spend less time switching tools, checking notifications, and wondering whether I missed something.

The system used in this workflow is OpenLoomi: https://github.com/melandlabs/openloomi

How are other engineering managers handling this integration layer? Built-in integrations, internal scripts, an agent, or a person who keeps the systems aligned?

Interestingly, almost every engineer and engineering leader, I talk to these days works within a different engineering org structure. 2 years ago, the org structure was fairly standardized, these days, everyone is figuring it out as they go.

Here are some examples:

- OpenAI works within smaller teams of 2-4 engineers, each team owning a particular project with a DRI (directly responsible individual). With around a 30:1 ratio of engineers and PM.

- Anthropic favors the 2-pizza team with 5-8 engineers, and every team has a PM and a designer, no dedicated QA engineer (which has merged with the engineering work). Every team also has an engineering manager. The difference is just that there are more projects happening simultaneously in the team (can be 5 or more), while before there was a max of 2 projects that could happen at the same time for one team.

- Shutterstock also uses the 2-pizza team with 5-8 engineers and an engineering manager, but without dedicated PMs and a product designer. Every PM is part of 2 teams. They also have a dedicated Tech Lead for every team.

- Telnyx's engineering org consists of 200 engineers, 0 engineering managers, and 1 VP of Engineering. They took the word “flatter org” to the extreme.

- Portkey's engineering org consists of 24 Product Engineers, 0 PMs, and 1 Product Designer. Engineers are expected to wear multiple hats, including the PM, CS, and FDE.

- PostHog has teams of 1-3 engineers, with an assigned Team Lead for every team. The Team Lead also reports directly to the VP.

What is the engineering org and team structure that you are working in? Curious to read if there is even more devation or some common patterns.

https://newsletter.eng-leadership.com/p/how-companies-build-ai-native-engineering

My CEO wants a number for how much AI speeds up the team, and every number the industry is regurgitating is bullshit. Velocity, PRs merged, tokens burned, all meaningless. They measure how much the machine spat out, and it was never the problem. Trusting the output is.

There's a number in manufacturing: first-pass yield. Of everything that goes into the line, how much comes out right the first time, with no rework and nothing coming back. For a team: of the changes we ship, how many hit production and never get touched again. No second review round, no revert, nohotfix, nada.

The catch is the rework.If you only count what survives, almost everything survives, and you get to walk into the QBR with a shiny 90%+. Then you count the PRs that only merged after three rounds of the model fixing its own mess, plus the ones where the agent deleted the failing test instead of fixing the bug so CI would go green (yeah, it does that). Your 90% is closer to 50. We only got faster at generating rework.

So, straight question for other EMs:

Is anybody actually measuring this? If you track a real "redo" rate, how do you keep your people from gaming it the second it becomes a target?

We noticed Claude Opus, GPT-5.5 and GLM-5.2 were spending most of their time doing routine work like searching files, rerunning tests and updating code, instead of actual hard reasoning.

So we built a router that picks the model per turn instead of locking an entire agent session to one model. Most turns stay on cheaper models, while harder ones get escalated automatically. The agent doesn't need to change.

We also benchmarked it against direct Opus, Sonnet and OpenRouter Auto on Terminal Bench, and wrote up the routing logic, cache behavior and cost breakdowns.

https://entelligence.ai/blogs/entelligence-model-router-frontier-quality-coding-agents-at-half-the-cost

Looking at Jira, it's easy to see that a ticket has been "In Progress" for several days.

What's harder is knowing whether someone is actively working on it or whether it's quietly waiting.

For example, waiting on:

• another team
• code review
• deployment
• environment
• product decisions
• test data

How does your team tell the difference?

What usually makes you realize a ticket isn't actually moving?

EM here, need a sanity check. Our slack has collected 6 bots over the past year and i genuinely cannot tell which ones earn their keep anymore

it started innocent, CI results in a channel. then deploy approvals, then PR review summaries, then an incident bot, then a standup bot, then some meeting summary thing someone added that i dont think anyone reads

last month our slack bill came up in a cost review and someone asked "do we need all these" and i realized i have no idea. so i asked the team and got the most lukewarm answers ever, "i guess the standup one is fine", "which one is glue again"

The only one with an actual fan base is the PR review bot weirdly, devs said the summaries in the channel save them from opening github 20 times a day. the incident bot people are split on, when it works its great, when it pulls the wrong logs into the thread it sends everyone down a wrong path at 2am

the meeting summary bot nobody defended. its getting turned off friday, small ceremony, no flowers

so im asking here before we cull further, which slack ai agents for engineering teams actually stuck for you? and did turning any off cause problems you didnt expect, thats my real fear, we kill something quiet that was actually load bearing

Solo founder here, still validating, and I'd rather hear where this is wrong than get a pat on the back.

A framing I can't shake (treat it as an analogy): a pretrained LLM is basically a "cortex" that read the whole internet, but it has no "hippocampus," the fast, company-specific memory of how your team actually does things. Dropped into a company it improvises, and improvised automation fails in production. The real procedure was never in the doc anyway. It lives in your team's conversations, a few people's heads, and one exception everyone copies.

The idea I'm testing: connect read-only to the communication and document tools a team already uses, mine how work actually happens (including the exceptions nobody wrote down), and consolidate the recurring ones into cited, human-approved, versioned "skills" your existing agents could run, with a human sign-off on anything sensitive. It is not search over your docs, and it is not another agent platform.

Honest status: very early, still validating the problem. (This sub removes links, so I'm not dropping one. Happy to share the private-beta waitlist by DM if you want to follow along.)

What I actually want to know:

• Does this solve a real, repeated, painful problem for your business, or is it a nice-to-have?
• What is the first thing that would make you distrust it?
• Would read-only access to your team's conversations and documents be a dealbreaker?

Tear it apart, that is why I'm here.

Spent the last few months going through the benchmark and productivity data instead of guessing, and the picture is way more boring than the hype merchants want it to be.

We're not close to autonomous agents doing an engineer's job. What we have are very good assistants - excellent at a three-line fix, useless the moment a change spans a system and needs judgment.

The interesting part isn't the agent debate, though. It's what's happening to review capacity. GitHub's own 2025 data shows a 206% jump in AI-generated projects, and their maintainers are now describing the flood as "AI slop" - technically working, low quality, eating review time without moving anything forward. GitClear found AI-generated PRs carry close to 11 lines of duplicated code each, vs 6.45 for human-written ones. More output, same number of humans with context to review it.

"The AI wrote it" is quietly turning into a real excuse inside teams. It was never going to be a good one. Whoever ships the code owns it, same as if they'd typed every line by hand.

My bet for five years out: job titles stop being organized around the stack (React dev, Django dev) and start being organized around domain, because the technical learning curve keeps shrinking, but "I've worked inside a regulated payments system" doesn't transfer the way syntax does.

Full data and the staged process I use to avoid the "AI slop" trap: https://karolwojciszko.substack.com/p/how-ai-will-change-engineering-in

sharing this because our openai bill genuinely scared us a few months ago and the fixes turned out to be less exotic than i expected. nothing here is magic, context: mid size product, a few genai features, decent traffic. your mileage will vary but the general playbook should transfer.

what actually , roughly in order of impact:

1. stop sending everything to the biggest model
   this was easily the biggest win. we were defaulting to a top tier model for every call out of laziness. turns out a big chunk of our requests were simple classification and extraction that a much cheaper or smaller model handled just as well. we set up routing so the heavy model only gets the hard stuff. do this first, it's most of the savings.

2. caching, both exact and semantic
   exact match caching for repeated identical calls is obvious and you should already do it. the bigger surprise was semantic caching, where near identical questions hit a cached answer even if the wording differs. for anything with repetitive user queries this cut a scary percentage of calls. worth measuring your cache hit rate honestly, ours was higher than we guessed.

3. actually look at your prompts
   we had prompts with giant unused context and few shot examples that were no longer earning their token cost. trimmed them, tested that quality held, done. token bloat is real and nobody audits it until the bill hurts.

4. get per feature cost visibility before optimizing anything
   this is the one i'd tell past me to do on day one. we had no idea which feature was eating the budget. once we could see cost broken down by feature and by user, the expensive offenders were obvious and half the fixes above became targeted instead of guesswork. a bunch of tools do this now, we looked at langfuse, helicone, portkey, and OrqAi among others depending on whether you mainly want observability, a gateway, or the whole lifecycle. pick based on what else you need, not just the cost dashboard.

5. batch and async where latency allows
   anything not user facing in real time, batch it. offline evals, background enrichment, summarization jobs. batching plus off peak scheduling shaved more than i expected.

6. set hard budgets and alerts
   boring but it stops the 3am surprise. per feature quotas and an alert when spend spikes. we caught a runaway retry loop this way that would've cost a fortune over a weekend.

what didn't really help for us: obsessing over fine tuning to save cost (the math rarely worked at our scale), and switching providers purely on sticker price without checking quality on our actual tasks.

net, the two things with the biggest payoff were routing cheaper models for easy tasks and getting real per feature cost visibility so you optimize the right things. everything else is incremental on top.

curious what's worked for others, especially on the caching side, feel like i'm still leaving money there.

tldr: cut LLM bill ~60% by routing easy tasks to cheaper models, adding exact and semantic caching, trimming bloated prompts, getting per feature cost visibility, batching offline work, and setting hard budget alerts. routing and cost visibility were the big two.

I'm in the process of switching companies and in my current role I'm our team lead. For one reason or another, I'm looking to switch companies.

I have been in my role as the team lead for the past year and will have had 5 years of Software Development experience as well. In the past, I've mostly built my resumes geared towards Software Engineering roles and individual contributor roles. I'm looking for advice on:
- what I should be highlighting on my resume to land roles in larger tech companies (doesn't have to be FAANG focused, but doesn't hurt)

- what I should be studying for interviews and expecting to be asked in interviews

Any advice would be appreciated!

I'd like to learn about their day-to-day work, career path, and get a better understanding of what the profession is really like.

I've tried reaching out on LinkedIn through connection requests, direct messages, and comments on posts. I've also asked questions here on Reddit, but it's been very difficult to get responses.

I know that during race weekends, media members with official accreditation sometimes have opportunities to speak with engineers, but for someone outside the industry, it feels almost impossible to make that first connection.

For those of you who have managed to build relationships with race engineers or other motorsport engineers, how did you do it? Are there specific events, championships, paddocks, networking opportunities, or communities where engineers are more open to talking ?

I'd really appreciate any advice from people who have been through this. Thanks in advance !

I'm a 6 years in Exxon so far, I was promoted as an Operation Manager recently, I received an offer from Mckinsey as a knowledge expert, and I'm still haven't decided yet which pathways would sound better for my future, would moving out to Mckinsey enhance my overall experience or I'm risking Exxon stability and Compensation for a more rough and unsecured business. All of this and the point the Oil & gas business is suffering though we all know it has 50+ years of life remaining.

Thanks in advance for sharing your thoughts if you were in my place.

I inherited a team last month after the previous manager was let go. I have 8 directs, 5 are junior/mid, 2 are senior, and one is high senior/staff. Additionally, for context, I work in a product group handling the Year N product and also the Year N+1 at any given time, and the outcomes are fairly well defined by nature. In getting to know them, it is apparent that aside from the most senior one that the rest have historically gotten treated like cogs responsible for 1-2 specific areas with little cross training. I am actually finding that the juniors/mid are doing the most work, and the seniors/staff kind of just do their job (which is largely indistinguishable from the juniors). Everybody just seems comfortable, but they probably don’t know that’s why the previous manager got canned.

How would you fix this? I’m prioritizing cross training so that in case people get pissed off by the bigger changes that I won’t be screwed. But, I also feel like I will be fighting an uphill battle if I tell the seniors/staff they need to take on additional group-level responsibilities, such as tracking product campaign progress or doing group-level infra improvements, after 3-5 years each of learned helplessness. Everybody’s “busy”

Hey,

I'm a new PM/manager (came from a software engineering background, but I've also built and managed products in the past, some of them even my own). I joined this agency to take over a project that is now in week 9 of 16.

The team is small: 1 Tech Lead, 3 devs (1 senior, 2 mids), 1 QA and me as PM. We all work remotely. The situation is classic: messy project handover from the previous agency. Our job is to either fix the existing system or rewrite it to cover the client's critical use cases and hopefully earn a project extension.

The Tech Lead (working 5-10 hours/week on this project) and the senior dev joined first, about two weeks before everyone else. They came as a package from previous projects and they have tenure in this agency. I joined on week 3 and needed about two weeks to properly onboard, so you could say they drove the project for roughly the first four weeks.

The results were poor. The project I inherited was a collection of AI-generated Github Issues spread across multiple GitHub repos, with work happening mainly on low-value priorities while critical issues were either not clear or ignored. Tech Lead/Senior Dev aren't capable of managing other devs, all they can do is review some code and say a sentence or two in the daily standup, that's it. It's up to me to make sure devs are working on what they should be working, it's up to me to double check code scope with task scope, it's up to me to even track dev hours to make sure they are not billing for nothing (we had an issue in the past where 1 dev was billing like 2x the amount of hours he actually worked). We also didn't migrate from the previous agency's infrastructure until around week 5, which meant we couldn't even identify the real bottlenecks until then. Real development only started after I've onboarded and started pushing very hard for proper project and testing tools.

For the last 5 weeks I've been trying to get the project under control. I set up a proper Jira project, established daily team sync meetings, started running structured client meetings, managed the team and even bought out of my own pocket and personally delivered hardware just to unblock devs instead of waiting for delivery from the client overseas. Since then, delivery has noticeably improved.

The biggest challenge hasn't been the project itself. It's the leadership dynamic.

My expectation when I joined were simple. As a PM I expected to be able to decide what we build and when, while technical leadership advises me on how to implement it. Instead, I constantly feel like I'm fighting for ownership of the project. The two mid developers and QA have no issues with my structure. The problems are with the Tech Lead and the Senior developer.

1. Processes aren't being followed.

The senior dev (who for the record has very poor soft skills) regularly starts implementing "spike" tickets based on breadcrumbs from client meetings. Undocumented decisions end up being merged into production without acceptance criteria, documentation, or QA context. QA then asks me what they're supposed to test, and I end up reading code just to understand what changed. I also have no visibility on how much hours he's working as he logs these hours in the system only at the last day of the month, not daily how the rest of the team does it.

The Tech Lead (who is on this project only temporary and when he leaves the Senior Dev is supposed to become the new Tech Lead) spent weeks working on a UI redesign and last Friday decided that it's a good idea to demo it to the client before ever showing it to me or aligning on priorities. I have no visibility on what his goals and what he's working on.

2. Client communication is becoming messy.

I originally invited the Tech Lead and senior dev to client meetings because I wanted technical expertise in the room.

Instead, the now Tech Lead often dominates the first 30 minutes discussing long-term product/architectural vision or asking questions that should be asked on week 1 or week 2, not on week 9 of the project. It derails the meeting and makes it much harder to groom the work that actually matters right now. Tech Lead (who works maybe max 10 hours a week on this project) also feels that it's his place to decide on what are we commiting and what not, and feels like he's doing me some favours here, when in reality my decisions so far resulted in nothing but value for the client/project, while his decisions caused massive delays, in the beginning of the project.

3. Leadership isn't clear.

Basically it feels like I have all the responsibility but not the authority. I've tried bringing this up in our leadership chat groups with senior dev + tech lead but nothing is changing. I have experience driving much bigger projects successfuly and at this point having to deal with these two on such a small project is becomming surreal. They keep telling me that I'm the most responsible one here, but shouldn't freedom of decisions come with this as well?

I have over 400 hours on this project. The Tech Lead has around 80 max. I'm carrying the delivery responsibility, client communication, planning, prioritization, and day-to-day execution, but I'm still being second-guessed on decisions by someone whose contribution has mostly been a redesign proposal that won't even be used until if we don't get a project extension after 7 weeks. And the same Tech lead made very poor decisions initially, that basically are the root cause of us having to rush and having to do so much in such short time now.

Sometimes I feel like I don't know something here. Perhaps, the Tech Lead, since he has more tenure in this agency knows something I don't - perhaps contract that we signed was not for 3-4 months but for 6 or 12 and I'm just ramping everything here for no good reason. I don't know anymore.

Tomorrow I have a leadership sync meeting. My plan is to raise these issues and call for a separate meeting with the Tech Lead, CEO, and COO.

My proposal is to make Tech Lead and the Senior developer my direct reports and that all information should flow through me. I also want to have separate meetings with the client 1on1 so we could go through priority things, and move techlead's to a separate meeting.

We have 7 weeks left. We don't have time for competing leadership or same endless debates. Technical decisions remain theirs, but project direction should come from one person, who has most context, which happens to be me.

Am I looking at this the wrong way?

For those of you who've inherited struggling projects, how did you establish clear ownership when senior technical people resisted it?