[SeeDave]

>In 2016, Slack was two years old and already used by millions of people. Our codebase had grown rapidly, and like many companies that focused on product/market fit, our code was built in a way that favored time-to-market over maintainability, consistency, or reusability.

>What does a button look like in Slack? How do you build it? What words do you put in it? It was up to individual teams to make these decisions.

I am really surprised that their engineering org took so long to see the long-term payoff of common CSS components/styling when it comes to linting, minifying, and caching on web and sizing/spacing/scaling on native mobile. I am even more surprised that their product team didn't consider a unifying "brandfeel" from the get-go. If your goal is to _scale_ and _scale fast_ while being a judicious steward of VC monies... wouldn't you want to eliminate as much wheel-reinventing as possible?

I say this without any gratuitous negativity/internet holier-than-thouism... I just wouldn't expect this level of "bespoke craftsmanship" for a solved problem like common theming/styling in a engineering org at their series F stage with Accel, a16z, and KPCB already on the cap table. Weird.

[heyitsgarrett]

I wrote this article, and appreciate your framing here. A few things contributed to this effect that I think are a bit clearer with hindsight. Central to this was a lack of clarity between designers and engineers about what the state of things actually was. Designers assumed that engineers had been doing some of this work in building shared components, while engineers trusted that designers were aligning with each other. A lot of that happened organically when we were smaller but as we grew faster, those assumptions start to break. Eventually, we were far along before recognizing how much some of our patterns had diverged.

We had a pretty good idea what needed to happen to fix it, but there was a ton of work happening to maintain our same quality at scale across all of our feature teams. When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.

In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix. We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.

[SeeDave]

Hey, thanks for your response! Great article and you guys are definitely in a good place now (yay Dark mode!) Your iterative approach to course-correction was absolutely the way to go so hats off for a job well done.

>When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.

Been there, done that, got the T-Shirt. Routing in Angular, API design and versioning, CMS integration, and more. I get it.

>In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix.

There are probably a dozen relevant Dilberts on design-by-committee which are probably amplified by the egos and inexperience of dozens of 2x-year olds working at $hottest_unicorn. I strongly suspect that you are a very kind, patient, and understanding man.

>We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.

Congratulations, again. My sincerest apologies for focusing on the 'start line' when your article was about the race. Hindsight is absolutely 20/20 so hats off for a job well done and thanks for the follow-up.

[ng12]

A lot of companies don't take front-end seriously. They don't invest in hiring the guys who will ask these questions and will prefer to pad their ranks with fresh-faced college grads.

[steve_adams_86]

You're not wrong. Most of the fresh faces I've worked with have been eager to just make it to their first real project, whatever that takes. Asking questions can get in the way of what leadership will see as progress, and they might not be aware of which questions to ask yet (because they haven't screwed up enough yet, haha).

There are plenty of fresh-faced college grads with good sense to ask those questions though, and I've worked with them. The problem can also be management who hears a good idea, finds out it'll take longer in the short term, and says no - let's move fast and break things or whatever motto you're familiar with.

You can have good foresight and know your team needs proper scaffolding to scale but never get the green light to get it built if the people managing you don't see the value in it.