 |
| “Patterns on the most effective teams I’ve worked on:” (comment) | ||
| recommended by 2 users | 2021 | throwarayes on: Maximizing Developer Effectiveness | management | original thread | | ||
| throwarayes on Jan 16, 2021 | on: Maximizing Developer Effectiveness | view on HN | ||
| 2 users recommended this comment. What they said: |
|
pdimitar Jan 28, 2021 | on: Developers spend most of their time figuring the system out | context
On my last job -- which I do regret somewhat for losing -- I failed at meaningfully delivering that message. There were SO MANY things to figure out, and I had no experience in Kubernetes (and only surface experience with Docker, Tilt and Helm) yet I was expected to be productive in 1-2 weeks after onboarding. The main reason why I started taking too long in doing any tasks was that I grew more and more reluctant to ask questions. They were always answered extremely shortly and unhelpfully and left me with the impression that nobody cared to help me start becoming productive sooner. Also you were expected to hang out in a rather unofficial Mumble server the entire day if you have questions. What? Are we working remotely or are we simulating an office? Seems it was the latter. So anyway, I took the long route and started exploring a lot while working on my first tasks. Needless to say, this got me fired. I regret losing the very respectable salary but beyond that I am actually happy that it didn't work out. It's like, I get it, you guys are all busy, but if you took one or two weeks to hand-hold me every day then we wouldn't have a discussion at the 4th month mark about why am I so slow and that I have to be let go. It was rather sad because I kind of liked the guys in the team -- but they were not helpful and you were expected to wing everything yourself. Which is fine, AFTER you receive meaningful initial help. Which I never did. Sorry for rant. Reminded me of this HN comment (disclosure: not mine) which IMO nails it: https://news.ycombinator.com/item?id=25800104 But, on topic again: I wasn't able to express that message properly some of the places I worked at. There are people who were receptive to it (it == "you need to properly onboard people even if that means some of your business-critical devs work at reduced capacity for a few weeks") when I said it in the past -- and most are receptive to it in my current job as well -- so it seems it really depends on the people themselves and/or the culture of the company. I guess it's kind of like hiring: it's much more randomness than anything else. |
|
specialist Jan 28, 2021 | on: Developers spend most of their time figuring the system out | context
>> Reminded me of this HN comment (disclosure: not mine) which IMO nails it: https://news.ycombinator.com/item?id=25800104 Ya, that's a pretty good list. > ...not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers. Amen. A team is only as fast as its slower member. h/t The Goal, theory of constraints |
| Also recommended by people who recommended this: | ||
| 1. | “Here's an example. You want to do some computations on an array of values:” (comment) | |
| recommended by 1 user | 2020 | steveklabnik on: Why Dark didn't choose Rust | original thread | | ||
Patterns on the most effective teams I’ve worked on:
- high degree of trust and emotional safety between team members. The team can safely share feedback and risk sharing our crazy ideas
- high degree of care for the craft. We hold each other accountable to quality
- ships, regularly, to real customers
- little status seeking - goes with emotional safety - few individuals on the team need to be “in charge” or hold arbitrary titles.
- the individuals are more than fairly compensated and the company shows their love for the team in big and small ways
- the team talks to their customer and has a lot of empathy for their problems. They want to be accountable to them
- the team has a lot of empathy for new team members and works hard to make on boarding easier
- some willingness to “get in trouble” with the broader org because you know what you’re doing is right ultimately for the customer
- high self starters: instead of complaining, people feel empowered to solve problems or prototype ideas without a permission structure
- not too much catering to “super stars”. 1-2 heros does not a team make, the senior people make it their job to lift everyone up. The team doesn’t obsess over their high performers.
There’s a lot more emphasis on emotional intelligence and empathy in an effective team than on any specific process.