As your career progresses, it can become increasingly difficult to understand how to move up the ladder as an individual contributor. Extending on our "Square’s Growth Framework for Engineers", we are now sharing in depth what it means to grow from being a team leader (Level 6) to being an organizational leader (Level 7), specifically focused on the journey for individual contributors.

While everyone’s career path is unique, we’ll navigate through ways you can become an organizational leader by partnering with your Engineering Manager (EM), Product Manager (PM), and peers within your organization. Keep in mind, this is focused on the journey, and is not necessarily a step-by-step guide or timeline.

Each section will reflect a part of our engineering ladder, and will include questions to help you think about your own path, achievements, and personal goals.

Personal Growth

Ultimately, you are responsible for your personal growth. Learning opportunities might be dependent on projects and teams, but it’s crucial to acknowledge that you are the driving force behind what you want to learn next. Growth can have many different destinations and it isn’t “one path fits all”.

There are multiple avenues available for engineers to achieve personal growth, such as: coaching programs, employee communities, internal technical groups (Java, Ruby, Go), and meetings with your lead(s). Below are some questions to ask yourself as you start to consider leveling up.

Questions to assess

• What avenues are available to you and which ones can help you the most?
• When having a 1:1 with your manager, do you raise issues you have been personally struggling with or do you just do project updates? Do you ask them about team strategy and how they think about specific problems?

Are you making use of your 1:1s with your managers to the fullest extent? Are you discussing topics that might make you feel uncomfortable but will help you grow?

• If you have a 1:1 with your skip-level manager, do you try to learn about the organization and where other teams are struggling? Or do you keep it informative and solely focus on your team’s current needs?
• Do you surface issues with your leads, skip-levels, GMs to help them identify gaps in your product and software?
• When discussing with adjacent teams about a project, do you only talk about said project, or do you try to learn more about some of their technical problems?
• When working, do you feel comfortable? If you do, what do you want to learn next?

Myths about Growth

Growth only happens in specific teams

As a team leader, your duties have several dimensions. For example, designing and implementing complex technical solutions that are scalable and maintainable, leading cross functional efforts to help refine project requirements, providing technical guidance to your team, and participating in hiring, onboarding, and leveling-up talent.

By definition, looking beyond you and your team’s immediate needs to solve problems shared through the organization is one of the paths to identify work for leveling up. It is possible regardless of the kind of team you’re on. For instance, you could join cross-team working groups, create shared systems/APIs, or help drive technical communities, as these venues can surface opportunities (new frameworks, paradigms, or technologies).

Growth only happens when you do two jobs at once

There's a general misconception about growth: that at some point in time, you will have to do two jobs instead of one, basically doing the work of a team leader and doing extra hours to fit in organizational leader type work. While situations like this could happen for a myriad of reasons (e.g. an urgent project), the transition from one level to the other is gradual. It means your current role and responsibilities will slowly evolve. While learning takes time, time spent isn't necessarily an indication of learning. That means spending a long time as a team leader or working long hours isn't an indicator of growth and does not prompt a promotion.

Self-Reflection

Assess

Before looking to the next level, two of the most important steps are to self-reflect and assess where you are right now. Look at the ladder for where you are and see where you are currently meeting, or not meeting expectations. Look for elements you could improve on. While you will start this exercise on your own, engage with your manager to hear out their perspectives. Having you and your manager separately assess your gaps to the next level and then comparing notes can be a quick and effective way to align. Together, work on developing strategies and creating opportunities that will enable you to grow and demonstrate your capabilities as a team leader.

For instance, if you aren't diffusing knowledge within your team because you’re focused on delivering a critical feature for the past months, your manager could encourage you to present your learnings to your peers. If these venues do not exist, discuss how to create them so your teammates can learn from your work.

If you and your manager agree that you solidly meet expectations as a team leader, start a conversation on how to become an organizational leader. Do the same as above: look at each criterion and grade yourself, pulling out examples from your hype doc, and ask for feedback from peers when needed. If you have 1:1s with your skip-lead (your lead’s lead), ask what they think about your assessment and ask for general career advice.

Personal Goals

As part of the reflection process, it's essential to be honest with yourself and assess what you would like to do more and what you would like to do less of as your career progresses. Defining this will help you understand the different paths that can lead to becoming an organizational leader and whether you'd be interested in those paths. Since growth isn’t linear, keep an open mind about other types of adjacent roles you could potentially move into laterally (e.g. people management or product development) or skills/areas of expertise you could take on.

Below are questions you can ask yourself to help assess this:

• What past impact have you found satisfying or are you most proud of?
• What past work felt the least satisfying and rewarding to you?
• On a day to day basis, what are some of the key responsibilities you really enjoy doing? What are the ones you would like to do less?
• Do you prefer to work on one project start to finish or be involved in N projects mostly just during the critical stages?
• Do you see yourself doing more strategy and planning, such as annual planning, quarterly prioritization, cross-team negotiations, scoping projects, doing task breakdowns and milestone definitions?
• Do you see yourself working with more teams across Square or would you prefer to work more closely with your current team?
• Have you considered managing a team, focusing on leveling-up engineers? Have you tried being a mentor? Do you find it rewarding?

Scope of Impact

Technical team leaders are responsible for complex, medium-to-large projects, which often involve several engineers and require deep expertise in several systems and technologies. In this role, you are acting as a DRI (directly responsible individual) that collaborates closely with PMs, EMs, and adjacent teams; you write design docs, help refine the product requirements and enable your teammates to execute on the plan. All of this work is relatively constrained within your team's boundaries but, at times will involve others for things like integrations, handling deprecations, and migrations.

The transition from a high-performing team leader to an organizational leader mostly lies in the scope and impact of your work. As a team leader, you mainly impact your team; As an organizational leader, you have an organization wide impact. Defining impact varies per organization, so while we will do our best to provide examples for most, it's unlikely we'll cover all of them.

Team

The transition from team leader to organizational leader is first and foremost within the day-to-day work on your team — you need to continue leveling-up engineers around you by enabling them to take on more complex projects, which in turn enables you to think more about the organization’s needs. You can achieve this through mentorship and coaching. For example: if an engineer is working on a design doc, pair with them to guide them through the process, think about the different edge-cases, assess the technical risk properly, and involve the right set of reviewers. If you are working on a large initiative, are there complex projects within it that could be designed and developed by another engineer in your team if you provided enough support for them to thrive?

Aside from leveling-up peers, there will be a gradual shift in how you think about projects and make decisions. You will have to balance tradeoffs between long-term goals and immediate short-term needs. In return, this will help inform and shape the technical strategy, by guaranteeing the right level of prioritization is done to enable long-term technical success of the team. For instance, if your team is about to start a new service, have you looked into cloud deployment? Have you talked with adjacent teams to understand what the current best practices are? Have you engaged with your EM and PM to allocate more time to do more due diligence?

Within your team, and as your role continues to evolve, your EM will gradually become more of a peer as they need to extend themselves: they will tap into your knowledge of the system and technical challenges to refine key investment areas, collaborate on strategy and execution, and define rough timeline estimates. This collaboration becomes even more critical during quarterly and annual planning.

During this transition, continue to keep an eye out for where your teammates are struggling, the types of problems they are trying to solve, and the types of trade-offs made. All of these can be early indicators of areas that need improvements at a technical, strategic, and operational level.

Organization

Organizations are less explicit about their struggles. They don't ask for support, they don't state the problems everyone faces, and they don't make requests. As a result, it is more challenging to identify improvement areas. To gain visibility into these issues, one strategy is to be more involved with cross-team efforts, to set recurring 1:1 with other tech leads in other parts of the org. This will help get broader context and connect the dots of common organizational problems.

If you’re not on a team that collaborates with external teams, engage with your EM and PM to create these opportunities. Cross-team partnerships could be about building public APIs where you will need to work with other experts in your company and multiple functions to get the right feedback. They could also be about internal product integrations. It's a perfect time to discuss the architecture that spans across multiple platforms and systems, and it's a great venue to learn from one another.

Being recognized for having an impact on the organization takes time and you will need to make sure your work is visible to your leads (through 1:1s, hype doc, yearly performance review, or direct callouts from other teams in weekly updates). The more your work is visible and appreciated by other teams, the more you will get involved in cross-team collaborations which, eventually, demonstrates organizational work.

Below are questions to help you:

• What are some of the challenges teams you are working with have faced during this project? Is there something we could do to make this better next time? Could a framework, new service, or cloud solution help? Could new processes help?
• What are some of the disagreements that have occurred within the team recently? How did you identify the differences in perspective? Did you help resolve the conflict? What are some of the things you or your team will do differently next time?
• Are there gaps in your software that will block future integrations? Are your team APIs explicit and simple enough? Are they returning good error messages? Are they following Square API recommendations?
• What are some of the issues your organization is constantly facing? For instance, when migrating to the cloud, are all teams well-supported? Do they have the keys and support to start this process? If not, what are some of the missing pieces you could help with?

Technical Execution

As a team leader, teammates recognize you as a technical lead (not to be confused with your manager). The projects you are directly responsible for are often complex, involve multiple engineers, and tackle some critical challenges (such as scalability and interoperability). In this role, you collaborate with EMs and PMs to help refine feature requirements and ask for resources when appropriate. When you are not directly involved in specific projects, you are participating in other initiatives through regular design reviews and early whiteboard sessions.

As your expertise and visibility grows, other technical leads within your organization will reach out whenever they need guidance or support. The transition happens slowly across multiple dimensions: depth and breadth of knowledge (not always technical), demonstrating the ability to think long term and take principled risks, and helping your team execute on a shared vision by leveraging multiple initiatives to reach set goals.

Project Management

As you progress to an organizational leader, you will continue to be directly responsible for projects of different scope, but the more complex they are, the more you will have to defer. In practical words, this means you won't be responsible for handling all the design docs, but you will have to provide direction and to mentor peers to write them. You will need to lead meetings that span across multiple disciplines and teams. You can think about this as growing into a role where you guide the tone and overall structure and others might execute on specific parts of the plan while you continuously provide support and ensure delivery.

Another area that will change slowly: it becomes your responsibility to work with your PMs and EMs to guarantee the product development processes are setting the team up for success. For instance, if you are having issues tracking who is working on what: did you try setting project standups? What have been some of the takeaways? Is this something your team should adopt for all initiatives? Drive these with a growth mindset: identify the problem, try a potential solution, learn, adjust; continuously monitoring and assessing changes based on pre-established goals can help refine these processes.

Expertise

Technical Depth

We all know that building expertise takes a significant amount of time. It can be about a given technology/framework (e.g. databases, frameworks, iOS, Android or hardware), but it can also be about architecture principles (SOA) or best practices (RPC, REST). As you develop more technical depth, you will be recognized within your team as the go-to-person for improving technical solutions, troubleshooting issues, collaborating with other engineers on adding features, and sharing knowledge.

As you become more experienced, it's necessary to take additional steps along the way to guarantee your knowledge gets diffused across your team and your organization. Many venues are great channels to communicate and share knowledge: presentations, workshops, mentorships, write-ups of guides and readmes.

Another dimension to building technical depth is to observe where others are struggling. It's an opportunity to provide abstractions, to create new frameworks, or invent new patterns. While some of these improvements could be small, keep in mind that some might be significantly larger and will require working closely with your EM to get these initiatives staffed and prioritized.

Below are some questions to help assess where your team may be at with this:

• Are others in my team knowledgeable about the technologies we are using?
• Are your frameworks enabling you to build robust solutions on top of a given technology? What are some of the key missing elements?
• Do other engineers in your organization know how your system works? Are there elements we could share with them?

Technical Breadth

By working on multiple projects, you will gain technical breadth. Your exposure to several parts of the system (e.g. jobs, feeds, webhooks, APIs) will help you understand how it works and how consumers use it. An analogy to technical breadth is often the big picture. It means you might not know each part of the solution in detail, but you will know enough to facilitate projects and architectural discussions.

Contributing to defining the big picture doesn't come overnight. It is a sustained effort to understand the foundational principles of your codebases and upcoming projects, future needs, and how they all fit together. Taking a principled approach here ensures that current projects in the roadmap fit within the long term vision.

With breadth comes a focus on collaboration and leadership. As you grow in the role, you provide technical insights other leads might not know or might have overlooked (e.g. a simple change in a given system might require a full overhaul), and, when observing problems that would require engineering support, you work with your manager on how to help staff these initiatives, taking into account your peers’ strengths and area of interests.

Questions to assess

• Does the product requirements document outline only the immediate needs? Are future use-cases considered? How expensive will it be to adapt to future use-cases that aren’t quite known right now?
• If we build this system now, will we have to rewrite it soon after? Is this an MVP that we can easily deprecate? Or will the path to deprecation be long and slow?
• For the current application architecture, are there areas that require more investment than others for the team to continue to operate?
• Are the tools currently in place enough to provide a good understanding for the different user flows and how they are currently performing? For instance, finding the latency of when a payment is completed to when data is available to 3rd party developers via webhooks.

Long-Term Approach

The most challenging requirement of becoming an organizational leader is to take and demonstrate a principled long-term approach so that future maintainers are able to contribute effectively to your team's codebase, and add new features.

For instance, when working on a new initiative: do the components of the system you are building have a clear and distinct responsibility? Are you discussing current and future use-cases, to navigate the balance between extensibility, maintainability, and simplicity? Have you assessed the different tradeoffs by seeking divergent opinions and perspectives?

This long-term thinking also applies to legacy codebases. It's often a good exercise to identify the existing problems of a codebase, assess what the risk is if your team doesn't invest in resolving these issues, and come up with strategies on how to tackle them. While this fits slightly more into a team lead role, an organizational leader will apply similar principles with a larger scope and/or higher level view (e.g. across multiple services or multiple mobile platforms).

For instance, are endpoints across multiple services providing enough information in case of errors? Are your error patterns standardized? How to create a standard and diffuse it across the organization (and company)?

Thinking about the long-term is not just about software; it's also about customer experiences (products, APIs, libraries, frameworks, hardware, etc). As a senior engineer, you are a partner to your leads, and you should assess requirements, ask questions, raise concerns, and collaborate to refine them so it’s easier for junior engineers to build the right abstractions.

Questions to assess

• Did we think about how this new feature will impact your entire codebase? For instance, adding a new attribute on a Customer profile and adding a new endpoint to manipulate only this attribute, is this the right platform approach? Could this conflict with other endpoints?
• When someone asks how to do something that seems a bit surprising, do you ask more questions to understand why they're trying to do this? If it's because an EM / PM / other person said so (i.e. they didn't stop to really ask why / think for themselves), can you help them have that conversation or raise awareness?
• Does this belong to the operating principles of your codebase? For instance, if the codebase is scoped per user, does it make sense to add support for non-merchant scoped data? If so, how do we achieve this so it works across the board?
• Does this solution solve future use-cases? For instance, if adding support for lookups by emails using a Global Secondary Index in DynamoDB, can we guarantee uniqueness of emails and if not, what other patterns could help us achieve this?

Ownership and Strategy

As a team leader, your role is about guaranteeing your projects are successful. It means managing timelines, expectations, assessing risk, collaborating with engineers to uncover blockers and unknowns, and ensuring your initiatives are on track.

As an organizational leader, while you will still be owning complex projects, you will have to step up and contribute more to the technical and engineering strategy. Engineering strategy is about defining how the organization will meet its objectives, as well as defining new ones. You get to contribute beyond the technical implementation and work directly with other leads to shape the team's structure, help establish a project prioritization strategy, and collaborate on a long-term vision.

In your current role, you're likely doing some of this without necessarily knowing it. For instance, you are contributing indirectly to the technical strategy when your EM mentions a future project and asks you to provide rough estimates and risk assessment; and, through exploration, to issue a recommendation on one of the identified solutions.

Technical Strategy

As you gain more experience, you can start having a small impact on the strategy by escalating to your manager and your peers opportunities and unsolved challenges. They might be related to making the software more scalable, more available, and more extensible. As you do so, a simple framework to follow is to always include risk: if the team doesn't start working on this opportunity within the next 12-24 months, what would be the short and long-term risk?

As time passes, you will find yourself doing more and more of these. Sometimes, it will require writing a document to explain what you have in mind, why you believe it's essential, and what kind of benefits this would add to the team, organization, or company. Your manager might ask you to contribute directly to the team's yearly roadmap and annual planning, which is a great exercise to do as it helps you appreciate how projects fit within the overall company goals and strategy.

Below are additional questions to consider.

• Do you know when your services will scale out (for instance, exceed storage capacity)? When should the team address it?"
• Sometimes, it's about the state of software development: if it takes four weeks to add a new feature instead of the planned 1 week, what did we miss in the task break-down?
• Are there parts of the software that need refactoring? What can be changed in the process to provide better estimates?

Engineering Strategy

While your primary focus might be more related to the technical aspect, you may start thinking about engineering strategy and act as a collaborator in helping shape the processes and the structure of your team and organization.

For instance, if work often waits days for reviews, what can you do to make things better? Is the code review process working well? If your team has grown from 2 to 10 engineers, and it takes 45 minutes to do a daily standup, should the process be adjusted (e.g. only to include DRIs or do a slackup)? If the team is migrating the different codebases to the cloud, what would be the ideal way to achieve this while minimizing roadmap disruption?

While the above examples are mostly practical (how to make the processes more effective), other parts of the engineering strategy are more tactical. For instance, if your team requires a general tokenization service, but nobody is building one, what are the available options? Another scenario is a reorg: your input might be solicited to help identify potential team structures that are technically well-balanced and provide room for engineers to grow.

If you’re not sure how to get started here, be curious and start asking questions to your manager and PMs. They can be about the project prioritization for this year, about understanding the rationale behind a process change. Having these conversations will help you understand the why behind these decisions and how they landed on this particular outcome.

Leadership and Collaboration

As a team leader, you have demonstrated the ability to cross teams and service boundaries to solve complex problems and ensure on-time delivery. You’ve continuously shared knowledge with peers, and you’ve provided support to your leads on defining the strategic direction. As you move towards being an organizational leader, it becomes your responsibility to ensure roadmap execution and find opportunities to improve the team or organization through collaboration and leadership.

As a collaborator, you need to support your peers in delivering features and products to customers. In practical terms, it means guiding them through the exploration of multiple design solutions, helping sequence the work (from a prioritization standpoint to breaking down tasks), and proactively seeking feedback from others to guarantee proper vetting, sometimes by being inclusive of multiple functions (design, PMM, analysts).

For projects that span across multiple teams, organizations, and disciplines, disagreements can happen. You will have to help navigate the differences of opinions, guarantee the thorough documentation of alternative solutions, and find ways to reach consensus. These interactions provide an opportunity to outline your leadership abilities and be done either directly (you participate in the write up of SPADEs) or by mentoring/coaching peers on how to handle these situations.

Through these collaborations, you will have opportunities to identify gaps in your products, un-owned technical work, and future challenges. Depending on the impact, these can be critical for the organization. For instance, if working on a project that introduces user reporting to your existing application, did you ask whether or not your current architecture can handle this workload? If not, what can? If you find a better solution, what can you do to make it more broadly available for the entire organization and company? It will become your responsibility to escalate this to your leads, assess and negotiate what can be done now versus later, and establish a path forward.

These interactions will showcase your leadership and collaborative skills and how to impact the organization.

Questions to assess

• When disagreement occurs, do you contribute to the write-up of SPADEs and facilitate the decision-making process?
• Do you escalate to your manager to refine the process and try new things when the current approach doesn’t seem to lead to a resolution?
• Are you able to mentor, throughout these exercises, other engineers to understand how to address concerns and reach consensus?

Team Building

As an individual contributor, team building fits into two main sections: contributing to your organization’s growth and thoughtful hiring.

Organizational Growth

As mentioned in other sections, you are responsible for your organization's long term success. One way to achieve this is to guarantee others around you learn, grow, and develop critical skills, and foster inclusivity. Another way is to help your manager refine the team structure (boundaries, charters, codebase ownership), navigate the hurdles around project prioritization and market needs, and provide cross-team support.

One essential element to remember here is to be inclusive: continuously engage with everyone around you, help identify their struggles and opportunities for them to grow, and involve them as you seek solutions. Your time and attention are some of the highest leverages the team has to develop future leaders. Ensure you are investing in a diverse leadership pipeline in order to amplify the team’s growth and capabilities over the long term.

Hiring Talent

As your organization continues to grow, you will end up playing a crucial role in the hiring effort by sourcing, interviewing diverse candidates, and providing thoughtful feedback. The next steps are about identifying in your team and organization the unfilled gaps (whom should we hire next, which skill sets do we need), and contributing to selling/closing efforts.

Identifying skill gaps can be done by observing unsolved challenges. Organizations have similar needs; for instance: if multiple EMs are struggling to find reviewers for their public API design docs, this might necessitate talking with your skip-level and prioritizing the hiring of a REST expert. You can contribute by being an active networker, interviewer, or member of a working group focused on level definition.

Conclusion

At the end of the day, everyone’s journey is unique and what’s important is to grow at your own pace, to understand in depth what the role means and find a path that makes sense to you and what you are trying to achieve – both from a career perspective but also from what you feel the most passionate about. We hope this advice can help you progress in your career at Square, or elsewhere.

Thanks to Ben VandenBos, Enrique Patino-Daly, Krishnan Seshadrinathan, Lacey Lobenstein, Lindsay Verola, Mackenzie Ritter, Michele Titolo, Michelle Ngo, Mike Humaydan, Pierre-Yves Ricau, Richard Moot, Toby Reyelts, and Tom Carden for their collaboration throughout the writing of this document.