▲ 168 points
back
96 comments
It's funny that this is titled "operating well" because the impression I have, from this post and from folks I have encountered or know, is that Stripe does not operate well.
I know of a number of instances where folks left Stripe and took an extended break before doing something else. I've heard a few nightmare on call stories (we all have stories but these sounded really severe/frequent). I've heard folks describe their workload as operational heavy with little opportunity to actually develop software or build things. I've heard a few things that make me wary of past and current middle managers there.
It's funny. I imagine it's possible to have a company full of smart, kind, hardworking people but a culture where operational work is celebrated and embraced rather than solved and reduced.
I've had nothing but good encounters with Stripes and ex-Stripes but something seems off, and this post inadvertently reveals some of that.
"An Elegant Puzzle: Systems of Engineering Management" by Will Larson also draws from the author's experience at Stripe (among others, and is published by Stripe itself [1]). I guess you can choose to see it as "there are lots of problems at Stripe as shown by the numerous published solutions".. but the transparency is worth something imo.
You're using the engineering definition of operations. TFA is using it in the traditional, business sense of the word. Organizational structure, decision making processes, goal setting, workflow optimization, etc. Think: all the things a COO would be responsible for.
I think the title is a bit misleading. The content seems less about operations and more about execution.
> Turn up the heat in every interaction and ask uncomfortable questions. Some of the questions I repeatedly ask:
> Can we re-frame this in terms of the customer’s problem?
> What’s the soonest we could get this done?
> What would you need to get this done tomorrow instead of next week?
Well, that sounds like a recipe for high turnover. I know few engineers who would want to work for this kind of low trust boss and they are all bottom of the barrel consultant types. I thought Stripe was doing better than that.
As an engineer, I ask these questions all the time. Clueless product marketing people will request the most ridiculous features. I ask them: don't tell me the solution, tell me the customer problem. And what's it worth to you to solve this with the pieces we have now, instead of building something months from now? My teams have deflected years of pointless effort this way.
The context and frequency of these types of questions is crucial. As an engineer myself, I would love to see more of these conversations as long as they’re handled the right way.
Think of these questions less as interrogative orders and more as discussion points / negotiations. I agree that the latter two need to be deployed wisely, sensitive to context and frequency.
To me many of these seem fairly focused on short term gains at potentially long term detriment. It seems Sam Gerstenzang has never stayed at a single company for much more than 2 years which is about the time frame when long term costs start to overcome short term gains in my experience. So not sure if this is the best advice unless you aim to bounce at the 2 year mark.
In my experience moving around every 2 years or so far outpaces staying longer in a financial sense, so if they want to prioritize people to stay longer than 2 years, they need to do so financially. If I can jump somewhere else and make 15-25% more immediately, why would I stay? It’s not long term vs short term its outright compensation for people staying makes staying not worth it.
The running theme underlying this post is having a clear, purposed vision for the company and tying everything that happens to that vision.
Providing a vision is the most important task for the management and leadership of a company. It permeates their conversations with other leaders who continue to spread it down.
The open questions mentioned in the article shouldn't be taken literally.
> What’s the soonest we could get this done?
> What would you need to get this done tomorrow instead of next week?
> What would we need to do to get twice as many customers? Ten times as many customers?
They strip away all the redundant and nice to have features leaving the core of what is truly necessary to build. That becomes the team's focus.
The questions are a thought experiment exercise that help inform and empower teams to say no to and ignore unnecessary work in the short term in pursuit of the vision.
Other parts of the article are about culture:
> Elevate each cross-functional partner you work with
And what is culture but the manifestation of vision and will.
Leaders and managers who incorporate these principles are the ones I want to work with. They are passionate, discerning, ambitious, and empathetic. They are rare but lead to a culture and work that feels gratifying.
Very surprised by the negative responses. For a high trust team, nothing he’s saying seems “toxic”.
It sounds like this guy is very good at running projects. I would love to work with him.
<Rant>
Is there any place in the world for a developer passionate about creating value for users and less so for fighting leadership-made fires (velocity! faster! quicker!)? I don't care to debate endlessly about velocity and processes. I just want decently thought of processes, to adapt to them and produce value.
As an IC I don't want to be involved in every step of the strategy, to keep a track of all my colleagues and how they work, to keep track of the tasks in the context of the epics and the milestones, and be blamed for when a strategy I was not part of doesn't work. I don't want to answer "how could you do this faster?" for myself because it's a horrible question to have to answer almost every week when you feel like you're burning out running. I don't want to answer "what is the priority of the task you are working on relative to our investor's desires?" without actually knowing who the investors are. I don't want to have feel impostor syndrome every start of the week and be in a team that gets ground down at the end of every week for the shit job we're all allegedly doing and where solutions are expected to come from us.
I just wanna get to work, have a clear roadmap that was developed by CxOs, leadership, consultants, investors, people with actual domain knowledge, deeply thinking about what needs to be done and in what order (in order to produce value for our customers). Then I want to create a technical road-map with my fellow engineers and engineering leaders that takes into account business requirements, technical know-how inside the team, planning and start working on that, in sprints, under the watchful supervision of ... supervisors that don't need me to answer questions that they should have had the answers to about a half a year ago.
I'm feeling my mind closing down to this kind of stuff. I don't know how much longer I can do this. I am now in a position where on Monday I get a pile of unthought of requirements, by Wednesday everything changes. Thursday evening a fire starts burning and if fix is not done by Friday morning, we are already behind and disappointing our bosses and investors. Doing the fix and dropping the current task, for urgency, will of course get the velocity / scope discussion. And the seemingly simple fix for the entire team is apparently that we should just increase velocity, but we're just too retarded to do that.
A number of years ago, I left the corporate world, as horrible as that was, there were some people that had answers. Since joining the startup world, perhaps due to bad luck, I've never had a proper answer. I always get a "I'll get back to you on this" and they never get back. If I push for it, it usually gets deprioritized even though it was considered top priority. If I push even more I have to start investigating it. Talk to stakeholders that are not aligned on answers, and it never seems to be about users. It's always growth and velocity.
</Rant>
I once had a manager that pushed and pulled everything and everyone in all directions at once without a plan. Everytime he said he has 1000s of problems to solve. Our last meeting, before the one with HR, ended when I asked him to spontaniously name the top 10, no screw ten, just name three problems you want your ops team tackle right now. Unsurprisingly, he failed to answer. I had my meeting with HR the same afternoon, he was out a mere 4 months later.
I've been wondering for some time if it would be possible and effective to delegate all administrative and process responsibilities to line managers. Remove the IC from the planning documentation process entirely and let them plan their own execution however they see fit within each Sprint.
The only responsibility for the IC would be stand ups with their manager to discuss progress and agree to future timelines. The ICs wouldn't have to go to any other Agile meetings or write any business/project planning docs. Manager would scope and write all IC tickets.
I think you would very quickly see a culture change with regard to process work. Having sole responsibility for both creating and completing the process work, it would be in the manager's best interests to make it efficient.
I've never seen an org try the above, but it doesn't seem crazy to me. I expect you'd still be able to attract managers through increased compensation and opportunities for career progression.
Note: I'm not saying the IC forfeits all planning discretion, I simply mean it would be the manager's responsibility to write it up into whatever documentation is required by the org, track progress, rewrite the plan as necessary, etc.
> If I push even more I have to start investigating it. Talk to stakeholders that are not aligned on answers, and it never seems to be about users. It's always growth and velocity
Why is this inherently bad? Growth and velocity can be beneficial for users.
The secret is that if you’re good enough pretty much any company can be what you want. Most people don’t really know what they’re doing so if you are good and just build stuff that is useful I’ve found that people don’t really get in your way.
If you try to ask for permission and write up docs, etc etc then it’s a pain, but if you just _do_ it resistance becomes a lot less.
After reading through this I am convinced that the author learned nothing novel outside of fundamental operations methods I regularly see deployed at companies of all shapes and sizes.
Yep... Maybe they are new to the last 10 years of startup product management? 'operator' makes it sound like they are coming from the investor world, where all you see is hoodies, flashy demos, PowerPoints will YoY growth numbers, and little of the day-to-day behind them
A lot of people in tech haven't collaborated with experienced product managers either, or owned little of the financial/growth side of launching something, where these kinds of questions get ingrained into you pretty fast. Much more of a dark art imo is how to act on them without giving your team whiplash and crushing stress (beyond their comment of 'keep innovation teams small', which means fewer people will still suffer the same problem)
Operating well means you could do things that doesn't scale/manually at first, but then you understand the process enough to automate it away so you can tackle the next problem and you don't need to throwing people in linearly/exponentially. It applies to both software and organization level.
There is a similar term in DevOps that I forgot. Hopefully someone can chime in.
I think you're talking about eliminating toil.
First time you have to step in and do something, cool, get in there, get it done.
Second time, sounds like that wasn't a one-off, you have toil, and you need a runbook on the company wiki or internal doc site - that way anyone in the team (or organisation or company), can quickly step in and do that thing.
Third time, have somebody else run through the runbook it, validate it, figure out if it can be improved. Perhaps have some better alarms and operational oversight.
Now, start automating parts of the runbook. Some parts will be easy, some will be hard. Do the easy ones first and update the runbook.
Automation will need alarms with the right thresholds. Think about those carefully and remember whenever an alarm fires there are only three things you should be doing: fix the problem; change the threshold; delete the alarm. If you do anything else - especially ignore it and just look at things and wait to see if anything else happens - you have misunderstood and are heading towards alarm fatigue. Don't do this. Ever. Remember the three possible actions.
Once all the parts of the runbook are automated and alarms are working correctly to trigger automatic resolution, delete the runbook.
You have now eliminated toil.
This can apply to any manual operational task that needs to happen anywhere in a business, but is most easily used when improving resiliency and durability in systems that have easy automatic resolution (such as horizontal scaling by adding more instances when loads are high on existing infra). It's exactly what an AWS EC2 ASG is there to do, for example.
For anyone that is interested, my team at Rootly (https://rootly.com/) built an incident management platform that has been greatly inspired by the folks at Stripe!
> Jump on that late night Zoom, reframe the problem, and go line by line to make it work
I think that most of us appreciate that sometimes it's just necessary to do this, e.g. because Things Are On Fire, but I think that, amongst the numerous other red-flags that other comments have pointed out, this one particularly sticks out to me.
If you need to grab workers to fight fires "late into the night", that's probably an indicator that your "operating" practices are creating fires that shouldn't have been there in the first place, right?
Highlighting this as a "pro-move" for management was probably not their best idea IMHO.
Easier said than done. No system with real usage can achieve 100% up time. When problems inevitably occur, what do you expect Stripe to do? Wait until 10am the next morning??
Interesting article, but mostly irrelevant to startups. It’s basically a series of guardrails/habits that big companies need to use to eke out some progress when default mode is to not do anything.
I think a lot of people at Stripe are drinking the kool aid waiting for the IPO to make some money. Hopefully they don't self destruct before that though.
I read the whole article and I though "this is management bullshit and this waynof working is toxic" then I read the comments and I'm glad people think the same
> Turn up the heat in every interaction and ask uncomfortable questions. Some of the questions I repeatedly ask:
> What’s the soonest we could get this done?
> What would you need to get this done tomorrow instead of next week?
Some helpful insight into why their employees are crying and burning out. Has anyone else's impression of the Collisons been tainted by the realization that they seem to have inculcated psychopathy into their corporate culture?
> Has anyone else's impression of the Collisons been tainted by the realization that they seem to have inculcated psychopathy into their corporate culture?
Nearly every confirmation of this shared here on HN is still self-censored to some degree, but to summarize: yes.
They are uncomfortable but without asking questions like these it is hard to become more productive. It is also demanding of the employees, no doubt about it but I think people that want to work at Stripe realize it is a demanding environment. Calling it psychopathy is uncalled for.
Is there something wrong about getting things done faster.
I can't imagine Stripe being a particularly good workplace if a manager is continuously trying to give someone a hard time on the basis of assumptions such as a task taking long is because of some inherent deficiency within the employee.
It seems to me that your assumption is that the manager operates in bad faith. If that is true, no matter what they do, it will all be bullshit, so there’s nothing to discuss.
On the other hand, if the manager trusts the employee, and they trust their manager, and they both want to deliver something valuable to their customer, those pieces of advice all look pretty good to me.
Using the word 'operator' is a pretty obvious red flag.
This word isn't common in software because we are all operators, but if you're writing for an audience that includes investors and consultants, using the word operator to denote that you're actually executing (as opposed to investing/consulting) is pretty common.
Not a red flag, just different vocabulary for a different audience.
I enjoyed replacing it with “worker bee” in my head, at least.
I think his use of operator is a result of his VC background where it is a common term. In that context it is used to distinguish b/w investors that come from a finance background vs a startup background. Or to describe people that transition from being an investor in a company/board member to working at the company directly.
Being an operator just means you're executing. If you're a good operator, you're good at executing on ideas/projects/whatever.
Why?
> “does everyone agree this is the right path? Does anyone disagree”
Hey, I’m just asking questions! We’re just discussing! You’re allowed to disagree!
It’s so funny, and hard to describe, the intentional slight malice in such moments. Like it’s absolutely there, and absolutely veiled and intentionally done in such a way to lend plausible deniability.
In a given situation, everyone knows the “correct” answer, it’s already been telegraphed in any number of ways. Sure, you can disagree. We have an open environment here after all. We value discussion.
Thing is, you’re probably not gonna have a fun time if you do. You’re probably gonna end up wishing you had kept your big yap shut. Strangely enough. “Disagree and commit”
I had a project that would have gone so very much better if we had simply recorded the minority report, and reviewed them when too many surprises stacked up to see if anyone was more right than wrong when disagreeing.
There’s a very disturbing misunderstanding about the difference between consensus and unanimity, made doubly so on projects that actually embrace distributed computing concepts like consensus and unanimity.
Yeah, this only works when the culture is based on trust. And when individuals trust each other. Using the question, especially in the way described in the article, is just putting more social pressure on employees. Bad management, bad people skills and in the end bad for ops management.
What in the world is an Operator?
I cannot believe the comments here so far. It’s just sad to see the decline of culture be reflected in Hacker News too. I thought Nietzsche’s “inversion of values” happens every few thousand years, little did I know..