HN user

ajax33

40 karma

akj1996 at gmail dot com

Posts10
Comments9
View on HN

TL;DR

- Spend the first 10 percent of the time communicating your vision for the thing.

- Allow others to spend the next 80 percent of the time moving the thing forward.

- Spend another 10 percent of the time polishing the thing, and helping others understand why and how you’re tweaking.

The number you quoted for oil and gas revenue is quite low.

ExxonMobil alone made $300 billion in revenue in 2023.

Even if you look at oil majors that only operate in the US - Marathon had $170 billion in revenue in 2023.

You need to step back from the day-to-day and see if you are able to generate any meaningful accomplishments at the end of a month or a quarter. Things being a little random at a day level is okay if you are ultimately growing as an IC with projects / accomplishments that can help you for your next job or promotion.

People who are in constant PoC mode will eventually get burnt out and won’t get rewarded for it either. It’s a sign of poor management. See if you can work with your manager to create a set of quarterly goals to accomplish which are meaningful to the organisation. Unless your org is a very early stage startup, they should be able to do this. If not, time to find a new job or you’ll end up having wasted your time

This is a really good list.

I head engineering for an enterprise SaaS startup in the manufacturing space. Wanted to add a few points to this:

1. Software Integrations: Enterprise software is almost never deployed in a vacuum. There will be a ton of existing software that companies use that they would want you to integrate with - most commonly being either some CRM like Salesforce or an ERP like SAP, Oracle. When pitching to a customer, it would be great to try and learn what existing software tools they use and see if opportunities exist to try and integrate with them ultimately. This will make your software very very hard for them to get rid off later and will also help distinguish you from your competitors who might try to be avoiding integrations. Designing your architecture with integrations in mind is a good idea.

2. Audit logs: Depending on the industry, there might be a strong requirement for compliance/auditing. The enterprise would want to ensure that every action undertaken on the platform is audited and can be reviewed on-demand later.

3. On-premise vs Cloud deployments: You might find certain clients that operate their own hardware and software and want you to just hand them some executable that they can deploy in their systems. On the other hand you'll also find companies that have gone all-in on cloud and won't bat an eyelid as long as you are deployed on some known cloud like Azure, AWS or GCP. Increasingly more and more companies are going the private cloud route and ask you to deploy on their cloud accounts (most commonly Azure - Microsoft has a much stronger hold on the enterprise market). Be prepared to handle requests like these. In several cases, you might be able push to have the SaaS being served from your cloud accounts but not always.

4. IT departments: Enterprise companies will invariably have an IT department that is supposed to ensure that the procurement process goes smoothly from a technical perspective and that you are compliant with all of their technical requirements. Their primary job is to ensure their asses are covered and nobody blames them later for technical/compliance issues later. Do not cut them out of the sales process. While they don't have the ability to approve the sale, they definitely have the ability to block it. Involve them closely and get their strong buy-in so that they don't become a bottleneck later.

Hi ! I am interested! Would be a great opportunity to learn something new while delivering real value to the world! My personal email is in my HN profile!

Could you please elaborate on what the drawbacks with the Azure postgres offering are?

I am currently evaluating the same choice - Azure Postgres vs self-hosting in my k8s cluster.