Explore Lessonly's Assignments

Choose Organization Growth Framework
Exploring Lessonly's growth framework
Choose Starting Position
Starting with the position: Software Engineer - 5.3 (aka Principal Software Architect) (Check out Software Engineer - 5.3)
Choose Assignments
Now it is time for you to build your unique job description! Simply go through and add a checkmark next to all of the Assignments you'd want to take on.
Click to copy the URL to share this exploration

Showing only relevant Assignments

Only relevant AssignmentsShow all Assignments

  • Lessonly

     Assignments:

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

    Full Description

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

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

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

    • Product & Engineering

       Assignments:

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

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

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

      Full Description

      Key Result(s)

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

      Details

      Things you might deliver/do

      • We are responsible for understanding how Salesforce data, when blended with Product-usage data, impacts our ability to better understand and potentially even predict the business outcomes
      • We are responsible for doing the exploration needed to empower CX to make even better recommendations to customers about their training program effectiveness
        • Helping CX uncover patterns in how the best-performing programs function so that they can help their customers better.
      • We may partner with operations on deciding on and maintaining the business intelligence tooling (think Tableau or other BO tools)
      • If the data does not exist that we need to be able to answer a question, you are relied on to help prioritize modifying the platform to allow for the data to be captured, or captured in the proper format.

      Illustrations

      • This excerpt from the book Inspired is a well-written summation of the expectations and value of this role:
      Requirements
      Examples
        Observation created over 5 years ago
      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!

      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!

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

      Full Description

      Success

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

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

      Full Description

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

      Key Result(s) / Outcomes

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

      Submit change suggestions in this GDoc

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

      We 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:

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

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

        Full Description

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

        Requirements
        Examples
          Observation created about 5 years ago
        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!

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

        Full Description

        Success looks like:

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

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

        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:

          --No summary set yet--

          Full Description

          Success:

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

          Details:

          • Backend Guild members get together to learn from and teach each other on various backend topics, including databases, Ruby, Rails, and anything else that could be valuable knowledge.
          Requirements
          • Must have a position with the reach of 1.1 or higher
          Examples
            Observation created over 6 years ago
          Featuring:Haley M.We put the team before ourselvesBack-end engineerBack-end engineering guild member

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

          whew

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

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

          --No summary set yet--

          Full Description

          Success:

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

          Details:

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

          A member of the frontend engineering guild 🎉

          Full Description

          Success:

          • TBD

          Details:

          • TBD
          Requirements
          • Must have a position with the reach of 1.1 or higher
          Examples
            Observation created over 5 years ago
          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.

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

          Full Description
          • We own the setup and maintenance of technical integrations that are core to a customer’s success including (but not limited to):
            • sFTP file syncs
            • Authentication providers (OAuth, Okta, SAML, SCIM, etc)
            • Custom branding via CSS
          • We continuously evaluate our time to value and minimize the time it takes to setup and resolve integration issues in order to provide a fully functional continuous training program.
          • We help identify inefficiencies and assist (when necessary) in building solutions
          Requirements
          Examples
            Observation created almost 6 years ago
          Featuring:Noah B.We put learners firstWe have difficult conversationsWe ask clarifying questionsWe get agreementsWe recognize the opportunity in challengesWe inspire others to do better workWe don't wait to be told what to do, we take initiativeWe challenge ourselvesWe represent Lessonly positively in the communityWe critique, we don't complainImplementation engineerTechnical investigatorTier-2 escalation engineer

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

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

            Observation created about 6 years ago
          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!

          We respond to and triage all application wide errors and outages

          Full Description
          • We respond to and triage all application wide errors and outages.
          Requirements
          • Must have a position with the reach of 2.1 or higher
          • For this role, you must be milestone 2 or greater inCollaboration
          • For this role, you must be milestone 2 or greater inInfrastructure
          • For this role, you must be milestone 2 or greater inRuby
          • For this role, you must be milestone 2 or greater inRails
          • For this role, you must be milestone 2 or greater inData
          • For this role, you must be milestone 2 or greater inEngineering Communication
          • For this role, you must be milestone 2 or greater inSoftware Investigation
          Examples
          An observation relating to  On-call application engineer  has not been publicly recognized yet.

          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.

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

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

            Observation created about 5 years ago
          Featuring:Joseph A.Engineering CommunicationTechnical InvestigationCollaborationBack-end engineer

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

            Observation created over 5 years ago
          Featuring:Brittany H.We put learners firstWe share before we're readyWe ask clarifying questionsWe get agreementsBack-end engineer

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

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

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

            Observation created almost 6 years ago
          Featuring:Thomas C.We put learners firstBack-end engineer

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

            Observation created almost 6 years ago
          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.

          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!

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

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

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

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

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

            Observation created about 5 years ago
          Featuring:Donnie W.CollaborationReactFront-end engineer

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

            Observation created about 5 years ago
          Featuring:Ethan M.CollaborationCommunicationCommunityMentorshipReactFront-end engineer

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

            Observation created almost 6 years ago
          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 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

    • Explore Options
    At this step you'll be able to choose different positions or roles that will take you down different paths along your journey. It'll give you an idea of what areas to focus on next and if you do focus on them, what it may take to get to where you are going