> The organisation quickly adapts to this balkanisation and optimises for it.
That is a very good point. Once you have a company optimized for individual work, as opposite to team work, any collaboration is seen as wasteful as the company has reached a local maximum.
> It means in some cases giving anyone the autonomy to make some choices, but giving someone with more expertise the autonomy to override those choices.
This working very well in some Swedish companies. (In some places it falls into the no-body decides so the default ends winning, trap). But, I have seen it working most of the time. A team own the product, the team has its own internal dynamics and power-structures. They have a lot of autonomy, know well the technology and the product. Architects, Technical Directors, and the like barely override any team decision if at all.
In Spain it was the opposite. It has a very top-down company culture. I think that Spanish software developers work 20% to 30% harder that their Swedish counterparts. But the team is building something that is in the brain of an Architect or similar role, the team does not know the product, the team does not choose the technology. The result is many hours working and in meetings for low output. (And very unhappy employees, you want to go to Spain on vacations and not for a job).
I agree with most points of the article, and it is a good though piece.
There is a subset of Spanish companies where this doesn't happen and it's actually frowned upon. But it's a specific network of (successful) companies, And you've got to know where to apply - if you choose a company at random, it's very likely it's going to be like you described.
I think it has to do with where the money is in our society. Investors and founders are very unlikely to have technical knowledge or be involved with technical people, so their mindset is that they are hiring people to tell them what to do like you'd hire workers to reform your house - they don't want their input, they want "muscle" to do the job.
Then the company grows in sort of a two layer structure, with the product guys at the top being completely ignorant of tech and the engineers below following orders. The result is usually a toxic environment where engineers group against leadership who are perceived as idiotic slavers.
Engineer culture is partly to blame as well. Tech people have pretty easy access to a job market that's quite good compared to the rest of the country, but there's quite a lot of cultural friction against people leaving a job to improve their conditions - there's a mentality that known evils are better than jumping into the unknown. So leadership has little incentive to change.
Do you think this has something to do with traditional Spanish culture? Ex-Spanish colonies are also notoriously led from the top down, and I read an interesting theory that the reason the Aztecs were so easily assimilated vs indigenous North Americans is their rigidly hierarchical organization allowed the Spanish to essentially hot swap themselves into power.
I think it has to do with culture, but not in the way you suggest. Up until the mid seventies, Spain suffered a dictatorship that followed a bloody civil war. That means that for decades society had very little social mobility and a lot of cronyism. Scientists, artists and intellectuals in general were purged during the war, looked down upon later, and the inherent censorship and closeness of authoritarian governments made the country culturally barren.
Many decades have passed since then, and nowadays Spain is of course a fully developed democracy, but the remains of that society still exist. It is present for example in the value given to stable jobs by the low-middle class, where people basically assume a glass ceiling - "why take risks changing jobs or try to start a business? You don't have the contacts nor the money anyway".
The lack of people with technical backgrounds in the upper class is also very evident: In the US you'll find many engineers that later went for an MBA and moved into leadership positions, and many companies have engineers as founders. Here, business administration is a career, not a masters degree, and for people who graduate in such programs, it is assumed that they already have the money or the connections to start their careers already in a leadership position - they practically choose "boss" as their job description, so to speak.
there's also the whole racism thing. north american settlers basically wanted nothing to do with the natives, except to claim their territory. we have a folktale of the one time a white guy and a native girl got together and it was "a big disaster". latin america has its own racism problems, but there was way more race mixing which is probably a more important diver of assimilation than who controls the power.
As an Spanish guy currently working in Japan... if you think Spain is very top-down, the meetings are endless, and employee satisfaction is low, I can tell you it can get much worse. If I didn't have a Japanese girlfriend, I would go back without thinking twice.
As the old saying goes, we don't value what we have until we lose it. Although on the other hand, I left because I was tired of asshole bosses...
> Architects, Technical Directors, and the like barely override any team decision if at all.
I would be interested to see how the products turn out in the long run, when the team decides on architecture A but the company as a whole bets on architecture B, e.g. the team likes AWS but the company wants to use Azure.
There's a joke in the US: "A camel is a horse that was designed by committee."
Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians.
But they ain't horses.
There's a lot to be said for a single, focused, experienced, architectural "czar."
As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture.
Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle.
But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes."
I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.
I think rather than a single person, you want exactly two people who have to agree on something to make a decision; and if you can't get to a decision, it's probably a sign you need to solve other problems first.
That way, there's someone who can challenge your opinion and you have to convince them to agree with it or find an alternative. Often during the convincing part you identify issues that you wouldn't have thought of by yourself, and since you don't have ultimate authority by yourself, you're less likely to unintentionally shut up someone who wants to disagree but defers to authority.
That is a very interesting point, and it is solved in negotiations between the teams. One team cannot use a technology that forces another team to change theirs. That will take away the autonomy of one of the teams.
e.g.
If one team decides to use Protocol Buffers for their public APIs instead of HTTP/JSON that is the standard, that needs to be discussed at a higher level. As that decision forces other teams to change their tech-stack, one team cannot make that change unilaterally.
If the team's application is composed by several micro-services and they want to use Protocol Buffers for their private/internal APIs, that is not a concern for anyone else.
The directors or architects will be arbiter of the discussion to make sure that it is taken fast and everybody opinion is weighted in. And, if the end there is no agreement, then the director will take the decision to keep things moving.
The main downside of this approach is when a team changes project and ownership of the code changes hands. In that situation you get a tech-stack that you may not find attractive. Usually the team will end changing that tech-stack to something they are more comfortable with, but it takes a long time.
They did say "barely". I'd imagine "we want AWS just because" would be one of those scenarios.
The rest of it doesn't have to be an explicit override, but asking the team for clarification: "You've spec'd out A but we do have B that is similar, is there something missing from B that you need?"
There would be some sort of process for coming to a decision on choices that have broad impact. The same way there would be a process within a team when different individuals disagree on direction.
The problem with a top down approach is that the architect doesn't actually know what is actually needed by teams. They're too far removed from the day to day. So you get a uniform but generally suboptimal set of technologies.
Ireland has higher pay, but not necessarily better management, or even quality of life (at a typical developer's wage). Ironically Spain's workforce is full of Argentinians for the same reason the Spanish want to work in Ireland.
There's a lot of international companies setup in Dublin due to the beneficial corporate tax rates available to them, which then creates a lot of jobs. Cue immigration to Dublin.
Oh, that one is not popular around here. I guess it's safe to assume that if you listen a Portuguese phrase followed by "boss", the actual meaning is the exact opposite of the literal phrase meaning.
Teamwork can be cooperative or collaborative (with most being somewhere in between) and I think it is important to be clear which type you are aiming for. Cooperation is like having a party and everyone brings their own food item to share with everyone else. Collaboration is everyone in the kitchen working to make the meal.
Certain tasks suit themselves better to cooperation or collaboration. I am not a programmer but it seems like collaboration is harder with programming?
I think you are right. Every line of code contains a massive amount of implicit knowledge. To collaborate, that knowledge must be shared, which is expensive.
Things like continuous integration are designed to make collaboration easier.
The old style of programming was supposed to be like your "everyone brings a food item" example, but there were always hidden gotchas: maybe everyone brings dessert and there is no main course.
Continuous integration is like putting everyone in the same kitchen, so that even while people are doing their own thing, it's possible to notice such conflicts early.
Thank you for delineating between cooperation and collaboration so clearly. Your comment and this article helped me to understand the differences between teams I've worked on.
I've moved from collaborative teams to more cooperative teams without really being able to put my finger on what the missing magic was. Collaboration is a beautiful thing and results in much more robust results, however it can seem nearly impossible to collaborate at times. This is a very rich and nuanced subject, imo.
There is a valid criticism everyone can agree with, but the "solution" is really vague and hand wavy. There is basically no solution. This is a communication and people problem as old as social structures, and the only thing you can do is compromise based on your abilities, powers of persuasion and insight as to what works best for other individuals you're working with.
If Yevgeney is good with CUDA, maybe ask if he also likes to only do CUDA stories, and also ask his teammates if they want to learn CUDA, and give them the opportunity to do so. It might be that no one does, and he's happy, or it might be there needs to be a switch, but you have to ask. This is not really about a democracy, it's more about communication and the optimal decision can be made voluntarily, or it can be "forced" because not everyone likes compromises.
Um, I'm not much of a team player. But when I did work with other people, if I had to write some crazy graphical interface or a 2D UI over a 3D game or something, it was much better to do it on my own. I'd just write a VERY GOOD API and let the others hook into the code. Document and comment everything so I can walk away from it and let other people take it over.
The kind of organization you work for sounds like both a soulless nightmare AND an incredibly inefficient waste of human potential.
In both Spanish and Portuguese, the word "mate" doesn't have a diacritic, but moreover the stress syllable is "ma", not "te". So, even if a diacritic was granted, it should be "máte" rather than "maté".
I have seen the greatest success in self organizing teams when they have a strong leader with clear values that enforces a vision.
I think self organizing is a bit of a misnomer, it's more like self organizing within the system of checks and balances that the leader has developed to ensure the values are being played out in the day to day work.
For instance in our teams we've introduced one of our values as cross training, one person shouldn't own any part of the system. Our team leads keep an eye on individual contributors and if we aren't getting enough cross pollination the team lead will intervene.
> The answer is to reconstitute the team – preferably along self-organising principles [...] This means radical democracy for some issues, (agreed) tyranny for others, and collective ignorance of yet others.
This is pretty much how we run things now. The harsh reality is that some people are better at some things than others, and as a business you really want to keep the right people working on the right things. Distracting team members with unnecessary all-hands status calls and other detritus is a big part of what burned our organization over the last 3-4 years.
The quote that keeps popping into my head on complex design questions is "too many cooks in the kitchen". Design/work by committee, unless you are just taking some new employees along for an educational ride, is a gigantic timewaster and will likely result in a shitty end product. Put the best greenfield developer on the new thing, and let them present it to the group next week, and then decide if you need to have one of those ridiculous 20 person design meetings.
The remainder of the post after "The answer is" provides no answers to someone wondering how to change this about their team. At best, it's a collection of mnemonics that remind someone who already knows what to do that they should do it. At worst, it's a collection of buzzwords that could mean any number of different things to different people, with described outcomes that are so vaguely positive that they amount to "just make the team right, you know?"
I once worked on a team that attempted to solve this exact problem by requiring all devs on the team to work in pairs all day, every day.
We would have a standup meeting together every day, then we would pick tasks to pair up on. Code was written TDD style, with the devs "ping-ponging" between writing tests and the code to satisfy the requirements of the tests.
The team consisted of two senior devs, one mid dev, and three junior devs.
Pros:
- Everyone on the team had at least a shallow knowledge of the entire codebase when it was all said and done.
- The code was fairly well tested (except for certain parts that interacted with third party services and were almost impossible to test).
- Some of the junior and mid devs improved their skills fairly significantly over the course of the year.
Cons:
- Development was ploddingly slow due to the insistence on pairing and TDD, with multiple deadlines being missed along the way. The project took more than a year to complete, when I know it could have been completed in a tiny fraction of the time if different development practices had been followed.
- Pairing for hours on end with other devs is stressful and often brings out the worst in people. Heated arguments were very common.
- Lack of individual recognition for excellence. There were quite a few times when I (as a senior dev) was put into situations where it felt like I was doing all the work, but wasn't getting the appropriate level of credit for it. The code would have my name on it, but every commit was also signed by the other people in the pair at the time (even if they were just watching). This normally wasn't an issue, but there were a couple of times where I built some really unique and clever/patentable solutions to problems, and the credit/recognition was essentially given to other people. It was especially demoralizing when it was time for raises and all the juniors got massive raises for doing so well (even though I was the one who did the bulk of the actual work while they watched). Meanwhile, I got a barely noticeable raise just to keep up with inflation.
I agree the post is great (which is why I submitted it) but I also found the last couple of paragraphs kind of a let down, after nodding along enthusiastically for the rest of the article.
The article links to this other post on a similar topic https://www.sicpers.info/2021/03/one-person-per-task/. The advice there boils down to "hey, remember agile? Not just the 'use Jira' but, but the rest of it. That was a good idea!"
> Basically all forms of collaboration become a slog when there’s no “us” in team. Unfortunately, the contradiction at the heart of this 19th century approach to division of labour is that, when applied to knowledge work, the value to each participant of being in meetings is minimised, while the necessity for each participant to be in a meeting is maximised.
And finally put into words why meetings are such important but painful activities.
The balkanisation issue mentioned is associated with silos. After division and creation of fiefdoms, silos are creating to maintain control but to the detriment of other groups.
I sometimes have a cynical perception that this “avoiding silos” approach is really about limiting individual career progression and mobility. If someone can say “I built subsystem X” then he has an accomplishment he can point to, get promoted on, get hired for by another company needing a subsystem like X.
On the other hand if someone built 1/8th of everything that was built together he can be kept at entry level in the same company forever.
Autonomy, mastery, purpose - all these things come from owning a silo.
Pair programming is a great way to make two people do the work of one, while sweating from stress of the forced close interaction :).
Well, OK. I've heard some teams can pull this off. I've never been in one, though. The problem I had when I tried (beyond the tension from lack of personal space) is, you really have to coordinate a lot of cognitive functions together. I found pair programming easy when it's just one person typing out something trivial, and another checking for typos. But it gets exponentially more difficult if the task is non-trivial, requiring some thinking and exploration up front. You now have both programmers cycling through ideas in their head, with the stress of each idea being subject to immediate evaluation by a co-worker.
The way I see it, successful pair programming requires the kind of brain tuning they did in Pacific Rim - the people involved must be "drift compatible", or else it doesn't work.
The only way I ever saw pair programming work was when doing team projects during university, other than that it always feels like yet another branch of agile ideology.
It is the whole stand up routine again, with who types what, how much time the keyboard is given to each one, ....
Pair programming is often mentioned as one way to speed up code delivery as review is included in the activity.
But as you put it, any non-trivial task, e.g. where you're creating multiple new classes and refactoring along the way is hard to do with pair programming.
The review you do when pairing isn't a proper review though. The point is to have someone who wasn't there during implementation look at it, while with pairing both people will have similar biases about the code.
As a software engineer, I think this belief is incredibly naive. This is like saying "surgeons should be fungible. They all have a grasp of anatomy and are good with scalpels". As a patient, do you really want a knee specialist doing neurosurgery? As a customer, do you want a frontend web developer writing code for 8bit microcontrollers? They both write code into a text editor, what's the difference?
I've worked at companies that (implicitly) held your belief and the turnover was always incredibly high because nobody sane wanted to work in a place that treated them like a cog.
> it goes against my belief that software engineers should be fungible, while subject matter experts are not easily fungible.
This implies that software engineers either aren’t SMEs, or that they are exclusively so in an undifferentiated way in the domain of “software engineering”.
IME, that’s doubly untrue: software engineering is a broad domain, and software engineers do not have interchangeable competence in that domain, but also software engineers tend to become SMEs in the application domain(s) in which they work, and this is important to their value as software engineers in those domains.
How about we treat people as adults capable of negotiating and discussing what they do and want to do? This problem then does not even arise.
Teamwork is difficult because being an adult is difficult. Just solve the adult problem and you’ll see that the rest of it comes together pretty easily.
That is a very good point. Once you have a company optimized for individual work, as opposite to team work, any collaboration is seen as wasteful as the company has reached a local maximum.
> It means in some cases giving anyone the autonomy to make some choices, but giving someone with more expertise the autonomy to override those choices.
This working very well in some Swedish companies. (In some places it falls into the no-body decides so the default ends winning, trap). But, I have seen it working most of the time. A team own the product, the team has its own internal dynamics and power-structures. They have a lot of autonomy, know well the technology and the product. Architects, Technical Directors, and the like barely override any team decision if at all.
In Spain it was the opposite. It has a very top-down company culture. I think that Spanish software developers work 20% to 30% harder that their Swedish counterparts. But the team is building something that is in the brain of an Architect or similar role, the team does not know the product, the team does not choose the technology. The result is many hours working and in meetings for low output. (And very unhappy employees, you want to go to Spain on vacations and not for a job).
I agree with most points of the article, and it is a good though piece.