In 2006, a relatively unknown product manager at Google made a career-defining move. Sundar Pichai claimed that Microsoft could change Internet Explorer and threaten Google's toolbar business, directly challenging the status quo. The toolbar team he led was generating massive revenue for Google through increased search adoption. But instead of protecting his turf, Pichai saw the bigger picture—the entire browser landscape was vulnerable.
His proposal? Build Chrome.
Management shot him down initially. Too expensive. Too risky.
But Pichai didn't give up. He gathered data, built his case, and eventually convinced Larry Page and Sergey Brin. Chrome launched in 2008 and became the world's most-used browser. That bet established his reputation as someone able to see beyond the product he was managing and worry about the business holistically.
Nine years after that pivotal moment, Pichai became CEO of Google.
The lesson isn't that you need to build the next Chrome (please don’t). It's that the best tech leads don't just manage their immediate responsibilities—they see around corners, build influence across organizations, and multiply the potential of everyone around them.
But here's what the success stories often skip: the context matters more than the tactics.
Read Your Environment First
Not all companies reward the behaviors that create great technical leaders. Some actively punish them. Before implementing any career advice, diagnose your organization:
Green flags (tactics will likely work):
Leadership asks for your opinion on technical decisions outside your area
Cross-team collaboration is rewarded, not just individual delivery
People get promoted based on impact, not just politics
Failure is treated as learning (most of the time)
Your manager actively helps with your career development
Red flags (focus on skill-building and exit planning):
Blame culture dominates problem-solving
Cross-team initiatives consistently fail due to politics
People who speak up about problems get marginalized
Promotion criteria are unclear or change frequently
Your manager actively discourages relationships with other teams
If you're in a red flag environment, the advice below might not work. Focus on building skills, documenting your impact, and finding a better organization.
1. Pick Problems That Matter (And Can be Solved)
Most tech leads spend their days fighting fires that shouldn't exist. They optimize systems that save milliseconds while manual processes burn hours. They refactor code that works fine while critical infrastructure crumbles.
The best tech leads ask a different question: "What's the one thing that, if fixed, would make everything else easier or unnecessary?"
Start with this weekly habit: Every Friday, list the top three problems your organization faces. Not technical debt. Not code quality. Business problems. Revenue blockers. Growth limiters. Customer pain points.
Then map those problems to technical solutions you can deliver. That manual data entry process that eats 20 hours of engineering time weekly? Automate it. The deployment pipeline that causes weekly emergencies? Fix it once, properly.
Here's a simple framework: Calculate the true cost of any problem by multiplying (hours lost per week) × (number of people affected) × (average hourly rate). Show this number to leadership. Problems become priorities when they have price tags.
Reality Check: If your organization consistently ignores cost calculations or treats all problems as equally urgent, focus on issues you can solve within your direct sphere of influence. Build credibility there first.
2. Build Relationships Before You Need Them
Your skip-level manager has more influence over your career than your direct manager. They're in the room when promotions are discussed. They set the strategic direction you'll execute. Yet most tech leads interact with them only during crisis or review cycles.
Start with your direct manager: "I'm interested in understanding the bigger picture of what we're working on. Would it be helpful if I had occasional check-ins with [skip-level] about how our work connects to broader initiatives?"
If they're supportive: Schedule a monthly 30-minute coffee chat with your skip-level. Come with one question about the business, one update on your team's impact, and one offer to help with their priorities.
Here's a script that works: "I noticed you mentioned [strategic priority] in the all-hands. My team has experience with [relevant skill]. Would it be helpful if we explored how we could support that initiative?"
Read your organizational dynamics first. If your direct manager is insecure about upward relationships, build trust there before going higher.
Extend this approach horizontally. Product managers, sales engineers, customer success leads—they all have problems you can solve and context you lack. A 15-minute weekly sync with your product counterpart prevents more issues than a hundred architectural reviews.
The key is consistency. Relationships compound like interest. Small, regular deposits matter more than sporadic grand gestures.
3. Protect Deep Work Like Your Career Depends On It
Because it does.
Some tech leads spend 10 hours in meetings, others spend 35. The key is identifying what's negotiable in your specific context. But that leaves ~17 hours for actual work, email, Slack, and thinking. No wonder most tech leads gradually lose their technical edge.
Start with one protected block per week: Mark 2-3 hours as "Architecture Time" or "Strategic Work." Deliver something tangible during these blocks: a design document, code review, or technical analysis.
When someone tries to schedule over your deep work blocks, offer specific alternatives: "I'm not available then, but I have time at 2 PM Tuesday or 10 AM Wednesday. Which works better?"
This assumes you're not in constant firefighting mode. If production issues dominate your schedule, fix your operational maturity first. The best technical decisions come from uninterrupted thinking, not 30-minute chunks between meetings.
4. Translate Technical Work Into Business Language
You just spent three weeks refactoring the authentication system. Your manager asks about the impact. Most tech leads say: "We reduced technical debt and improved code maintainability."
That's engineer-speak for "trust me, it was important."
Learn their language first: Listen in leadership meetings. What metrics do they track? What problems keep them awake? Revenue, customer satisfaction, compliance, growth capacity, operational costs—these are business concerns.
Connect your work to their concerns: "The authentication refactor prevented outages that cost us $50K last quarter and eliminated the manual verification process that was blocking customer onboarding."
Most technical decisions have business impact, but it's not always obvious. Your job is to find the connections and articulate them clearly.
Keep a simple impact log. For every significant technical project, document:
Problem solved (in business terms)
Money saved or revenue enabled
Risk mitigated
Time freed up for other teams
Review this log before every one-on-one, performance review, and promotion discussion. Numbers tell stories that adjectives can't.
5. Develop Someone Publicly and Deliberately
"He recruited, mentored, and retained a great team"—this was said about Sundar Pichai's approach to building his product team at Google. The engineers he developed became some of the best in the industry.
Pick one person on your team to deliberately develop this quarter. Not just mentoring—active, visible development.
Have them lead the next architecture review. But first, spend an hour preparing with them. Review their slides. Anticipate questions. Practice answers. Then, in the meeting, set them up for success: "Max is going to walk us through the design. He's thought deeply about the trade-offs here."
When they succeed, amplify it. In the team meeting: "Max's architecture review yesterday was exceptional. The way he handled the database scaling questions showed real systems thinking."
In highly competitive environments, focus on developing skills that make your entire team more valuable, not just individuals. This reduces the zero-sum dynamics that make mentoring risky.
The key is public advocacy. Private praise is nice. Public positioning changes careers.
6. Lead Cross-Team Initiatives That Matter
Every organization has problems that live between teams. Security vulnerabilities that span services. Platform migrations everyone needs but nobody owns. Developer tools that would help everyone but aren't anyone's priority.
These orphan problems are opportunities—in the right environment. They put you in front of senior leadership. They build relationships across the organization. They demonstrate ability to coordinate complex work.
Test the waters with small initiatives: Find a problem affecting two teams (including yours). Propose a simple solution that takes minimal resources. Share it with affected teams for feedback. Then take it to leadership. If that succeeds, scale up.
In organizations that punish cross-team collaboration, start with just one adjacent team first. The secret: Make it easy to say yes. Define success metrics. Set a clear timeline. Ask for minimal resources initially. Show early wins quickly.
Some cross-team initiatives are career makers. Others are career breakers—endless projects that consume years with no clear wins. Learn to tell the difference before you're too deep to escape.
7. Build External Credibility (Without Sacrificing Internal Delivery)
External visibility accelerates internal recognition—but it must complement, not compromise, your primary job.
Start with internal knowledge sharing. That complex problem you just solved? Write an internal blog post. That new technology you evaluated? Present it at the engineering all-hands. Build your reputation inside before going outside.
Then expand strategically. One conference talk per year. One technical blog post per quarter. Consistent but manageable—and only after you're delivering consistently internally.
Here's the key: Leverage your work twice. That migration you just completed? It's an internal case study and a conference talk. That performance optimization? It's a team playbook and a blog post.
Always ship first. External credibility without internal delivery kills careers. But external credibility with strong delivery creates opportunities you didn't know existed.
Final Thoughts
Most advice about becoming a great tech leader focuses on what you should do. But the hardest part isn't knowing what to do. It's accepting what you can't control.
You can't control whether your organization rewards the right behaviors. You can't force your skip-level manager to care about your career. You can't guarantee that your cross-team initiative won't get killed by politics you never saw coming.
What you can control is showing up consistently, solving real problems, and treating people well along the way. The rest is largely luck—being in the right place when the company needs someone with your skills, having a manager who advocates for you, working at a company that grows fast enough to create new opportunities.
So here's the real advice:
Do the work because it's the right work to do, not because you're guaranteed a promotion.
Build relationships because good relationships make work better, not because networking always pays off.
Develop your skills because skilled people have options, not because options always lead to advancement.
Read next: I Studied the Top 1% of Engineers at FAANG
4 Habits That Separate Them From Everyone Else
This blog post is a pure gold. Thanks for putting and sharing
Building relationships is sooo critical,
if nobody knows you, nobody will remember you when opportunities arise.