21–27 of 27 posts
If we could stop adding "Ops" to every word...
The last company I worked at renamed every department in this fashion. Sales? SalesOps. HR? PeopleOps. I worked ... in operations. We didn't get a shiny new name. But then, we actually did WORK, which had to continue at the datacenters -- not just get drunk on Zoom, like "PeopleOps" did.
So... OpOps?
It doesn't really answer any of the hard questions. There is nothing particularly controversial but the hard questions include: 1) How do you actually measure performance? 2) How do you deal with performance and variance in individuals? 3) How do you set an acceptable performance level? 4) How do you make allowances for external disruption that affects performance? With more than 3 years in management, I have persona…
It doesn't really answer any of the hard questions. There is nothing particularly controversial but the hard questions include: 1) How do you actually measure performance? 2) How do you deal with performance and variance in individuals? 3) How do you set an acceptable performance level? 4) How do you make allowances for external disruption that affects performance? With more than 3 years in management, I have persona…
Measuring development performance at the individual level is futile given the collaborative nature of the work and its complexity. Team and manager performance are more tractable.
Team performance is highly influenced by external disruptions, which is why the culture of engineering management since the 1980s has been centered around "removing blockers". Focusing on building a smooth-running operation (good hardware and software, fast code reviews, fast deployments, minimum amount of meetings, etc.) is probably what this article means by DecisionOps.
Re: managers, one formula I've used in the past (inspired by Andy Grove I believe) for managers' performance is a combination of the following: how is their team delivering ? How are they helping neighboring teams deliver as well? Do people want to work for this person (internal transfers + hiring) ? Or do people want to leave this team ?
Let me stop you right there. This is cargo cult bullshit. The Agile Manifesto said "Individuals and Interactions over Processes and Tools", and they said so with good reason.
As an engineering manager your cardinal rule is to maximize velocity towards whatever higher level goal you are given without burning out the team or causing other long-term fallout. All else being equal, this means clearing as much time for ICs to do work, and adding only as much process as necessary to avoid doing the wrong work. Of course you also have to manage the emotions of the team, and deal with all the shit flying around sideways and upwards as well.
So how do you do this? Well, that's a hard question, let me start by saying what not to do. The first thing is definitely not to reach into your trusty bag of tools and pull out a predictable and reusable framework, especially one with a lot of thought leadership behind it with abstract promises of "impact" by someone who doesn't even know what business you're in.
No, the first thing should be to assess your situation: what are the goals, who are the players, how are they feeling, what are the major challenges, etc. Only from that starting point can you have any hope of putting together a sane process. And once you do you should not settle too deeply into the comfort of a familiar rhythm—yes regular cadences and rituals can be a huge boon for your team's productivity, but as manager your job is to be constantly surveying the landscape and seeing if there's a way to do better.
> Practices such as agile, DevOps, MLOps, and AIOps are introducing reproducible operational tools that add rigor to the discipline. Let me stop you right there. This is cargo cult bullshit. The Agile Manifesto said "Individuals and Interactions over Processes and Tools", and they said so with good reason. As an engineering manager your cardinal rule is to maximize velocity towards whatever higher level goal you are…
This is great, but you also don't want to keep changing things. A predictable, well-understood process can be valuable even if it's not optimal, because the people involved don't have to think, and everyone understands where something came from and can have reasonable expectations about where it's going to.
> Practices such as agile, DevOps, MLOps, and AIOps are introducing reproducible operational tools that add rigor to the discipline. Let me stop you right there. This is cargo cult bullshit. The Agile Manifesto said "Individuals and Interactions over Processes and Tools", and they said so with good reason. As an engineering manager your cardinal rule is to maximize velocity towards whatever higher level goal you are…
> No, the first thing should be to assess your situation: what are the goals, who are the players, how are they feeling, what are the major challenges, etc. Only from that starting point can you have any hope of putting together a sane process. And once you do you should not settle too deeply into the comfort of a familiar rhythm—yes regular cadences and rituals can be a huge boon for your team's productivity, but as…
I can attest to the fact that established processes can be really great to deter obnoxious behavior and shut people up that are annoyingly trying to just push their own agenda on you. "there's a process for this, use it and stop bothering me".
Processes can also help with repeating tasks that benefit from being done the same way over and over but that can't be fully automated. Like a release process (not the very automatable parts of it, those should just be fully automated obviously).
Having a non changeable process in changing situations is horrible. Especially if the process actively works against you or how you do your work best. The process needs to be flexible. People and interactions over processes and tools.
It doesn't really answer any of the hard questions. There is nothing particularly controversial but the hard questions include: 1) How do you actually measure performance? 2) How do you deal with performance and variance in individuals? 3) How do you set an acceptable performance level? 4) How do you make allowances for external disruption that affects performance? With more than 3 years in management, I have persona…
A comment more useful than an entire article. Personally, I try to judge performance using standards and goals. To me, standards are a clear, agreed-upon baseline that every member of the team must meet. They're not what we preach, they're what we tolerate. It is intolerable if a member of the team doesn't meet a standard. Goals on the other hand, are what we hope for; they cannot be "lived up to", coerced on an indi…
Example: the goal for someone is to build feature X. Now, they could tremendously help the company by answering the questions of another developer for feature Y, but that makes them look worse when it comes to evaluation of their goal because it's less time they can spend on it.
Now, you can also set a second goal of "be helpful" or so, but how do you measure that?
And so on. In the end, goals might be good to get a better performance out of unmotivated/lazy folks, but for motivated/engaged folks, it's the opposite of being helpful.