A Step-by-Step Guide for your first 90 days as a Senior DevOps Engineer
Get Up to Speed Faster and Smarter in Your New Role
“The president of the United States gets 100 days to prove himself; you get 90. The actions you take during your first few months in a new role will largely determine whether you succeed or fail.”
Excerpt from The First 90 Days by Michael D.Watkins
When people are hired for a Senior DevOps or SRE role they are typically expected to “figure things out on their own”.
Besides formal HR and corporate onboarding procedures, you might find yourself in a situation without a clear onboarding plan.
In case there is such a plan and procedure in place — you are lucky, just go ahead and grind. In the opposite case, which is more likely, you may want to make such a plan yourself. Here is what it can look like for the first 30, 60, and 90 days.
First 30 Days
At this stage, it is very important to understand a high-level picture of your situation and get everything prepared for your future meaningful impact.
Get a Clue about the Org and Infrastructure Landscape
To understand the structure of the engineering team you work with and what the tech eco-system look like you can use the next questions:
Is there a diagram of the Org structure of the Engineering?
If no — draw your own.
What are the types of engineering teams, and what are their tech stacks, typically:
Development teams (Backend/Frontend/Mobile/etc)
Data teams (Engineering/Machine Learning/Analytics/Science/etc)
Quality Assurance and similar
etc
Which stage of DevOps maturity organization is at?
Find out what kind of Ops/DevOps/SRE/Cloud/NOC teams are present and which function they play.
Which DevOps shade do they represent?
Who do they report to?
What are their goals, KPIs, and active projects?
What is the historical context of those teams?
Which way security and permissions management is being handled?
Understand how the SDLC looks right now
Understand where things are hosted? (cloud/on-prem/hybrid)
How things are deployed? (manual/automation/which tools/who deploys)
What is the flow for changes to be made (git as a source of true/manual/custom/hybrid)
How everything is monitored (on-site setup/saas solution/who monitors what)
What are the typical day-to-day activities of different teams?
Is SDLC different for different teams?
Get Hands-On
Try to contribute as soon as possible and ideally across different places, that’s how you get familiar with the environment the best:
Create PRs with minor changes
Publish some documentation
Fix some simple bugs
Help to troubleshoot
And what’s important try to obtain all the accesses to the code storage, etc, and negotiate the broadest permissions possible at this stage.
At this point at the end of the month, you will have plenty of materials and permissions, at your disposal toutilize later.
Discuss success criteria
Meanwhile, you will want to leverage the time with your manager for meaningful conversations to understand what are the success criteria for your current position. Some good questions you can ask your manager and people around are:
What is the reason for your hiring?
Is that a replacement/new position, what is the historical context?
Is there a goals system OKRs/SMART?
Is there a planning systems Agile/Kanban being used currently?
Are those aligned with the everyday jobs you do or are being asked to do?
Capture info
This is obvious, but very crucial. You may want to capture everything you learn about a new org and store initially for yourself, so you can package that and contribute it into documentation for the org, which will be an extra perk for you.
You can use any mind-mapping or visualization software like Excalidraw, AsciiFlow, Lucid, or Miro.
You can capture answers to all the questions from above to any note-taking software, like Google Notes, Notion, Obsidian, Evernote, or Apple Notes. Later on, as you have more information you can synthesize pretty good findings out of that.
Along with that, I encourage you to start writing your BragDoc if you don’t do it already.
At the end of the month, you would have those diagrams and ideally permissions to do stuff.
From 30 to 60 Days
At this stage, it makes worth finding ideally one potential opportunity, which has an irrational effort/impact ratio. This will mean you will be able to achieve some early wins within your first 90 days, which will ideally bring a huge impact.
It is usually hard to find such an opportunity in such a short period, but I like to approach the situation in the way that you hone in and create such an opportunity for yourself rather than looking for it.
Here is a few things you could do:
Analyze Your Activities
Getting back to DevOps Shades, what exactly is the kind of the function you and your team provide to other teams?
How do you interact with other teams?
Do you deploy code? Do you fix CI builds? Do you troubleshoot problems on production? Do you tweak applications or auxiliary services?
Is that function similar for different teams?
Do you troubleshoot for team A, automate for team B, answer questions for C, configure permissions for D
What are typical requests from those people?
Do your team and other teams have the same understanding of your function?
What is the level of expertise of people in other teams?
Do they write code, test it, design architectures, or do project management?
What is the level of their seniority? Does it match what they do?
How do they threaten DevOps? Do they follow “you build it you own it” principle?
The answers to these questions would help you to understand the level of The DevOps Maturity Model in the organization.
Take a Closer Look at External Activities
Besides the situation with the DevOps adoption itself, try to pay attention to what’s going on in the org in general.
What are high-level projects everyone is talking about?
What are the things Engineering Leadership people are broadcasting?
What are the main initiatives different teams are taking care of on regular basis?
What are the crucial projects or goals on the horizon for different teams?
Is that aligned with the goals and activities of your team?
What are the patterns of the problems, which happened over the first 30 days?
What are the typical pain points people describe in their day-to-day job?
Map Internal with External and Look For “Aha moment”
I like this metaphor of “Aha moment” when you can discover the most impactful hanging fruit, no one was thinking about earlier. This is where you have this gut feeling, like “No way! This thing can be handled a way better!”
In my experience, such opportunities appear in the gaps between different areas of expertise/responsibilities and goals. The better you find a way to align those, that’s your hunch!
In practice it can be anything from, bringing in the new software or tool, which solves problems, developing simple automation from scratch which eliminates routine, or introducing a minimalistic redesign in workflow or processes.
Here are a few ideas on how I would approach the discovery process:
Try to distinguish a few people and achieve alignment with them and make them your allies in this journey
Pay a closer look to what they do and how they work
Try to ask open-ended questions
- What are their Jobs-To-Be-Done in everyday activities?
- What is their working flow and why?
- What are the pains they have and what are the gains they would like to achieve?
Pick a few options, put them into a table and try to give them weights
Confirm with your manager that it makes sense
Think aboutwhat you can improve and deliver a minimal improvement in a shortest period
Try to confirm that you are moving in the right direction with multiple people and it aligns with different initiatives
At the end of the second month, you would want to have a pretty good understanding of the eco-system, major players, and their problems. Ideally, you’d like to have a clear understanding of the result you want to achieve in the short term and one or two allies, who will help you with that.
From 60 to 90 Days
At this stage having the potential direction for your early win you may want to secure your way to success with it. That is the period you’ll need to make sure you have everything you need and get rid of blockers
Prioritize it and secure time for your new project
Constantly make sure you are on the same page with your manager
Negotiate extra time/resources with your manager if you need
Try to determine unnecessary activities you spend time on, which doesn’t make you closer to the goal
Keep iterating and get immediate feedback from your ally
Think in concepts of User Stories, makes sure your ally’s workflow becomes better with every iteration you do
Follow your ally’s steps yourself, and try to experience his UX on your own
Setup the same dev environment on your laptop
Make sure you understand all the use-cases
Try making “dummy” changes to mimic the flow
Try contributing as often as possible in the smallest chunks
Show Your Work
Wrap up the project to some logical breakpoint, when you can see a meaningful impact
Prepare a demo and a presentation with your ally for a broader audience, ideally for the entire engineering
Make sure you get feedback from multiple people with different points of view on the solution
Encounter their feedback into your demo and get a formal approval
Throw a demo and focus on impact when you present it
Get feedback after a demo and encounter it in your further work
The Bottom Line
If you follow these guidelines or just leverage some of them, the chances are pretty high that you’ll be able to build that initial momentum for your success, which you can ride later on. It may take you way more than 90 days, but in my experience, it should make a difference anyway.
Some additional perks you can get out of this process are:
Leverage your materials to contribute to the company’s wiki
Use your records for you BragDoc for your next performance review and your case-studies
Get social with you case-study later on sharing it with public
Subscribe to my newsletter and feel free to connect with me on Linkedin, and follow me on Twitter and Other socials in order to not miss the next episode!
Good Luck!