IF it's optional and truly treated that way, it sounds like a great idea to me. Otherwise, I'd consider it downright toxic. At every job I've ever had, I treat my lunchtime as, well, mine. If I need to go run errands, or just want to be alone, or want to go sit at Starbucks and answer emails for the startup I'm working on on the side, whatever, I do it over lunch. Or sometimes I just plain feel like skipping lunch for some random reason. If I had that freedom denied to me, I'd be miserable.
Just legitimately curious... not knocking the idea. Like I said, if it's not mandatory, I'm all for it. Just wondering how the culture has evolved around that.
This is one of the worst policies I've ever encountered. Companies that I've been involved with often do this at first, because at first, everyone SHOULD do support. After a few years, it's horribly unproductive. It creates a long term crisis culture that is reactive rather than proactive. Many days the entire development team will not be working on their individual development tasks and instead be ganging up on some perceived production crisis.
You need to introduce the concept of triage, not gang-support and no rotating support. Rotating support isn't just bad for your developers, it's a horrible way to support your customers. One week you have a problem that gets resolved quickly because the guy on support actually wrote the code that you are having a problem with. The next week, the same support call takes three days because the guy on support has no idea where that code even lives and has to learn the process. You might say 'oh, but that's how we cross train', to which I, as a customer, point out that those three days I had to wait for an answer were unacceptable, and you should have a better plan on cross training than 'wait til something breaks and throw completely clueless resources at it'.
I think you have this completely backwards: in order to be great, autonomy is required. There's much written about motivations and what makes people happy in the workplace but micromanagement is one of the most easily recognizable anti-habits of a bad work environment. It breeds resentment and engenders an atmosphere of distrust. Bring out the best in people by giving them autonomy.
If an employee can perform well with the additional investment of some structure and management, then it might be a cost effective approach.
One big question I have though is around compensation. How transparent are you guys with compensation, and what lessons have you learned there?
Within the constraints of that, though, we try to be as open as possible. In particular, we share some information about current salaries at Stripe with new hires, and we share full details about all of Stripe's investment and the terms on which it was taken.
That was more a personnel issue that a process one, though. His boss didn't have the backbone to fire him.
I get about 300 emails a day, several of which are mailing list digests with 25 emails apiece. I actually skim them all; I'm one of two people I know who doesn't use filters, and I think the other one gave up recently. For someone who's an informationavore like me, though, it's paradise, and a great way of keeping up the illusion of knowing everything.
I recently watched an 1990 Steve Jobs interview in which he gushed about this very idea as being a workflow of the future. Since the "desktop revolution" was old news, he was moving on to the "business process revolution" (something like that), enabled by networked computers. Companies would love it because it removed the friction of traditional employee work roles/titles and geography, and allowed managers to observe communication and measure stuff. It's interesting to see a company actually doing pretty much exactly what Jobs described in the video.
Although obviously, open source has used that model with great success.
Also, the fact that you had the talk initially set for the dinner time basically means that your culture is already incompatible with the lifestyle of those who value family over work. I am not saying it's a bad thing, I used to actually sleep at work when I was younger, but it is an indication of problems you'll face once your team gets over a certain size. Diversity has a smaller common overlap.
> None of this would matter if Stripe didn’t have
> fantastic people. Hiring well is the key to all of this,
> and people are the foundation of any company’s culture.
> Frankly, I’ve never seen a team like Stripe’s; *** we
> have the best people in the industry ***.
There are a number of factors that could "flip" the company's hiring from very selective to less selective. For example:
* Parts of their culture might not scale indefinitely.
* They might start running short of cash, and have to
settle for less expensive hires, or cut some of the
* They might have to start hiring so fast that they can't
be as selective about their hires.
* Their tech stack will grow old, and unappealing to
energetic self-starters who want to work with the hot
* Their current employees will get older, start families,
and have other equally (if not more) important things
The best part is the IRC channel for chat that has a bot to log my status report (optional) and record for posterity and put it on the shared dashboard as encouragement, recognition and engagement.
sigh... I need coworkers that know what IRC is..
I'm curious to hear if people at Stripe have given thought to just having all emails sucked into a searchable CRM versus having to manually add cc's each time?
Wow, that must be a pretty shitty job. Not to mention the time wasted with Allhands meetings.
I know you probably mean this at least in part in jest, but I've found this to be a pretty common perception in the tech industry. It's probably worth addressing directly.
We want to work with the best engineers, but it's arrogant to assume that that's all that we'll need, or that hiring non-engineering people will cause our culture to deteriorate.
That's not to say that that doesn't happen at some companies (obviously). If you view sales/marketing people as second class, and don't put the same thought into that part of the culture, it'll inevitably be worse. Without a lot of care, it's very easy to build a bad engineering culture too.
While building great software is at the very core of what we do, we won't be able to do everything that we want to accomplish by just hiring engineers. We need people who like talking to users, and people who can describe what Stripe is doing to the world at large, and people who'll help build the countless parts of Stripe that aren't purely about code.
If companies choose to ignore sales, marketing, partnerships, support, and everything else, they should be pretty explicit about the compromise: they're trading off success for narrow-minded solipsism.
We've hired people who aren't full-time engineers, and we'll hire lots more. We want people who can craft both kernel exploits and memorable prose. Those who spend their days working with people instead of code are just as important as anyone else, and their contributions are just as large.
Engineering staff have been hired with a range of work experience, i.e. some college hires, some self taught, some with industry background, any combination of the above - the (engineering) corporate culture grows organically as the team matures and works together
Marketing, BizDev, &c staff have been hired with significant industry experience, I don't know where they serve their apprenticeships, but it isn't here wherever here is - they bring a view of corporate culture with them from their previous experience, this doesn't seem to meld well with the growing culture on the engineering side.
I'm sure this isn't ubiquitous, but the tech industry seems to be very keen on nurturing engineers and, in a sense, taking a responsibility for the quality of the engineering community at large, but for other job functions is happy to be, for want of a better word, parasitic, relying on someone else to train those people, whether they be HR, Marketing, BizDev or whatever.
If you are a tech company with marketing/sales/BD teams, I have news for you: those people are working at a tech company _for a reason_. They want to be involved in (or at least near) technical things even if they can't contribute in the same way.
Resist the urge to develop isolated tech@ lists. Keep your discussions company-wide even as you grow in non-technical areas. Invite _everyone_ to your technical workshops and reading groups.
At Knewton I've grown tremendously as a marketer, but I've also become interested in the CAP theorem and automated deployment services, learned Git and created some projects, and really sharpened my front-end coding, among other things. I've also had the joy of working with a single developer over a hack weekend to launch a variation of a service that quickly become our top revenue generator and stayed that way for a while.
Get the right people and there's magic waiting to happen.