jonm.dev

The Art of Writing Software

Individual Contributor

At work, I recently decided to take off my Chief Software Architect hat and hand over the reins of my prior department to one of my direct reports. In my new role, I’ll be an individual contributor again, working on the Comcast Labs team on some advanced research and strategic analysis projects in my capacity as Senior Fellow. I wanted to capture some of my thoughts as I begin this next step in my career.

What have I learned?

In my time as an executive leading a department, I certainly learned quite a lot about how the business and organization operates. Many of these topics were obscured from me when I was an individual contributor previously, and many managers even actively try to hide these details from their teams. Usually this is in a well-meaning attempt to let the team focus on their work, but in my experience this is misguided, as it hides valuable context from the team. Certainly knowing the following things will affect the way I will approach my role as an individual contributor.

Having worked in the organizational transformation space for several years, it is hard to overstate the importance of collaboration with stakeholders. In large companies, and with problems or challenges at scale, it is nearly impossible to accomplish anything by yourself. At the very least, you’ll need to convince folks not to prevent what you’re pursuing, but more likely, you’ll need to recruit their direct cooperation. If you can’t articulate how your project helps them achieve their goals, it’s going to be much harder going than if you can enlist them as active promoters and allies. It’s no good spending a ton of effort on solving a problem no one ultimately cares about.

I’ve spent much of the last seven years or so actively encouraging a departmental culture of intellectual curiosity, mutual support, engagement, and empathy. There are, of course, many excellent entire books on these topics (two of my favorites are It’s Your Ship and The Manager’s Path), so I will only touch on a few high level things that I think worked well here:

Of course, while running a department, you necessarily learn about all kinds of operational systems. This includes learning how hiring works, how headcount is managed, how positions get created, how contractors work, and all manner of things that impact who you can have on your team when. Budgets are a big part of this, of course, and learning what the role of the Finance team is, the difference between CapEx and OpEx, understanding the budget cycle and process, and of course, managing your own budget are a big part of how companies work that most engineers are completely shielded from, much to their detriment. This sometimes leads to misunderstandings, such as:

Engineer: I wanted to do X but Finance wouldn’t let me.

Narrator voice: It wasn’t actually Finance.

Indeed, to put together a solid proposal, you actually have to understand how all this stuff works, or you are quite likely to accidentally run into brick walls you can’t even see. It’s like trying to engineer a solution when you don’t actually know what all the constraints are.

Finally, I learned a lot about hiring a well-rounded team, particularly when it comes to the management team in the department. Major wins came from hiring direct reports who had complementary skill sets and passions to mine, including having a clear successor. Perhaps that goes without saying, but I can say that my most recent department could be a case study for how well this works (and in my case, I was fortunate enough to have multiple direct reports who could have stepped in to run the department). More importantly, having had seven years to grow and develop consistency in certain management frameworks and processes within the department led to the prospect that I really could step away. The members of the department got a chance to learn how everything ran, and then, they increasingly ran it.

What am I excited about?

I’ve always loved programming and directly solving problems. Indeed, this was a major reason why I left academia after getting a Ph.D. and doing a postdoc–I didn’t want to be proposing problems by writing grants, I wanted to solve problems that already existed. Leadership is certainly one way to solve problems, especially problems at scale, but I have missed getting my hands directly in the solution. I’m excited to have the chance to exercise those parts of my brain again. I’m also excited to learn about some new technologies, potentially including some that I haven’t had time to learn in depth in a hands-on way, such as Kubernetes or Rust.

More importantly, I’m excited to have the opportunity to forge a new path for myself and for the company. I’ll be doing some survey work and strategic analysis (likely including Wardley mapping) to assess if certain technical capabilities could lead to an important new strategic line of business. I haven’t had the opportunity previously to do this type of work in a dedicated way, and it will be fun to immerse myself in it.

How will it be different?

Having seen how all the operational systems in the company work (the technosocial ones more than the technical ones), you can’t unsee it. Fortunately, I have a lot more visibility into those hidden constraints I mentioned above, and I think this will make it much more likely that I make proposals that are actually viable. In addition, I have a lot of relationships across the greater company and more personal facility with collaboration, so I have greater confidence that I will be able to loop those folks in at the right time (and certainly much earlier than past individual-contributor-Jon would have done so).

In my new role, I will not have any direct reports, but I may well have the opportunity to share some of the positive culture-building experience with my new department. I also wouldn’t be surprised to find myself leading a team again at some point in the future, so I’ll be able to apply all of those ideas again. I will still have the opportunity to continue mentoring, which is something I really enjoy doing.

But overall, I’m primarily excited to reconnect for a time with Jon the engineer; I’ve always thought of myself that way anyway, even when I wasn’t a front-line engineer anymore. It’ll be a nice reunion.