"Those who were followers; who lacked discipline, failed faster and more obviously."
Classifying one's reports into "top performers" and people who "lacked discipline" or "followers" betrays a categorical mindset very eager to bucket people rather than see the contradictions and subtleties of people's individual situations and work towards helping to resolve the difficulties, which is what leadership / management should be about.
EDIT to put it another way: good parenting (which I don't always practice, BTW) doesn't say "You're a bad boy", they say "You did a bad thing." Likewise when talking to oneself, it's really shitty to say "I'm a crappy X [engineer/painter/swimmer]".. it's far better to say "I did X poorly last time." A good engineering manager should help frame things this way, and shouldn't be saying "top performers" and "followers" but, instead: "people who performed well" and "people who tended to be behind or 'follow' in the last quarter" and help the latter identify how they can do the former (note: not be, but do).
We were in a global crisis. People were at home with their young kids, spouses, dogs, whatever distractions. Empathy and flexibility were required to make this work. "Failing" at work was probably the least of concerns for many people, given everything that was going on. I personally quit my job rather than deal with the guilt of having spent time getting my son to do his school work rather than triaging bug tickets. Others could not afford to do so.
For one, we ensure everyone commits and delivers and holds others accountable for failures. What you’re describing is not a measurement of performance, I see your point though.
I too very much disdain “team bonding”. But the point is to get to know and respect each other. By doing so you’re more likely to hold yourself accountable.
In terms of performance there’s two parts:
1. How much you commit to
2. How much you deliver on commitments
We expect 100% on #2 or explanations and plans to adjust. On #1 we expect that to change as you increase through the ranks. Junior members don’t need to commit to as much, senior more and staff should commit to a lot and help the junior.
Top performance is learning what you can accomplish and delivering, communicating when you’re having trouble, and then ensuring improvement over time in terms of committing to more.
So if I were looking to join your team and you said this it would be a huge red flag. Why? Because it's not easy or everyone would've done it already. The fact that you think it's easy really would be a cause for concern.
> For one, we ensure everyone commits and delivers ...
First sentence in and you've already added a qualitative factor. For a given task, is it "enough" to meet team expectations? This depends on how difficult it is perceived to be. Maybe there's some huge unknown unknowns. Maybe it's just really tedious and is real time gated for some reason. The standard retort is "we take that into account" but again this conflates subjective perception with objective truth.
Some people talk a very good game about how hard their job is and I've seen some very senior people skate because of this and the fact that for whatever reason they're liked (by management).
You expect 100% delivery on commitments. How is that not going to just reward under-promising? it also leads to things being half-assed. Bugs closed as "could not reproduce" or "working as intended". Features being just good enough to ship without the massive problems surfacing later. Hell, that's just another opportunity for more impact.
Further and to clarify, I said it’s fine if you can’t complete a task due to some unknown. Vocalize it to the team and update accordingly. It won’t be held against you if you if you collaborate to get it resolved. If that happens every time, there may be an issue, but typically people learn to investigate before committing.
Expecting people do what they commit is the only way to drive people to success. As I said, there are two factors, how much you commit to and how much you deliver on commitments. If people want to move up they have to commit to more AND deliver more over a 6-12 month period. Failure to deliver on a regular basis means you should commit to less. In either case, it’s easy to measure objective results.
Comments like these are red flags for me, because pushing back on estimates or communication is not going to go well. Your job is to produce results, if you fail, but ask for assistance that’s one thing. We can plan around that. If you fail and don’t request assistance that’s another. It’s about promoting solid engineering and development, keeping delivery timelines, etc. This worked on the remote places I’ve worked, might not be a great fit for you idk.
In terms of bugs, that’s more of an engineering culture. We always had strict and thorough PR reviews. High test coverage, formatted code with comments and two reviews from at level or more senior engineers.
Take someone who points out flaws in a system, things that need to be addressed before they become a problem. The exact same words from two different people can be interpreted differently. For example:
- "X is a top performer who anticipates problems with their deep understanding of the system"; and
- "Y is negative and simply points out problems rather than offering solutions."
The difference? Whether or not that person is liked, which really comes down to them being like me. That's literally all it is.
Take your example of "fun" days. Personally I hate that kind of faux team bonding. I mean if it works for you and your team then great. But don't be fooled. You haven't found the formula for "top performers". You've just found people like you.