sveska | Career track staff

Career track staff

[last update: 09 Feb 2024]

Responsibilities:

Focused on technical decision making, leading work that affects one or more complex systems and mission-critical areas.
Consistently delivers code that sets the standard for quality and maintainability.
Has a broad understanding of our architecture and how their domain fits within it.
Systematically thinks through potential design impacts on other teams and the company.
Go-to expert in an area, with an increasingly strategic mindset.
Explores 3rd party vendors and new technologies with a sizable potential impact on the company.
Proactively offers ways to optimize the team’s systems for costs saving, scale and operational stability.
Constantly keeps in mind the company’s security orientation (preferences, requirements, current tools, certifications) when designing and building systems.
Controlling security permissions (saying no when needed) within the team, to reduce attack surface

Examples:

Integrates a new monitoring solution, including the understanding of the business needs, gathering of requirements/pains, getting buy-in, performing a DR, educating the users, and leading the execution end to end. Post-production measures impact and satisfaction.
Leads a cross-teams effort of documentation standardization.
Leads a conversation and implementation around shared libraries across teams.
Leads a conversation and implementation around how we develop in a specific language (tooling, dev experience, best practices, etc.)
Migrates a huge project of ours to use a newer technology stack that will help increase our engineering velocity.

Anti-Patterns:

Forces their opinion (potentially abusing their “title”) without giving enough attention to tradeoffs and hearing others.
Focuses only on 1-2 teams or areas, instead of looking at the bigger picture (long-term horizon).
Gives up too quickly when trying to convince people (e.g. multiple teams, many opinions) due to high friction.
Falls in love with the solution instead of the problem. Cannot adopt others’ opinions and execute on them.
Builds solutions that are too “short-term” oriented or not robust enough. This is usually due to not enriching the requirements enough - or not providing the proper solutions.

Responsibilities:

Able to plan and execute large projects with complex requirements and interdependencies across teams and systems.
Consistently delivers on-time and at a high level of quality.
Defines key metrics and measures the project’s impact.
Consistently able to reduce the complexity of projects in order to get more benefit with less work.
Contributes to all major architectural decisions and reads all tech specs within their domain. Tracks status and considers implications for other systems.
Enables more junior engineers to take a leading role in designing solutions, by helping them understand requirements and organizational context.
Able to effectively prioritise their own workload and focus across many streams of work.
Markets and advertises projects. Creates excitement for users and driving adoption.
Helps define roadmaps and set visions for long-term projects.
Works closely with relevant Product Managers to gain context and understand business needs. Able to then represent the business/product in future meetings with their teammates.

Examples:

Able to explain a project’s business impact (“why do we do this?”) and tradeoffs to a wide audience. Builds decision making context for others
Knows how to utilize meetings effectively (e.g. status meetings, daily, weekly sync) to drive project momentum and keep everyone aligned.
Acts as a single-point-of-contact in the organization for a project. Doesn’t require multiple managers to be involved in understanding the project’s progress/status.

Anti-Patterns:

Struggles to raise flags and find alternative solutions when a teammate or a dependency is not keeping up, either in terms of quality or availability.
Avoids confrontations: struggles to resolve disagreements, explicitly stating their needs, etc.
Tries to achieve too many things on their own, instead of relying on others around them: either by asking help or delegating tasks.
Inadvertently suppresses innovation by other engineers, for example by giving their own ideas first and loudest, criticising without truly listening to new ideas or by giving the impression that there is only one right solution to a problem.
Busines Involment

Responsibilities:
Understands the yearly goals and main projects of many of the group’s teams, including their business impact.
Aware of yearly organizational growth (e.g. new headcount) within the group, aimed at supporting business needs.
Can clearly articulate and explain to others (e.g. new or less experienced ICs) the motivation and business needs of our main systems.
Can lead one of the main pillars in the group and become a point-of-contact for it when talking with others (e.g. product offering, scale, costs, security, precision, etc.)
Continually involved in the team’s backlog grooming — helps the direct manager to balance tech debt, areas worth to invest in, areas where we should de-risk/mitigate potential threats, etc.

Examples:

Leads the group’s FinOps effort: tracking expenses, creating visibility, suggesting new ideas to cut costs, getting the buy-in, executing, reporting progress to the entire group, etc.
VPs (VP Precision, VP Ops, VP Product, etc.) in the org feel the need to invite them to relevant meetings, instead of inviting their direct manager. The IC is the point-of-contact, and we don’t need managers in every conversation.
Takes an active part in quarterly planning — suggests areas that are worth investing in, helps with high level estimations, consults on priorities (with good reasoning behind them).

Anti-Patterns:

Lets things live in a “limbo” for complicated domains (where ownership is a bit fluid). Is passive or unclear about time estimations, or makes excuses on why we’ve reached this state.
Doesn’t create momentum in areas they lead: waits for someone else to pick it up for them (e.g. their manager).
Acts as an owner (design & decision making) but avoids the responsibility that comes with it (i.e. continuously supporting and pushing it forward).