I think your advice is great for tech leads at big companies, but for tech leads at startups, I have to disagree with the point about "Work for your product - not your company."
At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind.
"Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.
As a tech lead at a midsize company (~300 employees) I have to agree with this. There seems to be a strong tendency among tech teams to always push back on everything that business wants. We need to remember that we’re on the same team.
> If you’re at a startup, your product is your business.
Your product is whatever you end up with after the long tenuous period of being startup, which often evolves/pivots drastically over time. Your product is your ability to execute.
Depends if the product is a key profit center. If your startup is making a product and it's not a profit center, it might get binned, it might get pivoted, it might postponed. The advice is great, just don't die on a shortsighted engineering hill when the decision come from emotional attachment to your work rather than what's best for the companies positioning and financial health. You can always put that love and energy into a new/pivoting of the product.
The problem is if you're at a startup you probably don't know what your product is, because you don't know who your customers are.
My last startup died because we committed too hard to the product and the business model, which while innovative and one that I still believe could have succeeded - we utterly failed because we didn't understand our customers and we didn't pivot fast enough, ran out of runway and then everyone but the founders got laid off. Waiting on hearing about the equity.
If I may function as the devil's advocate - One can read the above as a claim that because you didn't have a good business guy engineers should have worked faster? Would a faster product iteration worked if the business acumen would still have been missing?
It might have. Part of it was arrogance and bad advice from VCs, not lack of business acumen. There was a rejection for industry practice because we were different and doing something different, but it wasn't actually different and couldn't monetize because we focused on users that couldn't pay us real money, while working in an industry that doesn't value innovation.
I don't think the argument is that engineers should work faster. It's that they should be willing to skip some of the stuff you would normally say is good practice in order to ship features super agile and make any necessary pivot easier.
It wasn't a lack of features so much as a lack of talking to people that had purchasing discretion. Never focus on users in B2B, focus on people who have the ability to approve a purchase order.
This isn't universally true. It only applies to a segment of "pioneering" startups. It will hurt a startup otherwise.
There are different types of startups. Not all startups are working on novel discoveries and exploring new frontiers. Zoom built a better video conferencing platform by not moving fast and breaking things.
I agree with you that you have to work for the company objectives.
I think at a start-up the correct decision early on is to take on a bunch of tech debt, but then pay it down as the horizon of the company expands.
Early on, you need to iterate fast on a few key flows and make a product that people want, but once you get product market fit, things like scalability and reliability start mattering a lot more and you need to pay down the debt.
The issue comes when the company's objective is actually to build a reliable, stable, long term product, but it is still in startup mindset of "ship this feature by yesterday at all costs", and expects the rest to come for free.
That only works if tech team is evaluated and measured with the same objectives as business teams.
I've heard so many times "think of bigger picture".. but when we did the tech team got kicked down - as we didn't achieve our own objectives because we sacrificed them for "bigger picture".
At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind. "Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.