Lessonly

• Product & Engineering

   Assignments:

  Onboarding buddy

  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.

  Interviewer

  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

  Featuring:Ashley S.Interviewer

  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!

  P&E DBW group member

  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.

  Discovery Manager

  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

  • Must have a position with the reach of 2.1 or higher
  • For this role, you must be milestone 2 or greater inStakeholder / Feedback Management
  • For this role, it is recommended to be milestone 1 or greater inPresentation Skill
  • For this role, you must be milestone 1 or greater inBusiness and Technical Translation
  • For this role, you must be milestone 3 or greater inDesign Collaboration
  • For this role, you must be milestone 2 or greater inProduct Discovery

  Examples

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

  Squad Manager

  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.

  Escalation mitigator

  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

  • Must have a position with the reach of 2.3 or higher
  • For this role, you must be milestone 1 or greater in(QA) System Modeling
  • For this role, you must be milestone 1 or greater inTechnical Investigation
  • For this role, you must be milestone 1 or greater inPrioritization
  • For this role, you must be milestone 1 or greater inDecomposition & Sequencing
  • For this role, you must be milestone 2 or greater inCommunication
  • For this role, you must be milestone 2 or greater inCollaboration

  Examples

    Observation created over 6 years ago

  Featuring:Rick G.We don't wait to be told what to do, we take initiativeWe share before we're readyEscalation mitigator

  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!

  ---

  • Engineering

     Assignments:

    Tier-3 escalation engineer

    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

    Featuring:Kyle W.We don't wait to be told what to do, we take initiativeWe put the team before ourselvesWe represent Lessonly positively in the communityWe put learners firstBack-end architectBack-end engineerImplementation engineerTechnical investigatorTier-3 escalation engineer

    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!

    Incident remediation lead

    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

    Featuring:Stephen G.InitiativeIncident remediation lead

    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. 🙌🏾 🙌🏾 🙌🏾

    Technical Partner Manager

    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

    • Must have a position with the reach of 2.1 or higher
    • For this role, you must be milestone 1 or greater inBusiness and Technical Translation

    Examples

      Observation created about 5 years ago

    Featuring:Rick G.Technical Partner Manager

    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

    Featuring:Rick G.We don't wait to be told what to do, we take initiativeTechnical Partner Manager

    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!

    Triage application engineer

    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.

    Tier-4 escalation engineer

    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.

    ---

    • Development

       Assignments:

      Front-end Code Reviewer

      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.

      Back-end Code reviewer

      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

      Featuring:Brittany H.Engineering CommunicationCommunicationBack-end Code reviewer

      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

      Featuring:Thomas C.Back-end Code reviewerBack-end engineer

      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.

      DevX Enablement Lead

      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

      Featuring:Ethan M.Front-end architectFront-end engineering guild memberDevX Enablement Lead

      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

      Featuring:Casey S.We don't wait to be told what to do, we take initiativeWe inspire others to do better workWe get agreementsDevX Enablement Lead

      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

      Featuring:Waseem D.We don't wait to be told what to do, we take initiativeFront-end engineerDevX Enablement Lead

      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!

      ---

      • Tech Leadership

         Assignments:

        Software Architecture lead

        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.

        Agile Coach

        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

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

        Examples

          Observation created over 5 years ago

        Featuring:Haley M.Adam G.Agile Coach

        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

        Featuring:Alec R.Agile Coach

        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

        Featuring:Steve G.We challenge ourselvesWe inspire others to do better workWe recognize the opportunity in challengesAgile Coach

        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

        Featuring:Haley M.Agile Coach

        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.

        Story shaper

        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

        Featuring:Ethan M.Joseph A.Joshua A.Waseem D.We ask clarifying questionsWe get agreementsWe inspire others to do better workCommunityDesign CollaborationBack-end engineerFront-end engineerDiscovery engineerEpic shaperStory shaper

        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

        Featuring:Aaron M.Story shaper

        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

        Featuring:Rick G.Epic shaperStory shaper

        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.

        Back-end architect

        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

        • More details exist within the Architects 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

        Featuring:Alec R.Ethan M.Waseem D.We share before we're readyDecomposition & SequencingEpic shaperFront-end architectBack-end architect

        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

        Featuring:Kyle W.We don't wait to be told what to do, we take initiativeWe put the team before ourselvesWe represent Lessonly positively in the communityWe put learners firstBack-end architectBack-end engineerImplementation engineerTechnical investigatorTier-3 escalation engineer

        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

        Featuring:Thomas C.We get agreementsBack-end architect

        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!

        Front-end architect

        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

        Featuring:Ethan M.Front-end architectFront-end engineering guild memberDevX Enablement Lead

        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

        Featuring:Alec R.Ethan M.Waseem D.We share before we're readyDecomposition & SequencingEpic shaperFront-end architectBack-end architect

        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

        Featuring:Conlin D.We put learners firstWe share before we're readyWe ask clarifying questionsWe highlight what's workingWe own our requestsWe recognize the opportunity in challengesWe inspire others to do better workWe don't wait to be told what to do, we take initiativeWe put the team before ourselvesWe challenge ourselvesWe critique, we don't complainCommunityInitiativeMentorshipProduct DiscoveryDiscovery engineerFront-end architectFront-end engineer

        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

        Featuring:Waseem D.We inspire others to do better workFront-end architectFront-end engineer

        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!

        Guild lead

        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

        • The Product Team Guilds Lesson

        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.

  • Management

     Assignments:

    Recruiter

    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.

    Manager

    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

    • 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, you must be milestone 2 or greater inProduct Knowledge
    • For this role, you must be milestone 2 or greater inSense and Respond
    • For this role, you must be milestone 2 or greater inSystems Management
    • For this role, you must be milestone 2 or greater inStakeholder / Feedback Management
    • For this role, you must be milestone 2 or greater inGoal Management
    • For this role, you must be milestone 1 or greater inPrioritization
    • For this role, you must be milestone 2 or greater inCommunity
    • For this role, you must be milestone 2 or greater inLessonly Business Knowledge

    Examples

      Observation created almost 6 years ago

    Featuring:Brea D.Casey S.MentorshipManager

    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

    Featuring:Adam G.We don't wait to be told what to do, we take initiativeWe inspire others to do better workManager

    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

    Featuring:Casey S.We inspire others to do better workWe get agreementsWe have difficult conversationsWe highlight what's workingWe critique, we don't complainManager

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

    Hiring manager

    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

    Featuring:Brea D.Hiring manager

    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

    Featuring:Rick G.Hiring manager

    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

    Featuring:Casey S.We represent Lessonly positively in the communityHiring manager

    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!