A German startup (Tandemploy - http://www.tandemploy.com/) is trying to establish something similar by allowing two people to "team up" together and apply for a single full-time position at a company. This sounds weird at first but the benefits for both sides are clear:
* The two "job sharers" can freely organize how they want to split their working time between each other, giving them a lot of flexibility and increased work-life balance.
* The company will have filled one full-time position with a team of two people, thereby greatly reducing the risk of sickness and one person leaving the company with all his/her knowledge.
RAID1 surely? Take one out and the array keeps working (though perhaps at lower performance).
This sort of job-share is not uncommon in some office environments, and it is part of how "zero hours contracts" work for companies like restaurants and so forth. Employ more people than you absolutely need for knowledge redundancy but don't give them full time hours. Then as people leave others take up the slack until replacement devices (sorry, people) can be brought online or a temporarily offline device is repaired (i.e. a sick/injured person gets better and returns to work) and resynced.
Sometimes it is very convenient for the workers as well as the companies, particularly those who can't, or don't want to, work full time for one of many reasons. But it can also be used to keep wages/conditions artificially low because from the companies PoV everyone is relatively easy to replace, temporarily from within the rest of the workforce and long term by bringing someone new in who the other part(s) of the job-share train on-the-job (I've actually seen this referred to as a Redundant Array of Inexpensive People - with the sound of the acronym a deliberate statement of how some feel about the situation).
IMO the problem with explicitly taking on two people at the same time to job-share like that is that they are more likely to chose to leave at the same time (or close to) which kills a chunk of the skill/knowledge sharing benefit.
On a side note, this is common in academia (particularly for married couples), and often seen as a negative thing there. The downside is that employers often expect two full-time employees for the price of one. My wife and I both have similar skillsets and looked at applying to a shared tenure-track position. We didn't for exactly that reason.
On the other hand, I think i could be quite nice if employers manage expectations and don't expect to get 2 for 1.
Tandems are also used when recruiting pro bass players / drummers since you often need one and only one of them in a band but it has to be always present for gigs.
Usually they are in duo, backing each others in several bands.
That's interesting. From the hiring company's perspective, are they hiring two employees with limited hours, or are they hiring a company (with two people in it) to do the work?
I think (not 100 % sure) that companies hire each one of the two people on a part-time basis, but with flexible working schedule, I guess other arrangements are also possible though.
This is interesting. From a hiring perspective, I feel like I'd be a bit wary of this. It'd be great to have a team that works well together, but I'd be really afraid it would overwhelm existing company culture/process/etc and cause a clash.
I think this is why a lot of acquihires fail (like, acquihired employees leaving quickly). They way the acquired team works together doesn't mesh with the way the new company works.
> I think this is why a lot of acquihires fail (like, acquihired employees leaving quickly). They way the acquired team works together doesn't mesh with the way the new company works.
I agree that there's typically a culture clash, but I don't think it's because the acquihired team overwhelms the existing company culture/process/etc. In an acquihire, most of the workers at the acquired company suddenly are working for a company that they didn't choose to work for. That's a ridiculously bad situation to be in as a developer: we have a great deal of choice in where we work, and it's poor strategy to let someone else decide for you just because they had enough money to buy out your boss. So developers choose. And they generally choose to leave because the acquiring company is overwhelming the culture they chose to work in with a culture they didn't.
This is different: everyone in this situation gets to evaluate the others and make a choice about their involvement in a business relationship. Of course there will be differences discovered after the fact that will result in both sides changing, but that isn't necessarily bad.
Well, that's why they give acquihired employees a whole bunch of RSUs. I worked for a boring corporate acquihirer for a while because they were paying me the stock equivalent of my salary (which also increased) every year.
In the marketing / advertising circles its not uncommon to hire a creative team (two anyhow). With one one having stronger graphics skills and the other copywriting. I have often wondered why agencies will use this approach with "creatives" but not developers. To me it seems like a close knit front end / back end dev team would be a good match for banging out the campaign based sites that most agencies do.
I spent some time travelling when I was younger and supported myself in part by working as a waiter.
I got a job in one place in Hong Kong where the owner hired a manager who brought his own team with him - four other waiters. After a couple of months delay until his friends were released from prior contracts, he also brought in his own kitchen team too.
It only lasted a year though when owner and manager fell out and the same thing happened.
It sounds rather a likely risk though... I speculate the kind of manager that brings his own team thinks long term. When one thinks long term, multitudes of possible outcomes must be thought through. The vision has to be defended against all kinds of visualised attacks. It's complex, and often hard to explain due to the level of detail and time that is put into it.
Then some dick who thought about it this morning over his coffee wants to suggest you change direction.
It's a bit like software development. There are a bazillion things not in the code you are looking at, that the developer deliberately didn't put in; an infinity of tiny decisions. Also there lots of things that are in that it is later clear should not be in. Decisions on whether to refactor are really, really hard.
Something something technical difficulties in the relationship between craftmanship and leadership.
Tl;dr: lots managers or head chefs will bring other folks because the environment will be more predictable or enjoyable, and the restaurateur is usually as or more invested in long-term strategy as/than then lead staff.
The dining industry isn't so deep and complex. For the restaurant manager / head chef / lead chef, it's generally "how much autonomy do I get with dining room design, menu design, hiring," "what's the food cost I need to beat," and/or "what's the concept (and can I play with it)?"
If the right level of autonomy/restaurateur participation is there and they can get behind the theme/concept of the restaurant, the chef/manager takes the job. Then they get to work building a menu they like and training the staff for the experience they want.
WRT bringing a team with them, as high-stress a job as running a kitchen/restaurant can be, knowing already you work well with someone is worth its weight in gold.
Restaurateurs also are not, generally, blowing by and making whimsical changes. The margins in a restaurant, after food cost, salaries, fixed costs, are usually not super high, so if they have money in it they're thinking a lot about how to maximize the ability for that restaurant to grow its business (or increase margins).
Luckily or unluckily, there's not a ton of strings to pull to manipulate the restaurant's profit:
- The rent will be the rent. Changing locations is a huge sunk cost in both capital and customers, since existing ones won't know where you've moved to (or be able to walk down the street to get to you) and new ones won't know yet why they should stop in.
- Salaries will have a floor for the area your restaurant is in. You can pay more, but in any case once you get to minimum wage, yeah.
The main way to modulate the profit point is to play with costs on the ingredients. You see pretty quick that if you cut ingredient quality by too much, you have to start dropping price points because people won't overpay by too much for crappy food. And some venues or concepts won't support breaking out of the average price for prepared food in a region, i.e. you've gotta be doing special to charge $20 for a cheeseburger.
So, you look at how cheap you can keep ingredients for the quality you want on the other end, And how well you can build the dining experience to resonate with the target customer so they fall in love with your restaurant and keep showing up.
The restaurateur is thinking about that a lot, as much if not more than the on-the-ground leadership he/she hired.
Did you consider contracting? You can bill as a team, you control the interview process, you can split and reunite at will, and the people who are booked can support the people who are benched are working on open source portfolio stuff to attract more clients.
I would have expected this, although you need a decent enough runway so you can pay you rent, family expenses, etc. It sounds like their employer kicked them out and they wanted to find stable, predictable employment quickly. Also, a team of developers may not possess the required business/sales skills, or not want to move into that area.
We did consider that. But then I thought to myself "who is going to worry about toilet paper and payroll and all that stuff". No-one on the team wanted to do any of that, let alone the sales and networking that are required to keep a consultancy afloat.
Spitballing.. What about sharing the responsibility by having one person responsible for 6 months, then change after that? Salaries transparent in a spreadsheet like at Buffer
Alternatively wonder if you could've spent the same effort networking as a team by group interviewing prospective HR people to fill the role you wanted.
I'd be surprised if they didn't consider it: it's a common enough model in our industry that I'd even be surprised if one of them has previously worked as a contractor. There are a lot of unappealing things about contracting, though.
1. To all intents and purposes this is a co-op model of an agency.
2. If the team could not break through to their employers that the employers were in the way and not letting a team of eight build something to help, then why do they think they can do this repeatably (is the value of an agency the ability to build valuable stuff or to persuade business to take the valuable stuff it needs?)
3. This should be the model for the future. Damn it, succeed damn it.
The company in question did let the dev team build the product. However, said company's tech leadership has been in a state of constant flux and apparently the management du jour no longer wanted what their predecessors wanted.
(Note: I used to work for this same company in this very dev team, although I left long before this happened and Adel was among the few left from those days.)
That is kind of what I meant - changing management teams, and same teams changing their minds, is one of the great problems of traditional agencies (and the rest of us!). Stopping it, or getting out in front of it, is probably the main survival skill an agency needs (along with building a pipeline)
Ultimately this is a nice idea but which are we - a team of developers who do not want to be an agency? An agency with a twist? This matters because it defines how people hire them and view them.
Not sure what you mean by co-op here do you actually mean a worker coop?
Most ad agencys are not coops the only high profile ad agency coop is no longer a coop (the egos in an ad agency don't lend it self to a coop structure)
What an interesting concept. For developers, it's easy to see the value in hiring an established team. I'm glad the companies you spoke too also saw that. I wonder if this could be applied to even smaller groups, say 2 or 3 developers who have worked together well in the past.
We didn't get hired "as a team" but I started a gig about a year ago and during the interview process we talked about other types of roles they were hiring for. One was a perfect fit for a buddy of mine so we had a quick discussion about the benefits of hiring us both. It's a remote gig but my buddy and I are local to each other and have worked well together on previous projects. They wound up hiring us both but put us on separate teams. I felt they really missed out on having the two of us mesh well right off the bat with little social ramp up. They never explained why they split us up, so I can't begin to speculate.
Impressed that this happened in Melbourne as opposed to the Bay Area. ZenDesk has done a good job of publicising their ability to move comparatively quickly around here, but this goes over and above.
If a good team did this in the Bay Area with sufficiently strong internal agreements to ensure they all got hired together they could probably get ~$100K signing bonuses each, comparable to an acquihire.
Now that's a great idea. LinkedInTeam.com - in fact one could build that as a seperate "profile" page where each Dev points from their profile to the "meta" page, and selects certain comments (is this team is great, as opposed to this person is great)
One could build a profile page quickly from the links and use only LinkedIn quotes - is quotes that are "trustable".
I wonder, if we were to rank team's abilities as a whole. Which factors could be used in it? (like skills coverage, understanding with each other, culture, etc)
Brilliant thinking on your feet of taking a problem and turning it on its head, still as a team. When a good group of developers get together the things that can be achieved are incredible. Well done!
* The two "job sharers" can freely organize how they want to split their working time between each other, giving them a lot of flexibility and increased work-life balance.
* The company will have filled one full-time position with a team of two people, thereby greatly reducing the risk of sickness and one person leaving the company with all his/her knowledge.
So, basically it's RAID0 for people :)