Comment by akickinthestone | Hacker News Reader

Comment by akickinthestone | Hacker News Reader

akickinthestone

On one company I worked on, in one year tech team shipped 53 epics, delivering all the features sales, CS and product needs. By EOY the company grew zero. Literally zero. This was a series A company. CTO got in a meeting with the CEO and said: we delivered everything you asked for, but the company didn't grew. What went wrong? CEO wasn't able to act on this. In the end the company started by laying off the tech team - which delivered what is was asked for (even sometimes knowing that it was not going to work).

The more I think about it, I get a feeling that if your core product depends on software and your CEO doesn't know how to develop software, then your company is doomed to fail. And because all companies depend on software nowadays, more and more are doomed to fail. There's also this new idea of CFOs running the company. But they don't run the company, they run the books. It's hard to grow a product based on the books.

It's confusing and it looks to me that less and less people have the balls to be accountable for their lack of action.

Why does the CEO knowing how to develop software matter? This sounds more like the company was unable to sell the software, either because of product/market fit or some other reason

Because the CEO needs to understand their product deeply to know what is achievable, what isn't, and how easy it is. Many (most?) software products leave simple "duh" type features on the table, while they pursue incredibly difficult and brittle things instead. This can be prevented.

Just like how, IMO, a car company CEO needs to know how a car works very well. They should know enough to gauge that a dual clutch transmission on a 30,000 dollar car is risky and will blow up.

Again, we see this same sort of problem with cars. Cars will have all these incredibly complex bells and whistles. But then the basics, like the engine and transmission, suck ass and break down. And that's why Honda and Toyota eats their lunch.

It does seem that something went wrong in your story, but I don’t think it’s the CEO not knowing how to develop software. Maybe I misunderstand what you mean by that phrase.

In all of these types of stories, it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part.

CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc

CEO determined there was a market fit or vision for a product, convinced an investor or shareholder to invest based on multiple reviews of this vision then hired a set of people to execute on this vision.

Yes, there are plenty of bullshit artists out there. But, the product itself is developed by people below the CEO.

> it is always the CEO or CTOs fault the way it is framed. There is never any accountability on the engineers part.

If we're going with the military analogy in TFA, it's always the general fault for loosing a war. Especially if the soldiers did all they were told to do. He's the one in control making all the major decision.

> CEO/CTO sets the vision. They are not the ones developing the UI or developing the API or writing documentation etc

That's why you need a feedback loop. If a general only stays in a bunker, deciding things based on map and single line reports, then it's a poor general. You have to also have a clear sense of what the product is (dogfooding it if it's necessary) so that you can adjust its course. Vision is all bell and whistle. People wants to pay for solutions, not nice ideas. They may even be willing to invest in such solutions. But you have to deliver it.

> If a general only stays in a bunker, deciding things based on map and single line reports, then it's a poor general.

This is a bit of an exaggeration: if he can pull the signal out of the maps and single-line reports and deliver results, then he is a good general. The point is he can't blame his failure on the fact that he didn't know what was happening, because his job is to understand enough to make money. If he failed because didn't understand, then he should have been prioritizing his information pipeline (whether that's personal knowledge or it's finding the right people to deliver the correct information to him intelligibly.)

Otherwise, it's like saying you weren't responsible for the car accident because you were drunk.

Unless a single person decided to go completely against what they are told and did something bad all on their own, then yes, it's always the CEO/CTO fault.

That shouldn't be an alien concept.

What's the alternative? Going against what the powers that be say is a great way for an engineer to get fired.

Reply on news.ycombinator.com