this_na_hipster

I completely agree. Additionally, as someone in the thread pointed out, this decision really doesn't make sense by Dropbox. You have a series of problems that I can't see a solution for.

1) If we have Dropbox Studios, who dictates the frequency of those visits? If a manager dictates, there will be resentment of some sorts. If its a democratic vote, what about the people that can't make that date?

2) Assuming the dates have been finalized, the people that cannot make that date are at a disadvantage. They might not be in driving distance to a hub or for other reasons. That would mean information again has to be propagated back virtually for all members.

3) If a date is set and all the necessary people have come together, is it essentially a company day off? If the goal is to meet and talk to people without doing solo-work, I would assume its filled with meetings or events. If this is true, this doesn't make sense to do it too frequently. If done infrequently, it defeats the purposes of these studios.

All of the thoughts so far don't even go through the cliques / groups that would form that can be gatekeepers of information for true remote workers that can't meetup.

Assuming a theoretical point of view as pointed by the article, there are multiple pieces still missing in my head.

Lets say a traditional software team has these 5 types of people: - Design / XD - Software Engineer - Software Manager - Product Manager - Data analyst or Data Scientist

If you assume all of these roles can be collaborated on a async basis and from within different timezones - that makes progress extremely slow right? Someone emails, someone has a question, someone has a clarification, etc.

Now if we assume same locale, that drastically changes the game since everyone can communicate at the same time even if remote. Therefore, my point#1 is, a global distributed teams that are across time zones really don't make sense.

Keeping in line with the article, let's say a company decides to outsource all these different professions. That would mean, you're even outsourcing management, people that need to oversee are needed to the same region. How high does one go? All the way to directors of each respective field or Vice President? Maybe we go as far as till we reach an owner for a service or product for that region. This is what happens basically today (pre-covid). Each region has a focus in a deliverable. India team is working on X, China team is working on Y, etc. So point#2, outsourcing has to happen not only for people that are executing work, but for people that are overseeing the execution as well.

That finally gets me to the last point. If we have these vertical's of people localized to specific regions, you cannot have specific outsourcing of jobs. You would need a batch outsourcing of jobs from IC's to managers. However, each region a company is in, requires locale specific folks to solve specific problems. Amazon US is very different than Amazon India pay after you receive package, for example. So my point#3, I don't believe we will see too much of a shift for jobs to other countries. We might see a shift in jobs from California to Texas for example.

By now, you might understand where i'm going :-). If you hired enough of a presence in mid-west, suddenly, you now have a pool of candidates that competitors, and other companies can also hire from. You as a company, unless you can spin an entirely new vertical, will back-fill employees from the mid-west again since the remaining team is located in that region. Thereby creating a pocket of talent. Enough pockets of talents will create many companies that want to hire that talent. This is what we effectively have today in major cities. The only difference is, you have a larger area vs a smaller city.

Thank you Guido for all you did for this community. While others have pointed out your contributions to the Python community, I have found inspiration in how you paved a path to the engineering culture all around us. In a time when career progression was to transition into management after a certain degree of tenure, your adamant refusal to stay technical and "just code" has shaped my personal views and my own aspirations for my career. You will always be cherished

This is a problem I have thought about over my career. The TLDR; You definitely need senior level engineers (Principal's & Above) as a career track in a healthy organization.

Here is why - (for the sake of discussion, "principals" refers to principals and above)

- In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political motivation.

- Principal engineers almost unilaterally have a series of noteworthy accomplishments that create a catalyst for innovation for all engineers around. The depth they create inspires people to really understand tech.

- Discussions with them require managers to have more depth themselves. Rarely can managers win arguments without brushing up on tech.

- Regarding some comments about "CRUD apps" as universal easy things all engineers can solve I find perplexing. Problems in distributed systems are all trying to make CRUD possible and organizations are still figuring out how to do that at scale.

- Regarding arguments about ageism for principals, yes, I agree that ageism exists to a certain degree. However, I find most principal engineers are older as you go up the chain. Therefore, what you are really saying is ageism exists for engineers < principal level. Where you can have new hires know the same depth as them and pay less for. Can you imagine trying to hire folks that built S3, Python, Kafka, etc. be replaceable by younger folks?

While I understand Ageism exists, I do see a trend change though. Take for example all these technical tracks in many companies now. All of these engineers are very tenured and usually very experienced(40+). In-fact they are considered irreplaceable by management since they set the vision of the company. Especially in the valley, the trend I notice is that you don't want to lose these "senior staff, staff engineers etc."