This is one of those "slow down to speed up" kind of things that startups ignore at their peril. People, especially technical types, have a mistaken assumption that "speed" in startupland is based on the amount of code shipped and anything that distracts from code shipping is a distraction to be ruthlessly excised.

The real speed that a startup should be optimizing for is the degree of new, actionable, insights produced on the quest towards product/market fit. Code should only be built insofar as it helps provide scaffolding towards that goal.

Design critique is helpful because it helps you get faster at getting faster. It's not some crutch that weaker designers need to adopt to keep up with the rest of us, it's a fundamental way in which designers learn and get better at their craft.

But look at the artifice of this whole process. The need to establish "roles". The prescribed language. If I did that with my team, they'd rightly look at me sideways and say, "what the hell is wrong with you, just spit it out already."

It's not that I'm advocating a heads-down, never-come-up-for-air approach. It's that I'd expect these sort of conversations to have happened in an organic fashion that doesn't cargo-cult corporate policy gerrymandering.

You do get immediate return on doing this. In art it is common to ask for critique-- it immediately improves that particular drawing (hey mate, you should maybe fix her nose, she looks like a pig) while also helping in the long run (okay I won't draw noses like that anymore).

It's not like you have to put a crown on everyone's head. The article goes really into detail, but it basically boils down to "Take turns." It encourages everyone to engage without talking over each other, avoids shying away from ever presenting your work, or going onto long rants. Which are things the author has mentioned has happened at other companies. Even in a small 3 person group, it's easy for one person to dominate the conversation. You don't want that. You want to utilize everyone's perspective and skillset. Three heads are better than one.

Sometimes a little bit of ceremony helps change existing behaviors and gives people with different perspectives the opportunities to speak up.

So far from true. At a startup, everyone is blunt, because it pays to be. Everyone there is counting on success.

Whereas at a corp, the ceremony was created by someone else who may not even work there anymore, for some superpsionic reasons that everyone basically just shrugs at because they don't want to lose their jobs. It'a a sludsgefest that startups can skip - no point in needless vagaries when in a startup, it's actually appreciated to collaborate organically instead of being culled for doing so.

So much of that response is utterly loaded with flawed assumptions. The irony is that your response is exactly why sometimes it's important to be cognisant of how to conduct critical conversations. It's not about "needless vagaries", it's actually about direct and on-point critique, without the loaded value judgements. This isn't a skill that tends to come naturally to people, that's what the "ceremony" is for.

A startup is not the place to have a personal journey of growth. It's a place to figure out an awesome thing to make and turn it into money. A startup isn't a class group project. That doesn't mean it should be adversarial like Linus Torvalds treats Linux kernel developers. But that's a far cry from expecting other people on your team to speak up and put in their contribution without needing to be prompted.

That's also making the false assumption that the only way to make an awesome thing and money is to expect everyone else to behave like yourself. The reality is that creating something that's truly amazing takes a variety of perspectives and personality types and sometimes actively cultivating that is critical, even in tiny teams. Mind you, if you only hire people exactly like yourself that solves that problem fairly well for the first year or so.

Timid people are not a protected class. This isn't a diversity issue. Bringing it up is just muddying the waters.

Code reviews/design critiques are extremely valuable even if you only have two developers, and they're both great at their jobs. It's not about not trusting the other members of your team, it's about learning from each others' experiences and creating a better product together.

But I agree that the level of ceremony surrounding the process will vary a lot based on the size of your organization.

I agree that review/critique is just as important, even if you have only a few people. Even with a small group though, roles for participants can help keep conversations on track and civil and ensure everyone can participate.

Establishing roles for bad-actor participants is not how you keep conversations on track and keep them civil, it's how you get passive aggression.

Roles can help to keep conversations civil when the participants are benign as well as malign by removing communication friction. For malign actors they make it easier to pick out specific behaviours to review in one on ones and - if they persist - dismiss them for.

A lot of corporate policies are about limiting damage by bad actors.

I know. My point is that large corporations have little in common with startups. A startup should not already be so ossified that it's possible for bad actors to get in and stay in.

In other words, if you get to the point that you need to wage legalese wars with corporate policy documents, you're probably not a startup anymore. We really need to stop treating big, 5+ year old companies like Twitter as "startups".

This is an amusingly familiar argument. As a consultant, I see so many companies–small startups and big companies alike–wasting weeks and months of time on wasteful work because of this strong bias against "wasting time" to coordinate their efforts. They're avoiding dealing with communication problems within their teams and reflecting on their work, or, as in this case, stopping to critically think and exchange ideas about a project as it's underway. All things that can avoid team-weeks of effort spent moving in the wrong direction or delivering a shoddy product because the scope of consideration was overly narrow.

Protocols such as this make it possible for groups of people to come together productively and shape a collective effort by reconciling multiple perspectives. The kind of discipline outlined here is what separates companies limited by the natural interaction dynamics of a few personalities and those that overcome those dynamics to combine the best of the talents of all the contributors.

If anything, these things can be more important for a tiny, lean startup, as you have less runway to charge down paths that aren't optimal than a big company with an established product.

Certainly you'd have to adapt the model to work for such a small startup. That doesn't mean you shouldn't share and gain feedback on your work.

I agree, to be honest it reminds me of newspeak, and whilst having a rigorous framework in place with allowed language patterns might well help in the corporate world, startups are not going to want to waste cognitive load on it.

I was going to comment: It's written in that corporatese/political/management style that reminds me of orwellian critiques of language.

It is superficially and obviously true, provides labels and slogans, but doesn't actually say anything meaningful or particularly concrete.

Everyone can read it, nod their head in agreement, it provides those with authority words to use that support them in however they want to structure things, and a mirror image opposition vocab provides standard put downs against those forms they don't like which can't really be argued against...

But if you brought everyone together and got them to read it, i don't think most people would have actually changed their mind much about how they think or what they would do, specifically because the language is pretty much vacant empty fluff...

Like the literary equivalent of rorschach inkblots.

It's one of those things where you have to learn the rules before you can break them. The problem with such things is that if you present them as rules you can break when you learn them, smart people are so eager to get to the rule breaking bit that they try and skip over the rule learning as fast as possible.

The solution seems to be to confidently present them as rigidly plain rules and only let people in on the secret that they're breakable once they've demonstrated some degree of mastery. It's better to optimize for breaking the rules too late vs breaking the rules too early.

You see this all the time in beginner art classes. A big list of The Rules is presented up front and there's no brooking of dissention. Even if you break The Rules in the right way, you are punished because it's not yet time to break The Rules.

This is a failure of messaging on behalf of art schools. Such classes should make it clear that certain technique is being learned, not general 'art'. If the expressed goal is to learn technique, then no student should be surprised to receive bad marks for failure to adhere to technique.

And that is schooling. This is industry. You're not here to learn the basics of your craft. You're here to perform. I don't think there is any room for junior people in a startup. Some non-producer, MBA-ran startups think they can't afford senior people. I think we can't afford the inevitable mistakes from inexperienced--however well-meaning--people.

But coding is complex and ever evolving. No matter how senior you are there is always something to learn.