It’s one thing to suffer from a blinkered, reductive view of the world. It’s another thing to be proud of it.
It’s one thing to suffer from a blinkered, reductive view of the world. It’s another thing to be proud of it.
A good engineering team has measurements in place that are reasonable approximations, where it is reasonable to build them, but also treats them as prompts rather than absolutes. Asking "why is this metric out of band?" is infinitely more valuable than stating "this metric is out of band, we've failed".
It's a totally valid and common jargon phrase from the web services world, apologies though, I assumed that it was wider jargon than it turns out it is...
Team member says they are feeling less creative because their kid is having bullying problems in school.
"Can't measure the creativity, can't measure the bullying... Can't manage this situation, sorry"
To put it differently—measure what you can; trust your feelings on the rest.
You can measure many, many things. Instead, you should measure things whenever they are good proxies for the outcomes you want to drive AND there is good cost benefit in measuring+analyzing them.
Surprisingly few things meet these criteria.
I was simply pointing out that many situations can't be solved through metrics. In my experience, the best managers try to solve most problems without metrics, but always insist on them in places where they are valuable.
In other words, they use metrics as a tool and make metrics work for the team instead of the team work for the metrics.
Given a choice between two metrics, managers will usually choose the most gameable, indirect, activity-oriented metric, even if it is far less useful for driving results.
And I can’t blame them. That’s the game. They have to make a number go up, their boss also has numbers that need to go up, and so on. In the worst cases, everyone is complicit in creating a forest of bullshit numbers that went up even while the company tanked.
Managers who react to known signals in predictable ways are strategically better than managers who just make stuff up on the day in unpredictable ways.
The alternative is to do the thing that doesn't scale, because all the purported ways of scaling are worse than that.
Many of the most important decisions do not have quantifiable outcomes. How many incidents did this architecture or refactor prevent? What cultural effect would that person we didn’t hire have had over the next year?
At least in early stage or growing startups, I think if every one of your actions is measurable and fully specced, you’re in trouble.
Yeah, but that is explicitly not managing them. That is the standard "I can't measure this situation, therefore I will not attempt to manage it" response of a good manager.
I am responsible for the outcomes of my teams, full stop. I am responsible for the growth and development of the engineers who report to me.
If that means sometimes standing back and letting the cook, then that’s the right thing to do. I’m not here to involve myself because otherwise people will ask “well what are you doing??”
(The answer to that is that the more independent teams can run at a high velocity of quality output, the fewer managers your company needs. That is good!)
Management is about controlling the outcomes. Nobody could claim to be managing a situation well if they are responsible but exercising literally no influence over the process. If the manager could be replaced with a garden gnome and it doesn't change the outcome then the situation is effectively unmanaged.
We seem to be in furious agreement so I don't know why my perspective is eluding you. You're looking at a situation that might have an outcome that is unacceptable. You've identified that there is no measurable way to assess progress or quality. You've concluded that there is nothing you can say, do or observe that will help. The situation is then left unmanaged because there is nothing to measure and you're waiting for something you can measure before you act. This is the basics of management, what you can measure you can manage what you can't you can't.
It just happens that in the small software is unmanageable, as quickly becomes clear if you have management experience of a non-software process and compare it to managing a software team.
At the same time, nearly all of us can identify developers who are highly, highly productive, and others who are not. We may not have great metrics for software productivity, but I can guarantee that Fabrice Bellard is about 100 times more productive than I am.
Metrics are inherently an oversimplification in attempt to get complex phenomena down to a strictly ordered value, but the real world doesn't work like that. I think your mistake is thinking that just because things can't be reduced so a small set of numbers would also mean they can't be observed, and that isn't true.
I’ve seen several teams fire less productive coders and then the team fell apart into individually good coders.
That teams require a blend of capabilities and personalities is anathema to the “everyone a widget” mentality of most corporations — but remains persistently true.
For me, the answer is no. Perhaps for you the answer is yes.