In a nutshell: people who work for Igalia own it (with equal amount of shares, usually after three years in the company) and participate in the assembly (usually after 6 months-a year in the company).
From that premise, our decisions and ways of working are generally very flexible towards employees. Having the same salary (with more for people who live in more expensive countries) or being able to work from wherever you want is just the tip of the iceberg.
Thanks! Basically, everybody who's been here for more than 3 years is a co-owner. I just did a quick count (I might be off by one or two), and I think we're 36 owners out of 41 people. Our explicit goal when we hire someone is to keep them long term and have them become co-owner.
Our workers (including owners) who live outside of Spain (where the company is based) typically have an official status of freelancers, though they have only one client and are as involved in the company as the ones who have a status of employee in Spain.
Thanks for making it clear that you work at Spotify. Transparency is good start :-)
I just watched both videos. Thanks so much for doing these ! Or maybe thank Henrik when you see him, haha :-)
I have a lot of questions.
From what I understand, Spotify squads each focus on one area and each squad has very different members so it can stay autonomous. Is that right? What happens if sysadmin / developer / designer from squad X gets hit by a bus ? I'm actually talking about the bus factor [1] here, I hope you are all well :-)
How often do you change squads ? What about tribes ? The second video mentions "guild unconferences". What is that ? Can squads work remotely ?
How does code review work at Spotify ? For the last 2 weeks, we've been using pull requests on Github, which I've found to be a very good way of doing code review. Since the reviewer is the one to merge, eventually his/her name is on the commit too, which in my case makes me focus even more before hitting the "Merge" button. Merging creates an explicit merge commit, which makes reverting things easy if needed. And discussion in the comments allow for efficient, asynchronous discussion.
The video talks about how important trusting employees is to Spotify. That makes me wonder: do employees sign such things as non disclosure or non compete agreements ? what do you (or what does Spotify) think of such agreement ?
For the last few months, I've been reading the Groove blog [2]. Recently, Alex, Groove's CEO, talked about how much time he was spending talking to customers. How much do you (devs, sysadmins, marketers, designers, etc) communicate with users ?
How do gradual rollouts work ? Do you use a third party service for that ? Would love to learn more.
Hey! Thanks for the long question. I'll pass on your regards to Henrik :-)
> From what I understand, Spotify squads each focus on one area and each squad has very different members so it can stay autonomous. Is that right? What happens if sysadmin / developer / designer from squad X gets hit by a bus ? I'm actually talking about the bus factor [1] here, I hope you are all well :-)
It's not always easy of course. I think the notion of T/M-shaped people apply. E.g. if only one person in a squad can do iPhone development, better spend time training some of the other people to do it as well. It also creates collaboration opportunities, which are highly important to actually make a team work. Then of course there is a lot of fluidity between squads. If squad X needs design help but are out of a designer, squad Y might lend their assistance.
> How often do you change squads ? What about tribes ? The second video mentions "guild unconferences". What is that ? Can squads work remotely ?
It varies. Some people have been in the same squad for two years, others are in new ones every six months. And generally, you change squads and if a tribe move has to happen, that'll happen as part of that. Squads are generally co-located though, so not many squads are remote-composed. A guild unconference is simply an unconference (http://en.wikipedia.org/wiki/Unconference) on a certain area, e.g. Machine Learning, Web, Mobile, Backend etc. So all the people who are interested in that get together for a day and debate the future of that area.
> How does code review work at Spotify ? For the last 2 weeks, we've been using pull requests on Github, which I've found to be a very good way of doing code review. Since the reviewer is the one to merge, eventually his/her name is on the commit too, which in my case makes me focus even more before hitting the "Merge" button. Merging creates an explicit merge commit, which makes reverting things easy if needed. And discussion in the comments allow for efficient, asynchronous discussion.
We use GitHub as well. Roughly the same model.
> The video talks about how important trusting employees is to Spotify. That makes me wonder: do employees sign such things as non disclosure or non compete agreements ? what do you (or what does Spotify) think of such agreement ?
We think trust is highly important, and embodied in what we share internally and how open we generally are. Not sure I can comment on the legal aspects of that though.
> For the last few months, I've been reading the Groove blog [2]. Recently, Alex, Groove's CEO, talked about how much time he was spending talking to customers. How much do you (devs, sysadmins, marketers, designers, etc) communicate with users ?
Never enough :-) We do spend a lot of time with user research, both structured via our research team but also Starbucks testing, when a few devs go down to the local coffee shop and test features. Then we have community outreach teams that keep us honest and makes sure to push the customer voice inside the company. Also, a ton of engineers hang around on e.g. /r/reddit and asks questions. And when users blog about or voice their concerns, it does make the round on internal lists.
> How do gradual rollouts work ? Do you use a third party service for that ? Would love to learn more.
Mostly custom built, and it varies a bit between the backend and the front end. It's all the usual jazz though, deploying per machine or percentages of users or localized to markets etc.
How does accountability work at Spotify? It looks like your squads have a specific goal (and maybe a leader?) but when you get up to the tribe level it wasn't clear if one person is in charge of a tribe, or if a product, design and tech lead all share authority. If that is true, do you guys not suffer from the tyranny of structurelessness? How do you do strategic planning/coordination?
How do teams that are not engineering focused get stuff done? For instance a customer support team or marketing team - would it have its own engineers and engineering management?
Edit: finally, how long have you worked at Spotify with this culture?
Sorry for late answers here but thanks for asking questions!
> How does accountability work at Spotify? It looks like your squads have a specific goal (and maybe a leader?) but when you get up to the tribe level it wasn't clear if one person is in charge of a tribe, or if a product, design and tech lead all share authority. If that is true, do you guys not suffer from the tyranny of structurelessness? How do you do strategic planning/coordination?
Squads don't have leaders, but they do have product owners who ultimately owns the roadmap of the product owned by that squad. A tribe is lead by a trio of engineering, product and design. Responsibility for the various facets of the tribes output is divided between the three roles.
> How do teams that are not engineering focused get stuff done? For instance a customer support team or marketing team - would it have its own engineers and engineering management?
Yeah, the tech/product side of that have homes in tribes as well.
> Edit: finally, how long have you worked at Spotify with this culture?
I've been here 2.5 years. This structure has been in place for roughly three years, maybe a bit more.
I recently spoke to a recruiter at Skyscanner, and he mentioned that they have also adopted a similar model to Spotify. He called the model "Squads and tribes".
I work for Skyscanner, and can confirm this. It's a very effective model for managing a business this size, and IMHO fosters innovation within the business. Very basic description of the model as it is at Skyscanner:
Tribes - High level products (hotels, flights, car hire)
Chapters - "Departments"; areas of expertise (data acquisition, front end)
Squads - Autonomous project units (New features, development of an existing feature)
Guilds - Informal interest groups (Linux, Python, agile development)
Everyone is in a Tribe and a Chapter relating to their "department", and area of expertise; Squads are formed to work on projects, then disbanded once the project is finished; anyone can join and participate in Guilds, which serve as interest/support groups for technologies/strategies/methodologies.
Edit: Corrected my brainfart. Thanks ssabev! Can't believe I did it twice...
That's a good question. I think about it as a way to distinguish from e.g. departments, projects etc and set the connotation that these are different things. If you use them to mean a 1:1 mapping to e.g. projects, then it falls apart. The terms aren't important per se.
In other words – you can't make a race horse by painting a pig brown.
Cool to hear our model is getting adopted. A big difference here is that chapters at Spotify aren't departments, they are usually fairly small (5-10 people), and that squads are long lived, rather than project focused.
Never worked at Spotify but they seem very innovative (and they already let me rock out for eight hours everyday), so hey, nothing to bad say on my end.
They're also great supporters of the London Python scene (also another good indicator of a good company to work with).
(Note: I used to do sub-contract work with them. The first thing that happens when you work with them is you get sent a copy of one of Semler's books on the subject.)
We've been doing Open Allocation at Monk Development (http://www.monkdevelopment.com) for about a year now, but haven't yet written anything about our experiences.
I'm very interested in this question as well, especially companies in Amsterdam, Berlin, Hamburg and Copenhagen. Anyone else know of companies doing things differently?
As an end user of Atlassian products - their support leaves a lot to be desired. Not sure if that ties in to "doing things differently" but there you go.
There are lots of tiny companies (2-20 people) that can "wing it", but it's difficult to make decentralized or distributed decision-making work at scale.
We're a slightly larger team (almost 50 peeps) at Axiom Zen (https://axiomzen.co). Our entire raison d'etre is predicated on coming up with interesting, high-risk ideas and carrying them through the various stages of market validation, prototyping, iteration, and growth. Because of this, we are working really hard to become and remain the best place for brilliant people to build awesome things.
We try to clearly define our values (just like Valve/GitHub), build them into our products, and use them as a heavy filter for hiring. We also go out of our way to ensure total transparency in the team, using GitHub for everything from sales to hiring so that everyone can see the stage everything is at, decisions leading up to a particular status quo, etc. Also everyone has an equal voice in jumping in to suggest / push forward changes.
Not sure if this fits the bill, but I've always found the openness of Thoughtbot quite impressive. They have an open "playbook" describing how they operate and develop. http://playbook.thoughtbot.com/
I love this model of working, but I think it's a lot more common in engineering teams than people realize. My company isn't anything special, and certainly most of the rest of the company doesn't work open allocation, but the engineering team pretty much does. You work on what you want, and you tell people what you're doing. Does anyone else feel this way?
It's not formalized in any way, but we have a small team that works this way. I would imagine it would be hard to scale, and takes the right sort of people, but it's a really great environment to work in. We are constantly experimenting and everyone is welcome where they feel they can be helpful - our video production team is deeply involved with the devops side of our streaming server for example...
Exactly. I've worked in several small companies and it used to be a case always... I guess the challenge is to have a similar structure in relative big organizations (e.g. 200+ engineers).
There's definitely pockets like this where I work (Gov't agency), but these pockets are still floating in a sea of the expected waterfall bureaucracy. It's basically up to team leads/PMs to decide if they're going to act as a buffer against that or not.
Not sure if it's in the same bucket as Valve or GitHub: at Mobile Jazz http://mobilejazz.com we're only 20 people (and that makes things a lot easier), but we've quite a different way of working compared to traditional companies:
* We pay fair salaries. For most people in our team it's way more than what they've earned before.
* We pay everyone the same (base) salary. Regardless of their role or title.
* We pay quarterly bonuses based on pro-activity, responsibility and other performance indicators.
* Everyone can work from wherever they like, still many people choose to work from our main office in Barcelona. (For example I work many weeks out of my camper van with 3G/4G connection from beautiful surf locations)
* In theory, everyone can choose how much or how little they want. Not always possible, but we try to make it possible as much as we can.
* We have managers, but they don't demand things. They are responsible that certain things happen, but decisions are being made collaboratively.
* All managers are either engineers or designers. No bullshit managers.
* We don't have a dedicated sales person. All work we get is from word-of-mouth and the first person a new client speaks to is either an engineer or designer (or both).
* We play Mario Kart / StarCraft after lunch ;-)
* We do a lot of sports activities together
* We have a lot of BBQs on our terrace
* We use some of the profits for fun internal experiments
(small projects without an expected outcome other than having fun & learning). However, some of them are now actually turning into actual products: http://bugfender.com/
* MJ University: we take online classes together as a group
* MJ Talk: weekly presentation about an interesting topic (not necessarily tech related). For example we had talks about personal finance (investing), achieving happiness, etc.
* We encourage pair programming where it makes sense
* MJ Retreats: we're going to remote places and work there together. At the moment six of us are on an island in Thailand. In February we go skiing in Austria.
* We put a lot of effort in hearing everyone's opinion and feedback and try to put it into action
With all that we've managed to attract and retain incredible talent, but most importantly we have a very pleasant time together.
That said, we're a company optimizing on lifestyle and happiness, rather than profit. So this way of running a business is probably not applicable everywhere.
However, sometimes we might think that taking the whole company to these great places is the best thing to do, but people tend to end up marrying, having children and getting tired of going to a beautiful island with their workmates when they could just stay at home with their family.
Work/life balance is not imposing our view of a great life to our coworkers. I'm sure you guys are cool with that and you've got a thousand more reasons to be a great place to work, but I wanted to raise this.
We make those things optional. We're at the moment on Koh Samui with 6 people, while the majority of the team is still in Barcelona and a few others at random other places.
Everyone should do what they think is right for them in their current situation. We just want to give options :-)
Pretty amazing. Are the founders/management team working towards what might be considered a high rate of growth or an incremental one? In other words, is the staff level, revenue, expenses, and earnings in some way optimized at the current level? Kudos for focusing on your people- this mix is difficult to achieve for what I am assuming is a bootstrapped business and impossible in a venture-backed one.
To be honest, we haven't put too much thought into the business side of things. We've been growing organically from two people (the two founders, I'm one of them) to now 20 people and things always somehow worked out. We're still learning ourselves, though. Pretty much every day.
Revenue and expenses are relatively stable. We've some really good quarters, and some not so good ones. But overall we're profitable. Sometimes we also spend a lot of money on "fun" things without thinking too much and then realize later that we need to be a bit more careful with spending ;-) In particular cash flow issues when waiting for the big corporations to pay their invoices.
In terms of staff, we're actually at the moment not growing that much any more, simply because having too many people makes it difficult to run such a business as the "family & friends" feeling gets lost and we'd probably need to introduce more hierarchy, which we also don't want.
From past experience, there are two danger points when growing: 25 employees and 50 employees.
At 25, you stop meeting everyone every week. i.e. Random encounters no longer guarantee that every person in the company keeps good contact with everyone else.
At 50 pax, you stop knowing everyone. i.e. You may know the list of employees by heart, but you don't really befriend them anymore.
Of course, these are soft trigger points. You start noticing something different at 20 people, and are sure of what is happening at 30. It is definitely not the fault of the 25th hire :-)
The remedy is always the same: Company culture. Growing slow is a good ingredient towards a good culture, albeit not the single ingredient.
Thanks for that. That's the way we feel as well. We don't have the need to be a huge company. We're quite happy with 20 people and grow slowly now with the right people.
Depends on the project. We've clients ranging from tiny startups up to huge multinational companies. So we usually adapt to their preferred processes with some recommendations from our side.
We're currently at around 53k€ for someone who works full-time, which is slightly above average for Germany and very high for Southern Europe, where most of our people are from.
We also have a few from Latin America, Eastern Europe and Mauritius, where this is also a very good salary.
We weren't looking specifically in those countries nor are we limiting ourselves, but it simply happened that we found people through contacts in our personal networks.
Have you had any resistance on that from folks in the US? I live in a very average/slightly below average cost of living area of the US and that's probably 8-10% below what most places around here are offering a developer with 3-5 or 5-7 years of experience.
I also noticed that you bonus folks based on pro-activity and other measures, which presumably plays a pretty big role in the decision-making process?
We've only spoken with people in SF and NYC, because that is where our US network reaches into. However, developers there are too expensive for us (at the moment), so it doesn't make much sense.
That said, we've noticed that many people care much more about the freedom and flexibility we over, rather than having a huge salary, as long as the base salary is fair.
With the bonus we want to encourage everyone to think and act like a co-founder. Take responsibility and action where needed instead of just ignoring problems until the shit hits the fan.
There's no general number. It depends on the clients. We have huge companies that pay very well, but we also like to work with startups on interesting projects. If we're really interested in a project we usually try to figure out a way to make it work for everyone.
Interesting. Another thing is, how do you determine market price for the project? I mean, your prospective clients might also ask quotes to competing agencies. So how do you know your price is competitive enough?
You never really know. Sometimes you win, sometimes you lose ;-) But I think in the end people work with us because of our honesty, transparency and the flexibility to adapt to their needs: http://mobilejazz.com/philosophy
We also had cases where potential clients decided to go with a cheaper option and then came back to us to "rescue" the project.
In the end the price itself doesn't say too much. More important is the value you get for that price and that is different for every agency. There are things like quality, being pro-activity and recommending the right things to do (not those that make the agency the most money), experience beyond pure design & development (e.g. marketing apps, getting featured, high App Store ratings and reviews, etc.)
Gore is a widely known company that does. However, a review of their glassdoor profile shows it is not as great on the inside as the marketing makes it out to be.
Nice recap. I had a friend who worked as a sales guy for Gore (his company was acquired by them). He said that he couldn't "order" anyone to do anything for him, so he had to spend all his time sucking up to people just to get any needed support.
Good point. I think it was the organization. In a large organization, you can't do everything yourself. "Can I get last year's sales figures for client A?" "When I get around to it." "I'm meeting with them next week." "Sorry, I'm busy."
It sounds pretty similar to most large organisations. In particular:
"Now instead of getting work done, people will dedicate their time to internal politics and jostling for group position"
Internal politics and jostling for group position happens in every large organisation I have worked at.
"unresolved because nobody could assume the role of dictator and push through needed work prioritization schedules"
Again, at every large company I have worked for the "dictators" of successful projects were rarely the people with official ownership of the projects or people high up in the org chart. So I'm not sure why nobody could assume the role of dictator.
One of the things that formal organizational structures provide is a set of tools you can use to fix logjams when consensus-building isn't possible.
By building an organization only on de-facto group dynamics, you toss away all of those tools and you have literally no option but to play along with these informal processes.
One of the few things modern management practice has identified for success is that informal processes need to be brought under some semblance of organizational control or they become incestuous and optimize for local efficiencies rather than enabling the entire organization to be successful.
>Again, at every large company I have worked for the "dictators" of successful projects were rarely the people with official ownership of the projects or people high up in the org chart. So I'm not sure why nobody could assume the role of dictator.
Here's how this works in flat organizations
employee a: I need you to do this
employee b: no
and that's the end of the story. Sometimes, if the organization is setup according to some kind of flat org theory you'll get these steps also
employee a: well I'm going to take this to committee
employee b: ok
<months pass, committee meets>
employee a: I told employee b to do the thing and he said "no"
employee b: employee a was acting like my boss and we're flat, I didn't feel the need to give into his demands (committee members nod in assent)
committee: we've decided that employee b does not, in fact, need to do the thing
and now the thing doesn't get done
Here's how it works in a grown-up organization
employee a: I need you do this
employee b: no
employee a: boss, I need b to do this for <business reasons>
boss: employee b, do the thing
employee b: no
boss: rethink that
employee b: okay, I'll do it
souls are crushed, free will is diminished, but the thing gets done and the company moves on
However, more importantly, many so called "flat" organizations are not, either formally or informally. Informally they'll all succumb to informal group behavior that all humans exhibit in groups of more than 1. Formally, they'll all have some kind of hierarchy, but will attempt to hide it or obfuscate it in some way. This is usually tested trivially by offering to swap a low-level employee with a high-level one and seeing if it actually happens (hint it almost never will)
Ok then, the 'flat' organization devolves into a hierarchical one where you have to ferret out the real structure (or guess). So that a/b scenario never happens, even in the flat company.
Except the structure in a flat organization is all ad-hoc, there's no teeth behind it. Just because Joe in accounting talks loud and operates with charisma doesn't give him dictatorial powers backed by "do it or you're fired" powers.
It also means that when shit goes wrong, there's no "buck stops here" person who's ultimately responsible. Joe can always argue that he's just a member of a committee and defer responsibility to everybody else, and use his charisma (and probably a backlog of favor trading) to scapegoat somebody else.
The most important thing is that all this is a distraction from the business of the company. All this time that Joe has to invest in gathering and cultivating meaningless power that he shouldn't have, and putting in place an invisible power structure that everybody around him has to navigate...could better be spent doing, I dunno, accounting perhaps?
Flat structures tend to work only when organizations are very small, or can be compartmentalized into very small groups, but there's tacit acknowledgement that even in those cases there needs to be a formal dictator to make sure the ball is moving forward and people aren't wasting time in power brokering exercises. When the organizations get large, it becomes a necessity.
You didn't specify in your question - what size firm are you thinking of?
There are lots of small firms (ie, ~5 people) who use this approach. Arguably, for a team of 2-5 people, it's the most natural strategy anyway.
The challenge, of course, comes with scaling this to a team of 50 or 500 people. At that scale, there are far fewer examples (though the comments in this thread point out some exceptions).
Assuming you ask because you're looking to find a place to work, in addition to the other names mentioned here, you may want to look at very small companies as well, because the odds are very much in your favor of finding one. Just be aware that the team dynamics may change as the company grows, which you may find you like, or which may mean it's time for you to look for your next step.
thank you. I am not looking for a place to work actually, I am working on a research project and at the moment i am interested in everything that is out there. but of course, I am interersted in companies that actually have to do some thinking about organisation in order to get things done
I'm not sure what others experiences are but for me it's mostly the same but also different in some ways than in the past. The biggest change is that there's more structure in some key places.
For instance there are a few PMs now for very involved projects, and we have engineering managers to make sure we're getting along ok and not falling between the cracks (turns out 100+ people reporting to one person can be tricky), but still remains enormously open.
Most decisions are made in the open (if they legally can be), there's almost always a Pull Request with discussion around it if you want to either take part or just see how that decision came around. The culture is pretty allergic to anything closed. People frequently ask for a URL if they're curious how a decision was made. This makes it much easier to not feel left out as a remote employee (which something like 60% are).
As an engineer I can largely still choose what I work on much in the same way as before: if there's a project spinning up and I want to work on that project and that team wants me and my team is cool with me going I can totally go work on it.
I've actually been encouraged to work on other things lately to get more perspective on the product and work with new people. I don't feel pigeonholed like I have in some other places.
Teams mostly self organize into structures that best work for them. Some teams look fairly traditional. Some use scrum. Some use some other agile methods. Some use nothing. Some work closely with a PM. etc. Use what makes you happy and what makes you productive. Different projects have different needs.
Things may shift around as growth happens (and they have), but largely I feel like the principles have stayed intact. Still the best place I've ever worked.
Some LinkedIn job titles from current GitHub employees:
* VP, Business Development & Services
* Head of Technology Partnerships
* CIO
* VP, HR
* Vice President, Strategy
* Vice President, Marketing
* VP Communications
* Director of Outreach
* Director of Sales
See also: http://www.nytimes.com/2012/09/09/technology/valve-a-video-g... - "The few employees who’ve put titles on business cards do so to satisfy outsiders apprehensive about working with people without labels. The same applies to Gabe Newell, one of Valve’s founders."
(no idea whether this is the case here...)
One of my former colleagues had this sort of experience at one job, where his job title was "programmer" (you got this title if you were a programmer; there weren't any others available). He was finding it sometimes difficult to get people to return emails, presumably because he didn't sound important enough. Apparently the last straw was being roundly ignored in a particular meeting with one external company! A swift title upgrade (no changes in responsibility...) fixed all of this.
I feel like this describes my present employer. The company culture emphasizes that everyone should experience maximum Autonomy, Mastery, Purpose, Transparency, Empathy and Fun in their job. Hierarchy is way less important to us than getting results. We're in Toronto and we have more about this at our website: https://nulogy.com/
Ah! Josh, your name was familiar to some of my coworkers!
A couple of points to answer your questions:
- We do centralize our product strategy and portfolio planning, but we decentralize our release and iteration planning.
- We focus on building strong teams of diverse talent sets that are becoming more self managing. Teamwork is big for us, flying solo on any task is rare-r than in other places I've worked.
- Our management (and everyone else) are really accessible for a medium sized company. I have faith that if I sent a calendar invite to our C*O for a 15 min chat on a free timeslot, they'd show up. Of course, respect goes both ways and I wouldn't book their time unless I really needed them specifically and it couldn't be handled asynchronously.
Monty Widenius published the http://hackingbusinessmodel.info/ which they were using at MySQL AB (before Sun I think). I don't think they use this at MariaDB Corporation. We try to use this at http://axai.com.mx, a small company I belong to in Mexico.
We do this at Olark to a large extent, but I don't think anybody has written about it in any detail yet. We have a peer-driven project proposal process that allows anybody to propose a project, and then "vote with your feet" to get it done. It's still pretty new, but I'd guess we'll write about it once we have a little more experience with it.
Ok this is a little off topic but maybe someone can tell me. These orgs make a huge deal about how salary is selected by your peers. How does that actually work though? Like the detailed logistics of it? Who exactly picks what you'll get? How is the final decision made?
Galois has a pretty flat structure, and employees can choose what they work on among the currently funded projects (they do mostly grant-funded research).
In a similar vein, there is http://agaric.com/about which is also a software cooperative (or collective? are those the same in the US?) doing Drupal work.
At Buffer we've started to move in this direction. I can highly recommend watching this video if you're interested in self-management and the idea of a new management paradigm: https://www.youtube.com/watch?v=gcS04BI2sbk. Frederic's book by the same name also goes into further details and shares several example companies: Buurtzorg, AES, Morning Star, FAVI, RHD and others.
I remember two firms from previous HN posts that stuck with me, Fog Creek and Balsamiq. Joel's methodology might be a little complex, but it makes sense.
We have a flat structure with no technical managers at Smarkets (London). Engineers self-organise into projects. Projects are self-directed and members of the project appoint a lead and have quantitative goals. Salaries will be set from anonymous peer review. We're a team of 11 engineers.
If the organizing method at Valve is so great, where the hell is the third episode of the Half-Life 2 trilogy? I've been waiting 7 years for god's sake.
Do you have any information on how exactly Attlasian works (links to some presentations/posts would be great)? From what I know they are not even close to Github/Valve kind of flow. But I might be wrong.
I don't think that is what was meant by OP. I think they were asking about the atmosphere/organization inside of the company, rather than companies that allow people to collaborate.
In a nutshell: people who work for Igalia own it (with equal amount of shares, usually after three years in the company) and participate in the assembly (usually after 6 months-a year in the company). From that premise, our decisions and ways of working are generally very flexible towards employees. Having the same salary (with more for people who live in more expensive countries) or being able to work from wherever you want is just the tip of the iceberg.