Tending your social network at work
Status: Draft
Confidence: Likely
In any organization, your network of people is a major asset. This becomes more and more true as you become a tech lead, area tech lead, staff/principal engineer, or other positions where you are expected to handle queries and make calls on big questions for people. In those positions, you’re not expected to have all the answers, but you are expected to be able to connect the right people and facilitate their discussions to produce answers. And even if you have the answer, it’s often better to connect and facilitate than give it yourself.
Don’t: “The answer is X.” (for all X)
Do: “Jeff has really good domain knowledge on Y which
gives us the requirements, and there are concerns about how the data
gets pushed to observability, and Jane’s a great resource on that. Let
me introduce you to them, and between the three of you I bet we can get
a really good answer.”
Don’t: Introduce people and then abandon them to
collaborate.
Do: Know how much support the person
needs. Do they need you to set up the discussion and guide it, then
coach them before, during, and after the meetings to start building
their skills in this area? Are they experienced and just need a name and
what the person knows and they can take it from there?
The broader your purview and thus your network, the sparser it is. This is a simple limitation of the amount of time you have in the day. For example, if you are a tech lead, your network should include
- everyone on your team
- your manager
- your product manager
- the tech leads and managers of neighboring teams
- your manager’s manager
- non-engineering stakeholders that directly influence your work
- your area tech lead, staff engineer, or whatever other engineering leadership is supposed to be advising you
That is easily twenty people already. Having a 30 minute chat with each of them each week can be ten hours or more a week. Now imagine an area tech lead or tech lead of tech leads that is supposed to know the other area tech leads, the tech leads in their area, the manager, stakeholders, all the relevant product managers, more of the management chain… It is a sad fact of physics that the area tech lead probably won’t know all the individuals in the engineering teams they’re responsible for because there just isn’t time. The key principle is that your network should have a short path to anyone in your purview. For the area tech lead, individual tech leads or team managers provide a one step path.
I divide my social network into three horizons:
- I talk to this person regularly (include people scattered across the company that you personally like)
- I talk to this person occasionally and the relationship is open
- I may have met this person, but I find them largely by referral from others
Horizon 1 is necessarily not that big. In fact, your limited time means that it’s always smaller than you probably feel like it needs to be. So many people get bumped to horizon 2.
You can also play a trick with groups. If you have a collection of people such as all area tech leads at a small-ish company, or all product managers in your part of the organization, and they have a broad communications channel such as a Slack channel, tending the slack channel as if it were in horizon 1 effectively gives you horizon 2 to everyone in that group. I have found that this doesn’t work well beyond two or three groups because otherwise it takes up too many slots in your calendar that need to be individual relationships.
For each person in your network, there are a bunch of aspects of them that it’s worth keeping in mind. Everyone’s list of aspects they tag people with will be different. The aspects I find that I reflexively keep at this point in time are:
- Do they learn via writing, reading, or speaking? (I got this from Peter Drucker’s Managing Oneself). For example, I had a manager/principal engineer in a team I worked with who needed to talk to figure out what he thought about something, so we would spend a couple hours a week talking while he figured that out. I write to get my thoughts figured out and in order.
- How do they communicate well? Do they do best with async Slack messages and an occasional, ad hoc Slack call? Weekly or semi-weekly scheduled one-on-ones? In one-on-ones, do they show up with an agenda of things that they have concerns about? Do you need to talk them around to their concerns to get them to open up?
- What lenses are they aware of? That is, when they look at something, what aspects of the thing does their mind automatically present to them? For software, this can include program structure, deployment and operations, process and human dynamics, politics, architecture, compliance, security, and a laundry list of others. Some will be the same as yours. Some you will have and they won’t. Some they will have and you won’t.
- What is their domain? What do they know? What can they do?
- What are they interested in? What material can I send them to maintain a positive relationship?
- What personal information do I need to have a rapport with them? Some people want to talk about the latest trends in functional programming as social lubrication. Others want to talk about their kids. Others want to talk sports. This is important, as being interested in how they feel about what is important to them is a very strong, unconscious cue to them that a relationship is positive and enriching.
Fortunately if you start attending to various aspects like this for people around you, your unconscious brain and its massive social machinery will tend to pick up on that and begin tracking it for you.