Mailbag: When your team wants your job, personal brand, and service registries.
Thanksgiving week started well, and then took a hard pivot towards influenza, which meant that I haven’t had much energy to write or think over the past bit. I did get a handful of interesting questions emailed in though, so I figured I’d do an email grab bag of three anonymized questions that came in over the past week and an answer to each.
When your team competes with you
The first question is a particularly challenging one, dealing with a team member who wanted your job when you were hired, and views you as blocking their professional advancement.
My question is around having a very talented engineer on your team. One that when happy can make a team move, and when restless can destabilize. When I started managing the team, one of the long-tenured engineers was clear that he had wanted the role himself, but the company had not felt he was a good candidate. He’s continued to vent to the team his frustration that he isn’t in the role.
I’ve seen this happen a number of times, and have experienced it myself. I’ve found it particularly common when there are complex power dynamics, perhaps the team member is highly tenured at the company and the manager is a new hire. I’ve also seen it happen more frequently to women managers leading teams predominantly composed of men. This is a rather difficult situation to experience, as you find yourself accountable for the success of someone who can feel like they’re determined to undermine you.
The three step approach I’ve found useful in these cases is: (1) align upwards exhaustively with your management, (2) partner with the individual to design and implement a career path that puts them on a clear trajectory to accomplishing their goal, (3) manage them out if they’re not willing to do work to accomplish their goal.
First, alignment with your management. The goal here is not to “block” the individual from escalating, but rather to align on the right outcome for the company so that you and your management chain can steer towards the best outcome for folks involved whether or not there’s an escalation. If you don’t align early, then you, the individual and management will get into a sequence of miscommunications that are hard to unwind later.
Second, work on building trust with the individual by laying out their options and working with them to create a plan towards the outcomes they’re most interested in. In this case, it might be having an honest conversation with them about why the company doesn’t have confidence in them as a management candidate, along with a roadmap of how you want to work with them on those skills, combined with a future opportunity to do a test run to demonstrate success once they’ve hit a milestone. It can be difficult to prioritize helping someone who is blowing your work-life up at the moment, but it’s the only way to start putting things back together.
Finally: if you can’t get them to partner with you honestly on moving towards their plans, then it’s probably time for them to move on to another company.
Startup CTOs and personal brand
The second question was about personal brand and whether it’s actually the right priority for someone in senior leadership to focus on.
Is it important for CTO of a startup to work on their personal brand as a Great CTO? Does this conflict with their obligations towards prioritizing their company’s needs? For example, they could have done more meetings, or helped more developers in removing their bottlenecks.
The concept of personal brand isn’t one that I use in my writing, and I find that specific term a bit unlovable, but leaving the particular words aside, there are two questions here to untangle (1) “Is it important to be well-known to be an effective CTO?” and (2) “Is a CTO focusing externally a theft of productivity from internal priorities?”
Regarding the first, the full-stop answer here is no, it’s not essential for a great CTO to be well known. Rather, what’s important is much less being known rather than knowing people. It’s far more powerful to have deep, real connections with fewer folks who will actually help you when you need it than having broad ambient awareness of your work. Being famous doesn’t let you do things; it’s developing your skills and building your relationships that lets you accomplish things that are impossible without them. I wrote a bit about building these sorts of relationships in Meeting People.
The second piece of the question is interesting as well, as it partially implies to me the mindset of an engineer who so wants to be focused on building that they’ve partially convinced themselves that work other than building is superficial.
If you are only focused internally, you’re probably doing a bad job as a CTO. If you’re only focused externally, you’re probably doing a bad job as a CTO. Whether you should be focusing outwardly or inwardly within your company is going to depend on your company’s particular needs at a point in time, and will shift frequently over time.
Service registries
The last note I got was someone working in infrastructure engineering at a medium-sized public company, wondering about internal service registries.
At $CO, we’re building an internal Service Registry for humans. It contains the names and descriptions of all the different internal services. It also contains various meta information such as the emails of the PM and tech lead who own the service and a link to the roadmap or pertinent slack channels. The plan is to use it to answer questions such as “who do I contact with questions about this service?”, “when was this service last deployed?” or “what is the version of the latest docker container for this service?” Have you seen similar services?
Every company I’ve worked at ends up building something along these lines, starting with some narrow usecase, often a deployment UI, and enriching it with more metadata and functionality over time. Some common functions are deploys, deployment history, observability graphs, logs, triggering the pager rotation, ownership, routing, access controls, feature flags, and so on.
Stripe’s internal version is named Amp, kicked off a couple years ago by Shawn Moore and Jay Shirley, and it’s become a cornerstone of internal developer productivity efforts. Uber had a similar tool, which started out as a service cookbook generated from a YAML config and evolved into a full-service portal. Most companies with a few hundred engineers will have something equivalent.
These tools are exceptionally useful, because they allow infrastructure teams to treat their work as a product, including A/B testing new features, getting usage analytics, iterating on usability, and making more nuanced tradeoffs to manage the complexity they expose against the power their users require.
A good example of this is deployments. Early on companies will have a very simple deployment model, perhaps just an iterative deploy with manual health checking. Over time, you’ll iterate towards having canary deploys, with different wait periods depending on the criticality of the deployed system, and asking a human to navigate that complexity will lead to frequent errors: it’s just too complex. These service registries are a great place to manage that complexity, giving a single-button deploy experience, and then providing step-by-step information of how the deployment is going so the deployer still has awareness of what’s happening underneath the hood.
This is also an interesting category because I think it’s fairly challenging to build an open-source equivalent that can get widespread adoption. The value of these systems is that they are workflow and system integration glue on top of every other internal system, which equates to something deeply custom particularly in the workflows. I’m certain you could build a standardized foundation and the integrations with Consul and such, but would you be able to preserve enough flexibility in the workflows to let infrastructure teams iterate it as a product rather than deploy it as a tool?