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.

  Business intelligence analyst

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

  Full Description

  Key Result(s)

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

  ---

  Details

  Things you might deliver/do

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

  ---

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

  Illustrations

  • This excerpt from the book Inspired is a well-written summation of the expectations and value of this role:
    • 

  Requirements

  • Must have a position with the reach of 1.2 or higher
  • For this role, you must be milestone 1 or greater inData
  • For this role, it is recommended to be milestone 1 or greater inProduct Knowledge
  • For this role, you must be milestone 1 or greater inBusiness and Technical Translation
  • For this role, it is recommended to be milestone 1 or greater inStakeholder / Feedback Management

  Examples

    Observation created over 5 years ago

  Featuring:Alec R.We highlight what's workingBusiness intelligence analyst

  hjkhkj

    Observation created about 6 years ago

  Featuring:Justin K.Business intelligence analyst

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

  LOVE THIS!

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

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

  Usage is a leading indicator to this.

  Thanks Justin!

  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.

  Product engagement analyst

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

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

  Full Description

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

  Success looks like:

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

  Requirements

  • Must have a position with the reach of 1.1 or higher
  • For this role, you must be milestone 1 or greater inData
  • For this role, it is recommended to be milestone 1 or greater inDesign Collaboration
  • For this role, it is recommended to be milestone 1 or greater inProduct Discovery
  • For this role, you must be milestone 2 or greater inProduct Knowledge
  • For this role, it is recommended to be milestone 2 or greater inInitiative

  Examples

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

  ---

  • Engineering

     Assignments:

    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!

    Report Writer

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

    Full Description

    Success looks like:

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

    Requirements

    • Must have a position with the reach of 1.1 or higher
    • For this role, you must be milestone 1 or greater inData
    • For this role, you must be milestone 1 or greater inProduct Knowledge
    • For this role, you must be milestone 2 or greater inBusiness and Technical Translation
    • For this role, it is recommended to be milestone 1 or greater inCustomer Service

    Examples

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

    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:

      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!

    • Operations

       Assignments:

      Infrastructure engineer

      We create, maintain, document update distributed reliable infrastructure.

      Full Description

      Key Results and Outcomes

      Manage Infrastructure

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

      Enable Scalable and Reliable Architectures

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

      Infrastructure Planning

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

      Activities

      • Provision Infrastructure
      • Ensure Instrasture meets
      • Assist in incidents and on-call duties as needed
      • Design secure network topology
      • Automate compliance reporting
      • Automate provisioning of infrastructure

      Requirements

      • Must have a position with the reach of 2.2 or higher

      Examples

      An observation relating to  Infrastructure engineer  has not been publicly recognized yet.

      Site reliability engineer

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

      Full Description

      Key Results / Outcomes

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

      Requirements

      • Must have a position with the reach of 2.2 or higher

      Examples

        Observation created almost 5 years ago

      Featuring:Stephen G.We highlight what's workingDevOps Enablement LeadSite reliability engineer

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

        Observation created over 6 years ago

      Featuring:Raphael A.Stephen G.We don't wait to be told what to do, we take initiativeBack-end engineerSite reliability engineer

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

      That slack thread tells the entire story...

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

      Love nearly everything about this.

      Way to go y'all!

      DevOps Enablement Lead

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

      Full Description

      Key Results/Outcomes

      ENGAGEMENT:

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

      ACTIVITIES / RESPONSIBILITIES:

      • Manage Infrastructure Costs
        • Monitor infrastructure costs
        • Provide estimates for future costs
        • Work to reduce costs where possible
      • Coordinate Maintenance
        • Make sure all parts of the company are on the same page regarding maintenance
      • Manage third-party integrations
        • Track utilization of third-parties
        • Help with contract renewal discussions
      • Enable other engineering team members
        • Provide documentation on how to acquire / reconfigure infrastructure
        • Track requests for acquisition/creation of infrastructure

      Requirements

      • Must have a position with the reach of 3.1 or higher
      • For this role, you must be milestone 2 or greater inSystems Management
      • For this role, you must be milestone 1 or greater inInfrastructure

      Examples

        Observation created almost 5 years ago

      Featuring:Stephen G.Engineering CommunicationInitiativeStakeholder / Feedback ManagementDevOps Enablement Lead

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

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

      Love it!!

      ---

      Email #1:

      HI everybody,

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

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

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

      Executive Summary

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

      Our Direct Exposure

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

      PaperTrail

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

      Vendors

      Vendors known to have some exposure to SolarWinds Products

      Twilio (Sendgrid, Twilio, Segment)

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

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

      Harness

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

      CloudBees (Codeship)

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

      • Librato (scoped to our CodeShip product)

      • PaperTrail (scoped to our CodeShip product)

      • PingDom (basic external monitoring used by Ops)

        Observation created almost 5 years ago

      Featuring:Stephen G.We highlight what's workingDevOps Enablement LeadSite reliability engineer

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