[HN Gopher] DecisionOps: Effective Engineering Management
___________________________________________________________________
DecisionOps: Effective Engineering Management
Author : sharatsc
Score : 44 points
Date : 2021-08-19 14:56 UTC (8 hours ago)
(HTM) web link (decisionops.substack.com)
(TXT) w3m dump (decisionops.substack.com)
| sirmoveon wrote:
| Sounds like the brogrammer of the devOps
| lbriner wrote:
| 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.
| underwater wrote:
| All four of your hard questions are effectively the same.
| Measuring and improving performance is one part of the job, but
| it's not the only part.
| tonioab wrote:
| 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 ?
| edderly wrote:
| 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.
| chambers wrote:
| 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".
|
| [1] https://apasseducation.com/education-blog/3-differences-
| cont... [2] https://dataworks-ed.com/blog/2014/07/how-to-craft-
| a-learnin...
| sharatsc wrote:
| Agree. Moving individuals from execution to ownership unlocks
| intrinsic motivation that far exceeds any external incentives
| goodpoint wrote:
| If we could stop adding "Ops" to every word...
| srswtf123 wrote:
| 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.
| xcambar wrote:
| Your comment calls an off-topic question/comment (off-topic
| to OP):
|
| If you have witnessed, or even just heard of, properly
| functioning HR, please share your story.
| otabdeveloper4 wrote:
| > I worked ... in operations
|
| So... OpOps?
| chrsig wrote:
| That'd be detrimental to the EgoOps everyone has adopted to
| help them feel like they're part of some special forces team.
| [deleted]
| dasil003 wrote:
| > _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.
| vosper wrote:
| > 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.
| tharkun__ wrote:
| I simultaneously agree and disagree with you :)
|
| 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.
| sharatsc wrote:
| Thoughts on (software) engineering management.
| thinkingkong wrote:
| 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.
| deegles wrote:
| > Did the team ship on time or not?
|
| 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.
| sharatsc wrote:
| Exactly.
| https://www.psychologytoday.com/us/blog/machiavellians-
| gulli...
| aplummer wrote:
| 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.
| iamcurious wrote:
| Ops is just one letter away from Oops.
|
| 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.
| sharatsc wrote:
| This would be similar to "cannot push release because builds
| are broken". These rules become useful only after critical
| level of agreement and adoption
| drewcoo wrote:
| 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.
| sharatsc wrote:
| 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
___________________________________________________________________
(page generated 2021-08-19 23:02 UTC)