Highlights

Setting strategy for first the quarter

I was able to explicitly and transparently communicate to my team that the strategy that I want us to roll with for our first quarter is to prioritize knowledge sharing and context building over paralellism. This is predicated on the belief that a focus on pairing and tight collaboration up front will enable smoother autonomous working later on. In practice, this means that although we could readily pick one initiative per engineer from the roadmap and have some measure of success doing so, it will ultimatly be better/faster to focus on one thing together. This was well recieved by the team.

I had this idea knocking around in my head, but it wasn't until I talked it through with a mentor that I realized that I had license to just go ahead and say it out loud.

Applying "first team" thinking

Even though my team is newly formed, we were asked to take on ownership of an existing process. This process doesn't neccearily fit within the team's mandate, but would reduce the current owning team's cost of ownership without burdening the new team too heavily. Having worked in this process before, I had enough context to have a sense of the level of effort involved. Having context on the wider organization, I also had a sense of how beneficial this could be to the other team.

When processing the request, I considered if this request was something that I needed to protect my nacent team against (an impactful "no") versus a chance to improve the state of affairs for the whole ecosystem of teams. This question reminded me of the concept of shifting your "first team", which I encountered in An Elegant Puzzle: Systems of Engineering Management. The blog post from which the particilar chapter was adapted can be found at https://lethain.com/first-team/.

To paraphrase, when managers within an org shift "their first team from the folks they support to their peers", they make decisions that position the interests of the whole organization above those of their immediate team, even going so far as to be willing to "disappoint the folks they managed in order to help their peers succeed. Not callously disappointing folks, but rather balancing outcomes from a broad perspective that included their peers." This, the theory holds and my experience as an IC leads me to believe, helps to build an environment where everyone gets what they need even if they don't always get what they want. I've been in orgs where the term "empire-building" has been thrown around and I find it demoralizing - why create a zero-sum game (or the spectre of one) when doing otherwise is an option?

It is with this intentional shift in first team in mind that I agreed that it would be in the best interest of the org, and, fortunately, not too much of a disappointment to my squad, for us to take on the responsiblity (after writing up the disucssion and soliciting feedback, of course).

Successful one-on-ones with direct reports

One report is a former peer. We talked this up front and, as I'd hoped, there is no weirdness here. All one-on-ones, including that one, were spent getting to know each other as people, setting expecations, exchanging preferences, sharing development goals, establing cadence and not using the time for project status updates.

💡

"Are there any elephants in the room that we didn't talk about" was a good discussion prompt.

Prep work paid off

Having on boarding docs to refernce and build on prior to my official start date was a great - I appreciate that there were folks stewarding on behalf of the yet unformed team prior to it's official inception.

On my end, spending time documenting propsals for ways of working in the weeks prior to kickoffs was a time investment that was well rewarded, serving as a basis for bootstrapping conversations about practices and ceremonies. My plan is to (continue) to lean heavily into documentation to make everything from technical to organizational decisions discoverable and refernable. More on at in another post, perhaps.

Peer encouragement

Many collagues have reached out to express support for my transition into managment. The most heart warming recurring theme is that I've made people feel included and a sense of belonging - even folks who I haven't worked with directly and, most surprsingly, people who I haven't worked with in years who heard about the move through the grape vine. Having serveral folks who I've worked with in various capacities say things like, your reports will be "lucky to have you as their manager" - that gives me to confidence to know that I've set off on this journey on the right path because I've already been on the path.

Room for improvement

Finding balance

Spent time with people management, process management, and tech discovery work, on boarding myself and my teammates. Still held on to some of my pre-management commitments. That's a bit too much, as I ended my work days feeling exhausted. While I did scale back on some commitments in the weeks prior to taking on the role, there is clearly still a need to break out the Eisenhower Matrix and start making some tougher decisions about how to spend my time. I don't think any of the activities outside of my new responsibilities aren't generating value (or I wouldn't be doing them), but there are only so many work hours in the day (and there should likely be fewer...)

On week one as an engineering manager