{"id":5817,"date":"2023-08-23T01:35:49","date_gmt":"2023-08-22T15:35:49","guid":{"rendered":"https:\/\/sysmit.com\/cf22\/?p=5817"},"modified":"2023-12-13T15:26:50","modified_gmt":"2023-12-13T05:26:50","slug":"10-tips-for-onboarding-new-sre-hires","status":"publish","type":"post","link":"https:\/\/sysmit.com\/cf22\/10-tips-for-onboarding-new-sre-hires\/","title":{"rendered":"10 Tips for Onboarding New SRE Hires"},"content":{"rendered":"

How new SRE hires can get stuck<\/h2>\n\n\n

There\u2019s more than one way to mess up your new SRE hire and get them stuck in a loop.<\/p>\n\n\n\n

Here are 6 ways new hires will know you\u2019ve made this mistake:<\/p>\n\n\n\n

    \n
  1. unclear role requirements<\/li>\n\n\n\n
  2. going too advanced too soon<\/li>\n\n\n\n
  3. not having any tangible, measurable things to do in the first few months<\/li>\n\n\n\n
  4. not feeling connected with the rest of the SRE team<\/li>\n\n\n\n
  5. no clarity on how SRE fits into the wider organization<\/li>\n\n\n\n
  6. little to no collaboration with teams outside of SRE<\/li>\n<\/ol>\n\n\n\n

    This article will unpack these 6 sticking points and show how to solve them.<\/p>\n\n\n\n

    Later on, I will share 4 additional tips to improve the onboarding experience. <\/p>\n\n\n

    Let\u2019s unpack and solve each of these sticking points<\/h2>\n\n

    Unclear role requirements<\/h3>\n\n\n

    SRE is a broad-spanning role.<\/p>\n\n\n\n

    Your definition of SRE might differ from other companies your new hire has worked at.<\/p>\n\n\n\n

    Or your organization might not have clearly defined its SRE goals at all.<\/p>\n\n\n\n

    This can result in a less-than-clear view of the work that needs to be done.<\/p>\n\n\n\n

    In a nutshell, the roles you are hiring for lose clarity.<\/p>\n\n\n\n

    New hires can only be as effective as their knowledge of what needs to be done.<\/p>\n\n\n\n

    I recommend that you consider this hierarchy of role clarity:<\/p>\n\n\n\n

    Novice<\/strong> – no role description at all<\/p>\n\n\n\n

    Beginner<\/strong> – written job description listing all duties<\/p>\n\n\n\n

    Advanced<\/strong> – detailed job description adding priority areas and key outcomes<\/p>\n\n\n\n

    God mode<\/strong> – a visual roadmap of everything from Advanced Mode outlining progression over a timeline<\/p>\n\n\n

    Going too advanced too soon<\/h3>\n\n\n

    There\u2019s an old saying that you can\u2019t run before you can walk.<\/p>\n\n\n\n

    This could not be more true for making sure new hires are effective in the long run.<\/p>\n\n\n\n

    I\u2019ve seen a lot of managers do this: give a grace period of 4-6 weeks of not-so-tough tasks and then throw the new hire into the deep end of the swimming pool.<\/p>\n\n\n\n

    This does not work in my experience.<\/p>\n\n\n\n

    The work your current SREs have been doing may be something they have been doing for years.<\/p>\n\n\n\n

    And it\u2019s likely they worked their way up to the level of competence you see.<\/p>\n\n\n\n

    So take gradual steps up to more advanced work with your new hire.<\/p>\n\n\n\n

    You need to gradually increase the complexity of the work.<\/p>\n\n\n\n

    This applies to SREs with prior experience too.<\/p>\n\n\n

    Not having tangible, measurable things to do in the first few months<\/h3>\n\n\n

    This ties in with a lack of role clarity.<\/p>\n\n\n\n

    If you have a clear idea of what your new hire needs to do, it\u2019s easier to set measurable goals of where they should focus their attention.<\/p>\n\n\n\n

    It\u2019s not easy if you don\u2019t know where to start the new hire off.<\/p>\n\n\n\n

    Some tangible and measurable pieces of work can include:<\/p>\n\n\n\n

      \n
    • Shadow other SREs on incident responses (measured in the number of incidents)<\/li>\n\n\n\n
    • Write incident reports (measured in the number of reports and takeaways)<\/li>\n\n\n\n
    • Document processes as they learn about them (measured in the number of processes)<\/li>\n\n\n\n
    • Write code to improve tooling (measured in lines and commits)<\/li>\n<\/ul>\n\n\n\n

      It may sound banal but it is tangible and measurable.<\/p>\n\n\n

      Not feeling connected with the rest of the SRE team<\/h3>\n\n\n

      This can wildly depend on how the team is situated – is it in an office or hybrid or fully remote?<\/p>\n\n\n\n

      It can also vary depending on whether or not you have team-building initiatives in place.<\/p>\n\n\n\n

      The key is to create an emotional connection between the new hire and the work\/team.<\/p>\n\n\n\n

      Here are 3 ways you can increase the emotional connection with your team:<\/p>\n\n\n\n

        \n
      • Rotating buddy programs.<\/strong> Connecting new hires with a new buddy is useful, but only one buddy means one strong connection. Rotate the buddies around the team over a reasonable time like every 4 weeks to increase the spread of what I call \u201cwork buddy feels\u201d.<\/li>\n\n\n\n
      • Participation in a collaborative project.<\/strong> Get the new hire in on any project or activity that involves multiple members of your team. This can include projects like capacity planning for traffic variations or setting up a new incident response protocol.<\/li>\n\n\n\n
      • Regular manager check-ins.<\/strong> I feel this should go without saying, but managers get busy at times and forget that they made a new hire or several new hires. It\u2019s a wise idea to set a schedule ahead of time to do very quick check-ins.
        • Ideal mode: do verbal check-ins at scheduled intervals.<\/li>
        • Autopilot mode: pre-write emails for sending at scheduled intervals.<\/li><\/ul>You can do both if you wish. I\u2019ve done it myself over the years.<\/li>\n<\/ul>\n\n\n

          No clarity on how SRE fits into the broader organization<\/h3>\n\n\n

          The last thing a new hire wants to do is step on toes.<\/p>\n\n\n\n

          Especially of people outside your SRE team.<\/p>\n\n\n\n

          This can happen if you don\u2019t delineate the specific role of SRE in the organization.<\/p>\n\n\n\n

          What do I recommend?<\/p>\n\n\n\n

          Explicitly communicate to your new hire how the SRE function supports the broader engineering function including:<\/p>\n\n\n\n

            \n
          • What developers are responsible for<\/strong> e.g. whether it\u2019s the \u201cyou build it, you run it\u201d or \u201cwe run it for you\u201d or a hybrid model.<\/li>\n\n\n\n
          • If other functions own a typical capability of SRE<\/strong> e.g. a dedicated observability team that works independently of the SRE team<\/li>\n\n\n\n
          • How much assistance do other functions need<\/strong> e.g. does AppSec need help navigating services when they are facing an incident? do developers need incident support?<\/li>\n<\/ul>\n\n\n

            Little to no collaboration with teams outside of SRE<\/h3>\n\n\n

            There might be a problem if you struggled with the last point about how SRE supports the broader organization.<\/p>\n\n\n\n

            Active collaboration with other teams is a key tenet of effective SRE teams.<\/p>\n\n\n\n

            I have heard enough SRE managers tell me about a related antipattern:<\/p>\n\n\n\n

            \u2192 their SRE function is centralized (bueno<\/strong>)<\/p>\n\n\n\n

            \u2192 but also only works with \u201coutsiders\u201d through tickets (\u00a1no bueno!<\/strong>)<\/p>\n\n\n\n

            The reality of SRE collaboration should be very different.<\/p>\n\n\n\n

            I highly encourage SRE leaders to create formal collaboration activities with other departments including:<\/p>\n\n\n\n

              \n
            • education sessions for developers on various operational areas<\/li>\n\n\n\n
            • collaborative special projects with other areas like quality assurance, AppSec, database analysts, etc.<\/li>\n\n\n\n
            • embedding SREs within critical feature teams<\/li>\n<\/ul>\n\n\n

              More ways to make sure new SREs don\u2019t get stuck<\/h2>\n\n

              Start new hires off \u201csmall and steady\u201d<\/h3>\n\n\n

              The trick here is to start new hires off with a small part of the bigger SRE puzzle.<\/p>\n\n\n\n

              What puzzle am I referring to?<\/p>\n\n\n\n

              It\u2019s all the work that your SRE team is doing like observability instrumentation, responding to incidents, and more.<\/p>\n\n\n\n

              My belief is that you don\u2019t want to throw a new SRE hire into fixing your tricky capacity issues (for example) on Day 1.<\/p>\n\n\n\n

              This also goes for new hires who have worked as SREs before.<\/p>\n\n\n\n

              What you do want to do is give them work that is small but measurable and gives them a sense of achievement once completed.<\/p>\n\n\n\n

              They need to feel like they are progressively unlocking increasingly complex work.\u2019<\/p>\n\n\n\n

              Kind of like how you\u2019d play a computer game.<\/p>\n\n\n

              Start slow with junior SRE hires<\/h3>\n\n\n

              When it comes to junior SREs specifically, I suggest you give them a mix of both “thinking” work and “doing” work, which keeps things spicy.<\/p>\n\n\n\n

              It will help them stay engaged with learning by doing<\/em> as well as develop their critical thinking around your processes.<\/p>\n\n\n\n

              Now, how would this pan out in real life?<\/p>\n\n\n\n

              I\u2019d say give the newbie hire more concrete tasks initially, such as reviewing past incidents or reverse engineering a solution that your other SREs came up with.<\/p>\n\n\n\n

              They can also shadow one of your experienced SREs during an incident response.<\/p>\n\n\n\n

              Not only does this approach help to provide a sense of achievement, but it can also help to build up their process orientation over time.<\/p>\n\n\n\n

              Over time, a well-hired junior SRE will begin to gain more experience and grow their skillset.<\/p>\n\n\n\n

              This is when it becomes important to give them the freedom to explore beyond the boundaries of the process.<\/p>\n\n\n\n

              This is the time to foster creativity and innovation, allowing them to come up with new and better ways of doing things that might not have been considered before.<\/p>\n\n\n\n

              By providing a balance of structure and autonomy, you can help your junior SREs to grow and thrive in their roles.<\/p>\n\n\n\n

              This way, you can also ensure that they are contributing to the success of your team and organization as a whole.<\/p>\n\n\n

              Avoid trial-by-fire onboarding practices<\/h3>\n\n\n

              The Site Reliability Engineering (2016) book by Google sheds light on the fact that the trial-by-fire approach is not an effective way to onboard new SREs.<\/p>\n\n\n\n

              This is a valid point, as merely exposing new SREs to numerous tickets can become overwhelming. Even counterproductive.<\/p>\n\n\n\n

              Instead, take a more structured approach to train new SREs.<\/p>\n\n\n\n

              One that includes ample guidance and mentorship opportunities.<\/p>\n\n\n\n

              This will not only enable new SREs to gain a better understanding of their role but also ensure that they feel supported and valued within their new organization.<\/p>\n\n\n\n

              You might incorporate this with a formal feedback mechanism that can help identify areas for improvement.<\/p>\n\n\n\n

              A thorough training program with an academy format can also be helpful in this situation.<\/p>\n\n\n

              Evolve the work as new hires become more effective<\/h3>\n\n\n

              At the beginning of a project, give team members relatively low levels of autonomy to ensure that everyone is aligned with the project goals.<\/p>\n\n\n\n

              As the project progresses, gradually increase their levels of autonomy to foster creativity and innovation.<\/p>\n\n\n\n

              To avoid developing a monolithic role over time, team members should be given responsibility for a breadth of issues.<\/p>\n\n\n\n

              This not only helps prevent burnout but also ensures that team members are constantly challenged and engaged.<\/p>\n\n\n\n

              Team members should also have the choice to code their own solution or to use middleware. This allows for flexibility and promotes creativity.<\/p>\n\n\n\n

              While being on-call is an important part of the job, it should not become the primary responsibility of SREs.<\/p>\n\n\n\n

              Many SREs quit the industry because they never get past the reactive “dumpster fires” and onto the proactive work they signed up for.<\/p>\n\n\n\n

              It is important to ensure that on-call duties are balanced with other duties to prevent burnout.<\/p>\n\n\n\n

              It is important to reemphasize that at no point should SREs become the main destination for tickets.<\/p>\n\n\n\n

              This turns them into operations in the traditional sense of “responding to tickets as issues arise.<\/p>\n\n\n\n

              You will not benefit from the SREs’ software engineering skills if they are constantly putting out fires.<\/p>\n\n\n\n

              Instead, SREs should be focused on proactive work to improve the system and prevent issues from arising in the first place.<\/p>\n\n\n

              Bringing it all together<\/h2>\n\n\n

              New SRE hires can get stuck in a loop due to unclear role requirements, going too advanced too soon, lack of tangible tasks, feeling disconnected from the team, no clarity on how SRE fits into the organization, and little understanding of collaboration with other teams.<\/p>\n\n\n\n

              To avoid this, start new hires with small, measurable tasks, give junior SREs a mix of “thinking” and “doing” work, avoid trial-by-fire onboarding, and evolve their work as they become more effective.<\/p>\n\n\n\n

              On-call duties should be balanced with other duties and SREs should focus on proactive work to improve the system and prevent issues from arising.<\/p>\n","protected":false},"excerpt":{"rendered":"

              How new SRE hires can get stuck There\u2019s more than one way to mess up your new SRE hire and get them stuck in a loop. Here are 6 ways new hires will know you\u2019ve made this mistake: This article will unpack these 6 sticking points and show how to solve them. Later on, I […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,29],"tags":[13,7],"_links":{"self":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/5817"}],"collection":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/comments?post=5817"}],"version-history":[{"count":2,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/5817\/revisions"}],"predecessor-version":[{"id":5819,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/posts\/5817\/revisions\/5819"}],"wp:attachment":[{"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/media?parent=5817"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/categories?post=5817"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sysmit.com\/cf22\/wp-json\/wp\/v2\/tags?post=5817"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}