An "experience report" on starting a new role as a Staff engineer. Folks tell me I've done a good job. That is really only meeting halfway because the team and organization around me has been very welcoming.
This is very Cian-specific as an approach, and ideas particularly under "Landing" worked in a specific local culture, but hopefully some of these notes and observations will be helpful to others.
Started Jan 4 2022 at Datadog, which IIRC at the time was ~3K people, ~1.5K in engineering.
Position: one of 2 Staff engineers reporting to the director of a group of ~70, comprising ~10 teams: "Engineering Efficiency & Effectiveness", the internal developer experience and tooling team; part of the Infrastructure org.
I was coming from a two year stint in a Staff+ position at CircleCI, which I think at most during my time there had ~700 people; ~250-300 engineers. I mostly worked in a group that grew to ~45, usually attached to specific stream-aligned teams but working on various group- or org-wide initiatives.
-
I was as clear as possible with initial contacts and interviewers on what I wanted in my next job and the kind of engineer I am; what I expect to bring.
At the same time, I took a ton of notes during my interviews, asked them lots of questions, and after each compiled a short list of questions to dig into in the next.
-
Reviewed ideas from Michael Watkins' The First 90 Days. I own a copy, but I find it hard to find time and focus for management books, so Rick Linquist's summary and particularly Watkins' presentation to MIT Sloan Alumni linked there were useful. Watkins knows his stuff.
Some notes:
- Everything in the section on "classic new leader traps" c. 07:45 is gold. I feel like actively working to avoid these has helped me a lot.
- Gain a deep understanding of the situation at hand and adapt to that reality.
- Consider effects on others of my landing.
- I really liked the notes on assessing and understanding culture c. 20:20.
- Limit my work in progress; prioritize my director / team's ideas of wins; identify and chase wins consistent with local culture.
While taking notes (9 pages!) on this, I jotted down a lot of questions that arose, like "Who are folks I can lean on as advisors outside my org?
$interviewer_1,$interviewer_2,$friend_of_friend?". More on that in a mo. -
Read the first two chapters of Tanya Reilly's The Staff Engineer's Path: "What would you say you do here?" and "Three maps". This is in early access so it's behind an O'REILLY sub, but it gave me lots to think about, and another 8 pages of notes. :oD
Some notes:
- There's a great list of questions in ch.1 - what I enjoy, how I deal with delayed gratification, etc. I found these a great guide in thinking about how to approach the new role.
- Understand "where I sit" (reporting position), and my initial scope. As part of this, I read the LinkedIn profiles of my reporting hierarchy to understand what companies they had been part of, in what roles, and their tenure at Datadog.
- Rating myself against Yonatan Zunger's five disciplines was a nice exercise.
- Towards the end of the chapter, Reilly has a section on "writing your job description" that I decided I'd try to do before day 30 - an alignment exercise with my director & team.
- Ch.2 has lots of great stuff on "drawing maps" of the organization which (being a visual person and a long-time D&D nerd) is something I relate to strongly.
- Whenever I try to "model or describe reality" like this, consider sharing what I come up with in some form.
- "If your work affects them or theirs yours, get to know them and understand their point of view."
- A useful list of questions about culture, e.g. "oral or written?"; "top-down or bottom-up?"
Again, I jotted down questions as I went, like "What precisely is Datadog's internal description of a Staff engineer? How many are there? What are their tenures, and what do they work on?"
-
Reviewing my interview notes plus all of the above, I collected two lists:
-
Hypotheses: things that may be true about the company, the role, and the people. Examples:
- Paying attention to "why and for whom" - Product questions - will be important.
- My production engineering background will apply more than I expected.
-
Questions: to verify hypotheses, or to answer some questions from Watkins' and Reilly's books. Examples:
- What's important for the group? Which problems need me most?
- How do we make decisions in the group? In Infrastructure? In Datadog?
-
Finally, if you haven't seen it before, Corey Quinn's thread on starting a new job is a great (and funny) resource I took some tips from.
My director had created a really nice onboarding document for me, and I had two onboarding buddies - the other Staff engineer in the group (in NY), and a team lead in France, closer to Ireland where I live. They gave me a lot of their time and helped me acclimatize.
The doc laid out my area of responsibility, our group's vision and roadmap, my team members, an initial onboarding project - I was happy to see it played to my strengths - and lots of people to have initial 1:1s with.
After my first few 1:1s, I verified a hypothesis that verbal communication and influence would be particularly important for my success. So, I invested a lot in 1:1s over the following months. They were all valuable, and more so because I had my "springboard" of hypotheses and questions, and gathered more as I went.
Some of the most useful 1:1s in early days were with the Staff+ folks who represented customers of my group. I've found the "Staff+ network" at the company really great: it's easy to find and chat with people in any area of engineering, and I find the tone of conversation is always collegial even where there's some conflict.
After about 2 weeks I wrote up a "first impressions" document that laid out an engagement model with teams in my group + "initial beliefs" about both the wider engineering organization and my group.
- The model suggested modes of working with teams and individuals. This was part of "writing my job description" - the idea was to set expectations and align with what my manager, peers, and other colleagues hoped for from a new Staff engineer.
- Consult:
- Work alongside a team to help understand problems, direct energy, guide solutions.
- Connect teams and individuals dealing with similar problems: enable a "system of theft" of good practice across teams.
- Embed:
- Given a specific problem, dig in with the team to help bootstrap initial work, or redirect/turn around struggling work.
- Focus on disambiguating problems to the point that they are a 10-20% stretch for folks on the team.
- Back off on details but continue to offer decision support.
- Coach:
- Work with individuals (for example, coming out of Consult or Embed modes), enabling them to effectively own specific problems and grow via them.
- Focus mostly on Senior engineers and Team Leads, with the goal of enabling them to do the same for less experienced engineers.
- Consult:
- The "initial beliefs" were short declarative sentences attempting to describe reality (h/t Tanya Reilly). No hedging language. The idea here was not perfect accuracy, but to stimulate feedback, corrections, and further thoughts. It was very successful and formed the basis of illuminating followup conversations.
After a month, I wrote up a "synthetic" Rumelt-style strategy kernel for the group. Synthetic in the sense of being built up from what I had understood in my first month: as a strategy proper, too broad. But a really useful descriptive tool to align myself with the team.
This helped me comprehend our environment and crucial challenges, the approaches we are taking to tackling those, and how all the work ongoing in the group fits into that. Again, it formed the basis of some great followup conversations.
Other engineers in the group also found it useful as a way of understanding what we're doing and why. Later, I used it as the basis for a series of internal blog posts explaining the group's work to the broader engineering org.
Having built up some context, I executed on my "starter project" over the course of months 2 and 3. This was an operational maturity review of the teams and services in my group: given my SRE background, I had a lot of tools ready to apply here; I thought it was a canny choice by my director. It went well, and the output has formed the basis of a lot of followup action (and dare I say it, incipient culture change) in the months following.
A thing I found myself doing often (and which has been appreciated by colleagues) is writing up "problem statement" documents. I think a Staff engineer with "fresh eyes" is well-placed to do this kind of work.
This is a way to state the problem before we start designing/implementing something. Usually I do this for one of two reasons:
- to build a "problem portfolio" in a particular space - that is, with no immediate intent to prioritize work;
- to set up a more difficult problem or cross-team collaboration for success.
In the latter case, I like to make sure I'm going to have time to follow up on pushing it through management / prioritization in the next quarter or so.
Taking a holistic view increases the chance of doing The Right Thing, IMO (or at least making it cheap to be wrong).
I finished up six months recently with a nice holiday. So far, it's been a very good landing: as of now I can see myself working at Datadog a long time. 🤞
Probably this is mainly down to a good fit between me and my team (and the company) but the preparation above - and treating the first month or so as "input mostly" - made a difference. In particular, taking the time to absorb the history and context around me.
One worry I had when joining - having previously always worked as part of some specific delivery or operational team - was that working with a broader scope would be isolating. As things fell out, I was delighted to find close and trusting team-mates in my group's leadership team. I've also had a great time working with the TLs and engineers throughout the group, and as I mentioned the Staff+ "fabric" is great.
I should note that it hasn't been all roses. One difficulty I had was adjusting to the local information management culture, which is a bit different from anywhere else I've been. It feels hard to make big decisions. The problems facing my group are pretty huge, too, but we've built an excellent team to address them and we're well aligned on how.