8 ms·

“Yes, if”: Iterating on our RFC Process

146 points by vinnyglennon 4y ago

throw242425 4y ago
It’s a bitter pill to swallow seeing this article. I am a former Squarespacer who left in the past year. All I will say is consider a few things carefully about this: 1. This introduces a lot of process, bureaucracy, and chances of gatekeeping politics. The whole “yes if” mantra just centralizes the political power to the hands of fewer senior leaders by cutting off legitimate blocking criticism from the rank and file. 2. Judge processes by outcomes. What has Squarespace done / shipped / accomplished in the last four or five years? I’m not alone in feeling like it’s a head-scratcher why the company would pay the most senior engineers to erect slow moving bureaucratic decision-by-committee disempowerment structures like this, and then turn around and act like that’s a good thing or constitutes what you’d want to see as productivity from staff or principal engineers. While I’m a proponent of writing things down, not surprising peer teams, pulling blockers or conflicts forward quickly … I don’t think templates and councils help more than they hurt, and often domain experts in different teams need empowerment to just totally bypass that time-wasting crap and do what needs to be done. If they don’t uphold the responsibility to do due diligence on review or finding conflicts, fire them or take them off the project, but don’t make everyone wear design-by-committee training wheels and act like that’s non-dysfunctional good engineering. YMMV of course, but I reckon it’s really worth it to ask what is the real engineering output, speed, productivity following from this kind of large process overhead.
- jugg1es 4y ago
  Full democratization/decentralization of engineering decisions is how you get into a quagmire of technical debt that can eventually kill your engineering teams. Some decisions need to be made by a group that is accountable overall to the health of the technical implementation. Like you can't be letting people use 5 different message bus solutions and expect your devops/support people to manage all of them effectively. Someone has to maintain sanity.
Jorge1o1 4y ago
> Approvers say “yes” or “not yet.” We want to encourage constructive comments, so the template doesn’t suggest “no.” Instead of just vetoing an idea, it’s better to be clear on what it would take to approve it. I'm not trying to be facetious, but what if the idea really is a No? Not every change is for the better. What if someone proposes "we should rewrite X in Y language," or "we should use Z database instead." Sometimes you need to say "No." Otherwise you end up with feature creep, endless rewrites and refactoring, code churn, and a bunch of other issues.
- pseudoramble 4y ago
  I get your point, and they do address this later on in the piece kind of. It sounds like it's perfectly valid to say no, especially after reviewing the document and their architectural meeting where they discuss it more in depth. But they're also not trying to actively encourage saying no in the document, instead encouraging responses that points to how to get to a solid idea. So saying "no" isn't forbidden, but it isn't the default either. At least that's my interpretation.
  - dilyevsky 4y ago
    Some people choose to not say “no” and we encourage that, okay?
- richk449 4y ago
  Yes, if you use the current language rather than rewriting. Yes, if you use our current database rather than a new one.
- Cpoll 4y ago
  > What if someone proposes "we should rewrite X in Y language," Yes, if 50% of our development team is proficient in Y, X is a bottleneck or EOL, rewrite will solve significant problems. > we should use Z database instead. Yes, if Z is widely used in our stack, Z will realize advantages that cannot be achieved with the current database, Z is required to solve upcoming problems. That's how I take it, at least: You shouldn't say "No," you should say "this is why not."
faizshah 4y ago
I like their template: https://static1.squarespace.com/static/56ab961ecbced617ccd2461e/t/5d792e5a4dac4074658ce64b/1568222810968/Squarespace+RFC+Template.pdf https://static1.squarespace.com/static/56ab961ecbced617ccd24... At work I use a pretty similar template for my design docs. Lately I have started to include a “strategy” section earlier in the design doc, so the first part of the design doc is giving all the background and context then the next section sets out the requirements and goals. Then you give the future vision that everyone can agree to. Then the next section gives a strategy of how to accomplish the vision e.g “we will take incremental steps first” vs “we will re-architect the service.” Then finally the next section is where the design starts, now that we agree on the future vision, requirements and our overall approach to the project we can talk about specific engineering choices and the plan to accomplish those. I wanted to ask a question to other frontend folks, have you been able to get a good design doc process adopted by your team? I have had difficulty because a lot of times FEEs think that their projects are too “simple” but then when I look at their code they have made design decisions that we could have discussed much earlier on if they had actually made a design doc. I also see FEEs going down wrong paths and re-learning things themselves that we could have addressed in a design review. What does your process look like for design reviews for Frontend?
oscillonoscope 4y ago
Isn't this just an ECR with a phase gate? It seems like a very normal process that's being written about like it's innovative
- NationOfJoe 4y ago
  if you do not mind me asking, what is ECR in this context?
  - oscillonoscope 4y ago
    Engineering change request.
weatherlight 4y ago
We adopted a very very similar RFC framework for some projects back in 2020 and those project, now three years later, are the ones that have the least problems. Even though they took a little longer to get started. What's that old army adage? "An ounce of sweat prevents a gallon of blood."
Scubabear68 4y ago
But did it make any difference? Are there metrics showing this was the right path? The reason I ask is that this process seems to be couched in terms of politics and psychology, and not about organizational value.
- hummus_bae 4y ago
  [dead]
JohnBooty 4y ago
I wonder if anybody's had similar experiences... I've worked at two companies with RFC processes. At both companies, the processes were -- and I hate to use such a strong word -- a total sham. I suppose the processes were crafted to look like some egalitarian meritocracy. In reality, it was just a test of who had the most political pull. If you had management on your side, your "RFC" was effectively law and dissenting voices were effectively career suicide. Which, you know... fine. I understand that choices are made based on cliques and political capital rather than anything else. Cool. That's okay! Sucks sometimes, but that's how the world works. Hopefully your org structure itself is at least something of a meritocracy, so that edicts from on high are of a generally high-enough quality. If they get it right-ish often enough, your org will be okay... probably. But what really rankled me was the fact that the RFC processes amounted to some kind of elaborate cosplay so that, I guess, folks could pretend that there was some sort of healthy collaborative process. If you're going to let a few "popular and management-blessed" engineers make all the decisions, fine, but don't add insult to injury by pretending otherwise. I've heard similar things from others, elsewhere. I hope there are at least a few companies dedicated to being something better.
- eugenhotaj 4y ago
  In my experience processes like these rarely work out as intended and usually add layers of bureaucracy for marginal benefit. It’s usually senior engineers or middle managers looking for “org wide impact” so they can get promoted.
  - treis 4y ago
    At [current job] it's run by a group of architects that aren't responsible for delivering anything. Which works about as well as you might imagine. Had one legit tell me something like "that's for you to figure out" when I pointed out some implementation challenges. Of course now that the project is behind there's no architect in sight to help us out.
    - jugg1es 4y ago
      I recently joined a group of architects that aren't responsible for delivering anything and you are not totally wrong. But it isn't the architect role to involve themselves in weeds of the implementation - that's your job. They should be helping if the project is falling behind, though. Then again, if the project is falling behind, then that is probably more indicative of a poorly-run product team and/or a bad SDLC process.
chrsig 4y ago
There's a huge swath - probably an overwhelming majority of the time - of good faith situations where it works well. That is, the suggestion isn't intended to be adversarial, and is otherwise plausible. A major problem however is if there's not a collective understanding that "yes, if" is not a suggestion or consent for that condition to be actualized. So it really should be "yes, if ..., however, that situation is very rare/cost prohibitive/high risk, so should be avoided" There needs to be some way to unambiguously signal that something is a no-go, even if there are situations where it would be a good idea.
ericalexander0 4y ago
Cool, but how did they measure the success of the changes? I expected to read something along the lines of DORA key metrics.
quickthrower2 4y ago
I like the template poster there, as it reminds you of pertinent points without having too much boilerplate to fill in. "Yesifs" are a handy way to avoid back/forth and shoe trust. They are also good in code reviews, or many gated places. If people use the yes if to do the yes and ignore the if, then there is of course a problem. Some places I have worked I feel like the team would have done that because of culture.
jugg1es 4y ago
I wish articles like this would follow up on it 3 years later to see what happened. Things always backslide unless you have a cheerleader for the process until it becomes part of the culture.
thenerdhead 4y ago
I run a RFC process for an open source project and it works quite well. I do not love the “Yes, if” attitude though. Putting a condition on something really hinders the creative process. You end up designing by committee or rallying behind the “approvers” which makes for bad design in my opinion. In comedy improv, there is a concept of “yes, and”. It is much more empowering. You accept the reality as is and build on top of it. If the changes get picked up, then it was meant to be. It helps foster trust in each other leading to great organic discovery on the way to being accepted.
FairyTail9 4y ago
[dead]
Tangy_sushi0 4y ago
[dead]
Namecheckr4 4y ago
[dead]
TheOneandonly1 4y ago
[dead]
fabulously_your 4y ago
[dead]
CitySlicker1 4y ago
[dead]
OfHearts00 4y ago
[dead]
Irish_Lass2 4y ago
[dead]
Charmed_Beauty0 4y ago
[dead]
GloryBringer2 4y ago
[dead]

146 points by vinnyglennon 4y ago

It’s a bitter pill to swallow seeing this article. I am a former Squarespacer who left in the past year. All I will say is consider a few things carefully about this: 1. This introduces a lot of process, bureaucracy, and chances of gatekeeping politics. The whole “yes if” mantra just centralizes the political power to the hands of fewer senior leaders by cutting off legitimate blocking criticism from the rank and file. 2. Judge processes by outcomes. What has Squarespace done / shipped / accomplished in the last four or five years? I’m not alone in feeling like it’s a head-scratcher why the company would pay the most senior engineers to erect slow moving bureaucratic decision-by-committee disempowerment structures like this, and then turn around and act like that’s a good thing or constitutes what you’d want to see as productivity from staff or principal engineers. While I’m a proponent of writing things down, not surprising peer teams, pulling blockers or conflicts forward quickly … I don’t think templates and councils help more than they hurt, and often domain experts in different teams need empowerment to just totally bypass that time-wasting crap and do what needs to be done. If they don’t uphold the responsibility to do due diligence on review or finding conflicts, fire them or take them off the project, but don’t make everyone wear design-by-committee training wheels and act like that’s non-dysfunctional good engineering. YMMV of course, but I reckon it’s really worth it to ask what is the real engineering output, speed, productivity following from this kind of large process overhead.

jugg1es 4y ago
Full democratization/decentralization of engineering decisions is how you get into a quagmire of technical debt that can eventually kill your engineering teams. Some decisions need to be made by a group that is accountable overall to the health of the technical implementation. Like you can't be letting people use 5 different message bus solutions and expect your devops/support people to manage all of them effectively. Someone has to maintain sanity.

Jorge1o1 4y ago

> Approvers say “yes” or “not yet.” We want to encourage constructive comments, so the template doesn’t suggest “no.” Instead of just vetoing an idea, it’s better to be clear on what it would take to approve it. I'm not trying to be facetious, but what if the idea really is a No? Not every change is for the better. What if someone proposes "we should rewrite X in Y language," or "we should use Z database instead." Sometimes you need to say "No." Otherwise you end up with feature creep, endless rewrites and refactoring, code churn, and a bunch of other issues.

pseudoramble 4y ago
I get your point, and they do address this later on in the piece kind of. It sounds like it's perfectly valid to say no, especially after reviewing the document and their architectural meeting where they discuss it more in depth. But they're also not trying to actively encourage saying no in the document, instead encouraging responses that points to how to get to a solid idea. So saying "no" isn't forbidden, but it isn't the default either. At least that's my interpretation.
- dilyevsky 4y ago
  Some people choose to not say “no” and we encourage that, okay?
richk449 4y ago
Yes, if you use the current language rather than rewriting. Yes, if you use our current database rather than a new one.
Cpoll 4y ago
> What if someone proposes "we should rewrite X in Y language," Yes, if 50% of our development team is proficient in Y, X is a bottleneck or EOL, rewrite will solve significant problems. > we should use Z database instead. Yes, if Z is widely used in our stack, Z will realize advantages that cannot be achieved with the current database, Z is required to solve upcoming problems. That's how I take it, at least: You shouldn't say "No," you should say "this is why not."

faizshah 4y ago

I like their template: https://static1.squarespace.com/static/56ab961ecbced617ccd2461e/t/5d792e5a4dac4074658ce64b/1568222810968/Squarespace+RFC+Template.pdf https://static1.squarespace.com/static/56ab961ecbced617ccd24... At work I use a pretty similar template for my design docs. Lately I have started to include a “strategy” section earlier in the design doc, so the first part of the design doc is giving all the background and context then the next section sets out the requirements and goals. Then you give the future vision that everyone can agree to. Then the next section gives a strategy of how to accomplish the vision e.g “we will take incremental steps first” vs “we will re-architect the service.” Then finally the next section is where the design starts, now that we agree on the future vision, requirements and our overall approach to the project we can talk about specific engineering choices and the plan to accomplish those. I wanted to ask a question to other frontend folks, have you been able to get a good design doc process adopted by your team? I have had difficulty because a lot of times FEEs think that their projects are too “simple” but then when I look at their code they have made design decisions that we could have discussed much earlier on if they had actually made a design doc. I also see FEEs going down wrong paths and re-learning things themselves that we could have addressed in a design review. What does your process look like for design reviews for Frontend?

oscillonoscope 4y ago

Isn't this just an ECR with a phase gate? It seems like a very normal process that's being written about like it's innovative

NationOfJoe 4y ago
if you do not mind me asking, what is ECR in this context?
- oscillonoscope 4y ago
  Engineering change request.

weatherlight 4y ago

We adopted a very very similar RFC framework for some projects back in 2020 and those project, now three years later, are the ones that have the least problems. Even though they took a little longer to get started. What's that old army adage? "An ounce of sweat prevents a gallon of blood."

Scubabear68 4y ago

But did it make any difference? Are there metrics showing this was the right path? The reason I ask is that this process seems to be couched in terms of politics and psychology, and not about organizational value.

hummus_bae 4y ago
[dead]

JohnBooty 4y ago

I wonder if anybody's had similar experiences... I've worked at two companies with RFC processes. At both companies, the processes were -- and I hate to use such a strong word -- a total sham. I suppose the processes were crafted to look like some egalitarian meritocracy. In reality, it was just a test of who had the most political pull. If you had management on your side, your "RFC" was effectively law and dissenting voices were effectively career suicide. Which, you know... fine. I understand that choices are made based on cliques and political capital rather than anything else. Cool. That's okay! Sucks sometimes, but that's how the world works. Hopefully your org structure itself is at least something of a meritocracy, so that edicts from on high are of a generally high-enough quality. If they get it right-ish often enough, your org will be okay... probably. But what really rankled me was the fact that the RFC processes amounted to some kind of elaborate cosplay so that, I guess, folks could pretend that there was some sort of healthy collaborative process. If you're going to let a few "popular and management-blessed" engineers make all the decisions, fine, but don't add insult to injury by pretending otherwise. I've heard similar things from others, elsewhere. I hope there are at least a few companies dedicated to being something better.

eugenhotaj 4y ago
In my experience processes like these rarely work out as intended and usually add layers of bureaucracy for marginal benefit. It’s usually senior engineers or middle managers looking for “org wide impact” so they can get promoted.
- treis 4y ago
  At [current job] it's run by a group of architects that aren't responsible for delivering anything. Which works about as well as you might imagine. Had one legit tell me something like "that's for you to figure out" when I pointed out some implementation challenges. Of course now that the project is behind there's no architect in sight to help us out.
  - jugg1es 4y ago
    I recently joined a group of architects that aren't responsible for delivering anything and you are not totally wrong. But it isn't the architect role to involve themselves in weeds of the implementation - that's your job. They should be helping if the project is falling behind, though. Then again, if the project is falling behind, then that is probably more indicative of a poorly-run product team and/or a bad SDLC process.

chrsig 4y ago

There's a huge swath - probably an overwhelming majority of the time - of good faith situations where it works well. That is, the suggestion isn't intended to be adversarial, and is otherwise plausible. A major problem however is if there's not a collective understanding that "yes, if" is not a suggestion or consent for that condition to be actualized. So it really should be "yes, if ..., however, that situation is very rare/cost prohibitive/high risk, so should be avoided" There needs to be some way to unambiguously signal that something is a no-go, even if there are situations where it would be a good idea.

ericalexander0 4y ago

Cool, but how did they measure the success of the changes? I expected to read something along the lines of DORA key metrics.

quickthrower2 4y ago

I like the template poster there, as it reminds you of pertinent points without having too much boilerplate to fill in. "Yesifs" are a handy way to avoid back/forth and shoe trust. They are also good in code reviews, or many gated places. If people use the yes if to do the yes and ignore the if, then there is of course a problem. Some places I have worked I feel like the team would have done that because of culture.

jugg1es 4y ago

I wish articles like this would follow up on it 3 years later to see what happened. Things always backslide unless you have a cheerleader for the process until it becomes part of the culture.

thenerdhead 4y ago

I run a RFC process for an open source project and it works quite well. I do not love the “Yes, if” attitude though. Putting a condition on something really hinders the creative process. You end up designing by committee or rallying behind the “approvers” which makes for bad design in my opinion. In comedy improv, there is a concept of “yes, and”. It is much more empowering. You accept the reality as is and build on top of it. If the changes get picked up, then it was meant to be. It helps foster trust in each other leading to great organic discovery on the way to being accepted.

FairyTail9 4y ago

[dead]

Tangy_sushi0 4y ago

[dead]

Namecheckr4 4y ago

[dead]

TheOneandonly1 4y ago

[dead]

fabulously_your 4y ago

[dead]

CitySlicker1 4y ago

[dead]