As some of you may know, I keep track of the employment notices down at the bottom of the footer bar of GOG. It's a hobby, I guess. Sort of a way of keeping track of the health of the company by seeing how long it takes them to attract a worker or pull down a posting.

On the posting for the senior engineer position, there's this curious passage: Now, maybe I'm exactly the opposite mindeset to be working in management because I feel employees are self managing if given a few simple objectives, but then again, I've never found myself in the kind of environment where I'm doing TPS reports or other pointless busywork that could be automated in the form of a bash script.

I'm also against managers in most cases, as I feel they are the chaff of the workforce to the laborer's wheat.

But the question is, why is GOG expecting metrics that the average layperson, much less anyone outside of accounting & marketing would know a damn thing about? I tried looking into DORA, but I found my eyes glazing over due to too much buzzwords and not enough information. It was all management speak with no BLUF.

As for SPACE? Who knows. Maybe solution space? Feasible region? Of course, neither of those map onto the acronym implied by the capital implication. Seems to be more new age Agile software development woo. I tried to get an idea, and just rolled my eyes harder than I have recently, audibly groaning.

Just ask if your teams are happy, is that really so hard to ask?

Because they keep running away?

The DORA page you linked to has a link to the SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency).

FWIW, I think that DORA is a bit self-aggrandizing ("DORA’s research has repeatedly demonstrated that" e.a.), and it should capitalize, bold and underline the first of its common pitfalls ("Setting metrics as a goal"), but I also see a lot of common sense on both pages.

Same as with agile, in the wrong hands (which admittedly can be found at the majority of enterprise-scale companies, where the people talking about and implementing these things don't have actual development experience) it'll become a perversion of what it stands for, but with actual understanding and a light touch, it could help direct thinking in directions where things can improve ("Individuals and interactions over processes and tools" was really quite a fundamental insight, and having a framework which points out that e.g. "Lack of interruptions" is directly correlated with efficiency could do a lot of good, too).

Also, this is a responsibility for the Engineering Team Lead: That is quite different than engineers being asked to chase metrics. If this team lead does their job well, they'll guide the development of tooling and take away useless red tape for their development team, which will cause these metrics to improve - without the developers ever having to be aware of the metrics. (While a bad team lead would indeed put the metrics front end center and make it the responsibility of the developers.)

(In another life, I could nearly see myself applying for the position.)

This sort of thing just advertises the reason any company is falling apart.

Like a reality version of the film Office Space.

Nobody sane, knows what these things are, as it really doesnt matter to a game selling company.


What does matter is how much time will someone realistically spend a week doing what some of us regulars do for free. Like right now, on forum. A bunch of us vet games, scope the horizon for more content and review games for our interests. spreading word of new and old treasure.

Hell, what gog needs is SplatterCat from youtube. Cripes, he even does the work for gog....do staff hustle for new devs? No! Courting would be great. Who know, maybe hell will freeze over and this will be their next job opening.

Professional Court Master
Duties include watch SplatterCat and go court the developers!

Yeah if I was running GOG, it would be the coolest place on earth, and would make shitload of money every minute!

I would do this and that and everything in between and beyond! It is easy when you know how, and I know how. It means the same as "by what means"?

That last bit right here, this also implies the management is smart enough to leave well alone, instead of forcing the metrics first. To acknowledge, or even dare engage with the metrics at all as anything other than a pseudoinvisible number that you give the occasional unsteady glance at is simply a losing proposition.

Rarely if ever have they been set to realistic numbers to account for everything that could possibly go wrong, from malfunctioning hardware to Steve having the flu.

In 100% of the enterprises I worked for (as an engineer) that imposed such metrics, it was because managers used these to decide who is or is not a good employee. As obviously, clueless as managers are, they could not judge that from actual work.

To be fair there is only one single good way to handle management: don’t. No exception. Fire all managers, and everything will run much smoother. And as a bonus, turn-over has good chances to be reduced a lot too.

Beacuse audit culture and performativity (in the postmodern condition sense)

I don't disagree with any of this - but all of this seems besides the point to me. The job application for the team lead is outlining _their_ future responsibility for "end to end" ownership of product delivery. That is, the team lead will be the only person who gets a say in how things are accomplished (no higher management undermining them) with regard to delivering features for the website. And this team lead will also be responsible for making the team more efficient in being able to do so, based on some actually pretty reasonable way to measure this efficiency. They're specifically looking for someone with development experience for this lead position, not a "manager" type.

All of this is a far cry from management forcing engineers to chase metrics. It's maybe setting an unreasonable goal for the team lead, depending on the current situation (both process-wise and for the code base), and if they hire a bad team lead, eventually the developers might suffer from this type of goal setting - but I'd say that anyone actually qualified for this position should be able to meet the very low bar of expectations just by having some current manual steps automated (causing the numbers to improve), and might accomplish a lot more by gradually improving team skills, setting an example with focusing on code quality and reducing dependencies, smoothing out the planning process, etc.

These metrics have a higher chance of protecting the developers against a bad team lead (by e.g. preventing a micro-manager or constant-meeting type from causing lots of interruptions), then of doing harm.

GOG should use common business sense and make sure the customer walks away satisfied as then they will advertise the place for free and almost certainly also return. Things like spamming emails, can thankfully be turned off, makes me want to run away and never return. Fixing this shop will certainly not pay back in the short term.

Metrics focused management has one goal and one goal only: generating artificial 'value' numbers for the stock trading game. These numbers have an influence on the valuation of stocks, as long as stock holders believe in them. And so they are the fuel to stock trading and stock holder profit.

Actual company health or quality of products has become irrelevant to stock trading. Which is why so many company are mismanaged and are bled dry in the long run for some short term profits.

I agree with OP / Darvond.

I don't have much to add except some of the software enterprises' devs / engineering managers have their heads so far up in their asses when they bring in these 'revolutionary' consultants and their project management systems, they've effectively lost sight of the trees.

I'm glad my engineering field doesn't have to deal with that bullshit.