Tools: Why You're Not Trusted With Bigger Projects Yet

The Real Reason Isn't Your Skills ## The Invisible Filter Seniors Use ## Ownership vs. Execution ## Communication: Where Most Devs Silently Fail ## Estimation and Predictability ## Proactive Risk Flagging (The Skill Nobody Teaches) ## Code Reviews and Ego ## Stop Waiting For Permission ## Trust Is Built in Small Moments ## Your Five-Point Checklist ## The Bottom Line You're not trusted with bigger projects because you optimise for looking capable instead of being reliable. That's the whole article. But stay with me — because almost every developer who reads that sentence thinks it doesn't apply to them. Over 25 years working across software teams, I've watched dozens of junior and mid-level engineers hit the same invisible ceiling. The ones who didn't get big projects handed to them weren't lacking in technical ability. They wrote clean code. They knew their frameworks. Some of them were, frankly, smarter than me. But smart and reliable are not the same thing. And your senior engineer, your tech lead, your CTO — they're filtering for reliable, every single day, in every single interaction. The bar isn't "can this person build it?" The bar is: "Can I give this person the problem and stop worrying about it?" That's a completely different question. And most junior developers don't even know it's being asked. Here's where most devs mess this up. They think trust is about what you deliver. It's not. It's about what happens before you deliver. Every senior engineer has been burned. Burned by the developer who said "yeah, I've got it" — and went silent for two weeks. Then surfaced on the deadline with something half-baked and a list of blockers they'd known about for ten days. That experience rewires your brain. After it happens a few times, you start pattern-matching early: That's the invisible filter. And most junior and mid-level developers have no idea it's running on them in every single interaction. There's a massive difference between executing a task and owning a problem. Execution looks like this: Ownership looks like this: Execution is what you're hired for. Ownership is what gets you promoted. The developer who executes asks: "What's my next ticket?" The developer who owns asks: "What else might be affected by this?" That difference is enormous. And it's visible from across the room. This is the part nobody talks about. Not presentation skills. Not standups. I mean the basic discipline of keeping the right people informed at the right time, without being chased. Here's the rule I give every junior developer I mentor: If you've been stuck on something for more than four hours, someone needs to know. Not because you can't figure it out — maybe you can — but because the people responsible for the project need to maintain an accurate picture of where things stand. When you go quiet, that picture degrades. And the moment a senior has to come to you and ask "hey, how's that going?" — you've already lost a point of trust. They shouldn't have to ask. You should have told them. This one habit — proactive, concise, honest communication — will do more for your career than any technical skill you can learn this year. This is where mid-level developers consistently undermine themselves. Giving an estimate and hitting it — consistently — is a superpower. I don't care if your estimate is three days or three weeks. What I care about is whether, when the time comes, the thing is done. Or whether you told me early enough that it wouldn't be. Here's what happens when you're unpredictable with estimates: you become a risk. And nobody assigns their biggest problems to a risk. Three things to change immediately: Predictability is trust. Simple as that. And this is why you stay mid-level. The developers I've seen grow fastest aren't the ones who never hit problems. Everyone hits problems. The ones who grow fastest are the ones who see problems coming and say something before it becomes a crisis. Here's what this looks like in practice. You're three days into a two-week project and you notice a third-party API you're depending on has rate limits that will blow up the whole design at scale. The wrong move: Keep working. Hope it doesn't matter. Raise it when it becomes a blocker. The right move: Open Slack. Write two sentences: That's it. That's the move. That's the thing that makes a senior engineer think "this person is someone I want on hard things." Here's a subtle one that caps more careers than people realise. How you handle code review says a lot about your ceiling. Developers who get defensive — who treat every comment as a personal attack, who push back without genuine consideration — they cap out. People stop giving them real feedback. They stop growing. And they stop being trusted with sensitive or complex work. The developers who thrive treat code review as information. They: And here's the flip side: when you're reviewing someone else's code, are you thorough? Do you actually read it? Or do you rubber-stamp it to avoid conflict? Your behaviour in code review tells senior engineers exactly how you'll behave when the stakes are higher. You wait to be told what to work on next. You wait to be given the context you need. You wait for someone to schedule the meeting that clearly needs to happen. The developer who gets big projects doesn't wait. They take initiative within a reasonable scope. They say: That's initiative. That's the thing that makes a tech lead think "I can give this person a problem and they'll solve the whole thing — not just the bit they were explicitly pointed at." You don't need permission to be proactive. You need judgment. And judgment is something you develop by practising it — not by waiting for someone to hand it to you. Nobody gets handed a massive project out of nowhere. Trust is built in small moments, over time: All of those small moments accumulate into a reputation. And your reputation is what determines whether someone puts you on the hard thing or the safe thing. The good news: this works in both directions. If you've been operating in a way that hasn't built trust, you can change it — and people will notice quickly, because consistency in the right behaviours stands out. Pick the one you're weakest at. Work on that. Then the next one. The engineers who get trusted with big projects aren't necessarily the most technically brilliant people in the room. They're the people who make it easy to trust them. That's learnable. That's a choice. And it starts with the next conversation you have, the next estimate you give, the next time something doesn't go to plan. What you do in that moment — that's what defines your ceiling. I've been writing software professionally for 25 years across startups, scale-ups, and enterprise teams. If this landed differently than you expected, drop a comment below — I read every one. And if you recognise yourself in any of these patterns, that's the first step. Follow for more unfiltered takes on building a software career that actually goes somewhere. Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: 1. Get a ticket 2. Build the thing in the ticket 3. Close the ticket 4. Wait for the next task Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: 1. Get a ticket 2. Build the thing in the ticket 3. Close the ticket 4. Wait for the next task CODE_BLOCK: 1. Get a ticket 2. Build the thing in the ticket 3. Close the ticket 4. Wait for the next task CODE_BLOCK: 1. Get a ticket 2. Build the thing 3. Notice what else breaks when this ships 4. Flag it 5. Suggest a solution 6. Follow through until the WHOLE thing works — not just your slice Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: 1. Get a ticket 2. Build the thing 3. Notice what else breaks when this ships 4. Flag it 5. Suggest a solution 6. Follow through until the WHOLE thing works — not just your slice CODE_BLOCK: 1. Get a ticket 2. Build the thing 3. Notice what else breaks when this ships 4. Flag it 5. Suggest a solution 6. Follow through until the WHOLE thing works — not just your slice CODE_BLOCK: "I've spotted a potential issue with the rate limits on X — it could affect the whole approach. Can we get 20 minutes to look at options?" Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: "I've spotted a potential issue with the rate limits on X — it could affect the whole approach. Can we get 20 minutes to look at options?" CODE_BLOCK: "I've spotted a potential issue with the rate limits on X — it could affect the whole approach. Can we get 20 minutes to look at options?" CODE_BLOCK: "I noticed we don't have any error monitoring on this service. I'm going to set up a basic alerting config — let me know if that's not aligned with priorities." Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: "I noticed we don't have any error monitoring on this service. I'm going to set up a basic alerting config — let me know if that's not aligned with priorities." CODE_BLOCK: "I noticed we don't have any error monitoring on this service. I'm going to set up a basic alerting config — let me know if that's not aligned with priorities." - How does this person handle uncertainty? - How do they communicate when things go sideways? - Do they surface problems early, or do they bury them? - Buffer your estimates. Always. Work expands. - Break work down before you give a number. Never estimate from the ticket title alone. - Say "I need a day to assess this before I give you a timeline." That is infinitely better than saying "two days" and delivering in five. - Ask questions instead of defending - Say "good catch" when it's a good catch - Change their mind when the argument is better than theirs - Every standup update you give before being asked - Every estimate you give and actually hit - Every blocker you flag early - Every time you say "I don't know, but I'll find out" instead of guessing - [ ] Communicate proactively. Don't wait to be asked how it's going. - [ ] Own the problem, not just the ticket. Zoom out. See the bigger picture. - [ ] Give real estimates and flag early when they're slipping. - [ ] Spot risks before they become fires — and say something. - [ ] Stop waiting for permission. Take initiative, with good judgment.