The “what” for the team is typically their mission, the “how” is team ops. How the team operates is largely the result of continuous improvement of the process of generating and filtering ideas, making sense of the work ahead, course-correcting on the way towards the goal, and inspecting and adapting the way people on the team work together.
Like with a good service, team ops work is hard to notice when it’s being done on par with people’s expectations, but it’s relatively easy to point out when it doesn’t get enough attention and care.
An example of team ops that is most familiar to most of the engineering people is the team’s short-term decision-making. Sometimes it’s called software development methodology, so things like agile and waterfall, but I think that the main component there is not the software, nor is it 100% about development. It’s really about the team making choices about what’s important to work on and how to go about that.
When crafting a staffing plan for a team, it’s really important to also think about how to staff for good team ops. That is, what skills, in addition to hard, directly applicable ones you might be looking for, you need to be represented on the team (and how much) to ensure smooth operations.
Let’s talk a bit about different jobs that are present on the team, occasionally or regularly, that fall into the category of team ops.
Information exchange
Remote and distributed (clustered) teams were real before February 2020, and the process of getting all the right information into all the right people’s heads has been just as difficult. Don’t get me wrong, it’s much easier now to capture the information compared to 10–15 years ago, even five years ago, but!
The main challenge with information exchange is that this information has to be used to be useful. This is part of team ops because it’s driven by people and teams. And because this process never stops and looks like uninterrupted series of small interactions, it fits very well the definition of team’s operational work.
Knowledge accumulation
The little brother of knowledge retention, team’s knowledge accumulation is invisible work that, when being done properly, leaves people with a slight sense of regret.
Really, who needs all that information a week or two after?
People tend to move on. It comes back occasionally and almost always unexpectedly, but that’s a topic for another story.
But this is part of the hygiene, and just like you don’t expect your teeth to get whiter after brushing it once, the knowledge won’t “accumulate” after writing docs for an hour or a day. It’s really about putting continuous effort into and being diligent about it.
Knowledge accumulation work then splits into durable and ephemeral. Durable is writing docs, recording videos, basically everything that can be reused multiple times and that can, potentially, live longer that it can remain useful. Ephemeral is all things text and voice chat, real-time meetings, and water cooler conversations.
Most of this knowledge is only useful within the company, which means it does not, in any way, add to the customer value. So, non-production work.
What makes it operational is that knowledge accumulation is kind of thing that is never done. It simply never stops. Which, it seems, is what makes it attributable to team ops work.
Tactical decision-making
Say, three people on the team are working on three separate things, and one of them gets stuck. Team members like to support each other, and so one of the other two teammates lends a hand. Which one?
To answer this question, the team needs to decide which of the two other things that were being worked on is less urgent. Or less important. To make this decision, people need to be aware of the context and of the immediate priorities. In a team where everyone is well-informed about priorities, making a choice like that is easy.
Now, what happens to the upcoming work? Does it impact the prioritized list of tasks in that are coming up? Does this all mean the team will need to sacrifice something to salvage part of the work?
Since most of the time the team in execution mode deal with smaller work items, reordering them in response to circumstances is a relatively tactical thing: few alternatives, limited range of consequences, simple choice. Which makes it part of team ops, too.
Representing the team to the org
A lot of non-production work, that is, the work that is not directly contribution to creation of the customer value, goes into representing the team to the rest of the organization. This might be an attempt to align interests and roadmaps of 2+ teams, or it might be showing off the results and lessons learned at an org-wide meetup.
Whatever it looks like, it’s always at risk of being considered secondary, unimportant. And this might as well be true sometimes, while under other circumstances it can make or break the team’s reputation and how seriously their achievements are taken by the organization. Which, depending on the way the org operates, can be anywhere between inconsequential and crucial.
Part of this work is giving information to people outside of the team that they need (which might not be exactly what they’re asking for, but that’s for another story), in the amount that’s going to be most useful to them, and all of that in the language they speak.
A lot of folks don’t perceive this as work, nor do they often think skills needed to do this work, but this really is (quite hard) work that can easily be left unnoticed due to its ephemeral nature. Which, again, makes it fit very well into team operations.
The problem with the team ops work is that it’s rarely recognized. There might be formal expectations that emphasize skills (communication; being able to deliver a message effectively) or behaviors (cooperation; reaching out to people if their input is needed), but putting a finger on it and claiming success is really hard. “Thank you for all the work you have put into not letting it all slide downwards” is something that managers say rarely, if ever.
As an engineering manager, you should accept the challenge of turning non-promotable, unlikely-to-be-recognized operational work that the team members do on a daily basis, and turn this into formal praise that is aligned with the org’s expectations and needs and recognized as real by your peers, other engineering managers. Conversely, if this work is not being done, if some folks on the team aren’t pulling on the weight, it should be part of feedback you give them.
