This was a response (in part!) to the HN questions posed on Cliff's original blog entry[0] -- hopefully it provided some answers! I would also be curious (and perhaps I should have phrased the title as a question?) how others have done this -- and specifically, what are some of the organizational idiosyncrasies (preferably of the positive variety?) that are outgrowths of a particular culture?
What Oxide have built is a great Engineering firm. Other than not tracking engineering metrics, the implementation details you listed are exactly what I try to establish in all of the engineering teams I join.
I’d love to hear what your sync & discussion meetings look like? I find in a highly cohesive team the discussions are never ending, and very fruitful, posing an interesting challenge of how to conclude them.
The answer is: it varies. Some of them are strictly agenda-driven (and if there is no agenda, the meeting is cancelled), others tend to be around-the-room updates + discussion, others tend to be more free-form. That we record all meetings ends up being (much) more important for us than the specific form...
The title is a little self congratulatory and might confuse cause and effect.
IMO many of the things listed are just side effects of this type of culture and the culture is 99% decided by the existing culture at founding time and hiring processes.
You can’t have a demo day without hiring intellectually curious people who like to share. You can’t pay a flat mid-tier salary with options that punish all late arrivers without just refusing to hire people that value their labor higher.
I’ve seen this mistake made at many companies. The critical piece is your hiring, retention, and performance management.
The rest of the stuff around meeting styles, knowledge exchanges, etc is all an emergent property of the team.
Engineering culture cannot be engineered. You can cultivate it by pruning out the personalities you don’t like and figuring out how to select for the ones you do like, but that’s about it. Changing the culture otherwise is pushing a boulder uphill.
Absolutely agreed about the importance of founding principles/values + hiring! (I thought that I had made that clear in the piece but perhaps not.) And while I think that the details broadly reflect culture rather than drive it, I also think (like an organism) that they are unseen feedback loops where the details do in turn drive the culture. (Compensation for us is very much in that category.)
> culture has to be deliberate without being overly prescriptive, and that can be a tricky balance
Cannot be understated how difficult it is to get this balance right. Especially in small companies where you get to work with “old timers”. Push too hard and people shut down. Don’t push enough and it all unravels quicker than you would think. To give a concrete example; In a firm where openness and async collaboration is critical, how do you push someone who always DM’s to use public channels instead, without making them uncomfortable?
Yeah, it's not simple! And it's hard to know if there's even a universal answer there. For example, with the person using DMs, is there another, deeper reason that they are avoiding public channels? I would try to get to the root of that by asking the question (e.g., "I notice you don't tend to use public channels, but we have found that public channels are really important for the team to learn from one another; is there something we can do to make public channels more amenable to your style?") rather than assuming that it's an act of subterfuge and ordering by fiat accordingly -- but it's tricky! (And I'm sorry that that's not terribly helpful...)
> We are writing intensive (but we still believe in spoken collaboration)
This is so hard to get off the ground without stern, respected leadership when dealing with disparate levels of interest in engineering (even though that’s everyone’s job, from Quality to Product), based on my little sample of experience
At Oxide, it was there from the beginning, plus it's built into the hiring process (the application is mostly writing), so there's strong selection pressure toward people who are into it. So I'm sure it's tough without those things.
I mean our application consists almost entirely of filling out this relatively long questionnaire, and we take it very seriously. This is the software engineer one. They vary slightly by role.
[0] https://news.ycombinator.com/item?id=39837073