CareerPlug

• Product

   Assignments:

  Product Teammate

  We are the builder, thinkers, the foundation for our business. Our business exists to provide value primarily via software – and we have the tremendous honor of being the caretakers of the software. Our motto as Product People is; Continuously Deliver Value – that Clients and Partners Love – and works for the business.

  Full Description

  This Assignment is different. There is no specific accountability other than to uphold the principles and values that come with being a member of Product.

  We hold ourselves to a very high standard, and this Assignment is intended to be an acknowledgment of that fact. The things we all must do to call ourselves Product People.

  • We are experts of our Product...not just our squad's functional area
  • We are students of the game... meaning we see process not as a set of commandments to be followed, but as guidelines that help us achieve our actual goals. Speaking of goals...
  • We are knowledgable about our business... meaning we know enough about our business and the market in general to make informed decisions
  • We know this is a team sport... meaning collaboration is a skill we seek to hone every day
  • We are outcome-focused... meaning we don't seek to just build software... we seek to make a difference... to change human behavior and deliver real results.

  This is not all of what it means to be on Product... but, it is a solid start. As such every member of Product must have this Assignment, and in the spirit of the 80:20 rule, let's set this to 20% for all positions. It'll remind us that the growth framework does NOT aim to capture 100% of your time, energy, or thoughts. The hope is that setting 20% of your job description to being something that does NOT have an observable outcome, it'll reinforce this idea.

  Requirements

  • Must have a position with the reach of 1.1 or higher
  • For this role, you must be milestone 3 or greater inProduct Knowledge
  • For this role, you must be milestone 2 or greater inProcess Knowledge
  • For this role, you must be milestone 1 or greater inBusiness Knowledge
  • For this role, you must be milestone 1 or greater inGoal Management
  • For this role, you must be milestone 1 or greater inCollaboration

  Examples

  An observation relating to  Product Teammate  has not been publicly recognized yet.

  Documentation Writer

  We are the documenters... we ensure that the most important parts of how our application is supposed to work never gets forgotten.

  Full Description

  Escalation Engineers who take on the Document Writer assignment work to ensure that escalations caused by lack of product or process knowledge are rare. They proactively update existing documentation when they see something incorrect out of date, create documentation (Guru cards, Loom videos) relevant to Escalation work (mitigations, processes, etc.). They work with Product Marketing/Technical writing/other squads to close knowledge gaps in the Help Center/Guru.

  One Number

  • Trust Score of the Product Team Guru Boards (how this will be measured... coming soon)

  Success:

  • No one on the P&E team has to ask how new functionality is intended to work
  • None of the direct stakeholder (enablement, product marketing, and customer support) has to ask how launched functionality is intended to work (can be measured with a decrease in tickets that could be solved by having documentation in place)
  • Documentation is created, reviewed, and added to Zendesk Guide before the feature is launched and passed to Customer Support and Customer Experience prior to launch to create support articles

  Note: The scope of this Assignment is it is responsible for creating a manual that inspires the customer-facing and enablement documentation but is NOT responsible for writing customer-facing and enablement documentation

  With every launch and every new feature, there are many details about the feature that we on the product have in our heads. These include:

  • Overview of the feature
  • How the feature works
  • Screenshots
  • Demo Video
  • and more!

  We have a goal to properly document the feature launching for both P&E and inter-departmental stakeholders.

  Things you might deliver/do

  • Create a story for creating documentation in each epic
  • Create documentation and move it through the review process
  • Add documentation for each feature to Zendesk Guide
  • Maintain documentation in the now and future
  • Share documentation easily with stakeholders via Zendesk Guide
  • The Feature Documenters (at least one person from each squad) will get together to create a Feature Documenters Handbook where they will agree on how documentation will be written, organized, and styled in the internal knowledge-base (Zendesk Guide).

  Requirements

  • Must have a position with the reach of 1.1 or higher
  • For this role, you must be milestone 2 or greater inProduct Knowledge
  • For this role, you must be milestone 2 or greater inCommunication
  • For this role, you must be milestone 2 or greater inCopywriting

  Examples

  An observation relating to  Documentation Writer  has not been publicly recognized yet.

  ---

  • Engineering

     Assignments:

    Code Reviewer

    We put teammates first by using code reviews as a way to help them continuously improve while continuously delivering value

    Full Description

    Code reviewers help in our quest to push quality to the left by giving actionable feedback on code including (but not limited to) the following areas:

    • Test Coverage
    • Performance
    • Security
    • Coding Conventions
    • Architectural patterns

    We put teammates first by using code reviews as a way to help them do their best work

    • We offer advice and resources to share knowledge and teach others
    • We discuss the advantages and disadvantages of different approaches
    • We aim to balance the number of PRs we create with the number of PRs we review

    Notes:
    As an engineer grows their engineering skills, they will be able to tackle larger and more complex code reviewers. A good guideline for what an engineer would be able to review successfully is to compare the complexity of a PR to their current ruby/rails milestones. Participating in code reviews for code at higher ruby/rails milestones is a great way to get more experience and grow, but having a more senior engineer to approve/act as a second set of eyes can be a good guardrail for safety.

    Requirements

    • Must have a position with the reach of 2.1 or higher
    • For this role, you must be milestone 2 or greater inCollaboration
    • For this role, you must be milestone 2 or greater inEngineering Communication
    • For this role, you must be milestone 1 or greater inData Modeling / Management
    • For this role, it is recommended to be milestone 1 or greater inEngineering Prioritization
    • For this role, you must be milestone 2 or greater inRuby
    • For this role, it is recommended to be milestone 2 or greater inRails

    Examples

    An observation relating to  Code Reviewer  has not been publicly recognized yet.

    Code Creator

    We write the software that drives the value delivery of our offering

    Full Description

    This is an Assignment primarily for App-Dev Software Engineers. However, site reliability, software in test, and escalation engineers may take on this Assignment. For specific notes to the types of folks taking on this Assignment see the bottom of this description

    The One Number we are accountable for

    • Likely Value Launched, Effectiveness... more on this coming soon, but for now check out this Guru card

    Supporting / leading indicators we pay attention to (aka constellation measures)

    • Coming soon

    ---

    Things you might deliver/do

    • Coming soon

    Notes to the different types of engineers

    • Escalation Engineers
      • Escalation Engineers who take on the Code Author Assignment execute against the things that will make everything better – T1/T2 mitigations, remediation of bugs that squads don't have the capacity to handle, implementation of functionality that we know will help reduce resistance and/or increase value for us, our stakeholders, or our customers.

    Requirements

    • Must have a position with the reach of 1.1 or higher
    • For this role, you must be milestone 1 or greater inProject Management
    • For this role, you must be milestone 1 or greater inData Modeling / Management
    • For this role, you must be milestone 1 or greater inEngineering Communication
    • For this role, you must be milestone 1 or greater inEngineering Prioritization
    • For this role, you must be milestone 1 or greater inEstimation
    • For this role, you must be milestone 2 or greater inRuby
    • For this role, it is recommended to be milestone 2 or greater inRails
    • For this role, it is recommended to be milestone 1 or greater inDecomposition & Sequencing
    • For this role, it is recommended to be milestone 1 or greater inSoftware Testing
    • For this role, it is recommended to be milestone 1 or greater inEngineering Systems Management

    Examples

    An observation relating to  Code Creator  has not been publicly recognized yet.

    Builder Task Shaper

    We take slices of work (epics/scopes) and break them into specific, actionable stories/tasks so that we can ship as effectively as possible.

    Full Description

    Our ONE Number:

    • Cycle time should be below 3 days for your squad
      • The theory is that if cycle time is low, it is likely because the stories are appropriately sized. If they are appropriately sized, and the squadmates feel as they know exactly what is next best to work on, you are executing this role at a very high level.

    Deliverables:

    • Actionable stories/tasks

    Details

    • Usually, only one per squad per quarter
    • Takes the epics/scopes and ensures that stories/tasks are decomposed in such a way that it will ensure the best flow for the squad.
    • Usually a full stack engineer or a very technical product owner/manager. Stories can, but likely shouldn't need much work done to them after you have done your magic to them.

    AKA

    • Story backlog groomer

    From our recent job description

    You will take the slices of work (epics/scopes) and break them into specific, actionable stories/tasks so that we can ship as effectively as possible (which means the stories/tasks are as small and as clear as possible). Ultimately we want stories/tasks/PRs that help us with forecastability and understandability on a pursuit of continuous value delivery.

    How we decompose and sequence the stories requires an understanding of the UI, backend, and the other "build" constraints. Though you’ll be doing your best if you’re getting help from your squad.

    Success looks like:

    • We use multiple metrics that help us measure the health of our delivery. One of them that helps us identify if we have bottlenecks is story cycle time. You’ll be successful if stories are a similar size and therefore have a relatively consistent cycle time.

    Requirements

    • Must have a position with the reach of 1.1 or higher
    • For this role, you must be milestone 3 or greater inDecomposition & Sequencing
    • For this role, you must be milestone 2 or greater inCollaboration
    • For this role, you must be milestone 2 or greater inCommunication

    Examples

    An observation relating to  Builder Task Shaper  has not been publicly recognized yet.

    ---

    • Operations

       Assignments:

      Tier-3 Agent

      We ensure Tier-II has what they need to succeed

      Full Description

      Tier 3 Agents support T2 and the rest of the company by verifying/routing bugs and other errors to the correct squad, investigating/answering product questions, and completing tasks that can only be performed through the rails console.

      Our ONE number

      • 90%+ of internal teammates who submitted tickets that reached T3 slightly or strongly agree that they got the information they needed to solve their issue in a timely manner.
      • Escalation cycle time
        • On average we agree that a conversation is needed if escalations take more than 2 hours per.
        • If/when an escalation is going to take more than 2 hours, everyone knows why and likely agrees with you

      Requirements

      • Must have a position with the reach of 1.1 or higher
      • For this role, you must be milestone 1 or greater inCommunication
      • For this role, you must be milestone 1 or greater inBusiness Knowledge
      • For this role, you must be milestone 3 or greater inProduct Knowledge
      • For this role, you must be milestone 2 or greater inSoftware Investigation
      • For this role, you must be milestone 2 or greater inCustomer Service

      Examples

      An observation relating to  Tier-3 Agent  has not been publicly recognized yet.

      Tier 1/2 Trainer

      Escalations are necessary, but they are also expensive (slow for customer and can be disempowering for tier1/2 agents). We Trainers focus on ensuring T1/2 have the knowledge they need to curb the need for escalation

      Full Description

      Escalation Engineers who take on the T2 Enablement assignment are dedicated to helping T2 level up their skills. They own the T2/T3 sync, and provide regular feedback on how the HX team can improve their bug submission skills. Working with the Escalation Mitigator, they resolve trends with escalations that don’t need a code change or can’t be solved through documentation alone - this can be giving other teams access to other tools and teaching them best practices, training them on how to use mitigations, or teaching them about more technical parts of the app like the API or webhooks that will allow T2 to solve issues for our clients without needing to bring things to T3.

      ONE Number

      • Reduction in the percentage of escalations that need T3 input by type (if there is a training on how to troubleshoot/investigate - a smaller percentage of those types of escalations should reach T3 post training)

      Requirements

      • Must have a position with the reach of 2.1 or higher
      • For this role, you must be milestone 2 or greater inProcess Knowledge
      • For this role, you must be milestone 2 or greater inSoftware Investigation
      • For this role, you must be milestone 2 or greater inPresenting
      • For this role, you must be milestone 3 or greater inProduct Knowledge

      Examples

      An observation relating to  Tier 1/2 Trainer  has not been publicly recognized yet.

      Escalation Mitigator

      Escalations are inevitable, but we ensure recurring escalations are reduced/eliminated altogether

      Full Description

      Escalations are necessary, but expensive.

      • Expensive because of the negative impact on Experience of CareerPlug’s client-facing teams
        • Anytime a client/partner-facing rep cannot answer a question, resolve a problem, or make a change that enhances the value of our offering to the client/partner in question, it reduces the overall experience.
      • Expensive because escalations are unplanned work for those that could be otherwise improving the system
        • Every moment that is spent NOT making improvements to the system by someone with the skill, access, and knowledge to make enhancements is less than ideal.

      The One Number we are accountable for

      • Quarter over quarter reduction in known escalations - there will always be new escalation needs popping up, but we shouldn’t let the same ones linger for months.

      Supporting / leading indicators we pay attention to

      • Observability
        • Stakeholders strongly agree or agree when asked “I know what the escalation trends are, and understand what we are doing to reduce them (so that we don’t have the same ones that are bugging us today be the same ones we are bugged by 6 months from now)”.
      • Outcomes
        • If the above is true, then we can/will have a quarter-over-quarter reduction in known escalations (as defined by any escalation type that occurs more than once per month for at least 3 contiguous months and/or takes more than a day of any tier-3+ agent).
          • There will always be new escalation-needs being added, such is the physics of creating software. The purpose of this goal is that the known escalation-needs are consistently being eliminated.
        • Client/Partner-facing team members strongly agree or agree when asked “I am continuously given ever-improving tools, knowledge, or skills from the Empower Squad and/or the other product squads that help me serve customers directly without needing to ask for help”.

      ---

      Escalation Engineers who take on the Escalation Mitigator assignment have their pulse on the escalation trends happening from T1 up. They share this knowledge across the product organization to help build feedback loops between other teams and the squads. They work with Platform Squad PO to prioritize and shape mitigations to resolve the most common escalations - allowing our users and teammates to self-serve and resolve their issues faster and with less friction

      Requirements

      • Must have a position with the reach of 1.1 or higher
      • For this role, you must be milestone 3 or greater inPrioritization Strategy (Sense and Respond)
      • For this role, you must be milestone 3 or greater inProduct Knowledge
      • For this role, you must be milestone 2 or greater inData analysis / synthesis
      • For this role, you must be milestone 2 or greater inBusiness Knowledge
      • For this role, you must be milestone 2 or greater inProduct Discovery

      Examples

        Observation created about 2 years ago

      Featuring:Christina W.Escalation Mitigator

      https://careerplug.slack.com/archives/C02T0CYA8GZ/p1691507297298429

      Sometimes when mitigating escalations, the right thing to do is:

      1. Wait until you see a pattern that makes the cost/benefit worth exploring
      2. Build a thing that makes the need go away
      3. Build a thing that empowers an earlier tier to meet the need
      4. Update documentation (internal or external) that addresses the need

      But, sometimes, especially in hi-trust environments, the thing to do is to empower and train earlier tiers. This is the hardest of the options, but an amazing one if you can get it done.

      CW has been reporting on the fact that IP Address allow-listing has been the top escalation for a long while.... BY FAR.

      She investigated multiple ways to mitigate this escalation, but apparently came to the conclusion that it would be best to empower and train T2 to be able to handle these requests. Therefore making the turn around time that much faster, clients that much happier, and removing that much bureaucracy from the CP universe.

      Well done!