It's so easy to conflate "top performers" with "people like me".

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.

Totally agree, and it's the kind of language that rings alarm bells for me especially when coming from a person with a manager role.

"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.

It’s not hard to implement a system which measures success.

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.

> It’s not hard to implement a system which measures success.

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.

You’re correct nothings perfect, but these systems are really easy to develop. That said and as I already stated, most people are mediocre. Same goes for management. I see lots of talk and little delivery. It’s the whole reason YC invests in founders that “get something shipped” is a thing. People don’t move fast, they talk, they mess around, they don’t commit and deliver. Same for managers as engineers.

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.

I do not think that is entirely true at all - I am definitely very well liked at my job and probably most people would say I am also not like them at all.

Nobody is conflating Steph Curry with 'someone like me'.

+50

> I think anyone who can’t work well remote, on average, will not be your top performers anyway.

I don’t think that’s the case at all. One could say a similar thing in that it enables the worst employees who can drag down so-called top performers. But I don’t like any of these framings.

I personally prefer working in the office. I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having. I’m able to attend talks, have discussions, etc., which get me going on certain ideas. I am a person that doesn’t work well in ambiguity. I like to have a plan discussed and agreed upon. I find this is much harder remotely, for reasons both known and unknown.

Very few deep conversations happen over Slack. I miss some of the deep conversations I used to have with fellow coworkers on slower days. You are also very limited to the type of work you can do. Basically any job requiring hardware interaction requires you to be in office, either by natural constraints or policies.

But I am also like the commenter above. It will be really hard to give up remote work. The convenience of not having to commute, dress a certain way, have my own food in my own kitchen, etc. are all massive perks. At some point, I may choose to go back into the office, but I’m going to do the remote thing for a while. Especially now that gas is insane.

>I’m more productive, focused, and able to check in with someone or go grab them and show them an issue I’m having.

I think there's an important distinction here. It may be more productive for you but not necessarily for the team. You grabbing another employee may increase your productivity but subvert theirs. Anecdotally, my personal productivity goes way up when I work remote because I don't have all the "drive-by" questions that erode my focused work time. Whether or not that makes the team more or less productive may be a factor team dynamics and contributions.

At the same time, being able to maintain productivity while handling questions is a skill in of its own. I work on a team building/maintaining internal tools/infra and a large part of my job is interfacing with other teams and maintaining productivity on my own work at the same time is a big part of my responsibility.

So it cuts both ways.

I don't think that's a distinction, and it definitely isn't one way because the you here will also be interrupting the team. All this gets into team dynamics, which can't possibly be whittled down to such small interactions.

Then there's this somewhat weird obsession with people supposedly being unable to perform their job without 8 hours of uninterrupted solo time. The work day isn't supposed to just be each person working solo trying to accomplish as much as possible. Interacting with the team is being productive. Extremes in either direction are likely not productive.

I agree that team interaction can be productive. (I might even be a bit cynical in saying that most team interaction is not, but that might be a digression). I think the distinction is in how the work culture manages those interactions. My previous job wanted open-door policies; what that turned into was a poorly managed ad-hoc set of interactions. Open door interaction tended to foster unproductive venting and it can become like corralling cats to refocus that energy into solving problems. That may be fine for a supervisor; it's probably not the best use of time for front line production person.

I think I may disagree about the "somewhat weird obsession" with uninterrupted work. (I'm assuming your '8 hours' was hyperbole). The research seems pretty clear that interruptions are more detrimental to highly focused work. I don't think it's unreasonable to expect certain blocks of uninterrupted time if the type of work requires it, but that shouldn't be conflated to someone expected to simply be left alone all day.

> I think anyone who can’t work well remote, on average, will not be your top performers anyway.

This sort of overgeneralization just tells me we'll have people in 5-10 years "realize" that many of the benefits of remote work were just built on relationships and processes created in the days before. It's like the "open office" floor planning all over again, but with higher stakes.

In defense of remote work underperformers in general, I work for a company with a lot of tribal knowledge. It shouldn't be that way, but that's how the company operates and our pleas for time/money to write adequate internal documentation fall on deaf ears (doesn't help that it's legacy software so there's not many people capable of writing said documentation). Result is there are a few wise old (as in 15-20+ years experience) veterans who know the "deep magic" of how the software works, but they also tended to be the least available online during our year of WFH (with some exceptions).

In the office the culture for accessing these guys was: Ping with slack DM/skype, if they don't answer in 15 minutes walk over to their desk and bend their ear, unless they were clearly working something more important at the moment. Sometimes there would even be short lines of people outside of their cube waiting for attention.

There was an organic interrupt-driven workflow for these experts because they were in so much demand (with occasional pauses in access if they were working on something time-critical). That whole workflow collapsed under WFH, and as these veterans were used to operating on their own/managing their own time roughly half of them failed to be readily available online. This led to issues for people like myself where we needed some piece of their knowledge but just got radio silence for hours, sometimes days. So you pick up some other work to fill in the gap while you wait for a response, but that leads to inefficiencies of its own once they actually do get back to you. Once I had a cascade of about 6 stories going in parallel because I kept picking up alternate work to fill gaps, only to get to a point in THAT work where I needed some tribal knowledge, so I pinged the appropriate SME, waited several hours, picked up another task in the meantime... etc

And leadership lacks any carrots/sticks to make these guys accessible aside from asking nicely. They're largely where they want to be for their careers, value their time, and have all the truly vital knowledge so they can't really be punished lest they leave the program.

Sadly I suspect my company's organization is closer to the average than yours, so lots of other companies fall into this boat. It's not always a matter of discipline :)

I've seen this pattern recently outside of software. This kind of "tribal capture" lead to mediocrity and nepotism. The untouchable tribal leaders fostered an environment where unpleasant roles were left understaffed until 'lower people' were subtly manipulated into taking them, who then left. It created a revolving door of staff that otherwise would have made good contributions. Management in response to the turn over, shut down critical thinking about the staff and just committed to the problematic structure.

Yeah that accurately describes my workplace as well. The revolving door of "lower people" you mention is very real. I'm one of those "lower people" and I've definitely been shifted into the work no one else wants. To be fair I was fresh out of college and took the "volunteer for the work no one wants to earn respect" route, and it did earn me some respect, even a promotion and a pay bump. But after a couple of years of trying to push further it's clear there's a ceiling, and my only chance of doing any of the interesting work is waiting for the old men to retire/leave, and then I'll likely be dumped into the deep end to figure things out myself, under extreme time pressure because critical stuff's breaking and I have 25% of the knowledge necessary to fix it, which makes me the remaining program "expert" :P

I'm sticking around for personal/defensive reasons (it's stable and recession-proof, and I have a one-month old so moving would be extra stressful for the family), but I doubt I'll stick around for more than another year or two. My turn for that revolving door is coming up

Interesting. This aligns with my past experience as well. If I may ask, are you / is the company working on rectifying this, and if so, how?

What we did was that we made our internal docs and agreed that whenever we were blocked by something, once we learned it, we would document it. It was a mixed success though because we never had time to work on the docs properly, and the veterans didn't touch it, so I'm curious if there is a better approach.

Yeah we're trying to do the same, document things organically as we learn them on an internal Confluence. It helps, but we're piecing together fragments of knowledge without context, so information density is low outside of specific tasks. It's enough to solve the same problem again, but not enough to gain much holistic knowledge of the software. And same as your situation most of the veterans don't bother with it (they already have the knowledge and are extremely busy).

Doesn't help that some of the engine code dates back to the late 80s, was originally written on a mainframe for a compiler where variable names had character limits, so even if you know the surrounding conceptual terminology it's functionally indecipherable unless you have a lot of experience with it. It's hard to tell what it's doing or why, or even if it's relevant to the problem you're trying to debug.

What we really need is something like a dedicated sprint where we stop the presses outside of critical maintenance and just write documentation, free up the veterans to write down their knowledge. But that would require the company to actually invest in what is otherwise seen (wrongfully IMO) as a cost-center. :P

And honestly if we had that kind of money there's other software redundancies/inefficiencies that need to be resolved first, that would lower the documentation requirements in the first place.

I hear you! Thanks for sharing.

Utterly nonsense. How about children learning from home via a laptop? Doesn't work. Same for people who need to be trained in a new work environment. You want real interaction. You need to experience more than only sound and video in order to learn efficient. It's extremely wrong to think that good performers can always do these things from home. Not right.

I joined my company straight out of college and it was during covid peak, it was totally remote and guess what, last week my manager called me and told me that I've been promoted with a salary hike(within less than a year).

If you've discipline and commitment you can make anything work. :)

Agreed. I've line managed people who have grown immensely during covid. I think the key is understanding the new medium... A remote office where conversations are encouraged to happen in the open and not by DM, is a better environment for juniors to learn than an office where there's closed rooms and knowledge moves in a more hierarchical way.

Congrats, but do you ever wonder if it would've been faster/easier in person?

I just want to note that my experience is the exact opposite of this in every regard.

I suspect it depends on age and class.

My 5 year old struggled and needed a whole bunch of support.

my 8 year old was able to work on her own, but still didn't get anywhere near as good learning outcome as being in class.

Now, the reason why my kids didn't fail utterly, was because my wife wasn't working and could, just about support their learning. Until it sapped her will to live.

This is roughly analogous to junior employees. They need special attention, and providing that over remote is a challenge to scale. Not impossible, but a challenge.

You also need to factor in that Junior employees are more likely to have shit accommodation.

Yeah, we did remote kindergarten and it was basically a disaster. We were lucky that my wife could help, otherwise our kid would have learned nothing.

Your experience as a child learning from a laptop?

On that topic, no, I am referring to observing my own children learning from a laptop. I could not have been more skeptical of this approach at first. I was wrong - the approach has worked well so far.

EDIT: I definitely should have mentioned that my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!

> EDIT: I definitely should have mentioned that my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!

lol Pretty big caveat

>my children are learning from a laptop WITH very close guidance from my wife who is raising them full-time and with intense dedication!

In other words, they are not at all just learning from a laptop.

Sounds like your children are actually learning from your wife.

My experience is that unsupervised education is worthless.

Nope. Personally I could not disagree more.

I studied CS pre pandemic at a regular university. The whole curriculum was designed around lectures and in-person classes. But I skipped most of them due to social anxiety and laziness. Because every class had a digital script and I could practice with old exams, I did fairly well. Even better than most of those guys that visited every lecture. I guess that part of the problem is that some students tend to think, that just visiting the lecture is enough. They forget to practice the stuff on their own. Which you do automatically if you work through the script all by yourself.

After university I dropped right into my first job. Because of the pandemic it was 100% remote. Again, this worked perfectly. I could not have been any better. I even was able to take additional responsibility due to my performance "which exceeds expectations".

So calling this nonsense is nonesense ;-)

Have you considered not hiring children?

I learned largely via laptop until Grade 8 (am 25 currently). I wasn't behind when I transitioned to regular school.

I suspect it works for readers, not audio consumers.

Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.

I hold myself to high standards and have been described as a top performer by every manager I've ever had.

I am disciplined and work extra hours as needed to ship. I am constantly thinking about the product and the engineering challenges we face outside of working hours. But sometimes things take longer than expected, sometimes complexity estimates are off, every so often I have a bad week due to personal reasons. Having to conduct a team-wide postmortem every time a ticket rolls over into the next sprint sounds exhausting and I'd start looking for a new job stat. At a minimum it's a huge amount of communication overhead when you should trust me to get my job done, especially considering my track record.

> Your management style sounds like it would rapidly kill creativity and innovation, psych safety, and codebase quality.

Couldn’t be further from the truth. I ran an applied research team for years. We had hundreds of patents, multiple publications, a growing open source project, multiple presentations a year, delivered a couple of the highest priority projects, and were consultants company wide for deep learning.

I was always fine with delays, but you had to discuss them and collaborate. Come to the team, explain, then we could prioritize accordingly (5 min). It’s not a big deal, but always required high communication. That’s difficult in a remote environment, but that’s why you have regular meetings & have to be more strict than normal about planning.

Perhaps it wouldn’t be an environment for you, that’s fair. But a project isn’t about you, it’s about a deliverable; often a team effort. If 10 min of communication a day is too much, idk then.

> People commit to their work and tell us when it’ll be done, if they fail we talk about it as a team. Team members quickly learn they must deliver and if they need help ask. We don’t delay timelines and I expected a clear “I think this will take days” if they need to delay, that’s fine, but they explain publicly and ask for help.

We have exactly the same strategy and it works very well.

> Those who were followers; who lacked discipline, failed faster and more obviously. Most software engineers produce more effort than they’re worth and skate by with meetings, “pair programming”, etc

This is so common and I am glad that remote work has been an effective extra filter. I mean, I don't mind mentoring junior devs, but also I am not a teacher and many of them seemed lacking total basics. Like they memorised algorithms but had no idea why they work or common issue was them just pasting code from Stackoverflow and then asking for help when it didn't work.

> People commit to their work and tell us when it’ll be done, if they fail we talk about it as a team

That sounds horrible. Software estimation is not a science and some say is impossible. To hold people to their estimates or else they've "failed" is toxic.

Just a personal opinion, but I hate daily standups. It's agile theatre. Nobody listens to what others are saying; they're too busy trying to make up good sounding stuff to say when it's their turn. I'm being a bit hyperbolic, but the general principle applies.

But sounds like it's working for your company so more power to you.

> an always open video chat

What.

It's a way to just be together, It's kinda just a way to share space and breakup the loneliness of covid and you can just ask questions to the team.

I've not done it as an established thing, but had standups where we pivoted to working on issues and as the issue got sorted everyone just chatted and enjoyed each other's company whilst moving onto other work. 3 hours later it's lunch and you end a mega video chat.

This most likely doesn’t mean that every person has their camera on 24/7, the setups I’ve seen have a “room” that is always open then people can enter and leave whenever.

Tools like Remotion or the virtual office apps with spatial sound and movable avatars also aim to lower the friction and make informal chats easier.

This sounds terrible and I would leave this team fast. I work in a high performing FAANG team. Deadlines get pushed all the time

Does one ever question why deadlines constantly get pushed? At best, it means those high performers are bad at setting initial deadlines. Or is it that meeting deadlines isn't considered a performance metric?

Now if deadlines are important, maybe it's just relative performance that you're speaking to. So if everyone misses deadlines you can still be high-performing, but it's like saying you're the skinniest kid at fat camp. It's normalization of deviance, and not a trait of high performing teams.

Because setting precise deadlines is nearly impossible without a massive investment up front, that companies aren't willing to make. Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines.

There's also a big difference between being a month late and a year late. It's also a lot easier to explain you're going to miss a deadline 3 months in advance than a week before.

You don't get high performing teams by forcing crunch time because the deadline is the deadline. This is also why I'm grateful not to work in video games; you can't reschedule Christmas.

>Software engineering projects aren't run like a civil engineering project where you have precise blueprints done before you set construction timelines.

Ironically, the civil engineering projects are one of the best examples of missed budgets and schedules. Almost every civil project at large scale becomes rife with change orders because coordinating different domains is complex, even if those domains have "precise" blueprints. Those blueprints always change, which is why the industry has "design" documents and "as-built" documents.

So what do you think it is? Why do they have an inability to coordinate large complex pieces of a project? Optimism bias? Can we really call someone a high-performer when they display those shortcomings? Or do we just normalize them so they aren't considered a problem?

The software is way too complex to gauge how long something will take. It’s also extremely risky to make a mistake in production. Projects slated for three months can take two years.

If you’re engineers are constantly hitting deadlines, probably it’s greenfield development or the problem space is simple

I agree. But if we don't manage it well at scale, that underscores that we don't really understand the complexity of the problem. Can you call someone a "top performer" when they don't understand the complexity of the problem?

We can write complex code with minimal errors[1].

"the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."

But I worry when we facilely normalize sub-optimal behavior because we've normalized it. Especially as FAANG and adjacent companies work on safety-critical software and when that attitude pervades other domains.

[1] https://www.fastcompany.com/28121/they-write-right-stuff

"Get better people" is not a talent strategy at scale unless you are also going to "pay them a lot more" which means that your corporate strategy also needs to include "make a ton of fucking money." Nice if you can pull it off, but the rest of the world needs to manage their companies too.

sadly, this is my experience as well...

...but it's also true that all-superstar teams rarely win vs teams composed on superstars and supporting staff [1], and thus you can't afford to hose the supporting staff.

[1] sorry I don't have a better reference - https://www.google.com/search?q=all-superstar+teams+vs+super...

Another side to this is, how possible it it actually to acquire a team of "superstars"? If you work at a big, well paying company maybe. But for anything non-FAANG, you might not have enough talent coming in that you'll be perpetually short staffed if you set the bar too high.

Pair programming is a fantastic tool. Why the snark?

I like pair programming and think I learned a ton by being the junior “driving” while the senior was “navigating.”

But I’ve also had some nightmare scenarios with people who just massively slack and do nothing. I worked with someone who wanted to “navigate” in 10/10 sessions and never said anything. They just watched me do stuff, didn’t respond to questions, didn’t work on docs, didn’t look stuff up. It was weird.

Mismatches like this made me eventually stop doing it as the team ended up separating out to pairs of superstars and pairs who did nothing. And it demoralized people.

That's why people should not be forced to pair program. (and I personally favor pairing)

Clearly this person is not throwing shade a pair programming, but lazy employees who might skate by doing lots of "pair programming" without pulling their weight.

I've come across people that are very good at getting "help" on their work to the point that they do very little work.

GP isn't talking about Pair programming in general. Pair programming is great. But quote-unquote "Pair Programming", where only one person does the work... not really. Been there done that.

Some people need more authority and external motivation generally in order to realize their potential.

I agree, and have to wonder what would happen if pre-remote some researcher tried to break it down to 'Computer Science Graduate' and 'Taught themselves on CodeAcademy'

I would bet the CS graduate is having a much easier time self-learning at home than the no-degree person who usually stops peoples work 12-15 times a day to get them to explain concepts or show them around the code, again...

Huh, I'd expect the self taught person to be more capable of teaching themselves the codebase than the CS grad, especially once you get into companies doing bog standard CRUD API + SPA webapp for a SaaS.

It's the new grads from courses that are theory heavy and practice light that expect a lecturer or tutor to guide them through the whole process in my experience.

From personal experience only:

Self taught people (Bootcamps are included here) are self taught to perform in the very specific tool-heavy world. Think Create React App + AWS. It's harder for them to independently understand bigger decisions/system design/building something from the ground up

CS grads know how to study, know when they are really stuck, and know what the good questions to ask when stuck are. They were thrown into this impossible course work and survived, they're better at studying complex systems, and to clearly define what exactly they do and dont understand

Bootcamp grads? they just need you to share a code snippet of exactly what you asked them to do in a different place in the codebase

You could explain 10 times why you chose to build the new microservices in Clojure and they still won't get it

People mistake self taught with understands complex software problems. Usually from what i've worked with, self taught is self taught to copy paste some commands into npm

Then their university/college has failed them. Learning how to think/learn/work independently should be the primary goal of tertiary education. It almost doesn't matter too much what your degree was in.

Sure, or more likely having a CS degree or not does not strongly correlate with programming skill or software development skill.

Some people are good at programming, and do a CS degree to expand their capabilities. Some people do a CS degree solely for the career options (which to be clear is not necessarily bad). Some people didn't do CS degrees for whatever reason, but have thousands of hours in codebases, and know when to look up an algorithm or data structure.

> I would bet the CS graduate is having a much easier time self-learning at home than the no-degree person who usually stops peoples work 12-15 times a day to get them to explain concepts or show them around the code, again...

I am a self taught and am pretty good at looking stuff up and figuring it out on my own, especially stuff that isn’t even in a manual. I figured this was pretty common since self taught is sort of forced to develop this skill.