Hacker News new | ask | show | jobs
by raincom 1043 days ago
Lessons learned from that post:

(1) "I was told to hire a lot of people. Put fuel on the fire they said. Bring industry experts who can move the needle. All this BS you hear all day. All failed. I hired VPs and bloated my payroll. Ultimately I ended up with a bunch of highly paid employees who don’t know how to do anything but to “build and lead amazing teams.” Imagine you hire someone to scale an area and their solution is to divide that area into 5 sub areas and hire someone for each of them to figure it out, etc. that’s their solution."

(2) "I ended up focusing my efforts on hiring and ramping up those VPs and dealing with their dumb ideas instead of focusing on my 3 core tenants: build, sell, and deliver."

4 comments

This is too real in big corp as well as the VC funded start up world.

A bunch of bourgeoisie over-educated idiots, usually with MBAs, who don't know how to do anything except take credit for work that other people do.

I worked at a startup that had <4 months of runway left and thought the best plan was to bring on a VP of Data Science because of their resume/history, in spite of the fact that we had no data to do science on and no customers for which to provide value via data science. That VP of Data Science turned out to be a person that didn't know how to do much more than, as the article said, "build and scale amazing teams".

The story ends as you'd expect, we all got laid off and the founder was shitty.

> I worked at a startup that had <4 months of runway left and thought the best plan was to bring on a VP of Data Science because of their resume/history, in spite of the fact that we had no data to do science on and no customers for which to provide value via data science.

I could see this happening with AI.

The solutions presented great.

The made sense.

They smelled good.

They made great leadership stories.

...but none of it actually mattered to the customer.

Yeah!

Reminds me of a project life cycle cartoon I first saw in a software book early in my career.

Just now searched for "systems analysis tyre cartoon" and selected this page, which seems the best, on a brief look, since it has both some history and multiple versions of the cartoon:

https://www.businessballs.com/amusement-stress-relief/tree-s...

There are more modern versions too, with additional panels, like: https://pmac-agpc.ca/sites/default/files/Tree.jpg

I especially like “how the customer was billed”.

>I especially like “how the customer was billed”.

Good one. A Bridge Too Far ... (1)

I shall sell them a naayysse lil ship in Arizona.

(1) https://en.m.wikipedia.org/wiki/A_Bridge_Too_Far_(film)

I like number 7, the documentation one, which really goes to show how little the real item is understood while everyone else is creating/imagining their own version. Dissociation within the whole team.
Nice one, I mean, nice seven. ;-)

Also, after reading your comment, I went back and looked at all the panels.

I now see a Zen-like quality of nothingness in 5, 7 and 10.

My link actually includes yours and many more, even non-computer ones.
Where exactly? I’m not seeing it; I’m on mobile if that matters.
That's how it works in a nutshell. Lots of talkers out there. The people I know who do the real work are the ones at the bottom, and you don't know them because they keep their heads down and focus on writing code. The people that self-promote the most are the ones least capable.
Time spent coding is a zero sum. Leaders are needed to identify how to do use that energy and time. In terms of business success. This might be the #1 thing (granted I’m entirely speculating). Are your priorities correct and do the engineers know them? This is not that easy. People will argue endlessly over when to address tech debt, how much security is enough security, how much to deliver early vs fully formed, what features to build, When to bail on a half made feature, etc etc.
Looks like we found the person “building and leading amazing teams” in the thread. How could those lowly coders ever figure out how to secure a product?
People building projects don't tend to argue about tech debt and security unless they've had a leader make decisions that compromised their comfort levels. Quorum decision making in those circumstances keeps those things in check.
> Quorum decision making in those circumstances keeps those things in check.

Depends upon the composition of the quorum. If the quorum is mostly "eh it works, just ship it", jugaad, chabuduo, corner cutting engineers, then I've witnessed adverse results.

Conscientious engineering that delicately balances trade-offs is difficult to teach, and poorly discerned by most casual observers (even other conscientious engineers casually observing) in the short term.

>jugaad, chabuduo

https://en.wikipedia.org/wiki/Jugaad

I love seeing other culture's words for the universal engineering concepts of "hack", "kludge" and "bodge"

Nah I disagree 20 years in the industry across fields and most management was just incompetent. I concur with the earlier poster.
The OP should hire someone to handle VC requests (better say to send most of those requests to /dev/null with a nice chocolate & flowers wrap) and keep customers happy with his productive five employees. Growth would come naturally over time.
You are supposed to do all that with other people's money, dummy.
He took VC funding so he did it perfectly right (well, depending on how much his previous job made).
Then I sincerely hope he played the kickbacks-and-favors game correctly and the reddit post is just for optics.
I'm not in the know. What's the kickbacks-and-favors game? I understand the words, but how does it work?
You hire useless people and pay them bloated salaries using investors' money. Then they order something from a consulting firm ran by your wife, or just remember the favor, and hire you into an overpaid useless role next time they secure a round.

On paper it looks like money is being spent on product development. In practice, it's a network of friends using buzzwords to direct VC money into their pockets.

Investors don't mind it too much. Fund managers are not investing their own money either (and are part of the game) and angels hope that a chance of owning 1% of the next Uber justifies all the financial shenanigans.

That. And investors usually don't invst their own money, but others' money via a fund or similar, and if something does not go well, they might not lose anything from their own and just tell the losers that IT investments have a high risk.