[{"data":1,"prerenderedAt":187},["ShallowReactive",2],{"navigation":3,"\u002Fblog\u002Ffrom-engineer-to-lead":34,"\u002Fblog\u002Ffrom-engineer-to-lead-surround":182},[4],{"title":5,"path":6,"stem":7,"children":8,"page":33},"Blog","\u002Fblog","blog",[9,13,17,21,25,29],{"title":10,"path":11,"stem":12},"Building a Reusable Skill for Vue 3: From Architecture Principles to a Published GitHub Standard","\u002Fblog\u002Fbuilding-a-reusable-skill-for-vue-3","blog\u002Fbuilding-a-reusable-skill-for-vue-3",{"title":14,"path":15,"stem":16},"From Engineer to Lead: The Shift Nobody Prepares You For","\u002Fblog\u002Ffrom-engineer-to-lead","blog\u002Ffrom-engineer-to-lead",{"title":18,"path":19,"stem":20},"Paginating Complex CTEs in PostgreSQL: Lessons from a Real Chat App","\u002Fblog\u002Fpaginating-complex-ctes-in-postgresql","blog\u002Fpaginating-complex-ctes-in-postgresql",{"title":22,"path":23,"stem":24},"Scaling Frontend Teams Without Losing Code Quality","\u002Fblog\u002Fscaling-frontend-teams-without-losing-code-quality","blog\u002Fscaling-frontend-teams-without-losing-code-quality",{"title":26,"path":27,"stem":28},"Taming Supabase Realtime in a Tauri App: Sleep, Wake, and Reconnection","\u002Fblog\u002Ftaming-supabase-realtime-in-a-tauri-app","blog\u002Ftaming-supabase-realtime-in-a-tauri-app",{"title":30,"path":31,"stem":32},"Why I Stopped Writing Components and Started Writing Composables","\u002Fblog\u002Fwhy-i-stopped-writing-components-and-started-writing-composables","blog\u002Fwhy-i-stopped-writing-components-and-started-writing-composables",false,{"id":35,"title":14,"author":36,"body":42,"date":173,"description":174,"extension":175,"image":176,"meta":177,"minRead":178,"navigation":179,"path":15,"seo":180,"stem":16,"__hash__":181},"blog\u002Fblog\u002Ffrom-engineer-to-lead.md",{"name":37,"username":38,"to":39,"avatar":40},"Junaid Rasheed","junaidrasheed","https:\u002F\u002Fgithub.com\u002Fjunaidrasheed",{"src":41,"alt":37},"\u002Favatars\u002Fme.png",{"type":43,"value":44,"toc":163},"minimark",[45,49,52,57,60,63,66,70,73,76,79,82,86,93,99,105,111,115,118,131,134,137,141,144,147,150,154,157,160],[46,47,48],"p",{},"Nobody gives you a manual when you become a lead. One day you're heads-down in a ticket, the next you're running a planning meeting, unblocking three people simultaneously, and somehow still expected to ship code. It's a role that sounds like a promotion and feels like a completely different job.",[46,50,51],{},"Because it is.",[53,54,56],"h2",{"id":55},"the-thing-they-dont-tell-you","The thing they don't tell you",[46,58,59],{},"When you're an individual contributor, your output is visible and measurable. You shipped the feature. You fixed the bug. You can point to the PR. At the end of the day, you know whether you did your job.",[46,61,62],{},"When you become a lead, your best work becomes invisible. You asked the right question in a planning meeting that prevented two weeks of rework. You gave feedback on a junior engineer's approach before they went down the wrong path. You noticed that two teams were solving the same problem differently and quietly aligned them. None of that shows up in a commit history.",[46,64,65],{},"This is disorienting at first. Engineers are trained to measure their value by what they build. Leads create value by shaping what others build — and that requires a completely different feedback loop.",[53,67,69],{"id":68},"the-coding-trap","The coding trap",[46,71,72],{},"Most new leads fall into one of two failure modes.",[46,74,75],{},"The first is holding on too tightly to the code. You're still the best technical contributor on the team, and it feels good to be in the code. So you stay there. You take the hardest tickets. You become the bottleneck for every complex problem. The team grows but your habits don't, and six months later you're overwhelmed, your engineers aren't growing, and nothing ships without you.",[46,77,78],{},"The second is abandoning the code entirely. You've heard that \"real leads don't code\" (you haven't, but it feels implied), so you step back. You go full calendar. You lose touch with the codebase, your technical credibility starts to erode, and you find yourself unable to push back on estimates or spot bad architectural decisions because you're no longer close enough to the work.",[46,80,81],{},"The actual job lives in the tension between these two. You need to stay technical enough to be credible and useful, while deliberately creating space for your engineers to own the hard problems. That balance shifts constantly and there's no formula for it.",[53,83,85],{"id":84},"what-actually-changes","What actually changes",[46,87,88,92],{},[89,90,91],"strong",{},"Your definition of \"done\" expands."," A feature isn't done when the code is merged. It's done when the engineer who built it understands it well enough to maintain it, when the edge cases are covered, when the next engineer can pick it up without a walkthrough. You start thinking in systems rather than tasks.",[46,94,95,98],{},[89,96,97],{},"Ambiguity becomes your daily environment."," Individual contributors mostly work with well-defined problems. Leads work with poorly defined ones. \"We need to improve performance\" is not a ticket — it's a direction. Translating vague organizational intent into concrete, actionable work for your team is a skill you have to develop from scratch, and it's harder than any technical problem you've solved.",[46,100,101,104],{},[89,102,103],{},"Your calendar becomes the product."," How you spend your time directly determines what your team can and can't do. A blocked engineer who can't get 30 minutes with you this week is an engineer who loses a day or more of progress. Time management stops being a personal productivity habit and becomes a team responsibility.",[46,106,107,110],{},[89,108,109],{},"You absorb uncertainty so your team doesn't have to."," Priorities shift. Roadmaps change. Stakeholders disagree. A big part of the lead role is acting as a buffer — taking in the chaos from above and translating it into something stable and actionable for the engineers on your team. They should be able to focus. That focus is something you actively protect.",[53,112,114],{"id":113},"the-mentoring-misconception","The mentoring misconception",[46,116,117],{},"A lot of new leads think mentoring means teaching. It doesn't — or at least, not primarily. The most effective mentoring is mostly asking questions.",[119,120,121,125,128],"ul",{},[122,123,124],"li",{},"\"What approaches did you consider?\"",[122,126,127],{},"\"What do you think the tradeoff is here?\"",[122,129,130],{},"\"How would you handle it if this constraint changed?\"",[46,132,133],{},"When you give an engineer the answer, they learn the answer. When you ask them the right questions, they learn how to think. The second one scales. The first one just makes them dependent on you for the next problem.",[46,135,136],{},"This is also better for you. If your engineers can reason through hard problems independently, you're not the ceiling on what they can accomplish. That's how you build a team that can operate without you in the room — which is, counterintuitively, exactly what a good lead aims for.",[53,138,140],{"id":139},"the-visibility-problem","The visibility problem",[46,142,143],{},"Here's something that takes too long to learn: if your work is invisible, you have to make it visible.",[46,145,146],{},"Not in a self-promotional way — in a communication way. Write up the architectural decision you steered. Share the context behind a tradeoff in your team channel. Send the summary after a difficult planning session. These aren't vanity exercises. They create a paper trail of the thinking that's actually driving the team, they help engineers understand context they wouldn't otherwise have, and they make your contributions legible to the people who make decisions about your career.",[46,148,149],{},"Individual contributors can sometimes get away with letting the code speak for itself. Leads can't. The work is too distributed, too contextual, and too process-oriented to be self-evident. You have to narrate it.",[53,151,153],{"id":152},"the-honest-summary","The honest summary",[46,155,156],{},"Becoming a lead is not a reward for being a great engineer. It's a different role that requires different skills, a different feedback loop, and a willingness to measure your success by other people's growth rather than your own output.",[46,158,159],{},"Some great engineers make terrible leads. Some average engineers make exceptional leads. The skills barely overlap.",[46,161,162],{},"If you're considering the transition, go in with eyes open. The job is harder in ways you won't anticipate, more rewarding in ways you won't expect, and almost nothing like what you imagined. That's not a warning — it's just the truth. And knowing it going in puts you ahead of where most people start.",{"title":164,"searchDepth":165,"depth":165,"links":166},"",2,[167,168,169,170,171,172],{"id":55,"depth":165,"text":56},{"id":68,"depth":165,"text":69},{"id":84,"depth":165,"text":85},{"id":113,"depth":165,"text":114},{"id":139,"depth":165,"text":140},{"id":152,"depth":165,"text":153},"2026-06-10","Becoming a lead sounds like a promotion and feels like a completely different job — because it is. On invisible work, the coding trap, and measuring success by other people's growth.","md","https:\u002F\u002Fimages.pexels.com\u002Fphotos\u002F3862615\u002Fpexels-photo-3862615.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=1",{},7,true,{"title":14,"description":174},"t5M1mNwfk-dxDnwLlPx2OO8J2saOrV5N7tOFEfxQ9Uo",[183,185],{"title":10,"path":11,"stem":12,"description":184,"children":-1},"When you've explained the same architectural pattern for the seventh time this month, that's not mentoring — it's a missing abstraction. How I codified senior-level Vue 3 patterns into a shareable standard.",{"title":18,"path":19,"stem":20,"description":186,"children":-1},"OFFSET feels right and embarrasses you in production. A practical look at cursor pagination, structuring CTEs honestly, and the DISTINCT ON trap, drawn from a real chat app.",1782657704081]