BYOT: Bring your own team
stripe.com
stripe.com
The idea that all will be hired or none will be hired is kinda odd as well. You are ceeding your career to bunch of other people in a non-entrepreneurial way. You are doing more work, giving more to Stripe than you are getting back. You are lowering their risk and not being compensated for that. Neither as a team nor as individuals.
It'd be interesting if you could collaborate and bid for your salaries as a group and/or make sure everyone got at least a minimum. It would be a failure if everyone in the group got the same amount.
The collective bargaining that would go on would be force multiplied in either direction. Either people wouldn't negotiate and companies like Stripe would get a great bargain of a team that already works together or they would get reamed as the team realizes that together they are more valuable than what they could bargain for individually.
Lastly, it's probably a risky move in that if a group leaves one company together successfully, they are more likely to move on from the second company together as well. If they are all working on the same project, you could have a disastrous and instantaneous brain-drain.
It's like building in a massive artificial bus factor into your company.
If people took an adversarial or merely valued their small in-group more than the company, they could get hired as a group, build an important system for Stripe and then en-masse, quit to create a consultancy and have Stripe as their first (reluctant) customer because they have knowledge of an important subsystem. In fact, this would be an excellent way to launch a consultancy.
Stripe, you may have opened a can of worms with this move. Teams hopping from startup to startup like individual employees do now would make startups even more chaotic.
Maybe they are banking on the downturn and think they can get high quality teams on the cheap. Seems like a way to open the business to alot of risk.
It is a question of where your ambitions lie - if you have already accomplished your financial goals, already written software that is used worldwide, already done the startup thing, and still want to code instead of going the management or investor route... why would you not pursue something like this?
Admittedly, Stripe is a poor candidate for this... nothing against them as a company, but people in my situation tend to look for work that has meaning on a charitable level -- environmental, education, health care, or other such areas where we can really make a difference in the world would be appealing.
It mentions on the page "you’d all be free to accept or decline individually".
Yes this is a risky move by Stripe, but as they say, it's an experiment and i'm sure a lot of people would be interested to see how this pans out. Kudos to Stripe for taking the initiative to open this up.
That is indeed what they say. But, say they interview a 5 person team, and really like 2 of them, but not the other 3. So, no offer is extended.
Now they are left with these two resumes of people that are just perfect. They know what those two people want for comp. Are they going to be disciplined enough to shred those two resumes right then and there? No discussion about "what if we wait a month or two, and...?"
Yeah. This just sounds like a great way to get more people's resumes, and cheaper hires than consultants. Tech individuals move around after a few projects anyway so the only difference between full time and consultants is the pay.
I could see the strategy appealing to some people. But at the end of the day, once you're in the company, there's no guarantee they won't break you up unless that's in the contract. Further, you will be limited to working with certain people via that company. As a consultant you need to do more legwork but have more freedom. I guess this could be seen as middle ground.
I'd like to hear from more people who've actually tried joining a company as a team. I recall one blog post from someone who tried it a year ago. I think she said the whole group didn't actually get hired and in the end they didn't get to work together as they had set out to. But she was glad to have tried.
Ultimately, this is a whole new model for companies. Nobody has established a track record at doing it successfully and the early players could make or break some of their reputation based on how successful these teams are and whether or not they stick together. I think it is riskier for the company and the employees than they realize. The company is, in a sense, outsourcing their management by allowing people to form their own teams. That could be the missing piece of the pizzle in software development, or it could be a disaster. I look forward to hearing more.
This might or might not be a failure. The central cast of Friends legendarily all pulled very high salaries because they formed an informal 6-person labor union, a key principle of which was that everyone got the same pay.
Companies do this all the time.
Otherwise it's nothing like an acquihire.
The thing is, I read a book called Million Dollar Consulting by Alan Weiss, and he always stated that consultants don't ever do execution, that they only focus on the thinking/strategising side. I'm now starting to think that was a big mistake and that I should indeed form a team.
Any thoughts or suggestions in light of the above?
I don't think there's anything wrong with an individual choosing only to do strategy though, in the same way that I only choose to work with certain programming languages. I do think it's wrong to say that consultants should never do execution, unless you have a very narrow view of 'consultant'.
I can see the appeal of this sort of technique. Within the mega-org that I worked in, we'd always try to keep good teams at least partially intact as members got promoted or reassigned.
Consultants who struggle to keep the pipeline full are, by definition, struggling. The small firms who have steady clients do tend to shed the "consultant" label pretty quickly, so I can see some selection bias. I've known plenty of firms that don't have a tough time keeping a steady stream of work. I've even worked in a few.
I think Stripe's bid will work because it will stay small. If it really caught on, the idea is deeply flawed. But for small teams, some of the time, it will work.
But I thought HN hated the idea of unions!? How is this any different.
Per engineer, Google, Facebook, Apple make multiple millions of dollars in profit per fiscal year and yet very, very few engineers make $1m+. Even $500k is out of reach of most non-managerial engineers.
So, no if Google made 2x or 4x the profit with the same engineers, they company would pay them the same exact rate if they could. Often times they do.
The only way to really gain serious income is ownership of a technology that you can sell either directly to the market or to another company.
No matter how much you make, as an employee you are always trading lower risk for lower or linear rewards. The company compensates you for your years of experience at a market rate but, retains the fullest share of the profits that they can. They also own the code of your labor after you leave the company so there's that. You work (especially as a developer) makes the company money even after you've left.
If code wasn't so complex and hard to maintain, there would be even lower salaries (compared to profits) at software-based companies.
Brilliant programming that creates even billions of dollars of value for one of those companies isn't even going to net the engineer 1% of the value they create.
These kinds of profits are only made by teams, and that's why individual programmers only get a fraction of it.
While I am not answering your question directly, Jeff Dean and Shel Kaphan come to mind, in their key, fundamental roles of building massive scalable systems - information search and retail selling, respectively.
http://research.google.com/pubs/jeff.html
http://www.geekwire.com/2011/meet-shel-kaphan-amazoncom-empl...
Neither of us got even a thank you :-(
Personally I can feel this "flow", and I have some favorite pair programming friends; it's hard to beat the feeling of having someone else that completes your sentences or writes down in code the idea that you were thinking out after just saying a couple of words or exchanging a single glance. The probability of this happening on a new workplace with people that you don't know doesn't seem so high to me, so this idea really makes sense.
Has any other company thought of this before?
I can't see many downsides - except for the poor companies that have whole teams disappear on them.
I've actually seen entire teams quit a few times in my career, but instead of them all quitting the same day, they quit within month or so, and it's the one that have the highest market value that go first.
If a company is afraid that an ENTIRE TEAM is going to quit on them, they have to make sure they are paid market rate, and happy with what they are doing, and who is managing them: There's no magic. Happy teams don't spend their time interviewing for new jobs.
So the minute you are worried one of your teams will submit a job application to Stripe, this means you know they are unhappy, and you aren't doing anything about it: Don't worry about third parties and fix it!
If things are getting to the point where one person in the group has soured on the company, you can bet they have all been griping about it for months over beers. This in turn sours the rest of the group and then they inevitably start dropping like flies once the first one leaves.
In the instance I saw that occur, I think they had their valid reasons, and it wasn't anything horrible about the company they were at--just found something better. But I started placing mental bets with myself on how soon it would be until the rest of the group left--turns out I was more or less right, except for one of them.
That said, the impact was definitely felt as they were all super talented people I'd love to work with in the future. So for companies afraid of hiring groups or several close referrals from a single person (which are essentially the same thing), the best thing you can do outside of providing an awesome and competitively compensated place to work is ensure there is solid documentation for things, and when possible ensuring that critical business knowledge won't be lost if someone leaves.
If it helps, let's remove the human element and think about it from a disaster recovery perspective. You need a replacement plan for the whole group. It's vital if you want to do things like take your team out to lunch (food poisoning) or to any group activity (transport accident) or be in a single office (anything that takes out the building will take out your team).
Could you rebuild your product team from scratch and still proceed with the deliverables that have actually been checked into source control and the issues that have been entered into the issue tracker? It's a good question to ask.
Incidentally, their DR test at one point wasn't really a valid DR test, since it didn't do of any sort of rigor. Not to mention the other DR tests/events I've seen at other companies ;).
> people are just generally assholes and will take advantage of a system like this.
Not to belabour the point but could you expand on what you mean? I would think that a rational economic actor would take advantage of a beneficial opportunity that presents itself.
I was "poached" into another company in a relatively large company in finance as a linux admin along with a PM coworker who I viewed as a good person and incredibly technically savvy. She was brought on by the AMRS CTO of the previous company. In a lot of ways, when we joined, we were viewed as a single unit with a single agenda by many of the other folk at the company. I tried steering of it as hard as I could, but it got pretty hectic for the entire company when the two "agendas" didn't work that well together. It might've just been the culture, but a few other things at the company gave me an off feeling that threw an enormous Machiavellian vibe all throughout, but that's a different story.
The guy who brought me in, though. He pulled me to the side after they decided that the dynamics were too much and switched me to a different team where my old PM coworker would act as my boss. The idea was nice and I had more freedom (they never took away my root access), but he completely confirmed that people can, and do, take advantage of "teams" to push an idea. He told me three things all paraphrased, but not inaccurate things:
"You're my fall boy. If something happens, I want you to fall in my place."
"I want you to outperform all of the other teams in the company." No pressure, right.
"You're here to push my agenda." I believe that his end goal with his 'agenda' was to become CTO, which.. thankfully.. didn't happen. Instead, [edit: very large company]'s head of tech stepped into that position.
---
The reason this gets to me and how I can see that attitude being incredibly expansive if adapted, is because this is a well known name in finance right now with increasingly large names from other companies coming in. Nobody's really batted an eye at it. This also isn't the first time I've seen this kind of attitude before. It's incredibly systemic finance and I see the same attitudes in SV. It doesn't seem like a leap of faith to say that the same bleedingly charismatic and moralistically dead attitudes exist there, too.
There's a certain attitude and behavior from those who feel that they're at the top that distorts the way they act. Watching House of Cards felt all too familiar. It was all very creepy, and I don't see that behavior going away any time soon.
My 2c.
There's absolutely a middle ground, but I'm not sure that direct hire of teams is not of them - yet. For that to work, many other things would need to happen first. I'm looking forward to the day that happens. For now, I'll stick with freelancing and hope others hop on this bandwagon with me.
HN discussion about it here: https://news.ycombinator.com/item?id=10390834
EDIT> Actually ... there is a benefit over acqui-hiring. If your teammates are unable or unwilling to forgo salaried employment, this could be a win. Could definitely bring in more experienced people who have families / mortgages, etc.
Long term I'd love to see stats on this. My intuition is you'd wind up more successful, similar to how referrals make better employees. There does seem like some risk though - the team will likely succeed or fail as a group.
I was thinking exactly the same thing: This is like acquihiring except that it skips the "spend a year on a proof-of-talent product which gets thrown away after the acquisition".
Of course, the downside is that the team interview process isn't likely to be anywhere near as effective a filtering tool as spending a year building a product.
I'd recommend that anyone doing this that they negotiate their salaries very heavily.
I work on tech M&A.
For better or worse, I've seen large companies sometimes acquihire (amongst other reasons) as a way to pay up without killing their salary bands.
> There does seem like some risk though - the team will
> likely succeed or fail as a group.
This is for "group defectors" i.e. engineering coworkers who are unhappy at their current company, complain about it together, and can coordinate their migration. This (potentially) gives them a way to move together as a team.
*(Granted, some startups are 100% engineers, but they could make much more money via an acquihire than this route.)
If a team already works well together, what is their new Stripe manager going to do?
That sounds a bit awkward for said manager. He or she would be in a weak negotiating position with the group.
I'd argue that although Stripe isn't seeking to hire more managers, they are outsourcing management a little bit by allowing these not-yet-hires to form their own teams. It does relieve some burden. I wonder what happens when something goes awry and a correction is needed. Will the group follow the new manager's suggestions? So many things could go right or wrong with this.
If I had a team I'd want to keep it together but not so much if it doesn't actually work.
That's why I am genuinely curious what they plan to do once they hire teams. Let's say you hire a team of a designer and a developer. It's not like they will be always working together and with no one else in the company. Chances are you won't be working as the tag team forever. That would be stupid both for the company and for these people because you are being too closed minded and won't learn much by only interacting with the other person when there are so many other talented people in the company. I presume that isn't what they plan to do. Then that leaves us with the option of just hiring them "as a team" but once they're in, there's no guarantee that they will work as the same team, just like how most acquisitions work--when they acquire a company they say stuff like "Company A's expertise will be helpful in us developing our such and such core features", but after the acquisition they all disperse and get assigned to different teams after a while.
So... what's the point? Well that's why I think it's a gimmicky way to attract attention and get more people to apply. Any counter argument?
Any team that gets an offer should come back and ask for +50% since they have as a united team the upper hand.
After this initial PR, said fired average people could write quite an exposé on their experience joining Stripe as a team. Sounds like a recipe for disaster to me and I don't think Stripe is ignorant enough to believe this strategy only has upsides.
Comparing a regular hire / fire to firing an individual from a team is not apples to apples.
For a regular hire, that person is a "team" of skills that can do many things. For example, Joe can program and do technical writing. If MegaTech hires Joe for a programming job, and then only assigns him technical-writing work, they've "laid off" his programming skill. Joe might be a little unhappy that he didn't get to do the job for which he was hired. He may mention it in his Glassdoor review, and that may impact future developers' opinions of MegaTech a smidge.
If MegaTech does a team hire and then lays off one person, it could appear that the initial idea of hiring the whole team was not sincere. That is risking more reputation than hiring and firing one person. When you hire/fire one person, it's clear the company and individual's initial plan failed. When firing a person from a team after a few months, it's not so clear whether the company ever really wanted that person or not.
So I think there are potential downsides. I also think Stripe is aware of these.
I look forward to hearing about this model and hope it works for the companies and groups who try it.
So the likelihood of all members of a given set of X people being employed is almost zero.
What happens to the team dynamic when the employer wants to employ Jenny and Steve but not Bill, Mike and Vivek?
This might sound good but it aint going to work.
This is basically just acqui-hiring without the acquisition. And acqui-hires are common enough -- not as common as straight up hiring, but enough to be interesting.
If we make an offer, we’ll make it to all of you, at the same time; you’d all be free to accept or decline individually, but of course we’d hope you’d all accept — and if you do, we’d work with all of you to find a place at Stripe where you can all start off working together.
- Hire new CRO or President of sales.
- He "builds out a team" generally consisting of people he's already worked with in the past.
- Sales org grows.
- CRO moves to next company. wash rinse repeat ad infinitum.
Why would this process breakdown given a team of proven, successful engineers who have shown to be capable of building/scaling a product in the past?
Cause sales ain't software.
A better question would be "what do they have in common?"
To be a bit blunt here: I've only experienced once that talking to a recruiter helped for anything. (OK, twice if I'm generous, it wasn't a recruiter, it was a hiring manager at a consulting company and I ended up rejecting the job.)
I have however sold myself in a number of times the last few years.
So if anyone in recruiting needs a good idea, here is one:
* do get back to devs with updates, not only customer
* know what you are talking about, don't ask if I still know how to bike (or program) just because I haven't been doing it full time in 12 months
* do sell
* in Europe
Could you be experiencing a bias because of your deal/people flow?
There might be some network bias here since it sounds like your experience (first- and second-hand data) is from outside recruiter-referred candidates.
When you bring new people to a company, they tend to work the way they use to in their previous occupation. More often than not, a new employee will start his sentences with "What we used to do in this situation" or "that's why we did it that way at X", trying to both build up on his past experience, and to find an anchor of familiarity in an unfamiliar environment.
This is normal phase and usually wears off after a few weeks/months. But for as long as it lasts, this behavior can be annoying for your current employees as they have built up their own thing, and they don't necessarily want to be reminded that there were other options that they didn't follow.
The risk that you take when bringing a team of 3 to 5 people is that they go in their own corner, dismiss all the tools that already exist, recreate the work environment they are used to, don't mix well at all with other employees, etc.
And what you get from people being used to work together, you loose in management pain. I think the usual way of hiring one person, who then can refer to the good guys in his previous team is a much sounder approach, as it lets time for the culture to adapt.
The downside to this will be the negotiated rate, and that is the upside for Stripe.... along with the lower risk hiring outcome they also receive.
When time is not on your side your negotiating ability is severely hampered.
There will always be an imperative for someone in a team to "hurry the paperwork" along faster than someone else because they need the financial security of a job etc etc. So unless the "team" is happy to delegate the entire negotiating process to one person with complete authority this situation will be unavoidable. And let's face it, not many people will blindly put their faith in someone else to negotiate every aspect of their next full time permanent position, including whether or not to accept it and give notice at their current employer.
Money isn't everything of course, but this is a sure-fire approach to limiting your income, thus don't think there will be many takers.
As someone else said in the comments here, the more practical alternative that actually does work is called consulting.
In advertising agencies it's not unheard of to hire creative teams (for example an art director + copywriter duo) who are used to working together. In fact where I work most hires and departures in the creative departament in the past few years were in teams of two or three people.
I've never seen this sort of collective bargaining work in action for the reasons I outlined originally.
Given that the Dunning-Kruger effect has two parts (incompetent people overestimate themselves AND competent people underestimate themselves) this looks like a plus: You get a chance to hire people which are competent but aren't confident in their own competence and wouldn't apply if not for the team.
> Once you’ve applied, we’ll take you all through the hiring process together: we’ll make sure you hit the same stages of interviews at the same time, bring you all to the office on the same day, and try to design at least one interview problem that you can work on as a team.
If we make an offer, we’ll make it to all of you, at the same time; you’d all be free to accept or decline individually, but of course we’d hope you’d all accept
This implies individual hiring criteria. It's interesting that they let the group try and solve a problem as a team.
I wonder how this will impact compensation and offer acceptances.
Also, if the conventional wisdom is that hiring excellent tech individuals is difficult, then hiring excellent tech teams -- would that be easier or harder than hiring individuals?
P(goodhire) > P(goodhire)^teamsize
If 4 people that work together and I want to hire happen to bring in a 5th person that did worse in my interviews, I don't worry about their judgement: I wonder about my interview process!
How is salary negotiated? What happens over time - do you just become discrete employees? What about internal promotion - does it just not happen?
I would find it incredibly difficult to get together with friends and decide 'right, i guess we're all worth X each then, let's go for that'.
I think this concept might attract fresh grads more and could be integrated into a BYOT internship program.
I think it's far better to be an early to mid-stage startup employee out of school vs. start a company directly. It's also really nice to be able to focus on things like just product or code vs. how to make the business successful, customers, legal, BD, etc.
This might be an interesting way to ensure that I work with people I'm inspired by. I dig what they're doing.
Starting a company isn't the most important thing in the world, especially when you aren't doing anything innovation and when you are just doing it because. Believe it or not, just cause you call your startup "Uber of X" doesn't mean it's innovative and doesn't mean you need to spend time building it.
It seems like an entire team would be more difficult to beat into submission, I mean, acculturate, than just one single person.
Cons for stripe: risk of the team bringing not only their previous company culture, but also their group micro culture. Risk of all of them leaving Stripe all at once (they did it once).
Pros for the new team: I can't think of any, I've never been in a group where I thought everybody was great (and beside I see meeting new people as a perk of changing job).
"... we’ll make sure you hit the same stages of interviews at
the same time, bring you all to the office on the same day..."
I am somewhat skeptical that this will be a great success. Just because a team performed well in one environment, it doesn't mean it will continue to do well in new circumstances (unless they are hired as external or independent consultants, as others have suggested in this thread).
As an individual looking for a job, I would also want to know if applying as a team lowers or increases my chances of getting an offer.
(I may be biased here: I work for Stripe from a small community off the Canadian coast).
?
Been thinking about "crew hiring" as I've roughly termed it, cohorts of flexible, ad-hoc, a-gamers who like to move around, groove on idea and commit when it feels solid, interesting and a great fit for them.
Taking this further, we see companies becoming an "atelier/studio methodology of multiple "teams" working within a collective space for a unified aim..
We can all easily see how this could degenerate as well as succeed.
It's a super fascinating idea, and I am genuinely fascinated to see what plays out. I have yet to bet against Stripe.
There are probably many people who want to work with their friends, especially when they did OSS stuff together.
On the other hand, I have different opinions than other people about when to leave a company, so I'm mostly on my own, even if I have worked with many good people who I'd love to take with me, haha.
We are starting SVOPs (Silicon Valley ops) - we have built some shit... But mostly we just wanted to start a consortium. Join us if you'd like...
SVOPs.slack.com - we are all actively looking for people or help - or even jokes or learning or what not...
Silicon Valley needs much more community (not in the Facebook kind, but in the "hey lets play DnD and drink and talk shit and be like OMG I heard about that and dos you know also....") kind...
We have a culture - it's not evenly distributed but it's here and it drives a lot of shit...
Come join. Where you are physically located doesn't matter: Sam@sstave.com
It's basically trying to cheaply scale the concept behind acquihires.
>the industry has always focused on hiring atoms; we’d like to try hiring molecules.