Comment by JonChesterfield 4 days ago
That's an extremely sensible idea in multiple dimensions. It prioritises clarity of thought over rambling discussion in conference calls. I wonder if there's a feasible path to gradually steer an existing organisational structure in that direction.
From experience, yes / kind of; for the project I'm on right now, I introduced ADRs (https://adr.github.io/madr/) as a not-too-formal, but still formal way to talk about technology. This was after ten years of working in more hype-driven culture, where the choice was made by one person, or it was the tech du jour, or some guy spent a weekend playing with it so obviously we should integrate it.
It's a simple shift where people have to do their homework instead of just yeet something over the fence. You want to solve X? Present us with three options and we'll talk about it. You want to introduce Y? But we already use X to solve that, present us with new insights and the justification to spend the time on it.
It's far from perfect and it requires buy-in and (self) discipline, but it's still better than what happened before. Because some companies are still paying the debt of hype-driven development even though the people that introduced it are long gone.
It also means
- You can't take calls from cars
- People leave 2 bullshit comments like "justification needed" for participation points and then go drink coffee instead of actually reading the doc or googling for said justification
- People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
Not taking calls from a car sounds like a feature. We don't need more distracted drivers or meeting participants.
People taking calls from cars (and thinking it's OK in the first place) is exactly why we're going back to 5 days in office. People are simply taking too much advantage. You're being paid to work those 40 hours a week, not do whatever the hell you want to during the day and try to cram in work while you're driving from one errand to the next.
I haven’t seen a single instance of someone taking a call from their car since working remotely, likely because no one was commuting. It was fairly common prior to the pandemic and I was in office.
but why be so controlling? imagine someone is so busy they have to commute at 45 min commute in the 15 minute gap between meetings. so you’re refusal to be more understanding is blocking progress. likely it’ll be you removed from the meeting and going forward you’ll be included less. have fun being a low level IC!
> People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
I’m very much a writing kind of person when it comes to organizing my thoughts and I worked at a place where we did a ton of written documentation kind of like this. Then I left there and worked remote with a different company whose CEO, when I sent him an email, would pick up the phone and call me. We would then have the 10 minute conversation you’re talking about here. I came to love it because it’s true, a short focused conversation can be a huge timesaver. Since then, I’m often really frustrated by vendors and partners who steadfastly refuse to get on a call, when it’s very obvious to me that a quick call would be a far better use of time than endlessly going back and forth on email.
These are informal quick chats work nicely, until it doesn't, then it's a disaster and docs are needed.
With certain people I can work like that. With others that I don't trust, have seen don't shoddy work, don't communicate well, then write a doc and we'll discuss it.
Was it an important lambda function though? How often would it be called, would it still be around in 10 years, etc? If the six page document justified the existence of a separate deployable, then clearly it was important enough to warrant it. If you claim six pages was excessive, did the lambda even need to exist in the first place?
> - People waste inordinate amounts of time writing docs for things that could be discussed in 10 minutes
What about if someone wants to know what was discussed? You end up telling and retelling the same thing over and over again to get people in the loop, vs pointing to the doc and its remarks. (Depends on the subject of course)
Technical things (algorithms, locations of docker images, code, data, checkpoints, things that were tried but failed) should be documented.
Unfortunately most of the doc culture is people trying to convince each other within the same team that we need XYZ even when everyone with half a brain already knows it. Like "we need more GPUs to get shit done" should be a 10 minute call, not a PRFAQ.
I was in a meeting with an AWS engineer who took it from their car. It felt weird to me.
> if there's a feasible path to gradually steer an existing organisational structure in that direction
The path I took was to just start doing it and expecting it for critical topics within my team (which was around 200-250 people when I started it). It takes several iterations to get good at it and the first few feel like it’s quite foreign and even wasteful. (It puts a lot more work on the author, by design.)
Eventually, it escaped just my group and (with support from others, including the CEO, who liked the process after seeing some of the documents that I or others shared with them) and is now fairly common in the corporate center for our standardized processes, though not nearly as standardized as I perceive Amazon to be in its use.
Basically: start doing it and stick to it for at least 5 complete cycles. Make sure that influential people (not necessarily org leaders) are public in their praise of well-constructed and effective documents.