During my time as a Leader in Software, I’ve always had a Venn diagram in my head of what I expect from the individuals on my teams. As it turns out, that Venn diagram gets very messy, very fast. Luckily, I have a penchant for Notion and it has the tools to illustrate how I’d like this content conveyed. This is a rundown of what I'm calling the Roles & Expectations Framework and the finer points and caveats when using it.

Growth and career progression are deeply intertwined, so it's difficult to speak about one and not the other. The levels, roles and responsibilities outlined are hypothetical, based on the most common definitions I've observed. Having a framework like this provides a definitive, "You are here in your career, you need to do X to get to the next level." Not having something like this in place leaves a lot of confusion and differing opinions about what comes next. With it, the path is clearer and answers are more consistent.

The entirety of the framework consists of Definitions & Mappings and Applying the Framework. Definitions and Mappings contains reference material defining the different expectations, while Applying the Framework is an optional companion Notion template for individual assessments.

Definitions & Mappings

Expectation Definitions outlines specific tasks and activities per expectation; and signals detailing activities indicating an expectation is being met. For more examples and attributes that make up each expectation, you can open the definition - Notion loves its icebergs of buried content. From those examples, an informed assessment can be made and individuals can see what's required to progress to the next level.

Role Mapping includes the degree of proficiency an individual is expected to achieve. If an expectation is not listed, it's not worth evaluating on. Different roles will have different priorities, which I've attempted to map out here. These are guidelines and will likely need to be adjusted in some circumstances.

Expectations

Below is a list of expectations I have from my teams along with tasks, responsibilities and signals. Often, and for contractual reasons, whatever is outlined in the Job Description is the source of truth for your responsibilities. However, this lacks specificity and nuance. The following is a more comprehensive list of the different components to focus on in a given role and common signals indicating how an individual is performing. They boil down to these 5:

• Execution - The ability to get it done. This should always be the highest priority. When all is said and done, if you don’t deliver, the rest doesn’t really matter - it's just speculation. The definition encompasses individual impact and includes components like communication, project management, initiative, etc.
• Craft - In software, these are the day-to-day fundamentals. Where Execution is an emphasis on “How it’s done”, Craft emphasizes “What is done”. Craft highlights the impact of technical contributions, or "hard skills".
• Design - Complementary to Craft, this is the macro component - establishing technical strategy and vision, designing solutions using that direction, and deftly guiding solutions to realization. It is synonymous with Technical Leadership, but is not exclusive to leaders and should have contributions and ownership from varying levels.
• Enablement - This is the impact you have on your groups and general community. It’s about contributing to a group’s wellbeing, culture and emotional health. There are some components that are inherent in day-to-day operations, and some that require proactive actions, like mentoring and coaching.
• Management - For lack of a better word, these are responsibilities that are typically owned by people leaders involved in building and optimizing high performing teams. Even if owned by people leaders, others can, and should, contribute to a selection of these activities to some degree.

These are the main things I look for when asked by a report, “How am I doing?” Within each of the Notion definitions, you can open it to find a list of additional examples detailing what would be expected at the different levels. However, depending on the role and level, different expectations will have different emphasis. That’s where the second table comes in: Role Mappings. It references a selection of the defined expectations, and will state what should be prioritized along with the expected proficiency.

Role Mappings

Here, the nuances of the expectations are outlined according to Level of Expected Proficiency, Priority and Scope. These are guidelines, and as with anything, there will be exceptions to the rule.

Proficiencies

The different proficiencies outlined include:

• Contributes - Participates in the activities and expectations listed to varying degrees. This can include performing the activities, contributing feedback and adhering to outlined processes
• Proficient - An advanced level of contributions and more understanding of the nuances involved in activities performed.
• Mastery - Complete knowledge of a domain, with a full understanding of the landscape and compromises that come with different approaches. Plans, acts, and communicates as an authority on subject matter. Provides support, guidance and direction as needed.
• Ownership - Demonstrates mastery, provides support and guidance, and indicates responsibility for the applicable domain at the listed functional level. Has the final say on matters, and is ultimately responsible for any outcome.
• Oversight - Holds the individuals with ownership accountable and provides support, guidance and direction as needed. Should also demonstrate mastery over a given domain or area of responsibility.

Priorities

The priorities are as follows:

• 1..n - If there’s ever a question of what should be prioritized, the lower value should come first. For example, with newly minted devs, I would expect Craft to be prioritized over Design. It's expected to have all the fundamentals down before going into larger design considerations.
• “+” - This is a constant expectation. It’s not prioritized because it must be done and continually considered. It is typically associated with Execution, and Enablement. Execution is constant because if you don’t deliver, what did you actually accomplish? And Enablement because we’re all part of the bigger picture and need to consider our impact on the groups and communities we’re part of.

Scope

The one other area to draw attention to is the type of proficiency: In-Team, Cross-Team (X-Team) and Org. Different roles will have different scopes of responsibility and levels of ownership. In-team has proven to be pretty straightforward, but cross-team and org level can vary wildly according to the organizational setup. But, because of the framework's flexibility, it's easy to create a pseudo-RACI and layout the expectations across the different software levels, even at a departmental or organizational level. When dealing with cross-team ownership, it helps to have ownership over a specific value-stream. See the book, "Team Topologies," for a deeper dive into optimizing team structures.

Beyond the framework: Projects

At the moment, this framework only encompasses activities, processes and outcomes at various team levels (single / cross-team). It does not account for project related expectations because those are related to business outcomes and are a whole other topic. Within the business strategy and decided projects, each team must perform ... and that's where this framework applies. Rely on your friendly neighbourhood product team for project level objectives and outcomes.

Applying the framework

If you're a Notion enthusiast, this section is for you. If not, simply use the framework as reference material and apply however you like.

You can use the Notion template provided here to provide individual assessments. It is broken down into 2 sections: Assessments and Assessment Outcomes. Assessments is a way to group and summarize the information, and Assessment Outcomes provide a place to finalize the assessment with notes, feedback, and action items.