4 ms·

It is amazing how culture problems often start with the CEO. Sometimes, non-technical CEOs are very good at their own speciality (selling, motivating, etc.) but

It is amazing how culture problems often start with the CEO. Sometimes, non-technical CEOs are very good at their own speciality (selling, motivating, etc.) but extremely bad at systems thinking. Other times, CEOs hire yes-men and yes-women below them and everyone is afraid/unwilling to tell the CEO the truth. Other times the company has raised a ton of money and attracts people who would otherwise not work at a startup and whose major focus is resume building and moving to the next job. If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. It means there is likely no transparency into the actual team and what is actually going on, which means the CEO is likely BSing the investors. All of these are reasons why you should not work at a startup if you do not 100% believe in the CEO. Be skeptical b/c most startup CEOs really do not have a track record of insight and integrity. If the CEO is aloof or seems out of touch and not someone who you think would really enjoy talking to you about your job and who respects the work you do, be wary.

grayfox 12y ago
Terrific insight. My situation at present has taught me many of these lessons... New comers to start-ups, do take heed!
jacquesm 12y ago
In five words: fish rots from the head.
monk_e_boy 12y ago
Replace CEO with "owner of small business" and this is what I see endlessly. The chops needed to build a business and sell a product are a long way along a spectrum from how to grow that business and how to keep the codebase stable.
- jnbiche 12y ago
  Agreed. Amazingly, some of them are even "technical", but have no concept of technical debt, and zero respect for software engineering practices that don't lead directly to new features. Either they never understood these things in the first place (since this is usually not taught as part of a degree in CS or EE) or they've long since forgotten them.
  - monk_e_boy 12y ago
    I'm upfront and start the conversation with, "You employed me to give you an honest opinion. I think we are going in the wrong direction, we need more tests and some refactoring. This will cost us money now, but save money later." and I always get the reply that sure, they totally understand, but we're going to do a quick and dirty hack today and sort it all out next week... I used to just refactor and test as I went along, but then you end up ruffling feathers and being slower that others. This is then used as ammo against you. So you lose by doing the right thing. I think pouring energy into other things (open source) is more productive.
  - derefr 12y ago
    You can be "technical" without a need for a concept of technical debt. - Indie video game designer/developers, for example, live in a world where everything they write is a one-off product that will ship, at most, a v1.0.4 six years after v1.0.0. To them, code is a medium for crafting an experience, and whether the code is of quality is immaterial as long as it creates the correct experience. - Data scientists (and bioinformatics pepole, and a few other similar groups) live in a world where everything they write is effectively a script-as-experimental-apparatus. If the script is producing output conforming to the proposed experimental method, then it's done. They run it, then discard it. It's not usually even under version control; only recently have such scripts been considered worth including for purposes of peer review and replication. And there are other examples. I'm not saying that these kind of people are "software engineers"—engineering of any kind is never even a consideration for them; whether the product is well-engineered has no impact on their livelihoods. But these people frequently are lumped into the category of "programmers", and that tends to confuse this sort of discussion a lot. The "software industry" doesn't just contain engineers doing engineering (well or poorly); it also contains prototypers and illusionists and tinkers and scientists, all working to their own criteria of art, none of whom will have any reason to pick up a single shred of engineering knowledge, even with decades spent in their own industries. And then these people apply for "programming jobs", and we wonder why they don't know what git is or how to properly modularize a codebase for maintainability. It's a communication problem, I think. We need to stop calling everything we're doing "programming." Maybe we need an entirely new verb for doing software engineering, of the kind you do when you're writing something like car firmware, or Amazon S3, or the Googlebot. "Programming" is about as precise in describing that as "doing math" is in describing the invention of the lambda calculus.
coffeemug 12y ago
> If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. I know you said 'concern' and not 'problem', but I generally do this and have a totally different motivation for it. Our guys and gals are really busy. There is a lot of work (often very specialized work) that needs to get done, and it's important to shield them from distractions. Investors generally tend to helicopter up -- they see our world/company from thirty thousand feet. It's a totally different perspective that takes some time and experience to get used to. Even most CEOs have trouble shifting into this mindset. It requires an enormous context shift. For people who don't have a lot of experience with this kind of thing, it can be dramatically harder to do it on a whim. A minute ago you were sitting at your computer, trying to figure out a C++ boost error message, and now someone asks you "how do you think the feature you're working on will impact the company's revenue in the next quarter?" That can really throw people off. They might feel like they should have had a better answer. Investor conversations can seem extremely important to people who aren't used to doing it on regular basis, and it can distract them from critical work. I think it's good general practice to try and avoid it. That doesn't mean undue paranoia -- if someone wants to talk to the investor (or the other way around), they're welcome to. But I think being thoughtful about protecting your people that are neck deep in work from distractions is usually a good policy.
- grandalf 12y ago
  I think at a certain point a company reaches a size where there are functional units that generally do independent work and the founder has little to do with it -- if an investor has an interest in that area (or ideally experience/advice to offer) it makes sense for some members of the team to be involved in the dialog, though probably not the guy writing the algorithms in c++.

grayfox 12y ago

Terrific insight. My situation at present has taught me many of these lessons... New comers to start-ups, do take heed!

jacquesm 12y ago

In five words: fish rots from the head.

monk_e_boy 12y ago

Replace CEO with "owner of small business" and this is what I see endlessly. The chops needed to build a business and sell a product are a long way along a spectrum from how to grow that business and how to keep the codebase stable.

jnbiche 12y ago
Agreed. Amazingly, some of them are even "technical", but have no concept of technical debt, and zero respect for software engineering practices that don't lead directly to new features. Either they never understood these things in the first place (since this is usually not taught as part of a degree in CS or EE) or they've long since forgotten them.
- monk_e_boy 12y ago
  I'm upfront and start the conversation with, "You employed me to give you an honest opinion. I think we are going in the wrong direction, we need more tests and some refactoring. This will cost us money now, but save money later." and I always get the reply that sure, they totally understand, but we're going to do a quick and dirty hack today and sort it all out next week... I used to just refactor and test as I went along, but then you end up ruffling feathers and being slower that others. This is then used as ammo against you. So you lose by doing the right thing. I think pouring energy into other things (open source) is more productive.
- derefr 12y ago
  You can be "technical" without a need for a concept of technical debt. - Indie video game designer/developers, for example, live in a world where everything they write is a one-off product that will ship, at most, a v1.0.4 six years after v1.0.0. To them, code is a medium for crafting an experience, and whether the code is of quality is immaterial as long as it creates the correct experience. - Data scientists (and bioinformatics pepole, and a few other similar groups) live in a world where everything they write is effectively a script-as-experimental-apparatus. If the script is producing output conforming to the proposed experimental method, then it's done. They run it, then discard it. It's not usually even under version control; only recently have such scripts been considered worth including for purposes of peer review and replication. And there are other examples. I'm not saying that these kind of people are "software engineers"—engineering of any kind is never even a consideration for them; whether the product is well-engineered has no impact on their livelihoods. But these people frequently are lumped into the category of "programmers", and that tends to confuse this sort of discussion a lot. The "software industry" doesn't just contain engineers doing engineering (well or poorly); it also contains prototypers and illusionists and tinkers and scientists, all working to their own criteria of art, none of whom will have any reason to pick up a single shred of engineering knowledge, even with decades spent in their own industries. And then these people apply for "programming jobs", and we wonder why they don't know what git is or how to properly modularize a codebase for maintainability. It's a communication problem, I think. We need to stop calling everything we're doing "programming." Maybe we need an entirely new verb for doing software engineering, of the kind you do when you're writing something like car firmware, or Amazon S3, or the Googlebot. "Programming" is about as precise in describing that as "doing math" is in describing the invention of the lambda calculus.

coffeemug 12y ago

> If the CEO is the only person meeting with investors or only trusts one or two other people to meet with them that is another big concern. I know you said 'concern' and not 'problem', but I generally do this and have a totally different motivation for it. Our guys and gals are really busy. There is a lot of work (often very specialized work) that needs to get done, and it's important to shield them from distractions. Investors generally tend to helicopter up -- they see our world/company from thirty thousand feet. It's a totally different perspective that takes some time and experience to get used to. Even most CEOs have trouble shifting into this mindset. It requires an enormous context shift. For people who don't have a lot of experience with this kind of thing, it can be dramatically harder to do it on a whim. A minute ago you were sitting at your computer, trying to figure out a C++ boost error message, and now someone asks you "how do you think the feature you're working on will impact the company's revenue in the next quarter?" That can really throw people off. They might feel like they should have had a better answer. Investor conversations can seem extremely important to people who aren't used to doing it on regular basis, and it can distract them from critical work. I think it's good general practice to try and avoid it. That doesn't mean undue paranoia -- if someone wants to talk to the investor (or the other way around), they're welcome to. But I think being thoughtful about protecting your people that are neck deep in work from distractions is usually a good policy.

grandalf 12y ago
I think at a certain point a company reaches a size where there are functional units that generally do independent work and the founder has little to do with it -- if an investor has an interest in that area (or ideally experience/advice to offer) it makes sense for some members of the team to be involved in the dialog, though probably not the guy writing the algorithms in c++.