Generally, I think having an open handbook is the trending culture. Building in the open is becoming more popular - GitLab really moved the needle on this, so IMO from an outsider's perspective, Airbyte [0] and Posthog [1] has the best (publicly available & documented) processes, apart from GitLab of course (I didn't like that they removed stuff like their compensation calc, but I understand the motivation).

[0] https://handbook.airbyte.com/

[1] https://posthog.com/handbook

edit: addendums

They're definitely trying, but they're not as open as they might appear.

I had one of their in-house recruiters work hard to get me into their company, and was kind of happy until it came to the reference checks, nobody had mentioned to me that they would be hiring a 3rd party company that was going to contact 7 years of previous employers. For some people this might be the norm, for me that's MASSIVE overkill.

A couple of years later someone on twitter was claiming that Gitlab's hiring process was transparent so I mentioned the problem, and they opened a public issue.

A month later I checked to see how it was progressing and they'd decided to make it private and I was definitely not allowed to see anything about it.

I've since noted in their materials that they explicitly mention the check, and it's 5 years worth, which is much better from a transparency point of view, but disappointing from a - I had to go and check their documents to discover a change had been made, point of view.

Out of boredom I was checking airbyte. Here are some details:

1. They want you to ship like a startup: https://handbook.airbyte.com/company/methodology#done-better...

2. They are remote but will adjust your salary based on location: https://handbook.airbyte.com/people/compensation#nomading

3. They are transparent but there is no mention of salaries.

4. They support diversity more than the French republic (aka: tons of BS): https://handbook.airbyte.com/people/diversity-inclusion-and-...

5. They'll give you $100 on your birthday!! https://handbook.airbyte.com/people/expense-policy#birthdays

Building these books in the open is signalling. No one knows except, of course, for the people who have gone through whether that guideline is legit or not.

valid point! I will def check these out.

Shameless plug - the place I've been at for the last 2 years has the best culture I've seen or heard of (I've been around since the 90s). It is so good I changed my plans and went from contract to Full time a year ago. Transparency, pragmatism, solutions over blame, remote first, learning focused, rational hours (4.5 day work week), approachable C level, solid feedback process up and down. CEOs drive this.

https://www.flywheelsoftware.com/post/why-flywheel

can you say a few more words about:

„As we value the Learner’s Mindset, we use the squad model so everyone gets to sharpen their skills, constantly and work on new things and work with different people.” ?

plus how does the „solid feedback process up and down” work?

Squads is basically feature teams. You may have a platform focus but working ina feature moves you around the stack and lets you pair up with others. We didn’t invent this but it’s good to work across the whole engineering org - you learn more from the diversity you are exposed to and hopefully teach things to others through collaborations, code reviews , design reviews etc

I've noticed a common theme across several such posts/comments - our definitions of a "good" company can widely differ. I, for one, find it's important that the team can always quantify how every feature adds value to customers. Others are happy just focusing on highly-technical, challenging work.

We're already starting to see examples of these differences in the thread started by @JonChesterfield; I'm sure others will pop up.

The only conclusion I can draw so far is that interviewing the employer remains as important as ever. Don't just write off a company because of what you see online, just have a 30 minute chat.

Could you say more about quantifying value?

I'm a big fan of both aiming to deliver value (by having a value hypothesis for each new thing) and making sure we're delivering value. But actually quantifying it can be tricky. Do you mainly use value proxies here? E.g., X people are using the feature Y times per week?

I read "quantify" a little ambiguously, possibly because I'm projecting.

For me, it's enough to be able to explain the potential customer value. And this often happens after the fact. We actually try to get people here to listen to their gut and do small versions of work, _then_ tell the story of why it might matter.

I'd say it depends on how much effort it'll take to deliver the work. Want to spend a day clearing up a piece of technical debt? Guesstimate how much faster you'll end up adding new features after resolving it. But the bigger the piece of work the more effort you should put in quantifying it.

Ah, got it. I think I mostly avoid the problem by looking for small ways to test the value hypothesis.

> I, for one, find it's important that the team can always quantify how every feature adds value to customers.

Are you me?

Ha, I wish!

The startup I work at is definitely Netflix culture inspired, I think they remain a pretty popular “culture role model.”

Wasn’t sure if it’d be for me at first, as it’s so different from where I was before. Previous company I was at, great social culture (pre-COVID), very nice people, but very top down decision making. Also nobody ever got let go (or even really talked to) for performance reasons, very easy place to coast. Some people referred to the culture as “toxic positivity”, which is a pretty good description. Really, the only way people got let go was at mass layoffs every 2 years or so, but between layoff people could dog it and nobody would say anything. Overall it was socially fun, but work wise extremely slow, inefficient and bureaucratic. I have lots of good memories from that place, but I don’t think it was an EFFECTIVE company culture.

At my current, “Netflix inspired culture” company, there’s a lot less process, a lot more personal responsibility, and an expectation of high performance. People who aren’t contributing enough are quickly told, and if they can’t turn it around, let go. I thought it might feel too harsh/cold for me, but I actually really like the culture. Low process, high productivity, and you can trust basically all your teammates to be high quality contributors and decision makers. I feel more pride in my team and what we’re building. Social aspects are definitely not as fun as at my last co., but I do think a fair bit of that is the post-COVID world, hard to have a really social/fun company culture when most people are remote most of the time.

My 2 cents,

10 years ago there was a huge focus on structuring engineering teams in ways that made it so that individual engineers did not matter. There were also tons of dependencies between teams as you would have "Systems Engineers", "Devops Engineers", "DBAs", "Data Scientists" etc. etc.

Web work was also relatively new, and few leaders actually had a handle on how much time things would take. Functional splits lead to teams making poor assumptions on other team's efforts, and agile produced cancerously bad software cultures.

My experience in 2023 is that few teams maintain any agile concepts outside of daily stand-ups/weekly syncs. Teams are generally functionally integrated, and have a more or less date oriented culture depending on how annual goals are set and how you make commitments to customers. Cloud computing, improved test infrastructure/expectations, CI/CD, and maturity have dramatically changed development culture industry wide.

Is this an a-typical experience? I can't think of the last time I saw a project with a date that the engineer hadn't set.

I agree with the gist of what you said above, but:

Web work was new 10 years ago?? What am I missing here? I've been doing almost exclusively web work for 20 years now.

Few leaders still have any kind of handle on how long things will take. Nor engineers or PMs, etc.

And agile produced cancerous bad software culture? Clearly you have way different experiences than I do. Unless by agile you mean top down corporate scrummerfall bullshit, then yes.

I find generally complexity is increasing, tooling is a bit better. Culture is backsliding to 90s bullshit, and the upper level situation hasn't evolved in any way. Over all I'm pretty disappointed by the state of the industry and the "worse is better" tendencies except in a few outlier areas. But maybe that's how these things go.

> Web work was new 10 years ago?? What am I missing here? I've been doing almost exclusively web work for 20 years now.

New in relative terms 10 years ago, the vast majority of leadership teams came from non-web software. Alternately, if they came from web software - they were going from writing landing pages to complex SaaS products. I rarely encounter people in leadership who haven't spent the majority of their career building web services/software which runs on the web at this point.

> And agile produced cancerous bad software culture?

Aye - My experience with agile teams was that the sprint structure took precedence over the customers, business stakeholders, and product. Engineers either got burned out because estimates came in low - or crap was shipped to hit the sprint deadline. Ironically if something new came up, rather than handling the new thing in an agile way - customers would get berated for not filling in acceptance criteria, or not putting enough detail in the acceptance criteria, or not sacrificing under the full moon in the acceptance criteria etc.

I spent the last 8 years avoiding agile shops, and I am pleased to see that there are fewer of them every year. I vastly prefer treating software engineers like any other professional engineering discipline where you assign a project to an engineer, let the engineer scope and design the project, then execute on the project.

That sounds pretty awful, I can certainly relate to the sprint deadlines bit.

In fact that sounds straight up dysfunctional. I've certainly worked in a few agile (to varying degrees) that functioned far better than that. To me they've been the only places that we're halfway decent.

They were outnumbered by places that either paid lip service to Agile (universally using SCRUM), or applied it in some backwards bizarre way. I think this is where that bad rep comes from.

It's a shame, I've personally worked with an onsite customer that was a C level exec, and we cut out reams of red tape, got stuff done, and delighted them. Maybe the real vision of it is just to hard to achieve given political realities and the shitty nature of the modern corporation.

I like the place I work, it's pragmatic, doesn't jump on every bandwagon, ships features to customers (I've worked places that just couldn't get things shipped), has interesting problems, blameless culture, 100% remote. Still a good size for me, not too big, not tiny. Great CTO who is very intelligent, kind, yet firm when he disagrees.

I doubt we're setting trends. It's just a lovely place to work. https://www.aha.io/

No such thing as a company with the best work culture. It is very dependent on the team and the manager.

And even if you found an amazing team, all it takes is one re-org for the team to be ruined.

Unfortunately the answer is a lot of companies. Not big names, not ones that extol their own virtues, not the loudest voices. So, yeah, difficult to find but numerous.

Generally I’ve found them to be smallish companies with a track record of growth (“uninterrupted prosperity”) and a culture that values the holistic good (i.e. has buried the exclusive focus on shareholders) and comes from the top.

Also welcome, what companies have broadly adequate dev culture?

Something like:

- you don't get paged when things break

- it's possible to ship to production within, say, a month

- there's a sane CI system in place

- there's no product owner between you and the customer

- at least partially remote working is OK

(@op perhaps you could clarify what would qualify as amazing culture? I suspect the bar is higher than the above)

You don’t want a product owner between you and the customer? You want to work with customers directly? Customers are exhausting!

Thought that one would be contentious. In a past life I had a product owner whose hallucinations drove development direction. I have zero faith he represented what customers wanted accurately, not least because as far as I can tell he never spoke to them either. That was not a good time.

That sounds like a bad product owner, not that product owners are bad. In every discipline there are people who are bad at their job and bring negative value.

I worked at a place with no product owner and I would literally have to task switch from writing code to talking to an irate customer on the phone because we only had basic tier 1 support. I would also have to fly out to the customer’s actual site to live debug while they stood over me mad. I’d have to also gather requirements and ideas from them. All while also needing to do a full-time software engineering job.

I would have killed for a Product Owner to shield me from that!

I am totally with you on product hallucinations being a big problem. For me the sweet spot is a product manager who grounds needs in user research that is then shared with the team, so we could get a real sense of who we were building for and why what we did mattered. And who then follows up after we put something out there to see if it's really working for the users, so that we can iterate until it's right.

It is a big jump to go from saying you don't want a bad product owner to saying you don't want a product owner at all. If you have a customer facing product, being a good product owner should be a full time job. You can't do that and be an engineer at the same time.

I would say that you don't want a bad product owner between you and the customer. Having a great one can build an amazing experience for both the customer and the devs. But you are correct that a bad one will traumatize you.

What would you say... ya do here?

Can the "product owner" actually program? Otherwise it won't work.

That's not at all my experience, the best PO I had were not technical at all, but laser focused on the users. They do need to be reasonably smart, and trust your technical expertise, however

They also need to be able to avoid making promises to customers and avoid falling into the trap of "This sounds easy and fast why are you telling me it's hard and time consuming"

I think it depends, a product owner needs to inject subject matter expertise. It can be that they know how to program, but it also could be that they deeply understand customers.

In digital health setting I’ve met a few drs-turn-pms who were excellent because they could translate between what drs wanted and what engineering was thinking in a way that swe-turn-pm would struggle. Of course, the best dr pm I know also learned how to program in python because he enjoyed it (and he even shipped some small self-contained projects!).

The least effective pm I met was a non-dr non-swe who didn’t have deep understanding of either side and essentially tried to apply general pm-principles-from-a-book. But even they were positive value after a quarter of finding their place.

I don't think the PO needs to program, it might help, but its not a necessity.

they do need to know the product inside out, and who the customers are, and why the product evolved like it did. They need to be able to advocate for the customer.

This covers the majority of the tech teams at Amazon. Full CI/CD is mandated for most organizations, and pager events are tracked at the VP level. So far, few teams have enforced Return to Office. The one area which is debatable is the time to ship to production, while most changes can hit production in less than a day - work is heavily planned in advance, the ship can turn slowly.

Biased, but shortwave.com has all of these things.

- we have an event based architecture based on per customer queues, I haven't been paged in months mostly because single customer issues don't cause pages (just tickets which are handled during working hours)

- I regularly ship to prod multiple times a day. I just finished a complete overhaul of our search in about a month.

- Our CI is pretty good for a startup, certainly has the most room for improvement on this list

- as a startup you get to directly talk to customers as much as you want

- I'm fully remote, but we have regular company offsites together

- regularly do lunch and learns to share knowledge

Well, I know that 'amazing culture' can mean different things to different people. I'm interested in examples of the companies that are setting the current trends how development should be done. Structure of teams, CI/CD, pipelines, responsibilities, tooling, day-to-day working methodology (product management probably too).

Of course this judgement is subjective - I'm fine with that.

Just to understand better: who are product owners at big(ger) companies? Even PMs rarely talk to customers. PMM? Research? Not sure what size companies have engineers talk directly to customers.

If you’re managing the relationship with the customer you will also be expected to work with leadership. Lots of meetings and roadmap discussions.

There's also a great podcast episode from Indie Hackers about the founder of Key Values, Lynne Tye. The name and logo is also great, as a development reference.

https://www.indiehackers.com/podcast/086-lynne-tye-of-key-va...

GitLab is my favorite company to watch, really hope they someday become more popular than GitHub

I interviewed there, and I thought their compensation strategy was disappointing to say the least. They basically pay bottom tier in every economic zone, and despite being a remote workforce, don't accommodate local economic situations.

I (an American) was temporarily living in Argentina. They wanted to pay me in Argentina pesos (that have a 20% inflation at the time, but currently around 50%). I mentioned how I plan on returning home to SF. The pay band was less than what I made at a seed-stage startup.

> I (an American) was temporarily living in Argentina. They wanted to pay me in Argentina pesos

Well .. yes? If you were Japanese in the US would you expect to be paid in Yen? It’s not like you were working for them in the US and they sent you as an expat. I’m sure they would have switched you to USD had you moved to SF

I would expect my employer to work with me and compensate me adequately for my skill level and work done.

Agreed. Not based on my nationality

My residence was the US. I will admit, me working in Argentina on a tourist visa is a grey/black area. My residence to both the US and Argentina government was the US. My visa only allowed me to stay ~3 months.

The point about currency seems like a red herring, since it can be easily converted into USD, etc., but insisting on paying people salaries based on averages in their current location is pretty inflexible and remote-unfriendly IMO.

People may move around and have financial obligations in multiple countries. E.g., if you have a mortgage and school loans in the US, and you want to live in Armenia for 1 year, your employer insisting that you take a 80% paycut due to "Armenian rates" is pretty ignorant and inflexible.

There were 2 problems:

1/ I was on a tourist visa. I did not have a bank account that could accept pesos.

2/ if I had an arg account, the gov limits how much can be sold for usd. [0]

[0] https://www.aljazeera.com/amp/economy/2019/10/28/argentinas-...

My Argentina developer friends don't even get paid in pesos. Why should I (a tourist) be paid in the local currency?

I mentioned that Argentina has 20% inflation and locally businesses provide salary increases every 3-6 mo. They told me salaries are adjusted annually.

I don't remember their exact response when I talked about me returning to my residence in San Francisco.

> that have a 20% inflation at the time, but currently around 50%

Official interannual inflation rate was 94,8% in December 2022.

https://www.indec.gob.ar/uploads/informesdeprensa/ipc_01_238...

I will second this. They get a ton of shit for not properly maintaining projects but damn do they try to constantly be moving forwards even if it’s not always super innovating.

Vercel, Fly.io, Automattic, GitHub, HashiCorp

GitHub's developer culture is producing famously slow and unreliable experiences for users

Example? Curious about that

Doesn't Automattic still require you to cancel any side projects as a term of employment?

Some of these companies can also be found here: https://peoplefirstjobs.com

It doesn't seem to be updated very often though with resources so I am collecting a static list of such companies in case anyone is interested to explore. Obviously it won't fit across the bill but some of the criteria:

- Product-led

- Known for excellent engineering culture

- Outcome oriented

- Remote

- Invest in professional development

- Neither chaotic or beauracratic

- Sustainable & profitable

At Doppler we have a strong culture of engineering excellence, thorough PR review, security, automation/CI, and helping each other succeed. We give engineers 30% time to work on things they think are important and are remote first (but also have an office in SF). Our engineering team hangs out in Discord all day to make pair programming/debugging easy. It helps that our CEO used to be an engineer.

Too bad you guys ghosted me after my take home assignment :) (totally rocked it btw)

Our process never includes ghosting anybody, even when we pass on a candidate, so something must have gone very wrong here. Could you email me at thomas@[company domain]? I'll look into this further.

Welcome to flaky startups wallowing in internal chaos.

I don't have firsthand knowledge, but based on their product I get the feeling Discord must have an amazing dev culture

Same, I sent them a resume basically saying this but no bite, unfortunately.

I don't have the link right now but apparently Spotify didn't follow their own squad stuff that they put out into the industry.

Airbyte

why?

You can check the details here https://handbook.airbyte.com/