diff --git a/alignment.md b/alignment.md new file mode 100644 index 0000000..9bf3f33 --- /dev/null +++ b/alignment.md @@ -0,0 +1,46 @@ +## Alignment and Adaptibility +You take on the most important challenge with an open mind; to what degree are you willing and capable to take on the challenge that the organization would find the most impactful, even if it's not your first choice. You actively consider how you can best help the organization, and work with leadership to align your strengths and goals with important challenges. You improve leadership's visibility into difficult problems while engaging positively in solving them. + +Example of success in this area: You would like to work on next, to improve your technical execution skill. Leadership would like you to rotate to , which is under-allocated and needs your experience and guidance. You have already been on this team before, and would probably not choose to take on this challenge of your own volition. However, you agree to the change in plans, approach with positivity, find ways to grow your skills in other areas while you are there, and are able to address the challenges on the team. + +--- +### Proposed Levels and Skills + + + + + + + + + + + + + + + + + + + + +
P1P2P3P4
    +
  • Volunteers for and is curious about stories/chores in the backlog that are important but less interesting
+
    +
  • Volunteers for tedious/unglamorous but necessary tasks, such as chores/stories/action items/support tickets/open GitHub issues, and drives them to completion.
    • +
  • Responds to allocations changes by striving to understand the new team’s needs and context in the organization.
    • +
  • Contributes to previous decisions on a story, without disregarding previous work
    • +
  • When asked, gives feedback to team leadership about less-than-ideal team experiences.
+
    +
  • When presented with a less-desired but important project, can adapt their skills and make a positive impact on the team.
    • +
  • Contributes positively to team decisions/artifacts that they would have done differently
    • +
  • Actively surfaces less-than-ideal team experiences (e.g. tension during inception, fears surrounding upcoming release) to team leadership and can be coached to resolve them.
    • +
  • Can identify useful context to assess team health.
+
    +
  • Frames less-interesting but high-priority work to highlight the value and learning-opportunity, improving the entire team’s outlook on that work.
    • +
  • Engages deeply with difficult, less-glamorous challenges and transforms them to be more desirable and actionable.
    • +
  • Is aligned with the priorities of the organization, and approaches their team allocation as a collaborative effort with leadership.
    • +
  • Adapts their personal growth and contributions to the organization's needs.
    • +
  • Makes sustainable progress towards current goals by continuously building on legacy codebases
    • +
  • Surfaces uncomfortable issues affecting the team in a kind, honest, and direct manner; keeps leadership in the loop while working to resolve the issues.
diff --git a/cf-domain-expertise.md b/cf-domain-expertise.md new file mode 100644 index 0000000..54b5512 --- /dev/null +++ b/cf-domain-expertise.md @@ -0,0 +1,48 @@ +## Cloud Foundry Domain Expertise +You understand the CF Products: How they work together, how they work with the larger ecosystem of non-CF Products. You can navigate the CF system and its engineering teams on a broad level, and know which areas to consider in problem-solving. + +*One example of success in this area*: You are trying to decide how to implement a database migration in CCDB. You know that this change may affect CC’s communication with Diego, with Routing, and with Networking. You surface how you think the changes will affect those teams to your PM/Anchor and work to find a solution that would minimize the impact on those teams. Additionally, you loop those teams into the conversation, and ensure that the solution you are moving forward with works as desired for them. + +--- +### Proposed Levels and Skills + + + + + + + + + + + + +
P1P2P3P4P5
+
    +
  • Shows curiosity about the product their team is building (eg: how it helps customers, who are the downstream consumers, how to downstream consumers rely on it)
    • +
  • Shows curiosity about bigger picture (boxes and lines) of CF (eg: watched videos from Cloud Foundry Summit, reads materials relating to technical concepts when presented by colleagues)
+		 +
    +
  • Has working knowledge about the product their team is building.
    • +
  • Is learning about how other teams/downstream consumers/customers use their product
    • +
  • Relates stories in the backlog to downstream consumers it would affect
    • +
  • Diagnoses issues that involve interactions with multiple CF components
    • +
  • Can explain boxes-and-lines version of their team's product
+		 +
    +
  • Has sound knowledge of the team's product(s) and its downstream consumers, and can be counted upon to represent the team's interests.
    • +
  • Preemtively identifies dependencies/repercussions of features on downstream consumers and past releases
    • +
  • Provides context on their team for historical decisions, features in past releases, and their team's domain
    • +
  • Can explain boxes-and-lines version of CF and is able to provide a more detailed view on CF components
    • +
  • Can ramp up a new PM on team domain, or fill in for their PM for short periods of time.
+		 +
    +
  • Has working knowledge of an area of CF (eg: the BOSH ecosystem, the Platform, Logging and Metrics)
    • +
  • Preemptively identifies dependencies/repercussions of an epic to all consumers within a domain area; can suggest changes to required components to resolve it
    • +
  • Teaches Pivots on their team about a particular CF domain area
    • +
  • Leverages their knowledge of related domain concepts to better the product
    • +
  • Can explain how a CF domain area has evolved over time (including familiarity with features in past releases)
+		 +
    +
  • Takes measures to dissipate their CF domain knowledge with a goal of empowering their team
+
diff --git a/collaboration.md b/collaboration.md new file mode 100644 index 0000000..ed5019a --- /dev/null +++ b/collaboration.md @@ -0,0 +1,61 @@ +## Collaboration +You communicate clearly, proactively, and kindly. You initiate the communication in challenging situations. You behave in a way that ensures safety, inclusion, and recognition of fellow pivots. Your behavior leaves space for others to speak, and to disagree with your views. You contribute positively to our culture. + +*One example of success in this area*: One of your teammates has a frequent habit of interrupting others in meetings, especially when they’re excited about an idea. You find them after a meeting, and directly but kindly deliver this feedback. They don’t know what you’re talking about. You ask if it would be okay to stop them next time this happens. They agree. In the future, the team feels comfortable with giving feedback about interrupting in meetings in the moment. + +--- +### Proposed Levels and Skills + + + + + + + + + + + + + + + + + + + + + + + + + + +
P1P2P3P4P5
    +
  • Communicates clearly and kindly with team mates
    • +
  • Actively leaves space for others to share their ideas
    • +
  • Is conscious and respectful of team's agreements (eg: core working hours)
    • +
  • Communicates with the intent to learn, and creates a safe space for others to disagree
    • +
  • Pairs easily/successfully with most Pivots and/or teams
+
    +
  • Actively works to build a more inclusive team.
    • +
  • Takes responsibility for their mistakes and/or misunderstandings, and can then focus on future improvements at the personal or team level.
    • +
  • Asks questions with humility, adding context about their existing knowledge or uncertainty.
    • +
  • Is self-aware and seeks feedback from their pair in the moment to ensure they are aligned
    • +
  • Initiates cross team communication when necessary
    • +
  • +
    +
  • Sets an example for clear and kind communication in a disagreement.
    • +
  • Openly reflects on the impact of their own behaviour and makes improvements.
    • +
  • Recognizes and gives T.A.S.K feedback about exclusionary behaviour
    • +
  • Tailors their communication style to collaborate well with a variety of personalities.
    • +
  • Fosters a healthy learning environment, by teaching and modeling a blameless culture. e.g. Facilitates growth-oriented discussion following a mistake or fire, encourages teammates to share their own growth goals
    • +
  • Brings teams together by promoting cross team collaboration (including orchestrating logistics, facilitating group meetings)
    • +
    +
  • Strongly facilitates decision-making where there are several conflicting viewpoints
    • +
  • Knows their blind spots and actively works towards managing them
    • +
  • Skillfully speaks up to address exclusionary behaviour in the moment
    • +
  • Coaches Pivots to recognize areas which could be benefitted by cross team collaboration
    • +
    +
  • Is a source of guidance across Pivotal in areas of productively managing personal conflict and/or contention
    • +
diff --git a/engineering-process.md b/engineering-process.md new file mode 100644 index 0000000..6ad0cb5 --- /dev/null +++ b/engineering-process.md @@ -0,0 +1,50 @@ +## Engineering Process +You understand the importance of maintaining feedback loops on an engineering team. You can expand on the philosophy behind our engineering process. You can innovate on our existing process to tailor practices to your team's needs. + +*One example of success in this area*: Your team is not very disciplined about build failures in CI. You start a conversation with your team to understand what could make CI more useful and share the pain you observe when CI is red. After discussing it, you make a chore to refactor your concourse pipeline, in order to get more actionable signals from each portion of the pipeline. Over time you use these signals to incrementally improve your CI pipeline and educate your teammate's about the importance of integrating early and often. You are eventually able to get your team to a point where CI being red is no longer the norm. + +--- +### Proposed Levels and Skills + + + + + + + + + + + + +
P1P2P3P4P5
+
    +
  • Follows along with existing engineering process on teams (eg: TDD, pairing, CI and Tracker discipline, etc.)
    • +
 +
    +
  • Understands and explains the importance of improving feedback loops
    • +
  • Makes small tweaks to engineering process on their team, in response to retro items or team discussion.
    • +
  • Can onboard new team members on existing processes
    • +
  • Understands and explains why balanced teams and balanced decision-making is important
    • +
  • Can explain parts of our engineering process in terms of improving feedback loops
    • +
  • Shows discipline in upholding the team's engineering process
    • +
  • Provides feedback to teammates.
+		 +
    +
  • Understands and explains the XP/Agile principles behind specific practices of team's engineering process
    • +
  • Identifies problems on teams that can be fixed by changing engineering process
    • +
  • Advocates for a balanced team, and facilitates balanced decision-making
    • +
  • Actively works to improve engineering process and feedback loops on teams
    • +
  • Provides T.A.S.K feedback to teammates, that helps teammates grow
+		 +
    +
  • Provides challenging feedback (kindly) and coaches teammates to change their behaviour
    • +
  • Teaches our engineering process to new Pivots and relates it back to XP/Agile principles
    • +
  • Recommends and proliferates team-wide changes to engineering process, to fix team pain-points.
    • +
  • Adapts to different flavors of process and ties it back to XP/Agile principles
    • +
  • Is an exemplary role-model for practicing and facilitating balanced decision-making
    • +
  • Continually works to evolve the engineering process on their teams
+		 +
    +
  • Innovates on engineering process and evangelizes that change across the org. Follows through by helping relevant and interested teams adopt it successfully
+
diff --git a/flow.md b/flow.md new file mode 100644 index 0000000..9593c99 --- /dev/null +++ b/flow.md @@ -0,0 +1,49 @@ +## Flow +You understand how software makes it from an engineering team to the customer, from start to finish. You can evaluate and explain the "flow" of work through this system, and identify bottlenecks. You can help your team prioritize these bottlenecks, optimizing for a positive impact on downstream consumers or for customers. You use your flow knowledge to advise teams surrounding yours, and to avoid blocking their work. + +*One example of success in this area*: An investigation in your backlog has been blocked for days. Your teammates have made a valiant effort, but no one has found a way forward. You find a way to implement the feature without needing the blocking dependency. You outline a plan for integrating the dependency once it’s ready, and talk to the upstream team to finalize it. + +--- +### Proposed Levels and Skills + + + + + + + + + + + + + + + +
P1P2P3P4
    +
  • Is learning about how their team's artifacts flow to the customer (eg: release process, CI pipelines, dependencies)
    • +
 +
  • Recognizes symptoms of reduced flow on their team (eg: persistently red CI, flaky tests, manual release process)
    • +
  • Cognizant of blockers (eg: blocked stories, CI, releases) and work with the team to unblock them
    • +
  • Resolves flow-related pain using modifications to existing process or tools
    • +
    +
  • Recognizes when and why team has reduced flow; surfaces the feedback to team leadership and at team retros
    • +
  • Frames symptoms of reduced flow in terms of customer impact
    • +
  • Can smoothly integrate upstream depedencies into team's work with little impact to team's rate of delivery
    • +
  • Ensures that their team is communicating clearly so as to avoid blocking others when possible
    • +
  • Adapts to changes in volumes of prioritized work so as to enable smooth delivery (eg: can work with PM to plan for tracks that can be parallelized, or unified to increase/decrease throughput)
    • +
  • Reflects on a team's release process and continually evolves it to improve flow over time
    • +
  • Can articulate the impact of breaking changes to downstream teams and to customers
    • +
  • Breaks out of the existing tools or processes when necessary, to reframe and fix a flow issue
    • +
    +
  • Recognizes systemic bottlenecks in delivering value to customers
    • +
  • Can identify and implement processes that provide the team ongoing feedback on flow
    • +
  • Intervenes to address systemic bottlenecks in delivering value to customers, using a variety of skill areas (e.g. technical execution/process)
    • +
  • Has knowledge of flow across the organization, and proactively shares context to unblock teams.
    • +
  • Applies engineering principles (rather than manual processes/toil) to improve flow
    • +
  • Can coordinate, execute, deliver to customer on complex integrations amongst multiple teams
    • + +
+ + +
diff --git a/niche-skill.md b/niche-skill.md new file mode 100644 index 0000000..86c35a5 --- /dev/null +++ b/niche-skill.md @@ -0,0 +1,8 @@ +## Niche Skill +Optional placeholder category, for specific skill-sets or specializations which are not expected of every pivot. A Niche skill is way for Pivot's to express their unique contributions to the org, and a way for leadership to recognize the impact of their unique skill. In order to use this category, the engineer, manager, and director must create and agree upon a career ladder for this skill-set. Once it's been created, the pivot commits to following this ladder if they want to be evaluated for performing that skill. + +Examples: subject matter expertise in MySQL, Facilitation + +*One example of success in this area*: You are on a team that has gone through two back-to-back rewrites. They haven't been able to ship and deliver on customer outcomes in over a year. You notice that the previous attempts to solve the customer problem didn't work because no one on the team has deep domain expertise on how container to container networking works. Additionally, you notice that there are other parts of the organization that could benefit from having thought leadership in this space. + +Your manager, director, and you talk through what it could mean for you to develop expertise in Networking as it relates to Distributed Systems. All three of you collaboratively build a career ladder of value you could bring to the organization by developing this expertise at a beginner level all the way upto a P6 level. You embark on the journey to add 'Subject Matter Expertise in Networking' as a Niche Skill to your Skills Matrix, and commit to stay on the journey to improve your expertise in Networking for the foreseeable future. diff --git a/project-leadership.md b/project-leadership.md new file mode 100644 index 0000000..b7b5fa4 --- /dev/null +++ b/project-leadership.md @@ -0,0 +1,25 @@ +## Project leadership +You ensure the productivity and health of your engineering team. You can act as a coordinator/liaison for initiatives on the team. You can act according to your team’s priorities. You ensure that voices are heard, and can take initiative to act alone when needed. Overall, you are a role model on your team for all aspects of our culture and process. + +*One example of success in this area*: You are anchoring your team. You’ve been working with your PM and Designer to outline a new epic, and would like to share your learnings with the team. You facilitate a meeting where folks brainstorm and share their thoughts. After the meeting, you work with the PM to scope out explorations that the team can do to de-risk the epic. You incorporate the output of the explorations, your knowledge of the problem, and work with the PM to choose a path forward. You share the outcomes with your team, and continue to be open to input from them as the features are developed. + +--- +### Proposed Levels and Skills + + + + + + + + + +
P1P2P3P4
+
  • Shows curiosity in learning about an anchor’s role on their team, and is ready to shadow their team anchor
  • Volunteers for facilitating team meetings
  • Discusses team “things” with their anchor (eg: team process, team health/morale, product, architecture)
+		 +
  • Is responsible for creating and upholding team discipline. This includes setting an example of following team processes themselves, holding other team members accountable, and fostering a culture of providing open and honest feedback about team’s artifacts (product, repos, process.)
  • Continually reflects on ways to reduce the tribal knowledge on their team, and evolves the on boarding process over time
  • Provides T.A.S.K feedback to LL/PL about team health and morale
  • Pairs with PM+Design on technical solutioning (eg: in pre-IPM, preparing for inception, etc.)
  • Provides guidance to the engineering team on execution towards a solution
  • Can provide technical leadership on their team, and are able to share their technical vision with team members
  • Able to anchor small/medium-sized teams with well-defined product priorities and technical direction
+		 +
  • Able to anchor teams with emerging product priorities and technical direction. They are able to help identify unknowns, and work with leadership to resolve them.
  • Able to anchor larger teams
  • Ensures they are not a single point of failure by effectively delegating responsibilities and sharing knowledge/context
  • Pairs with PM+Design to focus team’s effort more holistically towards solving customer problems (eg: participating in user interviews to learn about their needs, and helping PM+Design shape workflows that are technically feasible and solve a customer pain point)
  • Advocates for the needs of all roles/members of the team, and evolves team habits to create an inclusive environment on their team
  • Has a general awareness of work in progress; is able to catch missteps in real time and provide kind feedback to correct it
  • Is a safety-net for the team, and is able to intervene when they see tasks/priorities getting dropped
+		 +
  • Identifies systemic/long-running issues on their team and are able to intervene to resolve them
  • Works with leadership to establish a set of “prioritized skills” and are able to create an environment on their team where team members can grow those skills
  • Can delegate responsibilities to more junior team members and guide them through to completion (including providing stretch assignments)
  • Works with LL/manager to help team members grow (includes providing feedback and coaching)
  • Able to lead teams with long-running/systemic problems (eg: intra-team conflict, tech debt, cons lifting product priorities) through change
  • Aware of interfaces and interactions of their team with other teams, and work with leadership to improve them over time
  • Promotes/facilitates balanced decision-making on the team by demonstrating awareness of customer problems and sharing that with team members on a story level
+ diff --git a/support.md b/support.md new file mode 100644 index 0000000..d7b026f --- /dev/null +++ b/support.md @@ -0,0 +1,45 @@ +## Support +Passion for supporting our customers on their PCF journey, and ability to approach support issues with a customer-focussed mindset. You are able to handle interrupt-driven and exploratory work (e.g. questions on slack, on-call escalations, participation in cross-team meetings.) You ask relevant questions about an issue, figuring out what a customer needs to move forward, and drive it to resolution. You can communicate what you know respectfully to different audiences. You can also share what you still don’t know, and help identify the steps to learn more. You can apply your acquired CF knowledge on the fly, and are able to explore creative solutions to help meet the customer midway. + +_One example of success in this area_: Your PM notes that there is an open support ticket that the team should help with. You don’t have much context on the issue, but go into the Slack channel with an open mind. You ask good foundational questions, learning where assumptions have been made, and where evidence has been found. After speaking with the customer and with Pivotal Support, you realize that this is a known issue in an upstream product, and point support in the right direction. You explain how you got to this conclusion, and stay in the Slack channel until it’s clear that the issue has been resolved and the customer is satisfied with the outcome. + +--- + + + + + + + + + + + + diff --git a/technical-decision-making.md b/technical-decision-making.md new file mode 100644 index 0000000..32c5f53 --- /dev/null +++ b/technical-decision-making.md @@ -0,0 +1,52 @@ +## Technical Decision-Making + +Ability to weigh several factors when making technical decisions. Some factors that could be considered are maintainability, security implications, performance implications, effects on other consumers, extensibility and adaptability of system, etc. + +*One example of success in this area*: You have been noticing a lot of bugs arising the output of and . Additionally, you often see stories in the backlog around adding the same sort of features to both commands. You look through the code and notice that even though both commands are following separate code paths but are trying to accomplish roughly similar things. You share your findings with the team, and embark on a path to explore how to have both commands to follow similar code paths. After coming up with a plan, you get buy-in from your PM and other engineers to do this refactor as part of a larger epic. While you do this refactor you consider the maintainability and longer term extensibility of the system while you consolidate these paths. Finally, over time you observe that the number of bugs around those 2 commands decrease, and the team feels more comfortable navigating around that part of the codebase. + +--- +### Proposed Levels and Skills +
P1P2P3P4P5
+
    +
  • Responds with engagement to interrupts; can enlist help
    • +
  • Explains their suggestions and their approach to an interrupt or support issue.
 +
    +
  • Makes forward progress on most interrupts
    • +
  • Maintains communciation feedback loop with involved parties
    • +
  • Escalates to leadership when needed, so leadership can involve the right folks to help with the issue. +
    • +
  • Resolves familiar issues when encountered again +
 +
    +
  • Assesses interrupts and can identify what someone is really asking for
    • +
  • Prioritizes interrupts, with support from stakeholders as needed
    • +
  • Identifies and pulls in the right people to help with the interrupt
    • +
  • Onboards new team members on existing interrupt practices
    • +
  • Approaches conversations about customer constraints/culture/IT practices with a positive attitude and desire to understand
 +
    +
  • Recognizes patterns in interrupts, and channels that feedback to drive product improvements
    • +
  • +Continually assesses team's support load and evolves ways to reduce it / make it easier
    • +
  • Leads support conversations / resolution in high-stakes situations (e.g. angry customers, data loss, etc.)
    • +
  • Maintains context and switch between different + to resolve an interrupt
 +
    +
  • Understands support as a first-class feature of the product; shapes product definition based on that understanding
    • +
  • Rapidly context-switches and explores uncertain / complex support issues. Where valuable, takes the time to articulate the approaches taken and trade-offs of each one.
    • +
  • Teaches others how to explore in an unknown/unfamiliar (customer) environment
+ + + + + + + + + + + + + + + + + + +
P1P2P3P4
    +
  • Makes technical decisions, resulting in features that work to complete a story.
    • +
  • Follows along with their pair and report to other teammates on the reasons for certain technical decisions.
    • +
  • Observes and follows existing patterns/practices on the team.
    • +
    +
  • Surfaces and discusses various factors (outlined in P3+) when approaching a technical decision, with support from other pivots to make the final decision.
    • +
  • Makes sound technical decisions that conform to the team's existing architecture or vision.
    • +
    +
  • Factors in maintenance/impact on feedback loops/impact on readbility and onboarding as parameter when making technical decisions
    • +
  • Factors in support as parameter when making technical decisions
    • +
  • Factors in performance as a parameter when making technical decisions
    • +
  • Factors in extensibility as parameter when making technical decisions
  • Factors in security as parameter when making technical decisions
    • +
  • Factors in cost of change as a parameter when making technical decisions
    • +
  • Able to recognize risks of their proposed approaches when there are underlying unknowns; able to work with PM/leadership/experienced engineers to mitigate the risks and make a technical decision that moves the team forward
    • +
  • Able to recognize when new information emerges that requires changes in existing technical design; able to work with PM/leadership/experienced engineers to adapt existing technical decisions to the new information
    • +
    +
  • Takes an outcome-oriented mindset to technical decision-making.
    • +
  • Can articulate the tradeoffs and parameters (with priorities) that drove a technical decision
    • +
  • Bring others along on the decision-making journey, and teaches team members how to prioritize approaches and weigh-in several factors
    • +
  • Able to change course on decisions readily (in attitude) and easily (in artifacts produced) as new information emerges
    • +
  • Able to navigate uncertainty in underlying technical choices when making technical decisions
    • +
  • Able to explore options and make technical decisions (without painting project in the corner) when there are unknowns in the domain
    • +
diff --git a/technical-execution.md b/technical-execution.md new file mode 100644 index 0000000..950267e --- /dev/null +++ b/technical-execution.md @@ -0,0 +1,55 @@ +## Technical Execution +You can be depended upon to pick up a story from the backlog, do it well (quickly / dependably / transparently / correctly / valuably) and drive it to delivery. You ramp up quickly on new teams, and are soon productive as a solo or pair. + +*One example of success in this area*: You are trusted to drive stories to completion, and answer on-call escalations. Your anchor can depend on you to pair/solo on any story in the backlog, and provide leadership on tracks that need extra guidance. + +*Another example of success in this area*: You join a team whose main responsibility is integrating assets from other teams, and deploying them to a long, running production environment. You have minimal experience with operating the CF platform at scale. You are able to learn the tribal knowledge on the team quickly, and are able to execute on stories in the backlog with little guidance. Soon after, other pairs rely on you to onboard new team members, approach you with questions relating to the domain, and to reliably drive to completion uncertain/risky/technically complex stories. + +--- +### Proposed Levels and Skills + + + + + + + + + + +
P1P2P3P4
+
    +
  • Asks relevant questions on stories
    • +
  • Provides basic input into pair's progress
    • +
  • Provides coherent and informative updates at standup
    • +
  • Actively participates in pointing well-defined stories
    • +
  • Is comfortable with rotating pairs frequently
    • +
  • Is comfortable with carrying context on well-defined stories
    • +
  • Clarifies product requirements on stories, when necessary.
+		 +
    +
  • Able to lead a pair on well-defined tracks of work; can solo on well-defined tracks, if needed
    • +
  • Participates in writing acceptance criteria for well-scoped stories, when necessary.
    • +
  • Fits engineering chore work into existing feature work
    • +
  • Understands what changes need to be made, and how to execute on them in order to complete a story
    • +
  • Discusses the balance of short term execution with long term health
    • +
  • Recognizes and discusses potential anti-patterns
    • +
  • Can onboard pairs into well-defined stories
+		 +
    +
  • Able to lead a pair on all tracks of work; can solo on any story in the backlog, if needed
    • +
  • De-risks and makes progress on tracks with uncertain implementation
    • +
  • Works with PM + Design to scope epics to buildable blocks
    • +
  • Leads or anchors well-defined tracks of work.
    • +
  • Notices anti-patterns, can articulate reasoning and suggest ways to course-correct.
    • +
  • Consistently follows up on tasks/communication from stories
    • +
  • Can ramp up quickly to become productive on most CF teams
+		 +
    +
  • Identifies long-running/systemic technical problems (eg: testing anti-patterns, poor code health) affecting the team and drives intervention
  • Is focused on solving customer problems, and works with PM+Design to translate customer problems to well-defined stories for the team
    • +
  • Provides technical leadership at inceptions (eg: holds context around multiple cross-cutting tracks of work, and understands how to use that context to keep the inception focussed.)
    • +
  • Able to recognize what would help improve technical execution on teams, and successfully fills in that role. (Eg: notices PM needs coaching, and steps up to enable PM, etc.)
    • +
  • Teaches team members how to execute well on stories (eg: teaches definition of done for stories)
    • +
  • Teaches technical concepts and show team members how it is applicable to their product
    • +
  • Can navigate their way through legacy systems and improve throughput of the team (eg: notices complex code paths are slowing down feature delviery, facilitates conversations with the team on how to simplify them, gets buy-in from PM+leadership to prioritize this work, drives it to completion with the team.) +