Explore Lessonly's Assignments

Choose Organization Growth Framework
Exploring Lessonly's growth framework
Choose Starting Position
Starting with the position: Product Manager - 4.3 (aka Director, Product Management) (Check out Product Manager - 4.3 (copy from 2025-11-03 23:19:38 -0500))
Choose Assignments
Now it is time for you to build your unique job description! Simply go through and add a checkmark next to all of the Assignments you'd want to take on.
Click to copy the URL to share this exploration
  • Lessonly

     Assignments:

    We engage in meaningful conversations on ways to help the Lessonly organization do better work.

    Full Description

    We engage in meaningful conversations on ways to help the Lessonly organization do better work.

    • For example, we may take part in the following initiatives:
      • Connections Committee
      • Diversity and Inclusion Advocates
      • Marketing Blog Blitz
    Requirements
    • Must have a position with the reach of 1.1 or higher
    • For this role, it is recommended to be milestone 1 or greater inInitiative
    • For this role, it is recommended to be milestone 1 or greater inCommunication
    Examples
      Observation created about 5 years ago

    Over the last couple of weeks, Casey and I have had some great conversation about how things are going. There are things that she was willing to tell me that i needed to hear. She also was interesting in hearing some of the things I had to say. She is interested in how I am doing as well as my opinions of our organization from a fresh perspective. This not only shares how she cares about me as a person, but about the place show works. This is an interaction that is outside her reporting structure, but she cares


    • Product & Engineering

       Assignments:

      We are obsessed with the intersection between product usage metrics (such as weekly active usage) and business metrics (such as renewal cycles). Our prime objective is to identify quantitative evidence that will help CX, services, support, and product make better decisions about how each of them serves our customers

      Full Description

      Key Result(s)

      • Quantitative evidence plays a vital part in opportunity prioritization
        • ... as measured by qualitative feedback from the Opportunity Shapers
      • Insights are uncovered that helps better support our customers
        • ... as measured by qualitative feedback from the post-sales customer-facing teams (Account Management, Customer Support, Professional Services, and Customer Implementation)
      • The bi-weekly metrics all-hands has easy to understand, and clearly impactful metrics that Product can share with the rest of the organization to inspire excitement and provide clarity into the impact of the work

      Details

      Things you might deliver/do

      • We are responsible for understanding how Salesforce data, when blended with Product-usage data, impacts our ability to better understand and potentially even predict the business outcomes
      • We are responsible for doing the exploration needed to empower CX to make even better recommendations to customers about their training program effectiveness
        • Helping CX uncover patterns in how the best-performing programs function so that they can help their customers better.
      • We may partner with operations on deciding on and maintaining the business intelligence tooling (think Tableau or other BO tools)

      • If the data does not exist that we need to be able to answer a question, you are relied on to help prioritize modifying the platform to allow for the data to be captured, or captured in the proper format.

      Illustrations

      • This excerpt from the book Inspired is a well-written summation of the expectations and value of this role:
      Requirements
      Examples
        Observation created over 5 years ago

      hjkhkj

        Observation created about 6 years ago

      https://lessonly.slack.com/archives/C047M50C0/p1568211454034800

      LOVE THIS!

      Unexpected, but valuable. Keeping the most important thing, the most important thing. Which is...

      Are we allowing people to do better work with the things we build.

      Usage is a leading indicator to this.

      Thanks Justin!

      We are the ones that bring organization and clarity to the Discovery process.

      Full Description

      Discovery can be tough given your goal isn’t to deliver an artifact, but instead to deliver continuous learning. We are responsible for ensuring our Discovery Crew always has the next step, regardless if it is desirability, feasibility, or viability, we are the glue that holds a Discovery Crew together.

      Key Result(s) / Outcomes

      • Learning frequency/cycle-time, meaning there is clarity as to where we stand on the following three constructs, and we are continuously moving forward in all three:
        • Value: Will the overall solution be desired and useful to customers?
        • Feasibility: Can our delivery crew build what we need with the time, skills, and technology we have?
        • Viability: Will the overall solution have the desired business outcome?
      • Learning clarity
        • ... what value/unmet need/opportunity are we aiming to impact?
        • ... who is doing what to ensure we are focused on bringing clarity to the value goal?
        • ... when is our next major milestone, and what blockers are in the way
      • Discovery crew cohesion
        • Squads have two sets of crews within them… delivery crews and discovery crews. You are responsible for making sure that everyone on the discovery crew feels connected, informed, and supported (this slide has been used in the past as a way to help ensure alignment).
      • Stakeholder management
        • Consulted Stakeholders (PSC or POC members) should feel confident in the progress and direction of the discovery.
        • Informed stakeholders (all Lessonly employees, but specifically those that attend Team Shares and rely on the #Product-Weekly-Updates) should feel confident in the progress and direction of the discovery.

      Submit change suggestions in this GDoc

      Requirements
      Examples
      An observation relating to  Discovery Manager  has not been publicly recognized yet.

      We have a robust understanding of the current state of escalations and prioritize the best ways to reduce them.

      Full Description

      Description

      Escalations are necessary, but expensive.

      • Expensive because of the negative impact on Experience of Lessonly’s Customer Service teams
        • Anytime a customer-facing rep cannot answer a question, resolve a problem, or make a change that enhances the value of our offering to the customer 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.

      Key Result(s) / Outcomes

      • 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-2+ person).
          • 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.
        • Customer-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”.
      Requirements
      Examples
        Observation created over 6 years ago

      I ❤️ this message that is hidden away in a CH story. It tells the full tale of what I'm spotlighting: https://app.clubhouse.io/lessonly/story/26584/understand-escalations#activity-26619

      However, the thing that I appreciate about this, was Rick's conclusions that he put at the end of each question he referenced. That made it so I didn't have to guess at anything nor did I have to try and interpret the intent behind sharing the reports.

      Overall this was excellent.

      The only thing I was left wanting was clear next steps. But even with that need still existing I felt this was more than worthy of highlighting!

      Growing the team is one of the most important things we do... and we interviewers are responsible for helping to decide on our future teammates.

      Full Description

      Success:

      • You are counted on for two things as it pertains to new llamas joining the pack:
        • Help the candidates get a clear idea of the Lessonly culture as well as the different aspect of the job they are applying for.
        • You'll also be vital in helping the hiring manager assess the candidate across a plethora of criteria

      Details:

      • Attend all on-site interviews for a single position
      • Actively work to give the candidate clarity about who we are
      • Actively work to give clarity to the hirer about your perception of the candidate
      • Understanding of the role the interviewee is interviewing for and the why behind the role
      • Prepared on the general background of the candidate
      • Prepared 2-4 questions based on the role and the candidate
      • Be an active listener. Make sure you are present to the interviewee and not thinking about your life while he or she is talking Here are a couple of thing that I try to do before and during an interview.
      • You listen to answers to see if they follow the values of Lessonly. Ask clarifying questions.
      • When preparing questions, you keep in mind the Lessonly values
      Requirements
      • Must have a position with the reach of 1.1 or higher
      • For this role, you must be milestone 1 or greater inCommunication
      Examples
        Observation created over 5 years ago

      I've been with Ashley as she's been on an interview panel for the first time this week. The cool thing is, you'd never know it was her first time!

      Ashley has been asking really thoughtful questions during the interviews that have helped unearth some great details about the candidates we've been chatting with. Not only that, but I feel like she's communicated with our candidates in a way that is super respectful, down-to-earth, and would make me feel a little more relaxed if I'd been interviewed by her.

      I also appreciate in our debriefs how thoroughly she's thought through the interviews to make sure that we hire candidates that are great culture fits.

      Thanks for being an awesome interviewer, Ashley!

      We provide context through communication boosting productivity leading to new llama satisfaction.

      Full Description
      • We provide context through open communication to provide relevant information to the new llama and encourage a process of continued, self-directed learning.
      • We boost productivity by helping the new llama in many situations based on his/her experience and knowledge to become productive in their role quickly and to help build self-confidence allowing him/her to focus on adding value to Lessonly.
      • We help improve new llama satisfaction by reducing the initial confusion and uncertainty faced by all new llamas.
      Requirements
      • Must have a position with the reach of 2.1 or higher
      • For this role, you must be milestone 1 or greater inCommunication
      • For this role, you must be milestone 1 or greater inProduct Knowledge
      • For this role, you must be milestone 1 or greater inInitiative
      • For this role, you must be milestone 2 or greater inCollaboration
      Examples
      An observation relating to  Onboarding buddy  has not been publicly recognized yet.

      We engage in meaningful conversations on ways to help the Product and Engineering team do better work

      Full Description

      Success

      • Do Better Work Groups are a way for anyone on the product team to see something they want to see improved, propose a quest to identify the best solution, and once prioritized make that change happen.
      • You, as a member of a DBW group will be successful if you are a part of inspiring and enabling us to do better work!
      Requirements
      • Must have a position with the reach of 1.1 or higher
      • For this role, you must be milestone 1 or greater inInitiative
      • For this role, you must be milestone 1 or greater inCommunication
      Examples
      An observation relating to  P&E DBW group member  has not been publicly recognized yet.

      We are obsessed with product usage metrics because they are the leading indicators of how successful our squad, software, and the company are.

      We believe the influence of data is critical in nearly all decisions, from how successful a feature is... how successful a campaign is... how successful a type of customer is … how successful a launch is.

      Full Description

      We believe the influence of data is critical in nearly all decisions, from how successful a feature is... how successful a campaign is... how successful a type of customer is … how successful a launch is.

      Success looks like:

      • Quantitative evidence plays a vital part in product solution design
        • ... as measured by qualitative feedback from Solution Designers
      • Insights are uncovered that helps better support our customers
        • ... as measured by qualitative feedback from the post-sales customer-facing teams (Account Management, Customer Support, Professional Services, and Customer Implementation)
      • The bi-weekly metrics all-hands has easy to understand, and clearly impactful metrics that Product can share with the rest of the organization to inspire excitement and provide clarity into the impact of the work
      Requirements
      • Must have a position with the reach of 1.1 or higher
      • For this role, you must be milestone 1 or greater inData
      • For this role, it is recommended to be milestone 1 or greater inDesign Collaboration
      • For this role, it is recommended to be milestone 1 or greater inProduct Discovery
      • For this role, you must be milestone 2 or greater inProduct Knowledge
      • For this role, it is recommended to be milestone 2 or greater inInitiative
      Examples
      An observation relating to  Product engagement analyst  has not been publicly recognized yet.

      Each squad is empowered to determine how members work together to achieve their goals. This may mean flexibility around squad meetings and communication methods, but all successful squads are built on a foundation of collaboration and clear communication. The Squad Manager’s role is to guide the squad to success in these areas.

      Full Description

      Description

      We ensure that our squad is maintaining a healthy level of communication and collaboration, so that priorities and deliverables are as clear as possible.

      Key Result(s) / Outcomes

      • All members of a squad are aware and aligned on objectives and priorities. If asked individually - each squad member’s update on squad progress aligns with that of their teammates.
      • Squad functions with a high level of collaboration around quarterly objectives, checkpoint goals and/or iteration goals.

      Things you might deliver/do

      • Coordinate a squad’s shaping and ongoing reviews of objectives and goals. Facilitate discussion and agreements regarding priority. This may include:
        • Collaborate with squad to shape objectives and associated timelines/deliverables.
        • Facilitate squad definition and planning of checkpoint goals. Support ongoing collaborative discussions with the squad to confirm commitments are being met throughout the checkpoint.
        • Confirm iteration and/or checkpoint goals and verify progress towards commitments.
      • Identify and clarify impacts to squad resources and priorities by:
        • Organizing discussions and facilitating squad agreements regarding clear prioritization of stories
        • Maintaining an understanding of resource needs and collaborating with the squad to agree on the best allocations of resources/skills. (Bug prioritization/impact, customer and internal support needs, etc)
        • On behalf of the squad, escalating any concerns regarding priorities and resources to P&E managers as soon as identified.
      • Ensure all required squad meetings are taking place and coordinate team participation. The Squad Manager is not expected to run all meetings, but should make sure they happen and any participation and coordination of content is agreed on within the team. In addition to Standup and Huddle meetings, examples may include:
        • Retrospective (Ensure the discussion happens and identify who will run the retro. It is not required for the Squad Manager to run this meeting)
        • Team Share (Get agreement from squad re: Who is presenting? What is being covered?)
      • Communicate updates to squad members via channels such as Weekly Delivery Digest
      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 inPrioritization
      • For this role, you must be milestone 1 or greater inDelivery Forecasting
      • For this role, you must be milestone 1 or greater inCollaboration
      Examples
      An observation relating to  Squad Manager  has not been publicly recognized yet.

      • Engineering

         Assignments:

        We own our response to major incidents on our platforms, including application downtime, major bugs, and third party service issues by following the Lessonly Incident Response Plan which lives here.

        Full Description

        Success looks like:

        When you are the owner for an incident:

        • Everyone involved in remediation know what their role is
        • No role is dropped during an incident
        • The issue is fully and regularly communicated with the rest of the organization
        • The issue is appropriately communicated outside the organization
        • Successfully follow the Incident Response Plan

        Feedback loop/deliverables

        • Internal incident communication
        • StatusPage updates
        • Incident Retro Document

        Details:

        The Incident Remediation Lead is responsible for acting as the Incident Owner as defined by the Incident Response Plan during an incident response. This person is aware of appropriate communication channels for an incident and is able to organize everyone involved in remediation.

        Key Results/Outcomes

        • We own our response to major incidents on our platforms, including application downtime, major bugs, and third party service issues by following the Lessonly Incident Response Plan.
          • We are responsible for making sure the following takes place (this individual doesn’t need to take on each of these tasks, but they need to make sure these tasks happen through delegation):
          • All communication happens within the appropriate channels
          • All necessary investigations happen
          • The issue is resolved in a timely manner
          • A Post-Mortem meeting takes place within a day or two of the incident
        Requirements
        • Must have a position with the reach of 3.1 or higher
        • For this role, you must be milestone 2 or greater inRails
        • For this role, you must be milestone 2 or greater inData
        • For this role, you must be milestone 2 or greater inRuby
        • For this role, you must be milestone 2 or greater inCollaboration
        • For this role, it is recommended to be milestone 2 or greater inInfrastructure
        • For this role, you must be milestone 2 or greater inEngineering Communication
        • For this role, you must be milestone 2 or greater inSoftware Investigation
        Examples
          Observation created over 5 years ago

        Here is the Slack message that inspired this write up

        A copy of the post:

        Every incident we have is an exercise in unplanned learning. I wanted to make sure we share the lessons from the incidents so that these lessons can benefit more than just those involved in the immediate incident.
        https://about.lessonly.com/library/lesson/361443-incident-2020-04-20-access-exclusive

        Holy Schnikes!! I feel most supported, most proud, and most elated when a teammate surprises me with something that is so clear, obvious, and valuable that I'm taken aback.

        That happened this morning.

        Stephen, who we all know is an absolute best when it comes to seeing a need and fixing that need. His Sense and Respond game is next level.

        However, I haven't seen the "Systems-Building Stephen" as often, because Super-Hero Stephen is usually what we need.

        Well, here is what I love about everything about this message:

        • First, the sentiment... every bit of unplanned work, and especially incidents are learning opportunities... FACT 🎊
        • Second, it would have been easy to fall back on our current policies and do the bare minimum, but he showed tremendous initiative by saying... "Nah, we are not only going to learn from this one, but we are going to share those learnings by putting them in the place where learning should live... Lessonly!" 🎉
        • Third, it would have been easy for this to be a one-off thing. But he said... "Nah, this should be a part of who we are, a part of our culture, so I want to set us up to continue to do this in the future by putting this in a Path". ❤️

        I've been pondering a few new abilities, and one of them is Systems-Building... if that ability existed I'd say this was an excellent showing of system building in that it creates a path of least resistance through small actions.

        Well done sir, well done... now let's continue to iterate on this so that we can ensure we are continuously improving, continuously learning, and continuously doing better work. 🙌🏾 🙌🏾 🙌🏾

        We respond quickly and efficiently when folks have a question that they think is best served by a report. However, our prime directive is to continually look for ways to enable folks (internal teams and customers) to have a way to self-serve the answers they need to do better work!

        Full Description

        Success looks like:

        • Fast
          • ... as measured by report requests completed cycle time (Need to define ideal cycle time)
        • Quality
          • ... as measured by report request CSAT (Need to introduce CSAT into ZD)
        • Multiplicative
          • ... as measured by a continuous reduction (and/or maintain low level) of report requests. This means that the insight that folks are looking for, they can get themselves. Which is better for customer service and better for Product.
        Requirements
        Examples
        An observation relating to  Report Writer  has not been publicly recognized yet.

        We ensure that our technical partnerships are healthy. That means clarifying expectations, managing communication, and ultimately being accountable for success (win-win makers).

        Full Description

        We ensure that our technical partnerships are healthy. That means clarifying expectations, managing communication, and ultimately being accountable for success (win-win makers).

        Requirements
        Examples
          Observation created about 5 years ago

        https://lessonly.slack.com/archives/CU371H1RQ/p1601401557018300

        That post is so simple, but here is what it does:

        • Reminds everyone of the context
        • Asks everyone who might be impacted, therefore showing off a mission-control style information sharing
        • Gives clear reason why this group should care
        • Hints at next step (if it had a timeline on when the switch was going to be made, it'd been perfect IMO)
          Observation created almost 6 years ago

        https://lessonly.slack.com/archives/CDFMMU2HW/p1573128503000600?thread_ts=1572891238.000200&cid=CDFMMU2HW

        Here is what I love about this...

        • Initiative:
          • This was not something that I anticipated Rick jumping in on. However, he saw it, knew he could make it better, and executed brilliantly.
        • Understand the audience:
          • Hippo has traditionally needed things to be crystal clear when asking them to do a thing or answer a question. So, he took the time to write out clear instructions for them, which gives us the best chance of this being a successful encounter.

        Well done sir!

        We support Tier 2 when they need additional help to investigate or remediate issues by owning issues that are passed to us and we continuously coach Tier 2 to reduce the number of escalations when possible.

        Full Description

        Success:

        • Ultimately, if you are wearing this hat, your job is to execute against the things that will make everything better. By that, I mean tier-1 empowerments, 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.

        Details:

        • You'll route issues to tier-4 when there is a surge of high-priority work and you have to stay focused, or there is an issue the tier-3 team needs help debugging.
        • You'll help pattern match, in collaboration with escalation mitigator and tier-2 engineers to determine the best tier-1 empowerments

        Key Results/Outcomes

        • We support Tier 2 when they need additional help to investigate or remediate issues by owning issues that are passed to us.
          • These may be (but aren’t limited to) the following:
          • Tier 2 is at capacity and needs assistance
          • Performance or complex technical issues that can’t be resolved by Tier 2
          • We continuously coach Tier 2 to reduce the number of escalations when possible.
        Requirements
        • Must have a position with the reach of 2.2 or higher
        • For this role, you must be milestone 2 or greater inRuby
        • For this role, you must be milestone 2 or greater inData
        • For this role, you must be milestone 1 or greater inWeb Technologies
        • For this role, you must be milestone 2 or greater inPrioritization
        • For this role, you must be milestone 2 or greater inRails
        • 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 2 or greater inSoftware Investigation
        Examples
          Observation created about 6 years ago

        Multiple times over the last few months (and likely the last few years), Kyle has been working closely with Karlie and the US Cellular team on their integrations/enhancements/all the things. This has required him to jump on multiple phone calls and to work ridiculously late hours; a few times, he's been up in the middle of the night for a few hours to make sure everything worked as expected. Each time he's done this, he's still been a team player first thing the next morning. I appreciate his willingness to always take this on and do it with a positive attitude. Thanks, Kyle!

        We are the last line of defense, the ones that must remediate the pain by any means necessary. The department, the business, and ultimately our customers rely on us to ensure we can continue delivering on our mission.

        Full Description
        • We support Tier 3 when they need additional help to investigate or remediate issues by owning issues that are passed to us by following our documented Support process outlined here.
          • These may be (but aren’t limited to) the following:
          • Tier 3 is at capacity and needs assistance
          • Performance or complex technical issues that can’t be resolved by Tier 3
        Requirements
        • Must have a position with the reach of 2.3 or higher
        • For this role, you must be milestone 3 or greater inData
        • For this role, you must be milestone 3 or greater inRuby
        • For this role, you must be milestone 3 or greater inInfrastructure
        • For this role, you must be milestone 3 or greater inRails
        • For this role, you must be milestone 3 or greater inCollaboration
        • For this role, you must be milestone 3 or greater inEngineering Communication
        • For this role, you must be milestone 3 or greater inSoftware Investigation
        Examples
        An observation relating to  Tier-4 escalation engineer  has not been publicly recognized yet.

        We triage application errors that arise from our application error monitoring tool.

        Full Description
        • We triage application errors that arise from our application error monitoring tool.
        • We effectively triage each error within 24 business hours
        • We follow the guidelines outlined in the Triage Application Engineer handbook to successfully triage each error.
        Requirements
        • Must have a position with the reach of 2.1 or higher
        • For this role, you must be milestone 1 or greater inProduct Knowledge
        • For this role, you must be milestone 1 or greater inWeb Technologies
        • For this role, you must be milestone 1 or greater inRails
        • For this role, you must be milestone 1 or greater inData
        • For this role, you must be milestone 1 or greater inEstimation
        • For this role, you must be milestone 1 or greater inCollaboration
        • For this role, you must be milestone 1 or greater inEngineering Communication
        • For this role, you must be milestone 1 or greater inSoftware Investigation
        Examples
        An observation relating to  Triage application engineer  has not been publicly recognized yet.

        • Development

           Assignments:

          We ensure we’re shipping high quality backend code, we put teammates first by using code reviews as a way to help them do their best work, and we keep stories moving through our process.

          Full Description
          • We ensure we’re shipping high quality backend codeand give actionable feedback on code including (but not limited to) the following areas:
            • ~90% test coverage on stories
            • Performance
            • Security
            • Style guide
            • Architectural patterns
            • Hygienic (common conventions) concerns
          • 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 keep stories moving through our process
            • We review at least one story for every story we own

          Handbook(s)

          • Code Reviews: Part of our Engineer onboarding, this Lesson details the process and mechanics of a Code Review.
          • Story Workflow: Code Reviews: Also part of our Engineer onboarding, this Lesson outlines the expectations of code reviewers and who is responsible at each review-related stage in our workflow.
          • Code Reviews: What to Look For: A compendium of everything we've learned (and thought to write down) about reviewing code in the context of our application and domain. A great getting-started guide for new reviewers on the team.
          Requirements
          • Must have a position with the reach of 1.1 or higher
          • For this role, you must be milestone 1 or greater inRuby
          • For this role, you must be milestone 1 or greater inRails
          • For this role, you must be milestone 1 or greater inData
          • For this role, you must be milestone 1 or greater inPrioritization
          • For this role, you must be milestone 1 or greater inCollaboration
          • For this role, you must be milestone 1 or greater inEngineering Communication
          Examples
            Observation created almost 5 years ago

          I'm thankful for Brittany's PR updating our seeds file.

          First, she noticed that the test data it produces has gotten out of date over time and didn't provide an optimal testing environment. This PR is a step towards addressing that need. She also introduced a cool concept of using the filler text in Lessons as a way to help provide guidance on how they are expected to work. What a cool idea that provides assistance at the time of need while also providing realistic test data!

          Secondly, her PR notes very clearly shared the context behind these proposed changes, explained her solution, and even included "hot tips" to help call out pitfalls while testing it. I appreciate this because I was very quickly able to not only understand her changes, but think about them in the context of the problem they were aiming to solve. All of this information was conveyed in format that was concise and easy for me to follow, which is not easy in itself. While I found the PR description helpful, it will also provide helpful context to the next person to work in the seeds file :tada:

            Observation created about 5 years ago

          Tom and I both consulted on the design of the new content search. While doing a PR for some of this work, he looked beyond the syntax. He noticed that the flow of the code was likely going to not be performant for large clients. This is a critical skill to be able to look at code, understand the broader flow and intuit that there could be a problem for larger data sets. Finding this issue put Tom in a crossroads. Pulling the Andon cord on this is a non-trivial act. He reached out to me to make sure that we were in agreement about the issue and to make sure that solutions to this problem were larger in scope than PR comments could address. He then took responsibility to drive clarity with the rest of the team and make sure they were all prepared to come up with a new plan.

          We ship high quality code, we’re highly confident in providing the best experience for our users, and we deliver backend stories to contribute to the team’s success and keep progress moving forward.

          Full Description
          • We ship high quality code
            • Minimal (less than average) number of regrettable recycles on stories owned. For example:
              • ~90% test coverage
                • So we can (Shared) increase confidence that our code will work as expected
                • Not-you, engineering experience
              • Performance concerns
              • Security concerns
              • Style guide concerns
              • Architectural pattern concerns
              • Hygienic (common conventions) concerns
          • We’re highly confident in providing the best experience for our users
            • Minimal (less than average) number of regrettable remediations on stories owned. For example:
              • Performance issues
              • Authorization issues
              • Functionality issues
              • Error handling issues
          • Delivers backend stories to contribute to the team’s success and keep progress moving forward
            • Better than average cycle time of active states (as defined in OurGruuv)
          Requirements
          • Must have a position with the reach of 1.1 or higher
          • For this role, you must be milestone 1 or greater inRuby
          • For this role, you must be milestone 1 or greater inRails
          • For this role, you must be milestone 1 or greater inData
          • For this role, you must be milestone 1 or greater inEstimation
          • For this role, you must be milestone 1 or greater inInitiative
          • For this role, you must be milestone 1 or greater inPrioritization
          • For this role, you must be milestone 1 or greater inCollaboration
          • For this role, you must be milestone 1 or greater inEngineering Communication
          • For this role, you must be milestone 1 or greater inSoftware Investigation
          Examples
            Observation created about 5 years ago

          Tom and I both consulted on the design of the new content search. While doing a PR for some of this work, he looked beyond the syntax. He noticed that the flow of the code was likely going to not be performant for large clients. This is a critical skill to be able to look at code, understand the broader flow and intuit that there could be a problem for larger data sets. Finding this issue put Tom in a crossroads. Pulling the Andon cord on this is a non-trivial act. He reached out to me to make sure that we were in agreement about the issue and to make sure that solutions to this problem were larger in scope than PR comments could address. He then took responsibility to drive clarity with the rest of the team and make sure they were all prepared to come up with a new plan.

            Observation created about 5 years ago

          Joesph was given a big problem. Search on the learn page is slow. The big problem is determining what lessons a user has access to. The majority of the problem has to do with lessons in paths. This was not a part of the application that he had a lot of deep knowledge in. He took a lot of time to create test data (paths in paths in paths with lessons all over the place) and has worked to really understand how all of the parts work together. In fact, I would say know that he really groks it in a way that I do not. I offered him an initial design on how we should solve the problem. After working through all the details, he saw an even better solution that take the last couple steps in the journey to search nirvana. In the midst of all of this, he has done an incredible job communicating the changes with the benefits that they will bring.

            Observation created over 5 years ago

          Brittany has been taking the lead on our Forced Logout acceleration (doing some discovery, determining the best approach from an architecture standpoint, story shaping, delivery, etc.). While planning and working through some discovery, she ran into some roadblocks. She gave context, asked a clear question, and provided potential solutions so folks could easily comment in hopes to gain clarity and move forward in a timely manner (see the below Slack conversations for examples). Keep up all the great work, Brittany 🎉

          https://lessonly.slack.com/archives/C97TXG1PW/p1592937599264700

          https://lessonly.slack.com/archives/C97TXG1PW/p1592937611265000

            Observation created almost 6 years ago

          My main objective this quarter has been to fix bugs that leave learners unable to complete Paths (since learners completing stuff is kind of the reason we exist as a company). Of the 5 big bugs on our radar, we were only able to fix 2 before my newborn son arrived a week and a half early back in December. I fully expected the Learn squad to stay focused on their other important objectives in my absence, but Tom had other ideas. While I was out, he identified and fixed the root cause of another issue (ch36348), and had made major inroads researching the others. On my first day back yesterday when I mentioned Paths in the Learn standup, Tom smiled and said "I've got news for you on that". When we sat down together and Tom explained how he'd gotten to the bottom of several major issues and even fixed one of them (and keep in mind these are bugs that have existed for years which no one has been able to figure out), my outlook on the quarter's goal went from "Well, at least we made a dent..." to "Holy heck, we can do this!" So a big shout-out to Tom for not just working on Paths bugs while I was out, but really working on them, and making progress where no one, myself included, had been able to, to the benefit of the 100,000+ learners affected by them. 👏

            Observation created almost 6 years ago

          I am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.

          I have been inspired to bring the level of clarity I have found here in other aspects of my job.

          --No summary set yet--

          Full Description

          Success:

          • Learn more about backend development topics
          • Teach others about backend development topics
          • Push Lessonly's backend codebase forward by making improvements to it

          Details:

          • Backend Guild members get together to learn from and teach each other on various backend topics, including databases, Ruby, Rails, and anything else that could be valuable knowledge.
          Requirements
          • Must have a position with the reach of 1.1 or higher
          Examples
            Observation created over 6 years ago

          I just hopped in to a PR that fixes a performance issue to check it out and I found some amazing PR notes. Haley wrote out what the observable issue is, what the technical cause for it is, provided some measurements, walked through why the changes made were desirable, offered some explanation of alternatives, talked through benchmarks, and provided some detailed step-by-step testing notes.

          whew

          Haley, you put a lot of effort into making this PR understandable for anyone, and that is fantastic. Thank you for that!

          Here is the PR I'm talking about: https://github.com/lessonly/lessonly/pull/6862

          We serve the function of Product Engineering, and those executing against its roles. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Key Results/Outcomes

          ENGAGEMENT:

          • The people taking on the roles listed within the Engineering / Development domain, agree or strongly agree to the following statements:
            • I know how I’m being evaluated on these roles.
            • I receive actionable (meaning timely, frequent, specific, and observation-based) constructive feedback on my performance within the roles identified above.
            • I receive actionable (meaning timely, frequent, specific, and observation-based) recognition (public or private) on my performance within the roles identified above.
            • I believe I have the tools to meet or exceed the outcomes listed within the roles in question.
            • I believe I have the processes and environment to meet or exceed the outcomes listed within the roles in question.
            • I believe we are continuously improving in how we go about taking on these roles.
            • Note: This SHOULD have a direct impact on the NPS score of engineers (where they select 8+ on a 10-point scale to the question; “I’d recommend a friend come to work here”). However, given that full engagement is more inclusive than their primary roles, it doesn’t feel right to have that as a part of the measure of enablement leads.

          QUALITY:

          • As measured by staying below a 10:1 regrettable defect escapee to stories delivered ratio
            • I would love to make this ratio bigger, but let’s start here for now and establish a baseline before committing to something greater. One of the best measures of a great team is NOT the absence of issues, but how small the issue-to-resolution time. However, the spirit of this measure is that we are actively pushing quality to the left, meaning earlier in the process We will also measure the directed decrease in certain types of defect escapees that are targeted quarter over quarter.

          SPEED:

          • Points(or stories)/person over time doesn't necessarily mean we're delivering more value. However if points/person is decreasing then it'll very likely make it harder to deliver value continuously. Lean principles of single-piece-flow, collaboration principles that require heavy pairing at all parts of the process, and other strategies might appear to slow down the flow of work, but will help us deliver value more quickly. The idea here is that you as a software development enablement lead are paying attention to how the work is flowing and are making recommendations based on what you are seeing.

          Glossary

          • Timely
            • Within 48 hours of a remark-worthy event
          • Frequent
            • A least once per quarter
          • Immaculate Defections
            • Bugs caught by customers and are divorced from any specific project released in the last 90 days.
          • Regrettable Defect Escapees
            • Bugs caught by someone outside of the squad and is tied to a specific project released in the last 90 days that are priority-1, priority-2, and some priority-3 bugs (we will have to use our discretion when saying if a priority-3 bug is regrettable or not)
          • Non-Regrettable Defect Escapees
            • Bugs caught by someone outside of the squad and is tied to a specific project released in the last 90 days that are priority-4, priority-5, and some priority-3 bugs (we will have to use our discretion when saying if a priority-3 bug is regrettable or not)
          • Regrettable Work Release Defects
            • For the squads that test every story, these show up as stories that make it to the remediations lane because they are bad enough that we've decided to not ship with the bug.
            • For squads implementing trunk-based/single-piece-flow/fix-forward, these show up as bugs found by testers that we decide to “hotfix” or cause us to pause cloud deployment propagation because they are bad enough that we've decided to not ship with the bug.
          • Non-Regrettable Work Release Defects
            • Bugs caught by testers, but we've decided that they are low enough priority that we can ship/continue normal cloud deploy propagation with these known bugs
          • Cloud Deploy Propagation
            • We have three nodes as I write this. US-1, US-2, and US-3. Our current process is to deploy to US-1, but we hold off for a while before we deploy to US-2 and US-3. Sometimes a bug will be caught in US-1, and we will pause the deploy to US-2 and US-3. The act of deploying to one and then another is cloud deploy propagation.
          • Trunk-based/Single-piece-flow/Fix-forward:
            • As of writing this, the Skills Squad will be deploying every story individually to production (single piece flow). They will also not have any branches outside of the short-lived branches for their stories (trunk-based). Finally, when they encounter issues, instead of rolling back being the default action to restore service, the default action will be to deploy a fix/patch (fix-forward).

          Things you might deliver/do

          • Though you won't be exclusively responsible for engineers having the best tools and processes to do their best work, you will be heavily relied upon to ensure this is happening.
          • You'll search for the “multiplicative effect”: impact multiplied by the number of people
          • You'll be proactive by identifying and coordinate meeting common needs across the engineering team such as standards and conventions, documentation, etc.
          • You'll be reactive by helping coordinate solutions to problems you hear about from the team, such as on-call support being frustrating, or waiting on reviews taking too long.
          • You'll contribute to continually iterating on and improving the Engineer Growth Framework
          Requirements
          • Must have a position with the reach of 3.1 or higher
          • For this role, you must be milestone 2 or greater inMentorship
          • For this role, you must be milestone 1 or greater inRails
          • For this role, you must be milestone 1 or greater inRuby
          • For this role, you must be milestone 1 or greater inCommunity
          • For this role, you must be milestone 1 or greater inSense and Respond
          • For this role, you must be milestone 1 or greater inReact
          • For this role, you must be milestone 1 or greater inWeb Technologies
          Examples
            Observation created over 5 years ago

          I've been feeling a little down on our codebase lately, overwhelmed by the myriad things developers have to remember (and help each other remember in code reviews) to make the stuff we build work properly for our users. So I felt immense gratitude to Ethan for two things this week that will make developers/testers lives easier while helping us deliver better experiences for the folks using our software. But I'm also deeply impressed with how Ethan went about these changes. Change is hard, and the more valuable the change, typically the harder it is to make, or else we would have made it already! But Ethan met these challenges with curiosity, tenacity, and a drive to create clarity in messy situations.

          The first example is with autoprefixer, a tool that automatically adds to our styling code to make things look right in older browsers. For years, we've often forgotten to add this code manually when building new pages, taking up testers' time catching bugs and leading to rework. While Waseem started the effort to introduce this automation tool, it was Ethan who saw the value and ultimately delivered on it in Waseem's absence, picking up the story and diving into an obscure IE bug to make it shippable. And look at this incredible comment explaining the issue, its cause, and what we need to retest: https://app.clubhouse.io/lessonly/story/41159/add-css-auto-prefixer#activity-42233 :chefs_kiss:

          And then there's the UI Library, a massive project that will make the app more consistent for users and allow us to design and prototype new features at lightning speed. We've struggled for several quarters to prioritize that because it's hard to know where to begin. I'm not sure who all gets credit for the new approach (at least Ethan and Jaki) we're taking of looking at customers' custom CSS for clues about what's most valuable to standardize, but I'm :jazz_hands: to see movement on this project, and just look at the incredible statistical analysis Ethan did to get it moving: https://docs.google.com/spreadsheets/d/1pQPVfhRd1c-8wZiT7I5XibRwsKplGScaDgpM0Y2179w/edit#gid=72331942

          The next time I find myself thinking "X would be so great, but how do we ever start?", I'm just gonna ask myself "What would Ethan do?" 😉True grit.

            Observation created about 6 years ago

          https://lessonly.slack.com/archives/C927U8ZFV/p1567534294000800

          Need I say more?

          I think the awesomeness speaks for itself, but the specific things I love are:

          1) See a need, fill a need... that policy has been in place for a year, and no one took the time to make sure it was being done and clear... but, you did.
          2) Get agreements... in bold, and in a fun clear way, you ask not if you've seen it, but if you agree... masterful!
          3) The kindness shown here is both blinding and inconspicuous. Fucking love it.

            Observation created about 6 years ago

          Since we didn't have a team meeting yesterday, I wanted to shout about Waseem's recent PR to enable some accessibility checks in eslint: https://github.com/lessonly/lessonly/pull/7075 This is the culmination of months of work upgrading eslint and its dependencies. The benefits of up-to-date software are many (security, performance, reliability) but in this particular case it allowed us to enable some accessibility checks. Sure, linters like eslint help us keep our whitespace consistent, but this is an example of how they can really shine: as teaching tools. As a result of Waseem's work, now when we accidentally write UI code with accessibility flaws that make it harder for some folks to use Lessonly, we'll get a warning that "Hey, we can do better!" (And we'll have to fix it before that code can be merged.) Automation like this scales with our team, and it doesn't just make our code better over time, it makes us better. This gives me confidence that as we grow, we won't be one forgotten Lesson or hurried code review away from falling short on accessibility, but that, at least in these examples, it's guaranteed to be a part of how we build software. Finally, I'm reminded of Nassim Nicholas Taleb's Antifragile (which makes an appearance in Do Better Work), which is about building systems that aren't just resilient to failure, but that get stronger from failure. Here is an example where when we make certain accessibility mistakes, we're guaranteed to learn and grow, getting stronger and smarter as we do. Heck yeah!

          We ensure we’re shipping high quality frontend code, we put teammates first by using code reviews as a way to help them do their best work, and we keep stories moving through our process.

          Full Description
          • We ensure we’re shipping high quality frontend code and give actionable feedback on code including (but not limited to) the following areas:
            • Performance
            • Security
            • Style guide
            • Architectural patterns
            • Hygienic (common conventions) concerns
          • 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 keep stories moving through our process
            • We review at least one story for every story we own
          Requirements
          • Must have a position with the reach of 1.1 or higher
          • For this role, you must be milestone 1 or greater inPrioritization
          • For this role, you must be milestone 1 or greater inWeb Technologies
          • For this role, you must be milestone 1 or greater inReact
          • For this role, you must be milestone 1 or greater inCollaboration
          • For this role, you must be milestone 1 or greater inEngineering Communication
          Examples
          An observation relating to  Front-end Code Reviewer  has not been publicly recognized yet.

          We ship high quality code, we’re highly confident in providing the best experience for our users, and we deliver frontend stories to contribute to the team’s success and keep progress moving forward.

          Full Description
          • We ship high quality code
            • Minimal (less than average) number of regrettable recycles on stories owned. For example:
            • ~90% test coverage
              • So we can (Shared) increase confidence that our code will work as expected
              • Not-you, engineering experience
            • Performance concerns
            • Security concerns
            • Style guide concerns
            • Architectural pattern concerns
            • Hygienic (common conventions) concerns
          • We’re highly confident in providing the best experience for our users
            • Minimal (less than average) number of regrettable remediations on stories owned. For example:
            • Performance issues
            • Authorization issues
            • Functionality issues
            • Error handling issues
          • Delivers frontend stories to contribute to the team’s success and keep progress moving forward
            • Better than average cycle time of active states (as defined in OurGruuv)
          Requirements
          • Must have a position with the reach of 1.1 or higher
          • For this role, you must be milestone 1 or greater inWeb Technologies
          • For this role, you must be milestone 1 or greater inEstimation
          • For this role, you must be milestone 1 or greater inPrioritization
          • For this role, you must be milestone 1 or greater inInitiative
          • For this role, you must be milestone 1 or greater inReact
          • For this role, you must be milestone 1 or greater inCollaboration
          • For this role, you must be milestone 1 or greater inEngineering Communication
          • For this role, you must be milestone 1 or greater inSoftware Investigation
          Examples
            Observation created over 4 years ago

          Double shout out to our residential front end wizards (or wizard and witch, if you prefer) and "honorary" Practice members, Carolyn and Ethan, for super-ly putting the team first!

          When Ellie was here, they both jumped in to help her sort through front end issues and learn the ropes of our codebase, and now that John and I don't have our own React-Gandalf to look to, they have both made time (lots of it) to answer questions and help us navigate through some weird bugs on a difficult project.

          Carolyn and Ethan, we really appreciate how you've generously given us your time and have been so positive and helpful!

            Observation created about 5 years ago

          Donnie is also very patient with me. He has been a great (frontend) partner on a shared project. He’s always been able to help me improve something I’ve written and or walk me through some of his tips on reviewing. I really appreciate the atmosphere you bring any time we collaborate as well. Thanks

            Observation created about 5 years ago

          This is long overdue. Ethan is always very patient with me and no matter how trivial of a question I have, he always gives me his full attention and time. I have been trying to enhance my frontend skills and he is always very willing to help out and I really appreciate it.

            Observation created almost 6 years ago

          I am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.

          I have been inspired to bring the level of clarity I have found here in other aspects of my job.

            Observation created almost 6 years ago

          Last week, I did a code review for Conlin. In the PR description, he did a phenomenal job at leaving detailed testing steps and notes around why the story was necessary. Beyond that, however, he also went out of his way to thoroughly talk through the issue on a deeper level. He explained the research he did on the problem, potential solutions (and why they wouldn't work), his decided solution (and why it does work), as well as the history and potential future of the problem. As both a reviewer and fellow engineer, I was really impressed by how much thought and effort went into this.
          While I already find myself aiming to be as clear and informative as possible in my PR descriptions, seeing this inspired me to raise my standard going forward, and left me feeling grateful to work with Conlin.

          PR of Reference - https://github.com/lessonly/lessonly/pull/7482

          A member of the frontend engineering guild 🎉

          Full Description

          Success:

          • TBD

          Details:

          • TBD
          Requirements
          • Must have a position with the reach of 1.1 or higher
          Examples
            Observation created over 5 years ago

          I've been feeling a little down on our codebase lately, overwhelmed by the myriad things developers have to remember (and help each other remember in code reviews) to make the stuff we build work properly for our users. So I felt immense gratitude to Ethan for two things this week that will make developers/testers lives easier while helping us deliver better experiences for the folks using our software. But I'm also deeply impressed with how Ethan went about these changes. Change is hard, and the more valuable the change, typically the harder it is to make, or else we would have made it already! But Ethan met these challenges with curiosity, tenacity, and a drive to create clarity in messy situations.

          The first example is with autoprefixer, a tool that automatically adds to our styling code to make things look right in older browsers. For years, we've often forgotten to add this code manually when building new pages, taking up testers' time catching bugs and leading to rework. While Waseem started the effort to introduce this automation tool, it was Ethan who saw the value and ultimately delivered on it in Waseem's absence, picking up the story and diving into an obscure IE bug to make it shippable. And look at this incredible comment explaining the issue, its cause, and what we need to retest: https://app.clubhouse.io/lessonly/story/41159/add-css-auto-prefixer#activity-42233 :chefs_kiss:

          And then there's the UI Library, a massive project that will make the app more consistent for users and allow us to design and prototype new features at lightning speed. We've struggled for several quarters to prioritize that because it's hard to know where to begin. I'm not sure who all gets credit for the new approach (at least Ethan and Jaki) we're taking of looking at customers' custom CSS for clues about what's most valuable to standardize, but I'm :jazz_hands: to see movement on this project, and just look at the incredible statistical analysis Ethan did to get it moving: https://docs.google.com/spreadsheets/d/1pQPVfhRd1c-8wZiT7I5XibRwsKplGScaDgpM0Y2179w/edit#gid=72331942

          The next time I find myself thinking "X would be so great, but how do we ever start?", I'm just gonna ask myself "What would Ethan do?" 😉True grit.

          We own the setup and maintenance of technical integrations that are core to a customer’s success and we continuously evaluate our time to value and minimize the time it takes to setup and resolve integration issues in order to provide a fully functional continuous training program.

          Full Description
          • We own the setup and maintenance of technical integrations that are core to a customer’s success including (but not limited to):
            • sFTP file syncs
            • Authentication providers (OAuth, Okta, SAML, SCIM, etc)
            • Custom branding via CSS
          • We continuously evaluate our time to value and minimize the time it takes to setup and resolve integration issues in order to provide a fully functional continuous training program.
          • We help identify inefficiencies and assist (when necessary) in building solutions
          Requirements
          Examples
            Observation created almost 6 years ago

          Noah has been with us for a little over 6 months at this point and in that time, he's done a great job developing relationships with the rest of the company, going out of his way to help both customers and our internal folks resolve issues, and helping improve the escalation process. He's done such a great job that folks outside of our team have sent me messages about how helpful he's been. Here's the latest from someone in the company: "Noah has been killing it! He is doing an awesome job, especially with a few difficult customers lately. We appreciate him and his hard work SO VERY MUCH!!"

          Thank you, Noah for your empathy, patience, and the initiative you take to help everyone do better work 🎉

            Observation created about 6 years ago

          Multiple times over the last few months (and likely the last few years), Kyle has been working closely with Karlie and the US Cellular team on their integrations/enhancements/all the things. This has required him to jump on multiple phone calls and to work ridiculously late hours; a few times, he's been up in the middle of the night for a few hours to make sure everything worked as expected. Each time he's done this, he's still been a team player first thing the next morning. I appreciate his willingness to always take this on and do it with a positive attitude. Thanks, Kyle!

          --No summary set yet--

          Full Description

          Success:

          • Converting data science models created by data scientists and converting them into performant, reliable, and resilient, production-quality functions. Squads will take the interfaces that you create and use them to build user-facing functionality.

          Details:

          • Probably using Python
          Requirements
          • Must have a position with the reach of 2.1 or higher
          Examples
          An observation relating to  Machine learning engineer  has not been publicly recognized yet.

          We respond to and triage all application wide errors and outages

          Full Description
          • We respond to and triage all application wide errors and outages.
          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 inInfrastructure
          • For this role, you must be milestone 2 or greater inRuby
          • For this role, you must be milestone 2 or greater inRails
          • For this role, you must be milestone 2 or greater inData
          • For this role, you must be milestone 2 or greater inEngineering Communication
          • For this role, you must be milestone 2 or greater inSoftware Investigation
          Examples
          An observation relating to  On-call application engineer  has not been publicly recognized yet.

          • Software Support

             Assignments:

            Acting as a liaison between the Customer Support and Product Departments, we are the first line of defense for all escalated support tickets and help provide solutions to identified challenges.

            Full Description
            • We act as a liaison between the Customer Support and Product departments
              • Provide clear and timely communication with Customer Support
              • Create clubhouse tickets that require engineering squad involvement
              • Create troubleshooting documentation for internal resources
            • We serve as the first line of defense for all escalated support tickets by triaging incoming tickets and escalating tickets as needed.
            • We identify challenges and provide potential solutions to empower Tier 1 and our customers to be more self-sufficient.
            Requirements
            Examples
              Observation created almost 6 years ago

            Noah has been with us for a little over 6 months at this point and in that time, he's done a great job developing relationships with the rest of the company, going out of his way to help both customers and our internal folks resolve issues, and helping improve the escalation process. He's done such a great job that folks outside of our team have sent me messages about how helpful he's been. Here's the latest from someone in the company: "Noah has been killing it! He is doing an awesome job, especially with a few difficult customers lately. We appreciate him and his hard work SO VERY MUCH!!"

            Thank you, Noah for your empathy, patience, and the initiative you take to help everyone do better work 🎉

          • Tech Leadership

             Assignments:

            We are all about helping the squad to get stuff live faster and more predictably, not by cracking the whip but by removing obstacles that get in the way.

            Full Description

            This excerpt from Marty Cagan's book Inspired speaks to the success of this role better than we could:
            "Delivery managers are a special type of project manager whose mission is all about removing obstacles—also known as impediments—for the team. Sometimes, these obstacles involve other product teams, and sometimes they involve non‐product functions. In a single day, they might track down someone in marketing and press them for a decision or an approval, coordinate with the delivery manager on another team about prioritizing a key dependency, persuade a product designer to create some visual assets for one of the front‐end developers, and deal with a dozen other similar roadblocks.”

            Key Result(s) / Outcomes

            • Blocker/impediment management/removal
              • Creates an environment where raising blockers/impediments is safe
              • For each of the active work-in-progress stages of the story workflow, we (the squad) get a B or higher as our score
              • If we are NOT meeting a B, we have a plan identified or are working on a plan to get to a B in a particular story stage
            • Checkpoint and Quarterly delivery goals are hit > 90% of the time
              • If applicable for your squad, Daily and/or Weekly goals are also hit > 90% of the time
              • Communicated effectively with the Epic Shaper and Squad Progress Communicator
            • Squads are able to answer forecastability questions, such as:
              • What is our squad’s current capacity?
              • What capacity do we gain if we add folks?
              • What capacity do we lose if we remove folks?
              • What is the current risk of ongoing projects?
              • How confident are we in the above answers?
            Requirements
            Examples
              Observation created over 5 years ago

            https://lessonly.slack.com/archives/C8UPX4UPM/p1581707334029900

            I don’t think I need to add more to this.

            This post was so clear, and inspired a tremendous amount of confidence that we are truly believing in the feedback-loop philosophy.

            Well done y’all, well done!

              Observation created almost 6 years ago

            https://lessonly.slack.com/archives/G8Q5B0EVA/p1580215718016900

            In my opinion, this is a big part of what delivery management is about.

            • Who can help? Architects
            • Why is it important (with some color in there for good measure)
            • Who will benefit (specific, and playing at folks' emotions)

            Loved this!

              Observation created about 6 years ago

            https://lessonly.slack.com/archives/C8UPX4UPM/p1571263756008600

            This note starts with a dose of awesomeness with a call out to the momentum. Therefore bringing brightness to the room, while about to have a semi-difficult conversation.


            I really appreciated the fact that the following message made me feel unworried, because I believe there are clear indications the squad has their eye on the ball with statements like; "slowed down by two back-end blocker stories... merge conflicts". Talk about delivery operational awareness!


            Reflection without a gameplan for change is often pointless. So I was thrilled to read things like; "if we can get those into review tomorrow morning and be proactive about seeking reviewers". This shows a plan and how the plan differs from what we might have been doing.


            Then with statements like this; "I think we can have all of Epic 1 done by end-of-week and start testing with customers on Monday. @adam, I'm sure you're eager for this, so I'll keep you posted on our progress tomorrow."
            ... it exudes a quote I love, which is

            Keep the most important thing, the most important thing.

            In this case, the most important thing is getting working software in the hands of our customers so that we can keep the learning going strong! This reminds me of a Jeff Gothelf quote

            Keep measuring and learning even after you ship.
            ... it’s all discovery and we learn from everything we make; be it a paper prototype, or the next feature in your production software. I agree with him.

            🙌🏾


            This is a great example of us calling out when we are behind, when we are ahead, and when we are on pace, and what is the most important thing for us. Delivery management = operational awareness = self and squad accountability = excellence.

            I think overall the squad was a little behind their goals at the time of writing this. I'd love to see us lean into that difficult conversation a bit and express the psychological safety and clarity that comes with simply stating it plainly. The goal isn't perfection, the goal is alignment, togetherness, and communicating reality so that we as a tribe can react, learn, and grow from the highs and lows of our journey.


            It ended in such an inspirational way that I'll end this with that same sentiment:

            Let's keep up the momentum, and keep helping each other out tomorrow! :fire:

              Observation created over 6 years ago

            I had a few high priority stories that were in need of remediation. Haley kindly picked up one of them for me and in the course of doing so discovered that there was some weirdness with the story. It's been more of a headache then the original remediation seemed to suggest and I am really grateful for her picking it up and sticking with the story.

            We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level, we put teammates first by using code reviews as a way to help them do their best work, and we ensure we consistently ship high quality code.

            Full Description
            • We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level. Questions we may ask during these reviews:
              • What is the problem that this change is designed to solve?
              • What is the proposed change? Include details, especially where there is some risk.
              • How does this change impact other systems? How does it impact the codebase?
              • What are the risks of this change?
              • What alternatives are there, and what are the drawbacks of those alternatives?
              • What data backs up the proposed change?
            • 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 ensure we consistently ship high quality code
              • We have a higher than average code review ratio so that we can share knowledge with others and keep stories moving forward while keeping in mind how changes might affect dependencies, engineers, users, the codebase itself. . We may give feedback on (but not limited to):
                • Dependencies
                • Test coverage
                • System level impact
                • Performance concerns
                • Security concerns
                • Architectural pattern concerns

            Handbook

            Requirements
            • Must have a position with the reach of 2.3 or higher
            • For this role, you must be milestone 3 or greater inRuby
            • For this role, you must be milestone 3 or greater inData
            • For this role, you must be milestone 3 or greater inRails
            • For this role, you must be milestone 3 or greater inCollaboration
            • For this role, you must be milestone 2 or greater inInfrastructure
            • For this role, you must be milestone 3 or greater inEstimation
            • For this role, you must be milestone 3 or greater inEngineering Communication
            Examples
              Observation created almost 6 years ago

            This thread speaks to it: https://lessonly.slack.com/archives/CPHPVJSTH/p1574698910011200

            This is a great discussion and approach to taking on what could be a larger project in Linked Elements. The team was able to work together to identify and slice up the work in order to get value into the hands of customer faster. Alec said it in his summary here:

            We are going to structure the epics so at the end of each element the element is fully implemented. This means that at the end of epic two the paragraph element will have all of the linked element functionality. Then epic three will be the photo element fully implemented.

            • This will mirror how the platform team rolled out a role management, a fully functional piece of a larger whole. This means we can learn more about the entire linked element process earlier.
            • It gets to value quickly. We have been hearing for years from clients about the linked element functionality. With this plan, we will allow admins to do this whole process faster!
            • It will make the delivery manager role more smooth. Because of this plan, each epic will look similar technically speaking. The first element will take the longest because we have to implement all of Linked elements but after we will be able to determine with reasonable accuracy how long each element takes to build start to finish.

            As a result...

            • This enables the squad in efforts of successful decomposition of ideas into shippable units of work to deliver customer value, validate P&E assumptions, or both
            • Developing right-size slices of work that fit into the checkpoint and quarterly goals
            • Thinking through the stack in a way that promotes flexible story creation (e.g. model/database, API, routes, react components, UI).
            • Your squad consistently gets slices of work into customers hands for testing as early as possible in the lifespan of a project
              Observation created about 6 years ago

            Multiple times over the last few months (and likely the last few years), Kyle has been working closely with Karlie and the US Cellular team on their integrations/enhancements/all the things. This has required him to jump on multiple phone calls and to work ridiculously late hours; a few times, he's been up in the middle of the night for a few hours to make sure everything worked as expected. Each time he's done this, he's still been a team player first thing the next morning. I appreciate his willingness to always take this on and do it with a positive attitude. Thanks, Kyle!

              Observation created over 6 years ago

            So Tom was promoted to a new level of software engineer a month or two ago and it was well desearved in my opinion. But that's not what this is about. This is about how Tom hasn't stopped progressing. Most recently Tom has taken the lead on defining the architecture of Draft Mode and done so in a way that has made it seem like he is a seasoned vet who has been here well beyond the years he has been here. He has put together a POC and written up the architecture review doc that will be shared with the architects tomorrow. It could have been easy to let a more tenured engineer take the lead on this, but Tom stepped up to the challenge and I think we are better off because of it!

            Thanks Tom!

            We actively participate in Product Discovery (in close collaboration with the rest of the discovery crew…. usually product managers and product designers) to assess the technical possibilities and understand/test the feasibility of potential solutions that meet customer needs.

            Full Description
            • We work closely with product managers and product designers to assess the technical feasibility of solutions that meet customer needs by providing insight and answering questions such as:
              • What is the very early feasibility analysis that ensures there’s a manageable amount of risk as it moves into delivery (likely giving best case worst case based on nothing more than wireframes)?
              • What delivery goals are possible in a given time period with a given amount of engineering resources?
              • What are the impacts the potential solutions may have on our existing systems?
            • Check out this lesson for more details!
            Requirements
            • Must have a position with the reach of 2.2 or higher
            • For this role, you must be milestone 1 or greater inRuby
            • For this role, you must be milestone 1 or greater inDelivery Forecasting
            • For this role, you must be milestone 1 or greater inProduct Discovery
            • For this role, you must be milestone 1 or greater inWeb Technologies
            • For this role, you must be milestone 1 or greater inRails
            • For this role, you must be milestone 1 or greater inReact
            • For this role, you must be milestone 1 or greater inData
            • For this role, you must be milestone 1 or greater inCollaboration
            • For this role, you must be milestone 1 or greater inEstimation
            • For this role, you must be milestone 1 or greater inEngineering Communication
            Examples
              Observation created almost 6 years ago

            Conlin has officially sent out THE best meeting invite ever. He included a nicely formatted layout with three sections:

            • what the general situation is and purpose for the meeting, including a freaking timeboxed 😍 and labeled agenda 🎉🎉🎉
            • why the meeting is needed
            • who will be attending the meeting and what they bring to the table in terms of how they can contribute to finding a solution

            Conlin has simultaneously set us up for success in the best way possible while also being incredibly mindful of everyone's time. His thoughtfulness here helped me to feel incredibly valued. I think this is super awesome and is a setup that I want to follow in the future. Thanks Conlin!

              Observation created almost 6 years ago

            I am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.

            I have been inspired to bring the level of clarity I have found here in other aspects of my job.

              Observation created almost 6 years ago

            Last week, I did a code review for Conlin. In the PR description, he did a phenomenal job at leaving detailed testing steps and notes around why the story was necessary. Beyond that, however, he also went out of his way to thoroughly talk through the issue on a deeper level. He explained the research he did on the problem, potential solutions (and why they wouldn't work), his decided solution (and why it does work), as well as the history and potential future of the problem. As both a reviewer and fellow engineer, I was really impressed by how much thought and effort went into this.
            While I already find myself aiming to be as clear and informative as possible in my PR descriptions, seeing this inspired me to raise my standard going forward, and left me feeling grateful to work with Conlin.

            PR of Reference - https://github.com/lessonly/lessonly/pull/7482

              Observation created over 6 years ago

            So I thought this was worthy of a video shoutout here: https://www.loom.com/share/88ee172369584e2b8584ec5faf8af675

            In short, Conlin took just a couple hours to put together a spike (check out his post about it here: https://lessonly.slack.com/archives/C8UPX4UPM/p1557925515038000) for Lessonly Conversations that enables our team to test our riskiest assumptions with customers, get closer to reality without writing much code, and begin the learning process on a 2019 commitment. This is a great example of sharing before ready, experimenting rapidly to begin learning, and trying something new!

            We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level, we put teammates first by using code reviews as a way to help them do their best work, and we ensure we consistently ship high quality code.

            Full Description
            • We engage in architecture review conversations and offer feedback on potential approaches by thinking at a systems level. Questions we may ask during these reviews:
              • What is the problem that this change is designed to solve?
              • What is the proposed change? Include details, especially where there is some risk.
              • How does this change impact other systems? How does it impact the codebase?
              • What are the risks of this change?
              • What alternatives are there, and what are the drawbacks of those alternatives?
              • What data backs up the proposed change?
            • 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 ensure we consistently ship high quality code
              • We have a higher than average code review ratio so that we can share knowledge with others and keep stories moving forward while keeping in mind how changes might affect dependencies, engineers, users, the codebase itself. . We may give feedback on (but not limited to):
              • Dependencies
              • Test coverage
              • System level impact
              • Performance concerns
              • Security concerns
              • Architectural pattern concerns

            Associated lesson

            Check out the lesson on architects

            Requirements
            • Must have a position with the reach of 3.1 or higher
            • For this role, you must be milestone 2 or greater inWeb Technologies
            • For this role, you must be milestone 2 or greater inEstimation
            • For this role, you must be milestone 2 or greater inInitiative
            • For this role, you must be milestone 2 or greater inPrioritization
            • For this role, you must be milestone 2 or greater inReact
            • For this role, you must be milestone 2 or greater inCollaboration
            • For this role, you must be milestone 2 or greater inEngineering Communication
            Examples
              Observation created over 5 years ago

            I've been feeling a little down on our codebase lately, overwhelmed by the myriad things developers have to remember (and help each other remember in code reviews) to make the stuff we build work properly for our users. So I felt immense gratitude to Ethan for two things this week that will make developers/testers lives easier while helping us deliver better experiences for the folks using our software. But I'm also deeply impressed with how Ethan went about these changes. Change is hard, and the more valuable the change, typically the harder it is to make, or else we would have made it already! But Ethan met these challenges with curiosity, tenacity, and a drive to create clarity in messy situations.

            The first example is with autoprefixer, a tool that automatically adds to our styling code to make things look right in older browsers. For years, we've often forgotten to add this code manually when building new pages, taking up testers' time catching bugs and leading to rework. While Waseem started the effort to introduce this automation tool, it was Ethan who saw the value and ultimately delivered on it in Waseem's absence, picking up the story and diving into an obscure IE bug to make it shippable. And look at this incredible comment explaining the issue, its cause, and what we need to retest: https://app.clubhouse.io/lessonly/story/41159/add-css-auto-prefixer#activity-42233 :chefs_kiss:

            And then there's the UI Library, a massive project that will make the app more consistent for users and allow us to design and prototype new features at lightning speed. We've struggled for several quarters to prioritize that because it's hard to know where to begin. I'm not sure who all gets credit for the new approach (at least Ethan and Jaki) we're taking of looking at customers' custom CSS for clues about what's most valuable to standardize, but I'm :jazz_hands: to see movement on this project, and just look at the incredible statistical analysis Ethan did to get it moving: https://docs.google.com/spreadsheets/d/1pQPVfhRd1c-8wZiT7I5XibRwsKplGScaDgpM0Y2179w/edit#gid=72331942

            The next time I find myself thinking "X would be so great, but how do we ever start?", I'm just gonna ask myself "What would Ethan do?" 😉True grit.

              Observation created almost 6 years ago

            This thread speaks to it: https://lessonly.slack.com/archives/CPHPVJSTH/p1574698910011200

            This is a great discussion and approach to taking on what could be a larger project in Linked Elements. The team was able to work together to identify and slice up the work in order to get value into the hands of customer faster. Alec said it in his summary here:

            We are going to structure the epics so at the end of each element the element is fully implemented. This means that at the end of epic two the paragraph element will have all of the linked element functionality. Then epic three will be the photo element fully implemented.

            • This will mirror how the platform team rolled out a role management, a fully functional piece of a larger whole. This means we can learn more about the entire linked element process earlier.
            • It gets to value quickly. We have been hearing for years from clients about the linked element functionality. With this plan, we will allow admins to do this whole process faster!
            • It will make the delivery manager role more smooth. Because of this plan, each epic will look similar technically speaking. The first element will take the longest because we have to implement all of Linked elements but after we will be able to determine with reasonable accuracy how long each element takes to build start to finish.

            As a result...

            • This enables the squad in efforts of successful decomposition of ideas into shippable units of work to deliver customer value, validate P&E assumptions, or both
            • Developing right-size slices of work that fit into the checkpoint and quarterly goals
            • Thinking through the stack in a way that promotes flexible story creation (e.g. model/database, API, routes, react components, UI).
            • Your squad consistently gets slices of work into customers hands for testing as early as possible in the lifespan of a project
              Observation created almost 6 years ago

            Last week, I did a code review for Conlin. In the PR description, he did a phenomenal job at leaving detailed testing steps and notes around why the story was necessary. Beyond that, however, he also went out of his way to thoroughly talk through the issue on a deeper level. He explained the research he did on the problem, potential solutions (and why they wouldn't work), his decided solution (and why it does work), as well as the history and potential future of the problem. As both a reviewer and fellow engineer, I was really impressed by how much thought and effort went into this.
            While I already find myself aiming to be as clear and informative as possible in my PR descriptions, seeing this inspired me to raise my standard going forward, and left me feeling grateful to work with Conlin.

            PR of Reference - https://github.com/lessonly/lessonly/pull/7482

              Observation created about 6 years ago

            The PR Waseem wrote for https://github.com/lessonly/lessonly/pull/7197 is just fantastic, even by his own high standard. The context, problem, mechanics of the solution (including diagrams!), and even performance data are included. He's showing a deep understanding of the issue and the PR is educational as it explains itself. Everyone should check it out!

            We coordinate with the members of a guild in their craft.

            Full Description

            Objective

            We coordinate with the members of a guild in their craft (be it positions such as engineering or design, or specific roles such as story backlog groomers or quality control testers). It's not necessarily about teaching, but about enabling the group to learn and to work together.

            Key Result(s)

            • Guild meets at least once per month
            • Guild has worked on at least one measurable improvement once per quarter

            Details

            Typical deliverables

            • Learn together
              • The guild meets regularly (at least once each month) to learn together in some way, whether watching a talk, having a discussion, or anything that resonates with members.
            • Improve our product or team
              • Ideally each guild member will have worked on at least one change in the guild's craft over the course of the quarter.

            Typical tasks

            • Schedule meetings
            • Encourage participation
            • Prioritize work (collaboratively)

            Further Reading

            Requirements
            • Must have a position with the reach of 2.2 or higher
            Examples
            An observation relating to  Guild lead  has not been publicly recognized yet.

            We are responsible for setting the tone for how our software architecture is set up. This spans many concerns, such as performance and scalability, security and privacy, as well as reliability and overall supportability.

            Full Description

            Key Results/Outcomes

            This enablement lead is responsible for those fulfilling the following assignments (Tech Leadership domain):

            • {{Back-end architect}}
            • {{Front-end architect}}

            ENGAGEMENT:

            • The people taking on the assignments listed above, agree or strongly agree to the following statements:
              • I know how I’m being evaluated on these roles.
              • I receive actionable (meaning timely, frequent, specific, and observation-based) constructive feedback on my performance within the roles identified above.
              • I receive actionable (meaning timely, frequent, specific, and observation-based) recognition (public or private) on my performance within the roles identified above.
              • I believe I have the tools to meet or exceed the outcomes listed within the roles in question.
              • I believe I have the processes and environment to meet or exceed the outcomes listed within the roles in question.
              • I believe we are continuously improving in how we go about taking on these roles.
              • Note: This SHOULD have a direct impact on the NPS score of engineers (where they select 8+ on a 10-point scale to the question; “I’d recommend a friend come to work here”). However, given that full engagement is more inclusive than their primary roles, it doesn’t feel right to have that as a part of the measure of enablement leads.

            Things you might deliver/do

            • Though you won't be exclusively responsible for engineers having the best tools and processes to do their best work, you will be heavily relied upon to ensure this is happening.
            • You'll search for the “multiplicative effect”: impact multiplied by the number of people
            • You'll be proactive by identifying and coordinate meeting common needs across the engineering team such as standards and conventions, documentation, etc.
            • You'll be reactive by helping coordinate solutions to problems you hear about from the team, such as on-call support being frustrating, or waiting on reviews taking too long.
            • You'll contribute to continually iterating on and improving the Engineer Growth Framework

            Success:

            • You are responsible for setting the tone for how the software architecture is set up. This spans many concerns, such as;
              • Performance
              • Scalability
              • Security
              • Privacy
              • Reliability
              • Overall supportability.

            AKA

            • Architecture policy definition/enforcement officer

            Requirements
            • Must have a position with the reach of 3.2 or higher
            • For this role, you must be milestone 3 or greater inRuby
            Examples
            An observation relating to  Software Architecture lead  has not been publicly recognized yet.

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

            Full Description

            Success:

            • The prioritized and ready lanes have stories that are estimated in such a way that leads to low volatility, understandable to the stakeholders of the story (Eng, QA, Design, and release notes that are geared towards any non-tech stakeholder).
            • If story cycle time is low, that 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

            Details

            • Usually, only one per squad per quarter
            • Takes the epics and ensures that stories 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. Stories can, but likely shouldn't need much work done to them after you have done your magic to them.

            AKA

            • Squad progress enabler (epic to actionable stories)
            • Story backlog groomer

            From our recent job description

            You will take the slices of work (epics) and break them into specific, actionable stories so that we can ship as effectively as possible (which means the stories are as small and as clear as possible). Ultimately we want stories 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 any other constraints. Though you’ll be doing your best if you’re getting help from your squad, the bulk of this work will fall to you to ensure it is being done well.

            Success looks like:

            • We use a kanban board style of project management tool, but we encourage each squad to work in a way that is most effective for the squad. We have 3-week check-ins as a department, so some work in 3-week sprints, while others use a pure kanban. You’ll be successful if your squadmates are clear on what is up next.
            • 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.

            Key Results/Outcomes

            • We take slices of work (epics) and break them into specific, actionable stories so that we can ship as effectively as possible.
              • Stories are as small, as clear as possible, and have a relatively consistent cycle time.
              • Stories also help us with forecastability and understandability in our pursuit of continuous value delivery.
            Requirements
            • Must have a position with the reach of 2.1 or higher
            • For this role, you must be milestone 1 or greater inDecomposition & Sequencing
            • For this role, it is recommended to be milestone 1 or greater inData
            • For this role, you must be milestone 1 or greater inWeb Technologies
            • For this role, you must be milestone 1 or greater inEstimation
            • For this role, it is recommended to be milestone 1 or greater inRails
            • For this role, you must be milestone 1 or greater inCollaboration
            • For this role, it is recommended to be milestone 1 or greater inReact
            • For this role, it is recommended to be milestone 1 or greater inRuby
            • For this role, you must be milestone 1 or greater inEngineering Communication
            Examples
              Observation created almost 6 years ago

            I am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.

            I have been inspired to bring the level of clarity I have found here in other aspects of my job.

              Observation created about 6 years ago

            https://app.clubhouse.io/lessonly/story/32892/figure-out-whether-and-how-we-should-use-vpns

            It doesn't get a ton better than this as it pertains to context.

            By simply reading the story I know what the unmet need is, I know what the potential options are, I know why we are prioritizing it now, and I know what is being done next.

            ❤️🙌🏾

              Observation created about 6 years ago

            https://app.clubhouse.io/lessonly/epic/27348#activity-32580

            This is how acceptance criteria should be written.

            This level of detail should be at the story level to ensure clarity.

            However, I'd put this level of detail in the epic in scenarios where there is less design, or complicated logic, or a delivery team that doesn't find joy in pushing the boundaries on the details.

        • Operations

           Assignments:

          We serve the function of Product Infrastructure and Software Operations, and those executing against its assignments. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Key Results/Outcomes

          ENGAGEMENT:

          • The people taking on the roles listed within the Engineering / Development domain, agree or strongly agree to the following statements:
            • I know how I’m being evaluated on these roles.
            • I receive actionable (meaning timely, frequent, specific, and observation-based) constructive feedback on my performance within the roles identified above.
            • I receive actionable (meaning timely, frequent, specific, and observation-based) recognition (public or private) on my performance within the roles identified above.
            • I believe I have the tools to meet or exceed the outcomes listed within the roles in question.
            • I believe I have the processes and environment to meet or exceed the outcomes listed within the roles in question.
            • I believe we are continuously improving in how we go about taking on these roles.
            • Note: This SHOULD have a direct impact on the NPS score of engineers (where they select 8+ on a 10-point scale to the question; “I’d recommend a friend come to work here”). However, given that full engagement is more inclusive than their primary roles, it doesn’t feel right to have that as a part of the measure of enablement leads.

          ACTIVITIES / RESPONSIBILITIES:

          • Manage Infrastructure Costs
            • Monitor infrastructure costs
            • Provide estimates for future costs
            • Work to reduce costs where possible
          • Coordinate Maintenance
            • Make sure all parts of the company are on the same page regarding maintenance
          • Manage third-party integrations
            • Track utilization of third-parties
            • Help with contract renewal discussions
          • Enable other engineering team members
            • Provide documentation on how to acquire / reconfigure infrastructure
            • Track requests for acquisition/creation of infrastructure
          Requirements
          • Must have a position with the reach of 3.1 or higher
          • For this role, you must be milestone 2 or greater inSystems Management
          • For this role, you must be milestone 1 or greater inInfrastructure
          Examples
            Observation created almost 5 years ago

          Unexpected, concise, clear, communicated with both summaries and details, and action-oriented. As it pertains to emails about technical topics, it doesn't get much better than this.

          I now feel that much more confident that Stephen isn't just thinking about doing the tasks he is assigned... he is thinking about the overall picture and health of Lessonly as we navigate this journey we are on.

          Love it!!


          Email #1:

          HI everybody,

          As you may or may not be aware there was a massive hack on solarwinds which provides infrastructure software to many companies. ( https://www.solarwinds.com/securityadvisory ).

          I want to present to this group the (preliminary) findings as I investigated our exposure because industry-wide implications and more customers are going to be asking about this.  It is going to be beneficial to have some sort of statement to respond with.

          If you would like me to work with somebody on what that statement should be please let me know. And if you have any guidance on verbage before we craft such a statement I would appreciate it.

          Executive Summary

          We use a small unaffected Solarwinds product in non production environments.  A couple of our vendors had similar exposure.  Our biggest risk is Twilio which actually used an affected product, but they believe they were not impacted by the breach.

          Our Direct Exposure

          We do not use their software directly in our data centers.

          PaperTrail

          We use a product called PaperTrail in non-production environments for logging.  No sensitive information should be sent there.  This product

          Vendors

          Vendors known to have some exposure to SolarWinds Products

          Twilio (Sendgrid, Twilio, Segment)

          The company Twilio owns 3 services that we use.  Twilio did use the affected software "in a limited fashion."  They have been working with SolarWinds and believe they were ultimately unaffected by the breach

          Twilio is our biggest risk, but at this point I believe it to be mitigated.

          Harness

          Harness used an unaffected SolarWinds product (Pingdom).  Ultimately I see no risk here, but they did share this for transparency.

          CloudBees (Codeship)

          CloudBees owns the codeship product that we use.  They, like Harness, used some unaffected SolarWinds products

          • Librato (scoped to our CodeShip product)
          • PaperTrail (scoped to our CodeShip product)
          • PingDom (basic external monitoring used by Ops)
            Observation created almost 5 years ago

          Stephen publicly highlighted the work that Brittany and Matt B. did to keep queue size down when reindexing all Lessons: https://lessonly.slack.com/archives/G8Q5B0EVA/p1607543001201000 This shout-out not only encourages those on the receiving end to continue being good stewards of our systems, but gives all developers an example to emulate. I'm sure not every engineer would have considered the impact of enqueuing any number of jobs—perhaps now they will, and might even remember that keeping queue depth to within a few hundred is a good thing, as Stephen pointed out.

          We create, maintain, document update distributed reliable infrastructure.

          Full Description

          Key Results and Outcomes

          Manage Infrastructure

          • Create tools for provisioning infrastructure easily, reliably and in accordance with policy
          • Be able to validate infrastructure is in compliance
          • Automate the above as much as possible

          Enable Scalable and Reliable Architectures

          • Provide engineers with infrastructure to run applications in a scalable fashion
          • Enable engineers to understand and use infrastructure appropriately
          • Provide input on what options are available and how infrastructure is configured/monitored

          Infrastructure Planning

          • Identify opportunities to optimize cloud costs
          • Assist in capacity planning

          Activities

          • Provision Infrastructure
          • Ensure Instrasture meets
          • Assist in incidents and on-call duties as needed
          • Design secure network topology
          • Automate compliance reporting
          • Automate provisioning of infrastructure
          Requirements
          • Must have a position with the reach of 2.2 or higher
          Examples
          An observation relating to  Infrastructure engineer  has not been publicly recognized yet.

          TBD

          Full Description
          • Respond to infrastructure alerts
          • Respond to escalation from on-call engineers
          • Document actions
          • Conduct post-mortems when necessary
          Requirements
          • Must have a position with the reach of 1.1 or higher
          Examples
          An observation relating to  Infrastructure On-call  has not been publicly recognized yet.

          With great compassion for our fellow engineers and end-users, we manage the balance between speed of innovation and reliability of end-user experience.

          Full Description

          Key Results / Outcomes

          • Reduce Toil
            • Automate repetitive tasks
          • Engineering
            • Create features / enhancements / bug fixes to improve reliability, p operability of the system
          • Manage and Improve Incident Response
            • Help teams identify alerts that can lead to early remediation of potential issues while keeping noise minimal
            • Reduce downtime
            • Reduce (Mean Time to Recovery) MTtR
          • Enable Observability of Operational Systems
            • Establish goals for latency, traffic, errors, and saturation
            • Provide feedback on these metrics to value-stream teams
            • Help values-stream teams think about how their daily work impacts system reliability
          • Keep the lights on / Necessary toil activity
            • At the end of the day some toil is necessary to keep things running
            • Attend to incidents
            • Monitor, debug and enhance release process
            • Check backups
          Requirements
          • Must have a position with the reach of 2.2 or higher
          Examples
            Observation created almost 5 years ago

          Stephen publicly highlighted the work that Brittany and Matt B. did to keep queue size down when reindexing all Lessons: https://lessonly.slack.com/archives/G8Q5B0EVA/p1607543001201000 This shout-out not only encourages those on the receiving end to continue being good stewards of our systems, but gives all developers an example to emulate. I'm sure not every engineer would have considered the impact of enqueuing any number of jobs—perhaps now they will, and might even remember that keeping queue depth to within a few hundred is a good thing, as Stephen pointed out.

            Observation created over 6 years ago

          https://lessonly.slack.com/archives/G8Q5B0EVA/p1560261306012400

          That slack thread tells the entire story...

          1) See a problem
          2) MEASURE the problem in a quantitative way so that you know if you've fixed it
          3) Plan a fix for said problem BEFORE it becomes an issue that stakeholders are even aware of
          4) Work collaboratively on the problem without interrupting other priorities
          5) look at the measures from step 2
          6) Celebrate together

          Love nearly everything about this.

          Way to go y'all!

        • Product Quality

           Assignments:

          We serve the function of Product QA, and those executing against its roles. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Success:

          • Those executing against the following roles have a continuously improving set of tools and processes (balancing autonomy and focusing on feedback loops).
            • Quality control tester
            • Technical investigator

          Details:

          • You'll help ensure that testability is a consideration in build, and testers know how to raise it as a concern
          • You'll help ensure that things are testable across environments
          • You'll help ensure that testers have a shared understanding of risk and coverage needs across the app, based on current best knowledge and trends
          • You'll help ensure that testers have what they need from a tooling and clarity perspective to level up at the core testing abilities:
            • Technical Investigation
            • Bug/Story Writing
            • System Modeling
            • Risk Assessment
          Requirements
          Examples
          An observation relating to  Product Quality Assurance Enablement Lead  has not been publicly recognized yet.

          Our goal is NOT to test quality in, but instead to help the team build quality in from the start. Moving QA thinking farther left is our prime directive.

          Full Description

          Success looks like

          • Very few priority-1 and priority-2 defect escapees found in production.
          • You'll be successful at this role if the quality control process is one of collaboration and not tension between tester and coder.
          • You'll be successful at this role if the team learns how to build quality in from the start, a bit more every day.
          • We have this role because it is essential to ensuring a high-quality experience for our users. The goal is NOT zero bugs... the goal is balancing speed with risk management.

          Details

          • Measures like the number of remediations, number of written bugs, number of stories tested are all important, but none of them alone tell the story of the value of this role.
            • If there are no remediations happening, that means the engineers are perfect, or we aren't looking deep/wide enough, or maybe we've found a point where we are writing up shippable priority-3, 4, or 5 bugs but they do not need to block the stories. Alone it doesn't tell the story, but it is an indicator
            • If there are no bugs written, this could mean either the engineers are perfect, or our calibration of what constitutes a bug is off, or if remediations are through the roof maybe we have over-calibrated to what should constitute shippable. Alone it doesn't tell the story, but it is an indicator
            • If the number of stories tested is low... well, you should chat with your manager... not sure what this could mean other than bad things 🤔
          Requirements
          Examples
          An observation relating to  Quality control tester  has not been publicly recognized yet.

          We are responsible for ensuring our application is updated in a safe, effective, and communicative manner.

          Full Description

          Success:

          • You are responsible for ensuring our application is updated in a safe, effective, and communicative manner.

          Details:

          • TBD
          Requirements
          Examples
            Observation created over 5 years ago

          https://lessonly.slack.com/archives/C73ND911P/p1582829414005400?thread_ts=1582828748.005100&cid=C73ND911P

          Talk about attention to detail, operational awareness, and excellent communication!

          This was simply fantastic!!

            Observation created almost 6 years ago

          Patrick joined the team at the start of this quarter. Now that he has been here a quarter I don't know how we used to operate without him. It is not only his thoroughness when it comes to the stories themselves but he thinks about the "soul" of the ticket. What is this actually trying to solve? Is it solving for the entire problem? His attention to detail is staggering and I am grateful he is on the team.

          He was also instrumental in the xAPI testing. It is a tricky process to test xAPI in a review, staging, and production app. He was ahead of it the whole time and made me feel confident we are releasing something we can have confidence in.

      • Management

         Assignments:

        We are the trusted facilitators of some of the most sensitive data we have within the organization... the budget and salaries. Our goal is fair, consistent, responsible, and equitable decisions regarding budget management.

        Full Description

        Success:

        • You are a trusted facilitator of some of the most sensitive data we have within the organization... the budget and salaries.
        • You help ensure we live our value of having an equitable compensation strategy. Including but not limited to:
          • Base compensation
          • Bonus compensation
          • Spot bonuses (such as Llama bucks)
          • Expenses (including lunches, books, etc)
          • Work-related incentive compensation aka stipends (such as incentives for working holidays or for volunteering for on-call)
        • You are trusted to converse with and explain compensation decisions to your direct reports, and when called for to a larger audience.
        • All employees for which you are responsible (strongly) agree to the following:
          • I am paid fairly within the industry for my position
          • The incentives and stipends inspire me and show that the organization cares

        Details:

        • Must have an understanding of the budget process.
        • Must have an understanding of the basics of the Lessonly business from a financial standpoint
        • Must have experience or a strong desire to research and synthesize market data as it pertains to compensation
        Requirements
        • Must have a position with the reach of 3.1 or higher
        Examples
          Observation created over 5 years ago

        asdf

        Bringing new folks into our tribe is one of the most important activities any of us will do. We ensure a good candidate experience, a great interviewer experience, and ultimately a talent/opportunity fit we are excited about.

        Full Description

        Success:

        • Facilitating the hiring process such that candidates have a pleasant experience (as measured by things like Glassdoor reviews).
        • Making decisions on who we will make offers to, such that the talent/opportunity fit is high.
          • Meaning the fit is great for them and the direction they are wanting to take their career, and Lessonly and the direction we are wanting to take the squad/discipline/department/company.

        Handbook:

        • You are responsible for getting the job posted
          • Drafting the job description and working with Talent to have it posted on lessonly.com/hiring and appropriate job boards
        • You are responsible for the interview structure
          • Identifying the interview team
          • Setting the interview structure
        • You are responsible for managing candidates in the workflow and communication
          • Making the decision on which candidates will progress to which states
          • One specific communication requirement is that within the Clubhouse card representing a position you are hiring for, you are required to post a weekly update similar to the following:
            1. Applications actively being reviewed: All-time: ## | In-Progress: ##
            2. Theresa Interview: All-time: ## | In-Progress: ##
            3. Woven Work Simulation: All-time: ## | In-Progress: ##
            4. Hiring Manager Interview: All-time: ## | In-Progress: ##
            5. Final Interview: All-time: ## | In-Progress: ##
            6. Offers Sent: All-time: ## | In-Progress: ##
        • Making the final hire recommendation (making the offer by working with the P&E Talent representative as well as the {budget/comp manager} if you are not taking on that role).

        Incomplete Lesson - Hiring Manager’s Handbook

        Requirements
        • Must have a position with the reach of 3.1 or higher
        • For this role, you must be milestone 3 or greater inMentorship
        • For this role, it is recommended to be milestone 1 or greater inCommunity
        Examples
          Observation created about 5 years ago

        I'll post the original message at the bottom (can't link because it was a DM).

        This is how it should be done!!! What is it? Setting up interviewers for success. A few specifics:

        1. Brea had to turn around a hiring gameplan in hours because of a non-usual situation with a specific candidate... and did so!
        2. Brea gave clear background and context to what is happening in the interview
        3. In an effort to ensure the interview is as smooth as possible, she assigned each person with a specific value, skill, behavior, or knowledge she wanted them to check for.
        4. Finally, she was aware enough to realize that since folks probably weren't used to our new ATS, that she should give a bit of guidance/training on that as well.

        Overall an excellent way to set up an interview for success. An excellent show of adaptability given the time frame this was all put together under.

        The time crunch isn't something we will get used, to but damn does it feel good to know we can rely on each other to step up when needed to kick it into a higher gear temporarily.

        Well done!

        Good morning and Happy Thursday! We have an engineering candidate, [redacted], joining us Friday. :tada: He’s interviewing for a Senior Software Engineer position (his focus will be on SRE and data needs to start and eventually help us grow a data team). [redacted] has interviewed with Lessonly previously about a year ago and was offered a position the timing didn’t work out. Here’s some more info about him:
        Jobvite Summary: [redacted link]
        Woven Results: [redacted link]
        LinkedIn: [redacted link]
        Here’s an overview of Friday’s schedule:
        09:30 AM to 10:00 AM, Conversation with: Brea
        10:00 AM to 10:45 AM, Technical/Culture Interview with: Tyler, Kristina, and Makenzie
        10:45 AM to 11:00 AM, Break
        11:00 AM – 11:45 AM, Culture Interview with: Kim, Ashley, and John
        11:45 AM to 12:00 PM, Break
        12:00 PM to 12:30 PM, Hiring Manager interview with: Brea, Andrew, and Theresa
        Let’s take the following parts of the scorecard as our focus areas for interview questions. Feel free to ask questions that don’t focus directly on these areas after you’ve covered these areas - also feel free to swap with someone if you want. Let me know if you have any questions!
        @kim

        • Business and technical translation
        • Prioritization @Ashley
        • They work to meet deadlines, and if they can’t, they proactively communicate progress and make a plan
        • We have difficult conversations @John
        • They have strong opinions weakly held (No brilliant jerks)
        • They are willing to give and receive both critical and appreciative feedback @tyler
        • Troubleshooting/debugging
        • Technical Investigation
        • Prioritization @Kristina
        • Collaborative
        • Mentorship
        • Comfortable with change
        • Empathy @Makenzie Bontrager
        • They recognize when to ask for help and when to utilize their resources effectively
        • Self-awareness
        • Initiative A few notes on Jobvite since it’s a newer tool not widely used: Please login ahead of time by selecting the first link in the calendar invite and make sure you can see the Evaluation Form. If you have issues logging in, let’s chat. All fields on the evaluation form are required to submit it, so please select NA for those you don’t have a strong opinion on. I’ll be putting a quick debrief meeting on the calendar here shortly, and please let me know if you can’t make it Friday so we can find a replacement. Thanks! Brea
          Observation created over 6 years ago

        Hiring is hard.

        It is time-consuming, it is nerve-wracking, and it is easy to get overwhelmed with the work of shepherding candidates through the process.

        However, it is the single most important thing we can do to continue our journey to be the greatest product team so that we can help fuel the greatest organization which is here to push forward one of the greatest missions of our time :-) (couldn't help myself :-) )

        When someone comes in and finds a way to improve any part of it, I'm thrilled.

        In this case, Rick posted an update from the week of what was done, and where his head is at.

        https://app.clubhouse.io/lessonly/story/29768/hire-product-quality-engineer#activity-30491

        That is HUGE... and here's why... clarity and transparency are better work.

        We love transparency here. So, posting an update like this directly impacts folks' ability to follow along and be a part of the process. Also, anyone who is interested never has to ask "where are we with that", because it is in the right place, it is concise, and it is clear.

        :spidey-dance:

        Great job man... keep it up!

          Observation created over 6 years ago

        We're currently hiring not one but two mid-senior engineers, for which there's a lot of competition these days. I saw on Twitter yesterday that an engineer I admire had just been laid off and could could be a fantastic addition to our team. I let Casey know (she's the hiring manager for this position) and she followed up that day via Greenhouse and even replied on Twitter, referencing one of the candidate's blog posts she enjoyed for a personal touch: https://twitter.com/case_eee/status/1135723324414341127

        Compared with other teams who responded to this person with a generic "We're hiring" message, Casey's prompt and thoughtful response made me feel proud of how she represented our team. And of course the goal here—bringing folks we can all learn from and growth alongside on to our team—has a direct impact to each of us. Thanks, Casey!

        We strive to influence those we serve to achieve their own goals as well as their work goals via clarity, trust, accountability, empowerment, and being an example of the Lessonly values and definition of an ideal team player.

        Full Description

        There are three aspects to technology management at Lessonly. The core philosophy that all Lessonly managers adhere to. Systematizing clarity with appreciative inquiry and feedback loops. Mission control, meaning a focus on outcomes in nearly all we do.

        We will end this description with some examples of measures that technology managers will be held accountable for.

        The core philosophy

        The Lessonly Management philosophy is the underlying engine behind everything else within this role. This lesson is the source of truth for this philosophy.

        Positions that require this role will be required to have achieved an early milestone of the required abilities for the craft of your domain, to help us make good decisions for our teams.

        Positions that require this role will be required to have achieved a milestone 3+ for business knowledge to help ensure we can give good context to our team goals.

        Positions that require this role will be required to be milestone 3+ for {mentorship} and {community}, given how vital it is for us to care for the person more than the employee.

        These are the most important aspects of management at Lessonly, however, there are three other keys to success for management on the technology team.

        Systematize Clarity

        Another critical aspect of Lessonly management is seeking clarity (finding out what is working) and giving clarity (ensuring folks know what matters most and why it matters).

        Within the tech team, we do that in various ways. One of those ways is seen by the fact that positions which require this role will also be required to be an enablement lead for the appropriate domain, to ensure we are continuously working through this clarity feedback loop.

        Systems with feedback loops are a great way to ensure accountability. Accountability to those we serve… being able to hold those we serve accountable, as well as accountability to our teammates. Knowing we can rely on each other.

        Balancing autonomy and alignment to make room for innovation...

        Building systems with feedback loops so that it is clear what winning is…

        Leading with the principles of appreciative inquiry…

        These are all vital for the thought work which we are responsible for. Our work product isn’t physical, and can’t be measured purely quantitatively. This means it is on us to foster an environment that embraces uncertainty… encourage a team that embraces constantly changing definitions of clarity… a culture that embraces continuous improvement.

        Mission-Control… means focus on Outcomes

        We are laser-focused on iteratively, continuously, relentlessly adding value to the vision of making continuous training possible for all customer-facing teams.

        The best way to do that is to be continuously learning and improving.

        Outcomes, as opposed to outputs or activities, ensure we are all aiming at the same target/rowing in the same direction.

        It also gives freedom to have trial and error, which is one of the most tried and true ways to have lasting growth.

        Types of managers

        The Lessonly technology team greatly values flexibility and adjusting strategy (how we organize to solve problems) based on the strengths of the individuals on the team(s) in question. Therefore, the positions which require “people management” (or the term I prefer, accountable servant leadership), will also not all look the same. Here is a non-exhaustive list of some potential types. \

        Key Result(s) / Outcomes

        • Onboarding effectiveness
          • Time from hire date to a non-apprentice (achieved all of the appropriate milestones) on all of the required roles for the position. Ideally, 3 months from hire.
        • Career journey guidance effectiveness
          • When those you serve are asked the following question, 80%+ of them (strongly) agree: “When I look back from a year ago to where I am now... what I have achieved… how I’ve grown, I am excited about the progress I’ve made”.
        • OfficeVibe 10 key drivers
          • We do not hold anyone accountable for these measures directly, because it incentivizes behaviors we don’t want to incentivize… however, managers will have access to and should be aware of the opportunities of things we could do as well as the impacts of the things we have done on these measures. So the measure here is awareness of and a plan of action around this employee engagement data.
        Requirements
        Examples
          Observation created almost 6 years ago

        I want to give a well-deserved shout out to our awesome engineering managers.

        First off, to Brea, who is making a point spending time getting to know each and every engineer on the team personally. It's really helped me to feel valued by her, and I'm sure will help her relationships with her reporting engineers start off a lot more smoothly. There are a million things she could be doing to be learning about Lessonly, our codebase, how managers here work, etc, but the fact that she has spent time getting to know us (and at more than a group level) shows me that her people are her biggest priority and that's huge. Thanks Brea!

        And then of course to Casey, who has been working tirelessly as the solo manager for months now and, even though I wasn't here for most of those months, I feel confident saying she probably never complained. In the time I've been back since being on leave, I've been impressed at how she manages to meet with all of us, answer questions, write up stories, do code reviews, lead hiring, and still manage to be her positive, happy self that we have all come to appreciate. Thanks, Casey, for being a great manager while also leading and lifting up the team in so many ways. We are glad you decided to spend your superpowers on us here at Lessonly. :)

          Observation created about 6 years ago

        This morning, Gardee reached out to me with the following message:

        Hey Hey! Each quarter I work with --name is redacted-- on gathering feedback from teammates they work with day in and day out. Given that, I wanted to see if there were any observations/feedback (I took a look in ourgruuv already but wanted to ping for any additional things) you would like for us to discuss :slightlysmilingface:

        HELL YEAH!!!

        Way to be a proactive manager and go out and gather the feedback.

        Some might wait and see... others might try and have an in-person convo, but asking in a digital forum allows the person you are asking to take their time and give thoughtful feedback.

        Also, asking for observations shows that you want things that are actionable and not judgments that we are forced to unpack.

        I love, love, love this as an example of ways a manager can help their folks grow.

          Observation created over 6 years ago

        Wow... just wow.

        First, she tried something new, and added clarity as to how the new thing should flow:
        https://lessonly.slack.com/archives/C8UPX4UPM/p1564432055022900
        https://lessonly.slack.com/archives/C97TXG1PW/p1564432252002200

        Then, the retros happened... all three of them (I wasn't there, so I can't say how they actually went, but as an outside observer, I was impressed with what happened).

        Then, she didn't let the things that were discussed die on the vine... no, she took it upon herself to write up the note for all three, with clear actions, and clear ownership of who is going to take on which actions:

        https://lessonly.slack.com/archives/C97TXG1PW/p1564675008018100
        https://lessonly.slack.com/archives/C8UPX4UPM/p1564675014002100
        https://lessonly.slack.com/archives/C97TXG1PW/p1564670582013700

        I'm damn near in tears of pride and excitement (I cry a lot, so tears of joy, sadness, and pride are relatively common, but I will say they only come when something in the world hits me in my soul).

        Here's why...

        I've tried retros of all shapes and sizes. I've hated retros of all shapes and sizes. They are often well-intentioned, but it is really difficult to get a group of adults to open up and share in such a way that useful progress can be gleaned from it.

        When looking at the result of this, I think of our value of critique, not complain. Clearly, what happened in those retros is people opened up, put themselves out there, and critiqued and not complained! I see no way clear action items like this could be found without that happening.

        This shout out is aimed at Casey, but let's be clear, I'm thrilled with the vulnerability and teamwork that had to be shown by the entire Practice and Tech Services squads. Also, I Casey got the idea for this new format from Aaron (:highfive: man!!)

        Casey, it has been amazing to work with you from day one, and every day I am a bit more in awe. Thank you for being you!!

        Let's keep it rolling... ONWARD!!

        Our sole goal is to help fill the top of the funnel with "Hell Yeah" candidates

        Full Description

        Key Result(s) / Outcomes

        There isn’t a formal quantitative measure, however, once you are in a leadership position, recruiting becomes at the very least a passive part of your job.

        It does not mean it is a primary responsibility, or that you are running the recruiting process. It does mean that you are making time to have conversations with people outside of Lessonly for networking purposes. It does mean that when you do have an active opening, you are helping the Talent team member and if you have time you are proactively reaching out to candidates to have discovery calls before officially putting them in the process.

        Details:

        • Work with the hiring manager to identify the ideal candidate profile
        • Coordinate with the other recruiters for the given position to ensure you are not all reaching out to the same candidates
        • Devise relatable messages to send to prospective candidates that paint a clear picture of what the opportunity is
        • Cultivate relationships with the community to ensure we have a great pipeline of candidates when positions open back up
        Requirements
        • Must have a position with the reach of 1.1 or higher
        Examples
        An observation relating to  Recruiter  has not been publicly recognized yet.

        Our goal is, by continually refining the design of the org, to give the department as a whole the best chance of success

        Full Description

        Success:

        • You'll look at each squad and it's evolving mission, combined with the organizational goals, combined with budget and current personnel status and continually work on devising plans that give each squad the best chance of success.

        Details:

        • You'll ask yourself... do squads have what they need to be successful from a policy and personnel perspective?
        • You'll propose net-new roles and positions (such as software support engineer, when the needs of tech services became clear).
        • You'll re-establish the measure of success for positions, such as changing tech services into essentially three sub-squads, with the goal of making things smoother.
        Requirements
        • Must have a position with the reach of 3.2 or higher
        Examples
        An observation relating to  Squad organizational design architect  has not been publicly recognized yet.
      • Product

         Assignments:
        --None--

        • Product Delivery Management (Product Ownership)

           Assignments:

          Continuous learning, continuous prioritization to ensure continuous value delivery, continuous communication to all stakeholders. That is our job as epic shapers. We take the work that migth seem big and scary and help make everyone feel safe and confident that we will deliver!

          Full Description

          Objective

          As epic shapers we create, groom, and prioritize epics that take into account date-based commitments (if one has been set), stakeholder communication, and squad capacity awareness and rally the team around a plan to take on and deliver value through epics.

          Key Results

          • Optimize Learning Frequency
            • A project is decomposed/sequenced in a way that delivers value to customers as early as possible and therefore creates consistent (weekly is the goal) learning moments for a squad. Ideally we are learning weekly about things such as:
            • How customers will use the feature
            • What bugs/edge cases we might have missed
            • Are we meeting our hypotheses and measures
            • and more!
          • Each epic is written and sliced in a way, that when complete it accomplishes one (ideally all) of the following:
            • We are able to enable the functionality or work into a customer account to deliver value
            • We have progressed in de-risking the following:
            • ... Feasibility: Can our delivery crew can build what we need with the time, skills and technology we have?
            • ... Viability: Will the overall solution have the desired business outcome?
            • ... Value: Will the overall solution be desired and useful to customers?
          • in regard to commitments made by the squad, stakeholders (Internal P&E team members and cx squad members), have a clear view of and confidence in:
            • ... what value is going to be delivered
            • ... who it is going to be delivered to
            • ... when it is going to be delivered

          Details

          Things you might deliver/do

          • Write epics for a squad that takes into account date-based commitments (if one has been set), stakeholder communication, and squad capacity awareness. Great epics also take into account feasibility de-risking and customer value/impact learning.
          • You will be responsible for decomposing the big initiative into epics that tell a story while providing value along the way as early as possible
          • Responsible for prioritizing the epics. Working closely with the other roles to ensure stuff like bugs, tech debt, enhancements, and net new work is all sequenced in a healthy way.
          • Organize epics into milestones in Clubhouse

          AKA

          • Squad progress communicator (Initiative to epic)
          • Epic writer

          Even more details that need to live in a lesson:

          • If folks go to the agreed-upon place (weekly update, roadmap, etc), they will be able to see a clear view of progress that is easy to understand by a wide range of stakeholders (basically, every member of the Lessonly team).
          • Usually, there is one per squad per quarter.
          • Initiatives are usually big. They might even span multiple quarters.
          • In this role, you will be responsible for decomposing the big initiative into epics that tell a story while providing value along the way.
          • Good epics are ones that take into account date-based commitments (if one has been set), stakeholder communication, and squad capacity awareness. Great epics also take into account feasibility de-risking and customer value/impact learning.
          • You will communicate changes (scope, timeline, etc) both effectively and as early as possible.
          • You are also responsible for updating the Weekly Product lesson and coordinating with the Product Enablement team for the monthly round-ups and launch coordination.
          • Responsible for prioritizing the epics. Working closely with the other roles to ensure stuff like bugs, tech debt, enhancements, and net new work is all sequenced in a healthy way.
          • The strength and value is not that the person in this role making prioritization / technical decisions for epics but that they can facilitate the communication between the technical world (story prioritizer) and PM world (initiative prioritizer) using epics as their medium in order to make sure that "what is being worked on" is in alignment with "what we need" (and in what priority as a part of that).
          Requirements
          Examples
            Observation created about 5 years ago

          https://lessonly.slack.com/archives/CGS75SABY/p1599838143066600?thread_ts=1599837460.065700&cid=CGS75SABY

          Outcomes, baby, outcomes!!!

          We don't do actions and create outputs for our health... we do it to change human behavior... we do it to make people's lives better, / easier.

          Something as simple as having screenshots in the product board roadmap card made a big impact and reinforced a habit (that the answers AEs and AMs are looking for might just be in the roadmap).

          I love the opportunity to shout out outcomes as opposed to activities and outputs. So I'm thrilled to write this OGO. Well done!

            Observation created over 5 years ago

          As we on Assess prepare for the launch of Certifications, we had a bit of an "oh, shit" moment today where it seemed like maybe we weren't all in alignment about what a Certification is. I felt a little scared, since that's not where you want to be 5 months into a project the month it's supposed to launch. So Justin called a meeting with Ashley, our designer, and me as Discovery Engineer. A lesser leader might have played the blame game ("who needs to work overtime to fix this?") or gone full command-and-control ("Here's my plan—make it happen"), but if you've worked with him, you know that's not Justin. Instead, and I've seen him do this before, he approached the situation from a place of curiosity, asking questions like "How did we get here?" Maybe it's because he has a million kids and has seen it all, but Justin's calmness immediately put me at ease, and his confident curiosity—like of course we're going to figure this out—was infectious, keeping us focused on problem-solving. It turned out we were mostly in alignment anyway, and had just made some small divergent, decisions over the course of the project that we're finally having to square, and now have a plan to. If you struggle with crucial conversations like I sometimes do, take a page from the Book of Kime and stay confidently curious.

            Observation created almost 6 years ago

          I am grateful for how these 4 have been communicating on this project. This is a complex project for a variety of reasons. We are splitting up the frontend and the backend. Linking elements in our app is a difficult endeavor. The way these four have communicated to one another and to me has been such a joy. Whether it be Waseem posting killer updates in the channel, Joshua and Joseph presenting their findings on technical deep dives, or Ethan walking me through expectations on epic breakdown, everyone has chipped in to really get this off the ground.

          I have been inspired to bring the level of clarity I have found here in other aspects of my job.

            Observation created almost 6 years ago

          This thread speaks to it: https://lessonly.slack.com/archives/CPHPVJSTH/p1574698910011200

          This is a great discussion and approach to taking on what could be a larger project in Linked Elements. The team was able to work together to identify and slice up the work in order to get value into the hands of customer faster. Alec said it in his summary here:

          We are going to structure the epics so at the end of each element the element is fully implemented. This means that at the end of epic two the paragraph element will have all of the linked element functionality. Then epic three will be the photo element fully implemented.

          • This will mirror how the platform team rolled out a role management, a fully functional piece of a larger whole. This means we can learn more about the entire linked element process earlier.
          • It gets to value quickly. We have been hearing for years from clients about the linked element functionality. With this plan, we will allow admins to do this whole process faster!
          • It will make the delivery manager role more smooth. Because of this plan, each epic will look similar technically speaking. The first element will take the longest because we have to implement all of Linked elements but after we will be able to determine with reasonable accuracy how long each element takes to build start to finish.

          As a result...

          • This enables the squad in efforts of successful decomposition of ideas into shippable units of work to deliver customer value, validate P&E assumptions, or both
          • Developing right-size slices of work that fit into the checkpoint and quarterly goals
          • Thinking through the stack in a way that promotes flexible story creation (e.g. model/database, API, routes, react components, UI).
          • Your squad consistently gets slices of work into customers hands for testing as early as possible in the lifespan of a project
            Observation created about 6 years ago

          https://app.clubhouse.io/lessonly/epic/27348#activity-32580

          This is how acceptance criteria should be written.

          This level of detail should be at the story level to ensure clarity.

          However, I'd put this level of detail in the epic in scenarios where there is less design, or complicated logic, or a delivery team that doesn't find joy in pushing the boundaries on the details.

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

          Full Description

          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 role 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

          Details:

          Here is lesson that outlines internal documentation on the P&E team

          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).

          Here is an example of what success looks like

          Requirements
          Examples
            Observation created almost 5 years ago

          We had to respond to an RFP (Request for Proposal).

          There was a question about permissions, and I immediately knew that there is one person I definitely needed to bring in... THE HAMMER!!!

          I asked Kim how she would respond to this RFP question, and a couple of short hours later, she knocked it out of the park! Here is the doc she wrote up.

          Made me even more confident that Kim not only has my back, but she does nothing half assed.

          Well done... we all appreciate you!

            Observation created almost 6 years ago

          Documentation is vital for a software company. That is true for all aspects of our app but particularly user management. Lessonly cannot exist without learners, so the action of making it clear and easy to get users into Lessonly is important. Even though I know all of that creating documentation can be seen as the least fun aspect of software. It is more fun to build new stuff than to write in painstaking detail about the stuff you just built.

          With all of that being said, it only makes what Raphael did more impressive. We recently wrapped up the development of SCIM for OneLogin. We were left with the documentation piece. I tried my best to get it started but we reached a point where we had to set the JSON user schema and I was lost. Raphael (who got involved late to the project) was able to familiarize himself with the code base and write some killer documentation (found here: https://docs.google.com/document/d/1zaEPLM1wtiDHBth9owIG29R2c-3oYWq04jPtxvH-5P0/edit#)

          This is the definition of a team player. Hopping onto a project and helping out any way you can no matter what. Raphael has always been game for these sort of things but I was reminded again by this.

          As an organization, we launch together. That means alignment and unity across multiple departments. Within the P&E team, we have special responsibilities to ensure the success of a monthly product launch. We, launch coordinators, are the captains of the product launch journey we take every month.

          Full Description

          Success: Monthly launches

          • All of the features launching are in demo accounts 3 weeks prior to the launch date
          • All of the features launching launch on-time
          • Usage goals (as defined by the squad) are defined and measured against post-launch

          Details

          Things you might do/deliver

          • Launch Epic that includes the details of what is launching, when it is launching, and the overall launch plan
          • Launch Stories that include:
            • Rake tasks to enable features in proper customer accounts
            • Demo account preparation and seeding of data if needed
            • Feature flag organization and cleanup
          • Define usage goals of the features that are launching
          • Measure against usage goals post-launch and communicating the results to the organization
          • Help the product operations committee finalize pricing and packaging, and then help enablement with what they might need in order to effectively enable on it.
          Requirements
          Examples
            Observation created about 5 years ago

          https://lessonly.slack.com/archives/CGS75SABY/p1599838143066600?thread_ts=1599837460.065700&cid=CGS75SABY

          Outcomes, baby, outcomes!!!

          We don't do actions and create outputs for our health... we do it to change human behavior... we do it to make people's lives better, / easier.

          Something as simple as having screenshots in the product board roadmap card made a big impact and reinforced a habit (that the answers AEs and AMs are looking for might just be in the roadmap).

          I love the opportunity to shout out outcomes as opposed to activities and outputs. So I'm thrilled to write this OGO. Well done!

            Observation created almost 6 years ago

          Alec has been working on creating a presentation to demo the new Usernames functionality to the company - as a part of that, he iterated on what the presentation was going to consist of. There are many great aspects of the presentation that include: outlining the why behind the investment, shouting out the individual team members who were a big part of the success of that project, and lastly the CUSTOMER TESTIMONIAL!

          It is one thing to acknowledge great work on delivering a feature into reality BUT it is another to understand and share what impact the feature is going to have on our customers. This shoutout is for Alec in seeking out and getting a customer to record a video about the value that the Usernames feature is going to provide to our customers. This gives energy to our internal team who built this, those who will support it, and those who will sell it!

          Here is the presentation with the customer testimonial: https://docs.google.com/presentation/d/1lUMJ6CEe6hKN0Me056VGEZ7cf47pPxA9zLQnJ7lxfIQ/edit#slide=id.g58bf794290_0_61

          We serve the function of Product Delivery, and those executing against its roles. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Success:

          • Those executing against the following roles have a continuously improving set of tools and processes (balancing autonomy and focusing on feedback loops).
            • Epic backlog groomer
            • Blocker buster
            • Launch coordinator

          Details:

          • You know the value of low dependencies, and as such will help identify and reduce dependencies between epics (keep things small and smooth)
          • You know that done means in production, and therefore will help coordinate timing with testers (e.g. looking for things with delivery date targets and communicating with testers on test progress)
          • You have a view into the cross-squad release goals and can help ensure we meet our commitments (monthly releases and marketing campaigns)
          Requirements
          • Must have a position with the reach of 3.1 or higher
          Examples
          An observation relating to  Product Ownership Enablement Lead  has not been publicly recognized yet.

          We are all about identifying solutions for customers and prospects so that they can get to value faster with Lessonly

          Full Description

          The Account Executive/CX Manager will be the primary person building a relationship with the prospect. The solutions consultant will assist by running pilots and digging deep into the needs of the prospect/customer. You as a solutions engineer are the most technical and product-knowledgeable person of this three-person cross-functional sales squad. Your goal is to answer questions about “how might we” be able to meet the needs of this prospect/customer with existing platform configuration options

          Key Result(s) / Outcomes

          • Time-to-value
            • Accelerating the pre-sales process
              • [Required] The average ticket resolution time for a pre-sales support request to an engineer is at or below our 3-day goal of resolution
              • [Nice-to-have] For deals that require a touchpoint with a solutions engineer, the average sales cycle time is below the current cycle average of 60 days
            • Accelerating the implementation process
              • [Required] The average ticket resolution time for an implementation request to an engineer is at or below our 3-day goal of resolution
              • [Nice-to-have] The average time of implementation is reduced from the average of _ days when a customer requires working with a solutions engineer
          • Clarity of possibility
            • [Required] We will survey the AE or CXM that asks for a solutions engineer, and our ultimate goal is that we stay below 5% of the engagements answers (D) from below:
              • A Solutions Engineer was brought into your pre-sales or implementation discussion with a customer or prospect. Which of the following best describes the outcome:
                • A: A solution was identified for my customer or prospect using existing Lessonly functionality
                • B: A potential acceleration was identified and evaluated on behalf of my customer or prospect
                • C: It was identified that the customer or prospect request isn’t in alignment with our vision and work and therefore we wouldn’t support the request
                • D: None of these three above items were accomplished
          Requirements
          Examples
            Observation created almost 6 years ago

          This is on behalf of Rachael Hartsell (member of the CX team) and a shoutout she gave at the all-team. Today Alec hopped on a call with one of our champions to talk about some SFTP solutions. We had talked about some solutions beforehand and while we are on the call Alec was asking questions of the customer. He proposed another solution that we had originally built for one of our customers that I wasn't aware about. The fact that he was so prepared and based on he was able to suggest a solution based on what the customer said in the moment.

          We ensure it is clear and accessible for stakeholders to know the answer to "where are we with that project?"

          Full Description

          Key Result(s) / Outcomes

          • We hit 80% of our internal early adoption goals for the labs account
          • Only 3 "shoulda been in the lesson" questions needing to be asked per checkpoint across all squads (Weekly Product Updates) via Ask the Expert
          • Only 1 "shoulda been in the roadmap" questions needing to be asked per checkpoint across all squads

          Details

          Things you might deliver/do

          • If folks go to the agreed-upon place (weekly update, roadmap, etc), they will be able to see a clear view of progress that is easy to understand by a wide range of stakeholders (basically, every member of the Lessonly team).
          • You will communicate changes (scope, timeline, etc) both effectively and as early as possible.
          • You are also responsible for updating the Weekly Product lesson and coordinating with the Product Enablement team for the monthly round-ups and launch coordination.
          • Demoing functionality at all-team meetings when we can
          • Enabling functionality in our internal About Account and labs.lessonly.com
          • Announcing availability to internal folks via Slack or in an all-team meeting
          • Updating checkpoint goals and results to the P&E department
          Requirements
          Examples
            Observation created about 5 years ago

          https://lessonly.slack.com/archives/CGS75SABY/p1599838143066600?thread_ts=1599837460.065700&cid=CGS75SABY

          Outcomes, baby, outcomes!!!

          We don't do actions and create outputs for our health... we do it to change human behavior... we do it to make people's lives better, / easier.

          Something as simple as having screenshots in the product board roadmap card made a big impact and reinforced a habit (that the answers AEs and AMs are looking for might just be in the roadmap).

          I love the opportunity to shout out outcomes as opposed to activities and outputs. So I'm thrilled to write this OGO. Well done!

        • Product Design

           Assignments:

          We facilitate design activities aimed at collaboration, clarity, and alignment

          Full Description

          Success

          • Business / workshop goals achieved in time allotted (ex: Decisions made, solutions identified and spec'd, etc)
          • Confidence in presentation and activity management
          • Keeps all participants engaged. (ex: everyone participates equally)
          • Selecting the best activities for the type of outcome desired + group dynamics
          • Knows when to pause on the agenda to dig into a conversation vs. save until after the session.

          Feedback Loop/Deliverables

          • Workshop agendas and activities
          • Next steps after workshops
          • Post-workshop survey (for large, special facilitation)

          Details

          • This is a critical role in product discovery, as collaborating with 3+ people is challenging in and of itself. A facilitator alleviates the load of a discovery team bearing the weight by themselves
          • Sometimes, tricky product and/or collaboration problems call for a leader to facilitate that collaboration. This role delivers on that collaboration with confident, thoughtful leadership in the room, and creates an enjoyable experience that arrives at needed goals.
          Requirements
          Examples
          An observation relating to  Design Facilitator  has not been publicly recognized yet.

          As design reviewers, our goal is to make our application (and ourselves) more awesome!

          Full Description

          Success

          • Giving thorough, thoughtful design critique while upholding our company core values.
          • In early reviews, asking the right questions to evaluate if our users will understand, enjoy, and benefit from the designs
          • In late reviews, ensuring designs meet standards and cover all aspects of the checklist (accessibility, mobile, error states, unhappy paths, design system adherence, tone)

          Feedback loop/deliverables

          • Attendance at design critique sessions
          • When necessary, whiteboarding or real-world examples sent to the designer

          Details

          • This role should be played by many on the design team, as we create a supportive and collaborative atmosphere.
          • It's important that even non-milestone 2 designers participate, but they should not be the only participants in a design critique.
          Requirements
          Examples
          An observation relating to  Design Reviewer  has not been publicly recognized yet.

          We create reusable patterns to add to a growing library so that we can continuously improve our shared language, and this language allows the team to collaborate more effectively

          Full Description

          Success

          • Reusable patterns are identified and added to the growing design system library to be implemented by engineers
          • Designs are representative of and add to our understanding of how the system functions as a whole

          Feedback loop/deliverables:

          • Documented elements that have been reviewed and approved by the principal product designer, and Design System senior UI engineer
          • Element specs include visual design, interaction design, rules, and edge cases

          Details

          As we begin to create a full system with our app, it's critical that pieces created are of very high quality. This role has a higher milestone requirement to reflect the need for thoughtful, consistent design.

          Requirements
          Examples
          An observation relating to  Design System Contributor  has not been publicly recognized yet.

          We serve the function of Product Design, and those executing against its roles. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Success:

          • Those executing against the following roles have a continuously improving set of tools and processes (balancing autonomy and focusing on feedback loops).
            • Evaluative researcher
            • Solutions designer
            • Visual designer

          Details:

          • Designers across product teams are communicating, collaborating, and using consistent methods for defining problems and arriving at solutions. Designers are able to assess the processes they use in everyday product design work and know when to iterate on the methods and tools that they currently employ
          • The feedback loop is qualitative. Do the designers have what they need to succeed as it pertains to guidance on the process and proper tooling.
          • Maintenance of a design system
          • Ensuring the product team’s design practice is comprehensive, collaborative, and inclusive
          Requirements
          • Must have a position with the reach of 3.1 or higher
          Examples
          An observation relating to  Product Design Enablement Lead  has not been publicly recognized yet.

          We create, prototype, test, and iterate concepts in collaboration with the entire squad in pursuit of desirable, viable, feasible, and usable solutions

          Full Description

          Success:

          • Validating and learning as quickly as possible with collaboration being a major key. Our value of sharing before ready is most applicable to this role.

          Things you'll do

          • Utilize Lean UX methods used to create successful team collaboration to create desirable, viable, feasible, and usable solutions to big problems.
          • Create, prototype, test, and iterate concepts
          • Use the full library of techniques such as lo-fi, wireframing, hi-fi live-data prototypes and any of the other techniques in between.

          Feedback loop/deliverables:

          • Designs that enable clarity of how a problem will be solved.
          • Validated solutions to the problems/unmet needs proposed
          • When necessary, you'll work with the Opportunity shaper and Discovery engineer to flesh out the execution section of investment canvases

          Details:

          • Solution definition is the most visible aspect of the designer position: creating, prototyping, testing, and iterating upon solutions and concepts.
          • We will lean on you to influence best design practices when it comes to choosing prototype fidelity, finding ways to learn and validate, collaborating within and between product teams, and encouraging the sharing of ideas and concepts early on.
          • Iteration and Sharing Before Ready are two concepts at the center of what it takes to be successful in this role. Trying to go it alone will ultimately lead to failure. You should think of yourself as a shepherd of the solution, not as someone who owns it in isolation.
          Requirements
          Examples
            Observation created over 5 years ago

          https://lessonly.slack.com/archives/C8H3ENQ2J/p1582565374007400

          Just wanted to give a quick shout out to Ashley on something small, but amazing.

          I'd love for us to do more of this style of collaboration. Small bits along the way. Sharing early and bringing in feasibility and viability as you go. I believe this is vital to the continuous discovery/design/delivery methodology we are striving for.

          I absolutely love this!

          Keep it up!!

          We are relied upon by our squadmates for our strong design opinion (simple, elegant, brand-aware, desirable, viable, feasible, and usable) while being flexible and open to ideas during the collaborative convergence

          Full Description

          Success:

          • Your squadmates relying on you for your strong design opinion while being flexible and open to ideas during the collaborative convergence
          • Simple, elegant, brand-aware, desirable, viable, feasible, and usable solution and the necessary UX/UI.
          • Designing for MVP + additional releases

          Feedback loop/deliverables:

          • The feedback loop for this role is qualitative... how complete are the designs as measured by your squadmates.

          Details:

          • We move fast. We move together. Dual-track agile best describes our product delivery model. Meaning, at all times a squad is active in both discovery and delivery. This is admittedly very difficult to manage, but the payoff is worth the cost. Iterate, iterate, iterate.
          Requirements
          Examples
          An observation relating to  UI Designer  has not been publicly recognized yet.

          • Product Research

             Assignments:

            We are relied upon for the identification, justification for enhancing, and clarity around the opportunity for reducing resistance and/or increasing value within the user experience.

            Full Description

            Success:

            • The insights you gather around opportunities to improve the customer experience are critical when prioritizing upcoming product work.
            • You are relied upon for the identification, justification for enhancing, and clarity around the opportunity for reducing resistance and/or increasing value within the user experience.
            • You’ll have success in this role the more you understand the customers using our product both qualitatively and quantitatively.

            Feedback loop/deliverables

            Details/activites

            • You’ll notice that much of the language being used comes from the double diamond style of thinking. We build software to solve real problems for real people. The first step in doing that is having a deep understanding of the problem we are trying to solve and the context of those that are trying to make progress. Defining the Why.
            • Monitoring current feature usage and trends
            • Running usability studies

            Relevant excerpt for illustration

            • This excerpt from the book Inspired illustrates a useful take on research as an important part of the prod dev process:

            ... when we talk about how we do product discover, we are continuously doing two kinds of rapid learning and experimentation. One kind of learning is qualitative, and the other is quantitative.

            Especially with the qualitative learning, some of our research is generative, which is understanding the problems we need to solve; and some of our research is evaluative, which is assessing how well our solution solves the problem.

            User researchers are trained in this range of qualitative techniques (and some of them are also trained on the quantitative techniques as well). They can help you find the right type of users, craft the right types of tests, and learn the most from each user or customer interaction.

            The key to tapping into the real value that these user researchers can provide is to keep in mind that the learning must be shared learning.


            • This excerpt from a blog post illustrates the difference between evaluative and generative research:

            The goals of generative and evaluative research are very different.

            Generative research helps you define the problem you’d like to design a solution for.
            Evaluative research evaluates an existing design (in prototype form or in final form).

            Requirements
            Examples
              Observation created over 5 years ago

            Anne Marie is an absolute rockstar to work with. Salesforce is no small animal to tackle and she came in with no context, asked great questions, challenged our squad, and whipped together an incredible research plan and executed it. I personally wrestled with how to wrap my arms around the never-ending questions around reporting and how it could go in so many different directions. She had a heavy hand in stringing together what we were trying to find out and making the user testing actually successful. I’m amazed at the level of insights we've gained from her meticulous script and ability to ask important clarifying questions. I appreciate her dedication to her craft and how she's always innovating on how to better her research practices.

            If you ever get a chance to sit-in on user testing with Anne Marie, I highly recommend it. User testing can be difficult because you also have to manage the emotions and feedback from other humans. Her ability to guide users through research problems without creating biases is quite the balancing act. She's also incredibly friendly, accommodating and creates a comfortable environment that generates wonderful discussions. I've learned to be a better listener just by observing her. She can pivot on a dime or dive to 10,000 ft depths to really understand the root of the problems that our users face.

            But what I'm most impressed with is Anne Marie's commitment to treating everyone equally and as humans first. From checking in with each of our squad members individually on mental health, to being incredibly compassionate and sensitive to what our clients are facing during this time, I really am blown away by how brings brightness to the room no matter where she goes. She's stepped up for me when I needed help, validated my feelings when I've been overwhelmed, and I know she has my back. It's a pleasure working with her and I'm so excited to get to be on her team.

            As Generative User Researchers we help define (with evidence) the problem/unmet need we’d like to design a solution for.

            Full Description

            Success looks like:

            • Research initiatives and insights have a meaningful and consistent impact on how decisions are made, both within and outside of Product.
            • Understand potential customers and current customers that fall into the ideal customer profile dictated by the company/market strategy. Success is understanding these customers better than anyone.

            Feedback loop/deliverables

            Details:

            • You’ll notice that much of the language being used comes from the double diamond style of thinking. We build software to solve real problems for real people. The first step in doing that is having a deep understanding of the problem we are trying to solve and the context of those that are trying to make progress. Defining the Why.

            Relevant excerpt for illustration

            • This excerpt from the book Inspired illustrates a useful take on research as an important part of the prod dev process:

            ... when we talk about how we do product discover, we are continuously doing two kinds of rapid learning and experimentation. One kind of learning is qualitative, and the other is quantitative.

            Especially with the qualitative learning, some of our research is generative, which is understanding the problems we need to solve; and some of our research is evaluative, which is assessing how well our solution solves the problem.

            User researchers are trained in this range of qualitative techniques (and some of them are also trained on the quantitative techniques as well). They can help you find the right type of users, craft the right types of tests, and learn the most from each user or customer interaction.

            The key to tapping into the real value that these user researchers can provide is to keep in mind that the learning must be shared learning.


            • This excerpt from a blog post illustrates the difference between evaluative and generative research:

            The goals of generative and evaluative research are very different.

            Generative research helps you define the problem you’d like to design a solution for.
            Evaluative research evaluates an existing design (in prototype form or in final form).

            Requirements
            Examples
            An observation relating to  Generative User Researcher  has not been publicly recognized yet.
        • Product Discovery Management (Product Management)

           Assignments:

          We take the product strategy and work towards building the right thing by identifying, communicating the importance of, and prioritizing the opportunities we have. Our goal is to inspire stakeholders, the squad, and most importantly the customers by making the Why clear for every bet we make.

          Full Description

          Success looks like:

          • Alignment. You succeed in this role if the big 5 stakeholders understand and agree on the importance (hypotheses around the value proposition) of the investment. Big 5 stakeholders are:
            • External customers
            • or internal if the initiative is aimed at a group like services or CX
            • Internal business stakeholders
            • Such as CX, CS, Sales, Services, Finance, Execs
            • Design
            • Quality Assurance
            • Engineering
          • You are able to clearly articulate the implications derived from research insights to appropriate stakeholders, as well as propose and gather consensus on hypotheses around the value proposition of each product initiative.

          Feedback loop/deliverables

          • Completion, prioritization, and presentation of investment canvases.
            • All work doesn't need an investment canvas, but most work will fall under one. Your job is to ensure the investment canvases are complete. Three other roles participate in the investment canvas creation, but this is the role that is responsible and accountable for the canvases to be clear and complete.
            • Generative researchers and Evaluative researchers are responsible for the evidence, while you are accountable and consulted
            • Solution Design Leads, Hypothesis testing prioritizers, Squad progress communicators, and Discovery engineers are responsible for the execution section, but again, you are both accountable and consulted
            • You are responsible and accountable for the essentials and evaluations, while you should consult all of the roles from above.
          • Canvases will be judged by their effectiveness at conveying the why and the what on the journey towards cross-functional alignment.

          Details:

          • Research without synthesis is like a beat and lyrics without a song. The research should be the ingredients to the clarity that is required for great product work. However, the compilation and synthesis of the research along with hypothesis creation is what brings true clarity.
          • Creating Investment Canvases
          • Determining Desirability (in current, future, and potential markets) working with Biz Intelligence Engineers as well as Solution Discovery leads
          • Determining Feasibility (design, build, test, market, sell, support) working with Discovery Engineering
          • Determining Viability (financially, is the juice worth the squeeze?) working with finance and ops
          Requirements
          • Must have a position with the reach of 2.1 or higher
          Examples
          An observation relating to  Opportunity shaper  has not been publicly recognized yet.

          We serve the function of Product Management, and those executing against its roles. Our goal is continuous improvement of the tools and processes (balancing autonomy and focusing on feedback loops).

          Full Description

          Success:

          • Those executing against the following roles have a continuously improving set of tools and processes (balancing autonomy and focusing on feedback loops).
            • Initiative backlog groomer
            • Generative researcher
            • Evaluative researcher

          Details:

          • How we go about making initiative-level decisions, communicating those to the stakeholder, and inspiring the team... it is your job to ensure product managers have the proper tooling and processes to execute on these goals.
          • The investment canvas is the most visible manifestation of Product Management enablement.
          Requirements
          • Must have a position with the reach of 3.1 or higher
          Examples
          An observation relating to  Product Management Enablement Lead  has not been publicly recognized yet.
  • Explore Options
    At this step you'll be able to choose different positions or roles that will take you down different paths along your journey. It'll give you an idea of what areas to focus on next and if you do focus on them, what it may take to get to where you are going