I had a similar situation, but in my case was due to a an upstream outage in a AWS Region.
The final assessment in the Incident Review was that we should have a multi-cloud strategy. Our luck that we had a very reasonable CTO that prevented the team do to that.
He said something along the lines that he would not spend 3/4 of a million plus 40% of our engineering time to cover something that rarely happens.
> This is because you’re not being precise in your reasoning. Look at the specifics and make a decision based on the facts in front of you
I agree with the premise here, but in my experience running incidents review the issue that I see it’s a mixture of a performatic safetycism with reactivity.
Processes are the cheap bandaid to fix design, architectural and cultural issues.
Most of the net positive micro-reforms that we had after incident reviews were the ones that invested in safety nets, faster recoveries, and guardrailing than a new process and will tax everyone.
> Processes are the cheap bandaid to fix design, architectural and cultural issues.
They can be, yes. I have a friend that thinks I'm totally insane by wanting to release code to production multiple times a day. His sweet spot is once every 2 weeks because he wants QA to check over every change. Most of his employers can manage once a month at best, and once a quarter is more typical.
> Most of the net positive micro-reforms that we had after incident reviews were the ones that invested in safety nets, faster recoveries, and guardrailing than a new process and will tax everyone.
I 100% agree with this. Your comment also reminded me to say that incident reviews are necessary but not sufficient. You also need engineering leadership reviewing at a higher-level to make bigger organisational or technical changes to further improve things.
I like the German workplace (to white collar job) for several reasons but this one is one that drives me away.
We used to have an issue of deployments breaking in production, and one of the reasons was that we did not have some kind of smoke test in the post deployment (in our case we only had a rolling update as a strategy).
The rational solution was only create that post-deployment step. The solution that our German managers demanded: cut access to deployment for the entire team, “on-call” to check the deployments, and a deployment spreadsheet to track it.
In my experience it’s a cultural problem in Germany. Everything has to be done methodically, even if the method adds a disproportionate amount of friction. Often, the purported benefits are not even there. The thoroughness is full of holes, the diligence never done, the follow-ups never happening.
It leads to situations where you need a certificate from your landlord that you take to the certified locksmith that your landlord contracted and show a piece of ID to order a key double that arrives 3 business days later at a cost of 60€. A smart German knows that there’s a locksmith in the basement of a nearby shopping mall that will gladly duplicate any key without a fuss, but even then the price is inflated by the authorised locksmiths.
I document German bureaucracy for immigrants. Everything is like this. Every time I think “it can’t really be this ridiculous, I’m being uncharitable”, a colleague has a story that confirms that the truth is even more absurd.
It’s funny until you realise the cost it has for society at large. All the wasted labour, all the bottlenecks, and little to show for it.
The article is good, but I think it communicates with a narrower audience than it intended to in terms of demographics, especially the ones who do not work in nice tech companies.
For instance that passage:
> I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code.
I used to work in a tech company (bytes), and now I am working in an old money/traditional company (atoms) that uses technology marginally to stay ahead. My team's (a couple of dozens) median age is 53, and I do not see how this relates to them or even to myself.
I definitely would like to hear more from "Working Bee Engineer", "Dark Matter Engineer", "How I survived 25 layoffs Engineer", "How I kept my sanity working with internal clients Engineer", "I managed to raise kids being in Tech as Engineer", "The bodybuilder/triathlete/sports(wo)man Engineer" and so on.
I'm not being cynical, but I miss the old days of actionable and down-to-earth blogposts that anyone could relate to.
One of the aspects that has never been discussed in those studies is the competitor's offset, which wouldn't adopt the 4-day work week.
Local companies in Germany have a very defensive business due to the nature of the market (not so internationalized, highly consolidated, a lot of small businesses that no big corporation would try to enter, and low competition in mid-sized businesses due to bureaucracy).
For local SaaS companies or local companies for sure, it can work since no big competitor can rise. Still, the real test would be Germany placing that in their industrial base (e.g. cars, industrial instruments, chemical industry, logistics), or in some other businesses where the entry barrier is low.
Yes. Those are the specific conventions that the betriebsrat (Workers Concil) decides, but this varies from company to company and state.
My point is, considering this specific arrangement of 7 hours a day/workday (35h), what would be the offset comparing this same company with 28h/week (4D) with another company not in that arrangement in scenarios where throughput per hour matters?
I have a feeling people are overthinking the whole "we need to have a moat" and really the best moat you can have until you're a multi-million/billion dollar business is your craftsmanship (as silly as it sounds).
Good UI/UX is still the edge as technology becomes more of a commodity.
> They want to work on this part-time
> They want to quit their job but haven't set a date to do it
> They're going to quit their job but only after the YC interview
I resonate with the OP because I am in this exact situation that I am building something but I cannot leave my current job now.
When some friends started to build companies in mid-2000/mid-2010 you could code/build something, try to get some traction and you could be received by VCs/angels and occasionally they could write a 25K check for you to work for 3-6 months to build it and perhaps you could get some traction and then scale or go burst.
Now the bar for new products it's absurdly high if you're out of the YC or San Francisco VC circles or if you do not have anyone in the industry; plus most of the VCs prefer to invest in "pedigree founders" than in unknown people, especially if those people are outside of the bay area.
In my first endeavor, I went with a finished product that undercut some big enterprise SaaS vendors, and we lost space for a bunch of non-technical guys with PPTs and one idea.
>> Now the bar for new products it's absurdly high if you're out of the YC or San Francisco VC circles or if you do not have anyone in the industry; plus most of the VCs prefer to invest in "pedigree founders" than in unknown people, especially if those people are outside of the bay area.
I suppose that's if you pursue the "SAAS AI Analytics Crypto Cloud" latest hype where all the low hanging fruit has been picked already.
I'm in EU (Romania) and don't feel the least bit concerned or connected about San Francisco VCs and yet I'm preparing not one but two businesses which could go to 100s of millions (first) or billions (second).
1) First is a plain brick-and-mortar physical product delivery thing. Zero competition from "YC San Francisco VC" crowd who almost exclusively targets computer-only stuff as it's much easier and cleaner to deal with. But if you have the brains for computers (and I've been working as a well paid eastern European software dev for 20+ years), you can most definitely compete in the "physical" world should you identify an opportunity there as I did. This is the businesses that I estimate in the half billion before it reaches saturation or someone steals it from me.
2) Second is online services hence much easier to deliver and to grow hence with the properly polished product (which sells as hot cake in a brick and mortar setting) and target market should have no problem reaching billions. Provided that #1 works well enough to kickstart me into #2.
So ... cofounders. Anyone interested?
If so send me a mail or go on my forum and enter "sunshine" when you register yourself (so I know you're not a spambot, they are this dumb):
So the first business has no competition... but also no defensibility?
The second business should be able to be much bigger AND easier, but you aren't focussing all your efforts on it because you're splitting your time with the first, non-defensible business?
It's good to be optimistic, but balance that with realism. It's easy to build a billion dollar business on paper, much harder in reality.
Trying my best to put this politely, but this reads like a list of excuses.
If you have dependents and a stable income is important then by all means, wait for the perfect conditons to arise (they likely won't - or when they do, everyone else will also be taking advantage of such conditons).
Otherwise, take the plunge. Reduce your expenses e.g live in crappy apartment to save money and go all in on your dreams
Honestly, in this situation, you want paying customers not VC-funding. YC at least has an objective application process (VC's don't, it just cold-email) and even then the acceptance rate makes it a non-viable dependable strategies.
Especially if you're enterprise SaaS..the question you need to answer is, how do you get a customer to pay?
(Sometimes having a co-founder here helps to answer this question)
Further context: In Brazil since we have universal health care provided by the government, generally speaking non outsourced or contractors becomes public servants.
The issue is: Public service in Brazil is expensive and is virtually impossible to fire anyone. On top of that the cost of public service has second order effects in the public balance sheet for the municipalities plus it has a huge burden in the public retirement system.
Not saying that is right or wrong, but this is very common in the Brazilian heath system.
Not Indian and not personally affective. I came from a society quite similar in terms of cultural e socio-economical background with India and maybe there’s a missing point.
I got your point and you’re right in terms of worship philanthropic people with a lot of money.
However, there’s one aspect that is overlooked when a person that helped and/or serves as reference for a bunch of people that is the “emotional gratitude” or “sense of reference” that those people has in some peoples mind and no matter how much of objective and maybe correct post-mortem criticism will change people’s mind.
At the limit, any public figure can, with little scrutiny, be framed as bad.
One example from my country: Ayrton Senna (deceased F1 Driver) even being a millionaire, coming from a very privileged background in 80s in a country that used to have at least 40% of its people below the poverty line.
Even not doing (during life) objectively nothing for poor people, a lot of folks (me included) consider the guy as a reference, in some cases as a hero. When he died a lot of folks felt that they lost their “hero” and actually he had a state funeral that no other Brazilian will ever have again [1].
My point is that there’s more nuance and layers around that topic when someone with a lot of money dies, and there’s no right or wrong since we’re al humans.
> 2. In general, this is just an indication that YC is not the quality filter it once was. It seems they are more interested in founders online following (the founders are both YouTubers with significant channel sizes) than they are about the business itself.
I noticed same thing with the latest batches (2019+) where founders sometimes with only a welcome page in the site, an e-mail list, and a blog going to Linkedin and doing a lot of self-promoting to generate steam in the company instead to deliver something good.
The final assessment in the Incident Review was that we should have a multi-cloud strategy. Our luck that we had a very reasonable CTO that prevented the team do to that.
He said something along the lines that he would not spend 3/4 of a million plus 40% of our engineering time to cover something that rarely happens.
reply