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 personally found that you cannot really measure development performance much more than hand-waving.
A much more effective approach is to find somewhere that each member of the team can have a stake in something and be engaged. Make someone in charge of teh CI server or the deployment server or Git practice or coding challenges. It is much easier to see how people are performing then.
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 individual or forced from the outside. If a member of the team can't achieve a goal, then they need differents goals.
I set the standards to be low and universal, while the goals are high and person-specific[1]. I'm thinking objectives could be thought of as "parts of standards that must be met at a later point in time but now now"[2]. But I'm still figuring it out. I think material about education is relevant, and helps to avoid easy, versatile, and deceiving thought-terminating cliches like "expectations".
The problems with (personal) goals is that it's really hard to both define good goals and measure them. And if you don't you make things worse for good people.
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.
The way I read the article is that it talks about management performance not performance of the team being managed. These two things are regularly conflated.
Yes, engagement has a direct impact on the performance of individuals, and managers are responsible for creating an engaging environment - which shows why individual, team and manager performance are hard to disentangle.
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 ?
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.
Engineering manager efficacy is easy to measure. Did the team ship on time or not? You can argue about the metric and challenge whether or not its appropriate but at the end of the day thats mostly what teams care about. Everything else around hiring, retention, planning, okrs, etc, etc are all about building a resilient and predictible system in order to achieve the goal of generating more revenue.
If you force people to meet a metric, they will. Features will be cut left and right and quality will suffer when shipping is the only goal. A story as old as time itself.
Yeah and also in a significant amount of cases, the real job is expectation management around downstream dependencies and timeline. Arguably the only true metric is "was anyone surprised at the engineering deliverable in time and quality" IMO.
MintingOps (n) creation of new words by dressing them up with a postfix "Ops"
The piece is not about operationalizing decision-making, how to make decisions in ops, or even about which elective surgeries I should choose. It's an incoherent grab bag of management ideas.
Management ideas always sound incoherent for the reason in the article; there are no standards and it is seen as an art. The article is attempting (May be unsuccessfully to add some structure). Point is conceded about conflating people management vs decision making. They overlap (ie same person might be responsible for both), but are independent disciplines
Now, seriously, I find the various Ops way of seeing things refreshing. Usually it's just a repackaging of old ideas, but hey, half of infrastructure is packaging. So go for it.
If I get to avoid urgent work to make room for important work and the company has my back cause we are implementing "DecisionOps". That is fine.
This would be similar to “cannot push release because builds are broken”. These rules become useful only after critical level of agreement and adoption
> 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 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.
> 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.
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.
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.
26 comments
[ 4.8 ms ] story [ 62.9 ms ] thread1) 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 personally found that you cannot really measure development performance much more than hand-waving.
A much more effective approach is to find somewhere that each member of the team can have a stake in something and be engaged. Make someone in charge of teh CI server or the deployment server or Git practice or coding challenges. It is much easier to see how people are performing then.
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 individual or forced from the outside. If a member of the team can't achieve a goal, then they need differents goals.
I set the standards to be low and universal, while the goals are high and person-specific[1]. I'm thinking objectives could be thought of as "parts of standards that must be met at a later point in time but now now"[2]. But I'm still figuring it out. I think material about education is relevant, and helps to avoid easy, versatile, and deceiving thought-terminating cliches like "expectations".
[1] https://apasseducation.com/education-blog/3-differences-cont... [2] https://dataworks-ed.com/blog/2014/07/how-to-craft-a-learnin...
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.
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 ?
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.
If you have witnessed, or even just heard of, properly functioning HR, please share your story.
So... OpOps?
If you force people to meet a metric, they will. Features will be cut left and right and quality will suffer when shipping is the only goal. A story as old as time itself.
The piece is not about operationalizing decision-making, how to make decisions in ops, or even about which elective surgeries I should choose. It's an incoherent grab bag of management ideas.
Now, seriously, I find the various Ops way of seeing things refreshing. Usually it's just a repackaging of old ideas, but hey, half of infrastructure is packaging. So go for it.
If I get to avoid urgent work to make room for important work and the company has my back cause we are implementing "DecisionOps". That is fine.
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.
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.
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.