Monday, January 22, 2018

Support engineer medior - Level 2

The path to Support engineer Level 1 or "SE certification" as we commonly call it is relatively straightforward:
  a) Get to 100% unified metrics in at least 3 consecutive months:
    -- ZIGS 100% - easy enough with majority of our products, just be as hard on them as possible
    -- Writing 100% - this is the most challenging part as it requires constant learning and systematic weekly writing ideally without ups and downs
    -- Support coverage divided between colleagues and following The Support Engineer’s Creed

  b) Contribute to your team by helping them own all of the content

  c) Contribute the team with product ownership - comp analysis

  d) Cover the operational work of getting the products through the testing and out to production

When you have the metrics and both your team and internal customers provide good values feedback you are all set for Level 1 certification - on average this takes 9-12 months but we did have some cases (one of them only a few months back) of certifying in 6 months flat

SE Level 2 shares all of the requirements with SE Level 1 except that metric requirements are higher

However simply achieving higher SE metrics won't be enough to get certified for SE Level 2 as the standards for contributing to the team and the company are also higher - meeting those standards is a requirement for a positive Level 2 values review by stakeholders and internal customers

Standards

Here are some specific examples of higher standards expected from SE Level 2:
  1) QA - as level description also says:
    -- Provide real-world testing vs. just some easy to catch surface bugs or edge cases by pounding your mouse and keyboard until something breaks
    -- Be an advocate for automation vs. allowing others to ask for test automation from your team
    -- Plan your work and be meticulous with regression testing, never allow the same bug to resurface in production
    -- Know your products performance, usability (UX especially) and quality and raise issues vigorously and frequently; don't allow customers or others within the company to do this for you

  2) TQM - keep owning the content including everything you previously wrote and is available in production as it must be kept up-to-date

  3) Earn the respect of your team:
    -- DON'T keep quiet and allow for known issues to go unchallenged
    -- DON'T be stubborn and insist on low-ROI fixes and changes
    -- DO stand your ground when you know and have the facts that the issue you raised is valid and important to the customers

  4) Lead or assist with company-wide initiatives
    -- Update and create standards that affect multiple products
    -- Raise issues with content and products owned by other teams

Time period

Expected time period to gain the necessary experience for SE Level 2 from day one on the job is at least 3 years

This depends on each person individually but if you started working without previous database administration / development industry experience then you can consider yourself a fast learner if you certify as soon as you hit this mark

No regression

More so with SEs than with other roles, regression is an automatic process based on metrics

This also means that you can't regress when it comes to values and contribution you had in order to achieve Level 1 and must keep hitting the high notes most of the time

Hard skills

This will come naturally with experience through the creation of new content, real-life use case testing, test automation, and other work

Being T-SQL guru or knowing secrets of SQL Server and cloud administration isn't the goal, but knowing your owned products well and related technologies is

Ultimate test

Success = results / time / stakeholder_time

Note the last variable in this equation: stakeholder time

Ask yourself how much time do you save to stakeholders?
  a) Are you being reminded to update owned content (roadmaps, articles, videos)
  b) Are others in the company raising endemics and red flags in your products
  c) Do stakeholders have to invest much time in order to review your content (articles, release notes, F matrices, etc)
  d) Are you being asked questions about the team status that catch you by surprise
  e) Are you unable to answer a functional question related with the owned product
  f) Are you unaware of a comp status or a melting iceberg affecting your team
  g) Is your view of the product PUQ different from reality
  h) Have you recently approached product development and design like a "coder" instead of a customer

If you've answered any of the above with a Yes then that is a potential blocker you need to remedy