Recent Thinkings on Technical Leadership关于技术领导力的近期思考

Back to 2022, I gave an online talk on the topic of IC vs. Manager, sharing some of my observations and experiences from when I took on a people manager role in the Serverless department. Although this session was primarily aimed at a Mandarin-speaking audience. I've recently started jotting down follow-up notes on the IC aspects to help me recap. I think it might also be a good opportunity to share these insights with my network and exchange perspectives.

L6 at Amazon

The L6 level at Amazon covers a broad spectrum of responsibilities. I was inspired by the article "Belonging to Amazon’s Principal Engineering Community" by Carlos Arguelles, L8 SPE at Amazon, which offers valuable insights into technical leadership within the company.

One thing I’ve noticed is the limited availability of articles offering insights specifically about the L6 IC (Individual Contributor) role. Some say that L6 at Amazon is similar in scope to a Staff Engineer at companies like Google and Meta or Principal SDE at Microsoft. According to Amazon's internal role guidelines, this level involves a range of responsibilities, with varying degrees of scope, influence, ambiguity, problem complexity, execution, and impact.

Role Framework is an interesting topic. There is a book "Staff Engineer" authored by Will Larson, which outlines four archetypes for senior-level engineers: 1. Tech Lead, 2. Architect, 3. Solver, and 4. Right Hand.

At this level, you lead projects that require the collaboration of multiple engineers and teams, effectively acting as a "force multiplier." However, the challenges both technical and non-technical are significant. You’re expected to demonstrate strong technical leadership while navigating categories of problems, dealing with uncertainty, and simplify complexity.

One unique aspect of Amazon's flat leveling system is the absence of a Staff Engineer level. Instead, after Senior, the next step is Principal Engineer (L7). This gap can make L6 feel like a bit of an awkward middle ground. Some joke that L6 is the "lowest ROI" IC level across the company due to the heavy responsibilities and challenges, but without the clear distinction of a Staff Engineer role.

(Source: levels.fyi)

By the way, new MBA graduate hires are onboarded at the L6 level as their entry point.

Despite the challenges, the L6 role is a unique position in Amazon's engineering hierarchy, offering both high impact and substantial room for growth.

Deliver Results

The first question often asked in leadership roles is: How do you lead your team to deliver results ? As an L6, you're often tasked not only with leading a single project but also overseeing multiple concurrent threads efforts. Personally, I’ve contributed to and delivered 10+ VP/SVP-level-priority goals, encompassing public features, financial, and operational wins so far at Amazon. During my time at AWS App Runner, for a period, I managed 10 parallel initiatives (features, OE, security, intern projects, etc.), each with my name attached for accountability and subject to daily or weekly tracking. The key to success in such scenarios is effectively driving progress on each front, delegating tasks to the right team members, serving as the pathfinder, problem solver, and providing support where needed. Cons: I wish I had time to write code, but it's hard to find the time to fit it in.

Another common challenge is consistently meeting seemingly impossible timelines, how do you achieve that? I recently answered this question in a LinkedIn article. Here’s a summary of my approach:

Start with Realism

Begin by assessing the situation realistically. Identify what can and cannot be changed, and understand the level of flexibility in the following areas:

Resources: Can additional team members be added ?

Timeline: Is there room to adjust deadlines ?

Tasks: Can you implement phased milestone launches ?

Collaborate and Prioritize

Work closely with cross-functional teams partners, product, and engineering to define and prioritize tasks. Break things down into high, medium, and low priority.

Seek Guidance from Senior Leadership

Engage regularly with senior leadership and other functional teams. Don’t hesitate to ask for their insights and guidance. Use their input to shape your decisions and ensure you're on the right track.

"A Right, A Lot"

Achieving the "right" outcomes consistently is hard but essential. It's a long-term discipline that helps ensure success not just in the short term but over time, through delivering real value.

The combination of realism, collaboration, and guidance from leadership will help steer your team toward delivering results effectively. The challenge is hard, but when you get it right, the impact is significant.

Embrace a Variety of Tasks

As an L6, don't hesitate to take on a mix of responsibilities, such as region build, operational excellence (OE), and other tasks that may not always be high-profile. One of my mentors once told me, "Take on diverse tasks and get hands-on experience whenever possible. It will give you deeper insights into the real challenges your team faces and help you stay grounded in solving actual problems."

I worked on a multi-year project on a relational database migration. While it wasn’t a flashy initiative, it ultimately generated a good return, millions of dollars in annual cost savings and earning recognition as a major AWS Ops Win during an AWS Weekly Ops Meeting.

Balancing these tasks is key. While not every task may seem glamorous, the team will appreciate your versatility and willingness to dive into the details. It also allows you to maintain a well-rounded perspective on the work being done.

Bandwidth Management

The busiest times, my calendar quadruple-booked for the same time slot. When you’re juggling multiple tasks and communication channels, it can be easy to fall behind too many Slack messages and not enough time to reply. It’s important to manage your bandwidth effectively. Here are some strategies that help:

Maintain Document: Avoid relying solely on verbal communication. Instead, write things down. Create documentation or notes so that others can easily reference and find answers when needed. This ensures that important information is captured and accessible, even if you’re not available to answer immediately.

Use Channels for Discussions: When you have team discussions, do them in a shared channel. This way, there's a record that people can come back to and search for answers, reducing the need for repeated explanations.

Avoid Micromanaging: It’s tempting to want to sit down with everyone and personally debug issues together. I love doing that spending half a day troubleshooting side by side with team members but it's not scalable. If I spend too much time on individual tasks, I risk losing focus on bigger priorities, and it doesn't help onboard junior team members or ensure long-term productivity.

Effective bandwidth management is about balance giving guidance, but also creating a system where people can find answers independently and where your time is spent on the highest-impact activities.

Motivating Teams and Scaling Impact

As an L6, you’re in a position of leadership and authority within your team. However, it's important to remember that leadership at Amazon is about empowering others and fostering a collaborative environment.

One of Amazon's long-standing cultural principles is the "no-author" culture in Quip, which means that everyone is a contributor. Anyone can leave comments, suggest improvements, or provide feedback on documents. This fosters a sense of ownership and collective responsibility across the team. You can read more about this unique approach to documentation and collaboration in this LinkedIn post by Carlos Arguelles.

To motivate your team and build a strong sense of appreciation, always value their contributions. After each project launch, take the time to send an internal appreciation letter acknowledging the efforts of the team and any groups you’ve worked closely with. This small gesture can go a long way in maintaining morale and fostering a culture of recognition.

Delegation and Influencing Your Team

As an L6 SDE, it’s simply not feasible to execute every task or look into every single issue yourself. That approach will not scale. Learning how to properly delegate tasks to your team is critical for your success and the team’s productivity.

It’s important to understand that you don’t need to write every line of code. While I still contribute to coding in my current role, it’s more common at Amazon for L6s to write limited code over the course of a year. Instead, your role often shifts to influencing the team, both directly and indirectly, to drive the execution of your design and vision.

Effective delegation is not just about offloading tasks it’s about empowering your team to take ownership, make decisions, and move the project forward. By influencing your team in this way, you help ensure progress while scaling your impact.

Customer Call, Product, OP, WBR, and PRFAQ

During my time at Serverless, as a founding engineer of the product, I gained extensive experience in public-facing activities and high-profile initiatives. I collaborated closely with the product, GTM, architect and sales teams on product promotion, including public speaking and writing blog posts. I also contributed input on re:Invent session topics and provided support for content and context.

In App Runner, I was actively involved in every customer call as a founding engineer. Similarly, in S3, our VP, Mai-Lan, strongly encourages all L6 SDEs to participate in customer calls at least once or twice a month. The product team shares a schedule of upcoming calls and invites those who are interested or relevant to attend. These calls are a vital channel for gaining insights into customer needs and enhancing our contributions as an engineering team. Additionally, there are engagements such as WBR, OP reviews, and other similar initiatives that provide L6 ICs with a deeper understanding of the product and business, which in turn enhances our ability to make meaningful contributions to the company. It is long run value. In my previous departments, I participated in OP, WBR/MBR meetings and provided input, and I also contributed to writing several PRFAQs alongside the product team. "Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers." - Andy Jassy.

Partnering with SDMs

As an L6 Engineer, it is usual to collaborate with one or more two-pizza teams in daily work. Your manager and skip-level manager are key partners, and it's important to work closely with them, especially on directional discussions. SDMs (Software Development Managers) often have a more complete view of the project than ICs. Collaborating with SDM and people senior than you helps you better understand the roadmap, build wider vision and provides an opportunity to offer valuable input based on your technical perspective.

Give Feedback in Real Time

One of my managers, an L7 leader at Amazon, shared a valuable approach for communicating with teammates: giving "minutes feedback." This means providing feedback shortly after an event or interaction, while it's still fresh. It helps ensure that the feedback is relevant, actionable, and timely, allowing teammates to improve and adjust quickly.

Bar Raiser

I serve as an internal change management Bar Raiser since my second year at Amazon until now, which is different from the interview one. I have participated in a Bar Raiser group within each department I’ve worked in. In this role, we review every release change from various teams within the department and hold the final approval authority. We hold weekly office hours, rotating the responsibility to provide input on each team's operational excellence, pipeline, automation processes, etc. We are meticulous and set high standards. My first mentor at Amazon once described an ideal change management to me this way: "The level of rigor needed is such that, if you hand the process to a colleague with no context, they should be able to carry it out without additional support." Serving as a Bar Raiser has deepened my understanding of Amazon’s commitment to "Insist on the Highest Standards" and given me more opportunities to learn about the work happening across different teams. It is crucial to ensure quality.

Be Inclusive and A Team Player

Transparent communication and inclusion are critical, yet they’re often overlooked or met with hesitation. People might fear the conversation being derailed, worry about additional obstacles, or struggle with other uncertainties. To address these challenges, it’s essential to keep everyone involved, don’t exclude people from meetings, emails, or Slack channels. Sometimes, you may observe engineers, and even some managers, behaving not like this. Keep in mind, you might bypass colleagues a few times in the short term, but over time, this behavior is noticed and remembered. It's important to work collaboratively and be a good team player.

Years ago, a respected manager encouraged me to adopt this mindset, and I’ve embraced it ever since. Limiting discussions to an exclusive or small group can sometimes signal overconfidence or a lack of readiness to accept diverse input. Unless the conversation is confidential or involves personal privacy, keeping a wider audience informed provides visibility into your work, creates opportunities for valuable feedback, and ensures you don’t miss what you don’t know. Managers can’t always catch every detail, so inviting broader participation helps ensure important threads are audited and given proper attention.

Inclusion, in another sense, also refers to Diversity, Equity, and Inclusion. It means embracing people from diverse backgrounds and cultures with an open mind, and supporting each other as a team. At S3, we have an internal Inclusion Ambassador program, with monthly meetings where all Ambassadors come together to reflect and share insights. Similarly, AWS offers the Global Inclusion Ambassadors program, which is open to the public.

I served as a mentor for the Military Apprentice program, where I was assigned an apprentice at Alexa Healthcare. He was previously an Air Force aircraft mechanic stationed at Whidbey Island in Washington, and transitioned into a software development career. At first, I wasn’t sure if this transition would be successful, as he lacked much foundational knowledge. However, looking back, it was a deeply memorable and valuable experience for me. During the program, we learned from each other. I provided him with context and guidance to help him understand the fundamentals of software development. Today, I often see updates on his progress, he’s now a highly skilled software engineer. Real innovation thrives when diverse perspectives are brought into the conversation, and every voice is heard.

Politics

There’s no easy way around office politics. The key is to be straight and explicit in your communication. At the same time, it's important to understand where people are coming from, be empathetic and kind. If communication issues arise, address them directly and work to fix them.

Philosophy

As Joe Tsai, Chairman of Alibaba, once said, "Leadership is about dealing with people, getting others to do what you want them to do." While practicing this skill can be challenging, it's a vital aspect of technical leadership. Learning how to effectively collaborate with and motivate others is the key.

As for me, my philosophy is simple: People will have their likes and dislikes, that’s expected and nothing new. Always stay humility and empathy. Keep open and straight.