Engineering Buy-in; Managing the Manager; Vibe Coding; Habits of Successful Managers
Issue #61 Bytes
đ± Dive into Learning-Rich Sundays with groCTO —ïž
Engineering Buy-in
Think your great idea will sell itself? Think again. This article breaks down the secret to getting your project approved: engineering buy-in. It's not just about having a solid proposal; it's about the conversations you have before the big meeting.
The article, written by a former Apple engineer, explains how talking to key people individually can help you refine your idea, preempt misunderstandings, and turn potential critics into your biggest supporters. Learn the sneaky (and smart) strategies for getting your coworkers and managers on board, the different ways to execute your plan, and the potential pitfalls to watch out for.
Read the full article to master the art of "engineering buy-in" and make your next pitch a guaranteed success.
Article of the Week â
âInstead of taking on everything ourselves, we need to look to our teams for support. After all, a big part of management is doing ânothing.â And your metrics of success arenât simply dependent on you but also on your teamâs success.â
How To Manage Yourself As An Engineering Manager
You can't lead a team if you're constantly underwater. Alex Ponomarev breaks down the real challenge for most new engineering managers: managing yourself before managing others.
1. Protect your energy like itâs part of your job, because it is
You donât have to run on fumes to prove youâre doing good work. A lot of your value now comes from the things no one sees: the calm decisions, the trust you build, the fires you quietly prevent. If youâre running low, take the break. Your team needs you, not a burned-out version.
2. Make space for stress
Youâre not doing it wrong just because things feel hard. This role throws a lot at you. The trick is to notice when youâre getting overwhelmed and give yourself permission to pause, even just for five minutes. Itâll help you come back clearer and less reactive.
3. Stay grounded, especially when itâs tense
You donât need to have the perfect answer in the moment. If something sets you off, itâs okay to say, âLet me come back to you.â Your team will respect the version of you that stays steady and thoughtful, even under pressure.
4. Set boundaries without guilt
Youâre not being difficult by saying no or blocking off deep work time. Youâre just being honest about whatâs sustainable. The people around you will actually trust you more when youâre clear about what you can and canât take on.
5. Flex when the plan changes
Things will shift, often at the last minute. Try not to take it personally. Stay focused on the outcomes, not whether the path looks like the one you sketched last week. Course-correcting is part of the job.
6. Pick your three most important things each day
Seriously! Just three. Thereâs always more coming, but if you can focus your energy on what truly matters, youâll move faster than trying to do everything at once. Let the noise wait.
7. Use whatever tools keep you sane
Donât overthink the system. Find what helps you stay on top of things, maybe itâs a to-do list, maybe itâs blocking out calendar time, maybe itâs voice notes. Whatever helps you make space to think lean on that.
8. Be the kind of steady leader youâd want to work for
Keep your word. Own it when something slips. Donât hide when things go sideways. Your team will follow your lead, especially when things are messy. How you show up in those moments is what earns long-term trust.
Other highlights đ
I Know When You're Vibe Coding
You ever review a pull request and just⊠know the code was written by an LLM? Not because itâs bad. Itâs clear, it works, itâs tested. But something feels off. Itâs too clinical. Too clean. Like it was dropped in from a parallel dimension where nobody on your team has ever touched this repo before.
Thatâs what vibe coding is:
AI-generated code that technically works (or does it?), but clearly ignores the standards, practices, and shortcuts your team sweated over for years.
Itâs not about the how. No matter if you typed the code, copied it, or summoned it via incantation. What matters is: do you care about what ends up in the codebase?
Because throwing out years of hard-earned conventions for the sake of typing speed is like being a barista who rushes so fast they spill coffee everywhere just to shave five seconds off an order.
So sure, use LLMs. But donât let them vibe code into production.
Guide them with good prompts
Be clear about your projectâs norms
Use examples, not just expectations
Donât prototype in production clothes
Or write it yourself
Principles havenât changed. We just forgot to pass them to the next autocomplete.
Why things just work around some EMs
Some engineering managers wait for things to happen.
The roadmap, the priorities, the feedback, the blow-up.
The best ones donât.
They make things happen.
đ§ Leading Up & Across
These questions focus on how you interact with leadership, stakeholders, and the broader org.
Do you fight for your teamâs raises even in tough times, or just pass down what leadership says?
Do you give your manager action items in your 1:1, or just answer their questions?
Are you actively participating in non-engineering Slack channels, or assume itâs all noise?
Do you have strong relationships with stakeholders in various departments, or only talk with your engineers?
Do you push HR for better team activity budgets, or just do the minimum?
Do you actively look for the best candidates to hire, or just look through the CVs the recruiters send you?
Do you show up to leadership meetings with answers and options, or with updates and problems?
Do you go talk to customers yourself, or just read the notes your PM gives you?
Do you fully understand how the company operates and makes money or just talk about engineering velocity?
Do you take ownership of company-wide problems, or do you assume they belong to someone else?
đ§ Leading the Team
These questions are about how you show up for your team and shape their success.
Do you chase feedback from your team and peers, or hope theyâll tell you something in the next performance review?
Do you train your engineers to step up, or complain that you donât have anyone you can delegate to?
Do you push back on unrealistic deadlines early, or only speak up when things are already on fire?
Are you constantly asking PMs and designers to move faster, or does everyone in the org ask you to move faster?
Do you take responsibility for the business results your team delivers, or are you satisfied with a good effort?
Do you follow up on action items after meetings, or assume someone else will?
Do you actively shape the roadmap or just execute what the PM tells you?
Do you try hard to help your PM understand the tradeoffs, or just silently resent their decisions?
Do you think beyond just engineering and contribute to the long-term company success, or do you just focus on technical debt?
Do you share your teamâs wins and progress loudly, or assume leadership will just notice?
Find Yourself đ»
Thatâs it for Today!
Whether youâre innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.
See you next week(end), Ciao đ
Credits đ
Curators - Diligently curated by our community members Denis & Kovid
Featured Authors - Alex Ponomarev, Alexander Kondov, Anton Zaides
Sponsors - This newsletter is sponsored by Typo AI - Ship reliable software faster.
1) Subscribe â If you arenât already, consider becoming a groCTO subscriber.
2) Share â Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.