Hub-First vs. Remote-First vs. Pod-First ... Skating to where the puck is going to be

Finding good and the right talent for an engineering organisation is as challenging as ever.

And then you need to keep engagement high and attrition low and you need to build/deliver something (with good/high velocity/efficiency/quality).

One key component to get this right is a good/the right structure for your engineering organisation.

And you probably want to structure it in a way so that it not only works today, but also in 2-3 years from now, because otherwise by the time you are done building the org it will not work (anymore)).

Two of the most popular models right now are …

• Hub-first (with a set of engineering hubs in 3-5 (or even more) locations; 80% of the engineers are located/based in these hubs)
• Remote-first (with 80% of the engineers working from home)

In this article I want to talk about how these models (from my point of view) work (or not work) and how a/the model of the future can look like.

Some companies have famously banned/abandoned working from home (IBM, Yahoo, Reddit, …; Note: I am not sure how applicable/relevant these examples are to you (your situation/context is probably different; and … there is also the thought/suspicion that these companies did ban remote work to lay-off people¹)).

Some companies (famously) put all (or at least most) engineers in one place (Netflix - Los Gatos, NewRelic - Portland, …).

But the majority of engineering organisations are run using the famous and well-known hub-first model.

The companies that embrace a no-office or remote-first model for the company (or at least for engineering) are (still) in the minority (e.g. GitLabs, InVision, StackExchange, BaseCamp, Etsy, …²), but the number is growing.

There are studies and lots of articles that suggest that more and more people want to work from home (e.g. because the commute is becoming impossible to manage) and there are studies that show/measure the (increasing) value of working remote (for the individuals and the companies)^{1 3 4 5 6 7 8 9}.

Note: Working remote has become a catch-all phrase/concept for a lot of different desires, e.g. “I do not want to commute”, “I want/need to work from home (most of the time)”, “I want to work only 4 days/week”, “I want/need to work from different locations (in Europe)”). In the context of this article we will only talk about the “pure” remote workers (working full-time and working from a fixed location (mainly the home office)). If people are interested I can write another article on how to take part-time work and location-independent work environments into consideration.

Some of promises that come with the remote-first model is that hiring will become easier and that people will be more engaged (because they work from home and get a better work-life balance) and will be more productive (because there are less distractions).

At the same time remote-first seems to come with it’s own set of problems (e.g. less (or no) long-term employee engagement, loneliness at home, lack of collaboration and communication, not effective, low velocity, slow, …).

For the last couple of month, I have been thinking about this and have started to wonder not only what works today, but also what will/might work in 3-5 years from now (because if you start to build an engineering organisation today you want to make sure you are skating to, where the puck is going to be; otherwise by the time you are done it will not work anymore).

In general we need to realise that we are living in a world …

• … with more and more people (overpopulation)
• … with more and more urbanisation (and the resulting traffic problems)
• … with more and more globalisation (talent is everywhere and is moving around; talent is (becoming) nomadic)
• … with more and more overaging (of the tech population; the average age of teams will go up; means the interest will shift from playing pool in the evening to picking up the children)
• … where the loyalty is shifting from the location and the product/company/deliverable to the craft (I am a backend engineer vs. I work for so-and-so)

Spoiler alert: For the last 20 years I have mainly build and run hub-first organisations, but start to think that hub-first is probably not the right model for the next 10 years. I also think that some (or maybe even most) of the problems that people experience with the remote-first model are not caused by the model, but by a lack of experience how to execute on a remote-first setup (and/or a lack of awareness for the particular problems you can experience when you build/run a remote-first model (and what to do about them)).

To put some structure in the discussion I will use the terminology that was introduced by Spotify when they talked about how to structure an engineering organisation (namely Squads, Tribes, Guilds, Chapters, …).¹⁰

Let’s also simplify the discussion by assuming that we have already agreed that delivery squads are a good idea and that these delivery squads need to be co-located.

Note: Independent from the organisational model (hub-first vs. remote-first), not co-locating the work (in a hub or in a timezone) is a total anti-pattern. If you spread the work over more than 2-3 timezones, every delivery squad will struggle to get something done. And in that case the lack of productivity has nothing to do with hub-first or remote-first being bad models. It is just that you executed badly.

As described in the Spotify model a delivery squad has 3-8 people and is totally integrated and autonomous. It has a Product Owner, an Agile Coach, Frontend-Engineers, Backend-Engineers, … and everything else it needs to be successful. It delivers on its mission. It owns a piece of the overall product and/or a piece of the overall user-experience.

Now … let’s talk about location and co-location and management structures/dimensions.

Basically the Spotify model is a hub-first and assumes that the engineers of a squad are co-located in one physical location (and with that it is guaranteed that the work is co-located in a timezone :)).

Furthermore you can argue that three dimensions of support need to be in place: People-Management, Delivery-Management and Skills-Development. The Spotify model suggest that the Delivery-Management is done by the Squad-Leader and that the Squad-Leader is also the People-Manager. The Skills-Development will be done by the Guild-Leaders.

Now .. can you run something like this as a remote-first model? And the answer is simple: Yes, we can. But … we need to realize that in the Spotify model co-locating the people(more specifically the delivery squads) in an office-location achieved something else. It made sure that the work was (automatically) co-located. And that is the important point. My opinion is that the location of the people matters less, as long as you make sure that all of the people in a/the squad are in one timezone. The work needs to be co-located (in a timezone (plus/minus one time zone)).

Or the other way around (as noted above): If you run a hub-first model or a remote-first model and the delivery squad is spread out over more than 3 time zones you will probably experience difficulties to get the velocity you are looking for.

We are now at a point where we agree that you can use the Spotify model as a base for a hub-first structure (that is what Spotify did) and as a base for a remote-first model as long as you make sure that the Squad are co-located/aligned at time zone boundaries (plus/minus one TZ).

Next I want to take a look at the (perceived) pros (hypothesis/promise/expectation) and the (perceived) cons (the reality) of the structures.

	Hiring	Execution	People
Remote-First	Seems easy. But … when you look closer (see also below) you realize that you are not as free to hire whoever you find wherever you find somebody (e.g. hiring junior developers needs to be considered with care).	Hard, but …doable. You “just” need to make sure the delivery squads (and the work/features they need to deliver) are co-located in a timezone. You then need to adopt all of the good best practices for running distributed agile teams.	Doable, if you hire engineering managers with a lot of experience how to do/run a remote-first organisation. And … you need the entire company to be on board with this. In the best case remote-first is not a/the model for engineering, but for the entire company.
Hub-First	Seems hard, because … you need to hire a role in a given location. But … you can also hire junior talent (and develop it through coaching and mentoring). And … it is (probably) easier to retain people (because it is easier to bring a/the culture alive in the hubs).	Easy(est). Not that I have not seen software delivery projects fail with this model, but it becomes harder to f… it up.	People management for hub-first is different from people management for remote-first. Not necessarily easier, but different. More focus on people development (because in general your staff is less senior).

Remember: Regardless of the structure, you have to co-locate the work (and that just means that the delivery squads need to be organized so that they are in the same timezone (e.g. Finland, Nigeria, South-Africa)).

Both models can work. The secret to success is not in the model, but in the execution. If you are executing on a remote-first model and lack the awareness what this means and/or lack the the proper commitment to make it work, you will fail. And that is not, because remote-first is a bad model, but because your execution/implementation of it is bad. Same is true, for the hub-first model. Too often I am hearing: “We cannot get enough talent fast enough. Let’s implement a remote-first model, so that we can hire people everywhere and faster.”. Be warned: This is a bad reason to do remote-first. You are just exchanging one set of problems (that you probably failed to analyse and understand) with a new/different set of problems (that you do not know about yet). Models are not a replacement for thinking it through and good execution.

For instance the hypothesis for remote-first is that hiring will become easier/more doable/manageable, but the reality is …

• … you still need to hire with a location/timezone in mind, so that you can co-locate the work (+/- 1 TZ around the center of the delivery team)
• … you cannot hire junior people as easy as you used to (because they need mentoring)
• … you cannot hire (senior) people that want and need the social aspect of being in an office
• … you have to be careful not to hire people that like the idea of working from home, but do not really know what it means (because they will become unhappy/unproductive within 12 month))

… means the pool of people that you can hire into a remote-first organisation is probably smaller than you think.

Remote-first is also not less expensive than hub-first. Whatever you save in cost for office-space you will probably spend on travel expenses, because as a rule of thumb, I would suggest that …

• Once a week you need to bring everybody that are within a radius of 200km together (driving and/or trains)
• Once a month everybody within 1000km gets a chance to come together (short flights; 1 night in a hotel)
• Once a quarter the entire/worldwide org comes together (long flights; 3 nights in a hotel)

One other myth that can be busted is that it is easier to get/stay focused when you work from home (because there are less distractions). My experience is different. The (possible) distractions at home are just different (e.g. children, spouse, dog, cat, … looking for your attention). And yes, the (disciplined!) remote-worker can get a lot/more done when being/getting into the zone, but … these people tend to have an ability to get into the zone, wherever they are (a procrastinator will not suddenly become more effective, by working from home :)).

Let’s recap. Where are we? We think/believe that (in the next 5 years; especially for engineering organisations up to 200 people) remote-first is/will be(come) the best model to build/run an engineering organisation and as a baseline we can (still) use the concepts (and the roles and responsibilities) from the Spotify model, but we need to make sure that the delivery squads are “co-located” in a timezone.

There are probably a couple of myth/expectations/benefits that are associated with the remote-first model that you want to be careful to take for granted …

• Hiring will not necessarily be(come) easier
• Remote-first is not going to be much cheaper than Hub-First (because what we safe on office cost, we probably spend on travel expenses)

But even then, we are probably still struggling with the following set of problems …

• How to deal with new-hires and young engineers (basically the people that need/want/benefit most/a lot from personal/face-2-face coaching/mentoring)?
• Making sure that the engineers get a chance to build and maintain relationships and are engaged with the company and the mission and the purpose of the endeavour?
• Fight the degradation of being social. Fight the loneliness at home. Provide help/support to make sure people do not work 18 x 6.

It seems that even in a remote-first (or work-from-home) model the people would probably benefit from being in proximity to each other.

In that context I would like to introduce a new model/idea: The pod-first model.

In this case we still end up with everybody working from home and with no office, but the engineers are located around/near some well-placed/well-located pods. The pod is a place (a cool/good city with a good talent pool) and/or a person (a very good and very well-known engineer). The idea is that the pod is big enough so that you can fish for talent and small enough so that people can come together once a week to hang-out together (socially and professionally; for these weekly get-togethers, socializing and learning is the main purpose of the exercise).

Credit: The idea to evolve the remote-first model into a/the pod-first model was first developed in a discussion with Bjorn Freeman-Benson (at the time CTO of InVision)¹¹.

The pod has a radius of 100-200km and is run by a strong people manager (up to 20 people).

All of the pods in a timezone/region are in one tribe.

In the best case (as always) the squads would be formed by people that are in a pod, but it is probably unrealistic to assume that this will always be the case. More realistic is a situation where the members of the delivery squad come from different pods (but never from a pod that is in another tribe).

Note: Pods are probably named after a location (e.g. the Munich Pod). Tribes are named after a timezone/region (e.g. the East Coast Tribe), but the squads are named after the mission/purpose (e.g. the Search Squad). Squads are not named after a location (e.g. the Dublin Squad (even, if by accident all members of the Squad are in Dublin)).

Pod	Tribe	Squad

Last but least the guilds (the home of the craft) are a truly global concepts, means the members of the guild are distributed all over the globe (but as described in the Spotify model, over time chapters might form on the tribe level and/or maybe even on the pod level). Again guilds are (obviously/clearly) not named after a location or a mission/purpose, but the craft you are building in that guild (e.g. frontend-engineering, backend-engineering, systems-engineering, data-engineering, product-management (product-owners), project-management (agile-coaches), …).

Final thoughts/take-a-ways …

• There is no general answer for the question what is right for you and your organisation. I think it mainly depends on the type of work that you need to do and where you are on the journey to be(come) the next unicorn.
• In any case, I think you can make hub-first work and remote-first work. The insight here is that it probably makes sense to start with a remote-first model (for the first 100 engineers) and then transition to a hub-first model. And in any case none of this will work, if you do not co-locate the work.
• Both models are challenging. Doing one model badly and then switching to the other one thinking this might be better/easier might not be a good idea (it might be better to find out why a/the given model is not working for you and … fix whatever the problem is).
• People work for something (a vision/mission/purpose) and/or for someone. In the best case both. Picking a/the wrong model and/or executing badly on the model you have picked will put you in a bad position to make any of these models work for you and/or the people you have hired, means … after 2-3 years you will end up with a piece of software that kind of works, but the people who have build it have left the company.
• The pod-first model might be a good way to have the cake and eat it too.
• You might start the journey with a remote-first/pod-first model and then end up with a hub-first model later. In that case you have to make sure you are prepared to manage the transition(s) the org needs to go through. You need to make sure that while you go from model to model the “old” people do not feel left out or left behind (just imagine how it would feel, if you join a remote-first organisation and then suddenly the company starts to build engineering hubs. I think it is natural to assume that people will start to ask themselves how they fit in).

WDYT? I would love to hear from you!!!

And last but not least, I would like to thank Bjorn Freeman-Benson, Peter Bardwick, Coach Braggy and Barry Steinglass for the feedback on and input into earlier draft versions of this article.

Appendix - Notes on Roles and Responsibilities

The pod leader …

• … is the people manager for the people in the pod
• … is doing all of the hiring/firing/performance management
• … owns the skills development/career development (with the support of the guild leaders)
• … is responsible for employee engagement
• … owns employer branding in the pod
• … is attracting and retaining and developing the talent in the pod
• … has strong people management skills
• … has strong communication skills
• … will travel/move around in the pod to meet/visit people (2-3 days/week)
• … will report on the happiness of his pod
• … will do weekly/bi-weekly/monthly 1:1s (Skype, Face-2-face, …)
• … has very high emotional intelligence
• … very high verbal intelligence
• … has an amazing character/personality
• … is the type of (interesting/amazing) person you want to spend time with (because you always learn something and/or can get advice on something)
• … is very well connected. Has a very good network.
• … very approachable. Very social.
• … is interested/motivated by the ambition to develop people (and deliver value to their CVs)

The squad leader …

• … is responsible to deliver on the mission of the squad
• … owns the delivery of a project/a feature
• … is very detail oriented
• … is very process oriented
• … is very intelligent
• … is interested/motivated by the ambition to build systems (and deliver value to customers)
• … has lots of agile project management experience
• … can be an engineer, a project manager, a product manager
• … is not a title on your business card. This is a role you play (for a while; while the squad exists/delivers on its mission). When you join the next squad you might again be(come) the squad leader … or not.

The guild leader …

• … is a strong technical leader (Backend, Frontend, Databases, Systems, DevOps, Agile, …)
• … is famous (e.g. writes books, talks at conferences, recognized industry expert)
• … is a Senior/Principal Engineer
• … is experienced in running virtual/global teams
• … understands that sharing experience and expertise is the mission of the guild
• … will establish (when required) chapters/sub-guilds in tribes/pods (to support more local/personal knowledge sharing)

The pod leaders and the squad leaders will report to the tribe leader. The tribe leader owns all pods/people and all squads/projects in his time zone. The tribe leader appoints the squad leaders and the pod leaders. In a small tribe (3 pods, 4 squads; in general I would expect that you have less pods than squads; the optimal pod size is 5-15; the optimal squad size is 3-8) the pod leaders and the squad leaders will reports directly to the tribe leader (in larger tribes there might be a layer in-between).

I think in larger/well-developed organisations it will be necessary and valuable to have 3 separate individuals play the role of pod-leader, squad-leader and guild-leader. In smaller organisations it might and will probably make sense to maybe have one individual play 2 roles (e.g. leader of the Billing Squad and leader of the Berlin Pod) at the same time (at least temporarily).

Means every engineer will be supported by 3 roles that will help him/her to get the job done.

Footnotes