Ask HN: How do I know if the startup I'm working at is dysfunctional?

At this point in your career, you should optimize for improving your skills by working with programmers who are better than you, in a rapid feedback environment.

Did you work with anyone who was better than you? What were the most useful skills you learned?

Really looking forward to a reply here! Pg did write a bit about what he has learned from tlb: http://www.paulgraham.com/gh.html (see the "Recognition" paragraph)

There's arguably no single greater environment than learning from great people.

Communication, choosing your battles, patience, emotional intelligence, just to mention the managerial and partnership aspects. Too many technical / marketing skills to name.

I come from a 100% technical background, and I can tell the skills I've acquired in the past year will last me a long, long time.

Several, including pg and rtm. The hardest skill is knowing what could be simplified, and what's good enough.

Holy Occam, you've managed to say more with a single sentence what I was struggling to put in several paragraph (all while I still working on the first draft my comment)!

OP needs to learn and the way to do is not just doing, but by looking at good examples, then doing, then receiving feedback on how it could be done better, and then improving.

This mirrors advice often given to musicians. Nobody wants to be the best player in the band.

Assuming that pushing to gain skills is the highest priority. Since I have while a bit of autonomy in the current startup (comparing to working in other company), would it be possible to improve my skills while simultaneously trying to changing things in the company (since I'd get to do more things)? Or would that be a futile effort?

I am not qualified enough to say if it is dysfunctional, however a big red flag to me is when your CTO says he "doesn't want git to be polluted".

My first piece of advice would be to go into his office and very respectfully ask him to unpack what he meant by that statement. He may have just been trying to say that you were too junior, he doesn't believe that unit tests are worth the business advantage, or any number of things.

The reason I suggest this as a first step is because it will open up the communication between him and you over something that may give you more insight as to why he would say such a statement that is so grossly over exaggerated to the point of being a lie.

The theory would then go that if you could get your CTO to open up about this subject, then they are going to be more likely to open up to about other suggestions regarding the development process/other operational efficiencies.

I actually talked with the CTO (not directly related to that), but I believe he doesn't think unit test is a worthwhile investment at the time. From what I learned, I don't think he has ever worked in an environment with a strong culture for automated testing + CI.

That is really cool that you began that dialogue!

Even though this is far from unit tests, were you allowed to suggest anything like Selenium? which would allow you to at least test the business facing functional points so that you could be sure that a release wouldn't break what the business person sees.

Just wondering if he is 100% against tests in all scenarios!

Selenium needs quite a bit more overhead than the unit test I'd be doing, so I think it's even less unlikely.

He is certainly not ideology against tests by any means, it's just he doesn't believe the trade off would be worth it (test writing time and debug vs time spend directly on development). My guess the answer would be along the line of "we're lacking resources"

One approach is to start documenting how much of your time is spent either a) manually testing changes because you have no automated tests b) debugging, fixing bugs, and patching messed up data due to bugs that easily could have been caught by tests. I find that investing in basic acceptance tests pays itself off very quickly. Good tests allow you to iterate on your early product much faster, because you can actually make changes without breaking things for your early users. If you can document the wasted time, maybe you can convince him of the benefit.

Write one test and use a CI rig to show how you can offload the testing in an automated fashion. (e.g. circleci.com, travisci.com, codeship.io, buildbox.io)

Part of the problem is that I'm not THAT good. I believe that there are a lot of things that can be fixed and/ or done better. And I'm fairly certain there are certain programmers that could do that, unfortunately, I'm yet to be a programmer of that capability. I can't keep up with both the expected work and trying to setup CI (to the extent that would demonstrate its usefulness)

FWIW You don't need to very good (or even write any code) to use travisci, it's very easy to do. You can start with just running basic compilation/lint checks: http://docs.travis-ci.com/user/getting-started/ -- just compiling/linting the code (to check for missing libraries, files you forgot to add to git, syntax errors, etc...) is _already_ useful. E.g., if you have a python codebase and never you never run pychecker or pylint (or if you have a php codebase and never run php -c or if you have a Java project and never build it entirely until release day...) you may be missing something that can lead to hours of downtime 4-5 weeks down the line.

If you're using a dynamically typed language I'd suggest very trivial (1-5 line) unit tests _just_ to test that you can instantiate the objects and catch basic type errors. If it's a web app, a simple script that starts a local instance and then make sures that retrieving "GET /" returns "200 OK" is again a huge improvement over _nothing_.

Overall, my/tlb's recommendation remains: be in a position where good programmers can offer you good feedback and where you're pushed to improving your own capacity.

> Part of the problem is that I'm not THAT good.

Not with that attitude, you're not :)

The only way you're going to get approval for "improving things" is if you can do both of the following: 1. Build a sound business case that shows that there is return on effort for the startup, and 2. Build a proof of concept that shows HOW it can be done in your environment. If you can't do both, then it will be fairly difficult to sell your company on your ideas for process improvement.

Rather than worrying about setting up CI all at one go, what I would suggest you do is structure your personal development workflow around some form of automated testing - either test-driven development or by just frequently running an integration and/or unit test suite. Keep the test code in a separate git repo and start out simply: setup a git hook script to execute the test suite locally after every time you run 'git pull'. From there, just build up the cleverness of your testing apparatus as you have time. If you start finding defects in other team members' changes incidentally as part of your work practices, that will prove the method in a way little else could.

You're definitely that good. I hear you, and I know exactly how this feels.

I've worked for two companies in the past year and a half, both with teams of ~5-10 developers, and nobody at either company was/is using any sort of automated tests. It's definitely frustrating -- not to mention lonely -- especially when you're immersed in a culture (hello HN) that's pimping a new test runner every two weeks.

I like testing for one and a half reasons: to capture the software requirements, and to change the software easily when those requirements change. If you've got one test, that's better than zero.

You don't have to set up your own Jenkins server -- Travis CI should do the trick nicely, and it's super easy to set up (although I know you're not supposed to say that kind of thing).

Here's a thought: Could you persuade the CTO to let you add the tests as a submodule to the project repo?

None of the cloud CI would work for us: we have an inhouse hosted git server (the CTO does not trust open source, in general). So to do automated testing, I'd have to set up a Jenkins server on my own.

That's strike two against him. Have you had the conversation with him about why he feels that way about open source?

The attitude about cloud services is more understandable, though inconvenient. However, I think you may be laboring under a misapprehension: You don't need to have a CI server to run tests automatically, you can have a test suite running locally and trigger it with a pre-commit hook (so you can't actually commit if a test fails).

My intuition would be that functional startups are visibly functional; they feel awesome. If you have to ask whether your startup is dysfunctional, then the key fact is that it's not awesome which I would expect---someone correct me if I'm wrong---that your equity is substantially less likely than usual to be worth much. Sure, there are non-awesome companies that succeed, but maybe they're just the rare examples from the very wide pool of non-awesome companies, or maybe they have founders who were good or lucky at obtaining venture capital or had some other special advantage. What's your company's special advantage? Do you have enough equity, or enough pay, to make it worth more than all the other startups you could join can offer you? Did you graduate from MIT or from Nowheresville college, and are they paying you $60K/year or $110K/year? Every offer has to be understood in comparison to its opportunity costs, the other offers you might get.

I'm from nowhereville college, and the pay is lower than the low end you gave.

Part of the reason I asked on HN is because I don't know if feeling awesome is the norm in a startup: the work is expected to be stressful, isn't it?

> Part of the reason I asked on HN is because I don't know if feeling awesome is the norm in a startup: the work is expected to be stressful, isn't it?

Yes and no. Waking up to a call at 3am because something you wrote broke and 50 guys in a warehouse are waiting on you should be stressful. A bug that costs the company $10-20k in double shipped orders is stressful.

If the stress is from just dealing with your coworkers, and not 'oh shit something went wrong', then I'd say its a cultural problem.

> I'm from nowhereville college, and the pay is lower than the low end you gave.

If you are not making 60k in the Bay Area, well, that is too low.

If you live in Nowhereville still, its probably fine.

"My intuition would be that functional startups are visibly functional; they feel awesome."

It is a lot more complicated than that. The term "sausage factory" usually applies - http://www.urbandictionary.com/define.php?term=sausage%20fac.... Even very successful startups can feel very dysfunctional in the heat of the moment. First, when you grow fast and do things that have never been done before, lots of things break. Second, very often management may be absolutely brilliant about some matters, but have giant gaping holes in other areas. A CTO may have figured out a breakthrough in machine learning, but have no idea how to run an engineering organization. A CEO may be able to sell sand to a Sheik, but have no idea how to do proper accounting. As a company matures, it figures out a way to augment the leadership and compensate for weaknesses of the CEO or founder. But there are always growing pains early on, as a startup has not yet identified and fixed said holes.

You really should be evaluating a startup by the high notes that it is hitting, not by the amount of dysfunction. So it should feel awesome at least some of the time. But the startup may very well feel dysfunctional most of the time. That is ok, the dysfunction can be fixed later, but if there is no market or technical breakthrough, then the startup is probably not going to do well.

OP, the questions to consider are: do you have a product that people love (ie, they use all the time and recommend it to others)? If yes, is this a sample of people that is representative a bigger market opportunity? Does your CTO seem reasonable enough that if you demonstrate the value of tests and a build process, he'll allow you to allot time to fix things?

Interesting topic. There is nothing you can lose by starting a friendly "debate".

There are three likely scenarios:

1. You are wrong, CTO is correct, and you learn something valuable.

2. You are correct, the CTO is wrong, and he gains respect for your initiative and skillz

3. You are correct, the CTO is wrong, and he loses respect for you.

First two are obviously good, 3rd one is a good sign you probably won't or shouldn't stay long there.

Tech skills are like retirement funds: compound interest is your friend. A dollar invested now, at the beginning of your career, is worth more than a dollar invested later on.

Right now, you want to be pushing to gain skill as quickly as possible. The skills and habits you develop now will pay back tenfold later on. This probably means being surrounded by developers smarter than you, sooner rather than later.

I'm not a TDD "fanatic" or whatever that even means, but some amount of automated testing is a sensible form of risk management. If you're being actively discouraged from pursuing it, you're the smartest guy in the room.

That means it's time to move on.

To be fair, I think it's more of a concern that trying to write tests would slow the actual work down - I was trying to write regression test (still unit test, but definitely not tdd).

Writing unit tests do not slow work down. It actually makes time more efficient by ensuring working code continues to pass over time. This has huge returns in how a developer can now spend their time.

Well lets be clear unit testing temporarily slows immediate progress down while potentially increasing future productivity.

Sometimes its beneficial to get a feature out the door sooner so sometimes unit testing isn't best for the business needs even if it does slow down future progress.

Lots of companies have really crappy dev processes but still manage to succeed in the market. Do what you can to improve your process internally but really the important thing is making your customers happy and getting more sales.

> I tried to write some unit tests, and I was asked to removed it from git because the CTO doesn't want git to be polluted.

This is how you know.

The only part of this that is a red flag is what the CTO said about unit tests. You need to know why he said that. An outsourced product that has a shitty tech stack and that growth rate are fixable problems lots of startups have gone through. But an attitude that "everything is fine, we don't need to be better" in that set of circumstances is a disaster.

My current company was in a similar situation a few months ago in some respects, but we were releasing constantly and desperate to improve. We're WAY better now, and we're getting measurably better in every single respect every day. The reason we're unrecognizable from what we were 4 months ago and why we'll be that way yet again is because we're desperate to improve and have NO egos. Not a single person on the team is anxious to be right - we're anxious to get better.

Find a team that's as anxious as you are to improve. That, you can't fix.

I don't think anyone in our team is anxious to be right. However, I also don't think anyone in our team is anxious to get better too (both in term of personal skills AND our process in general). For several reasons, most of our developers treat (and work) this as a 9 to 5 jobs.

I told everyone to take off at 4 and watch the world cup. I came back at 6 and everyone was still working (and watching the cup), so I got back to work with them. We're still on Slack squashing bugs and we're all pumped to be doing it. Just taking a break to check HN while files upload.

You'll know that environment when you see it. If you're not in a position to create that where you are, move on.

> I came back at 6 and everyone was still working (and watching the cup), so I got back to work with them. We're still on Slack squashing bugs and we're all pumped to be doing it...You'll know that environment when you see it. If you're not in a position to create that where you are, move on.

Funny, my advice would be the exact opposite: avoid environments that blur the lines between personal life and professional life.

Depends what you want. I see a lot of both here on HN, advice going both ways. I'm confident we do a good job giving people options - the most important way is that I encourage people to make a habit of only spending 6-8 hours in the office a day, and if you want to work more than that, do it from home/coffee shop. That way, you're not sitting around feeling pressured to keep working when really you're done for the day. The founders obviously basically work all day, so we're always available, but I think it alleviates the pressure that I see felt at offices where everyone seems to stay late as a habit.

Basically, yeah. Outsourcing tech in a young startup is a red flag to me. It suggests either they think it's interchangeable and it doesn't matter who makes it, or they don't understand it. Either way, bad times. It doesn't sound exceptionally dysfunctional, but I would be hunting for a new job ASAP.

Instead of presenting a judgement like I think <x> is <y>, try finding an opportune moment or company-wide email thread and presenting Hey, what do you guys think about <x>? or Well known companies <a> and <b> swear by <x>, what would it take for us to try it out?

As someone who works with a legacy codebase from c. 1990 as well as a more modern codebase [that is still 10 years old], both of which lack unit tests...

I work for a healthy business that has annual revenues of about ~4 million in gross per developer. So if we can make code that old work, you can make your stuff work. It just sucks.

Tbh, if I was you and you honestly believe growth is too slow for the startup to survive, I'd seriously consider jumping ship and finding a new job.

I also second the find better programmers than you and learning from them. Tbh, I tried to avoid that to get greater job security and I think that was a mistake.

It is a startup, with only 5 developers. In my honest opinion, it should feel dysfunctional at this point and you should be stressed out. I don't know what you expect but don't expect it to be easy breezy and lots of learning. There is a point for that but it sounds like they are just trying to crank things out. This is your first job and you should treat it like boot camp and get as much as done as you can. Do your job and think about criticizing later once you have gained some experience and have something to compare against. So write this post again on your next startup.

Thanks everyone for the advice. I have another question: assuming that pushing to gain skills is the highest priority. Since I have while a bit of autonomy in the current startup (comparing to working in other company), would it be possible to improve my skills while simultaneously trying to changing things in the company (since I'd get to do more things)? Or would that be a futile effort?

That's exactly what you should do. Being able to influence people and drive a vision forward is another skill you should try to develop, and which seems easier to get started at while at a startup.

I just started at a startup as well straight out of college. If you are only pushing to release every 4-5 weeks, that is extremely slow. You should also suggest moving to agile with more developers in smaller teams. Odds are, if you don't feel great about being with the startup, it isn't going to end well. GL

Most companies are dysfunctional, so odds are yours probably is, too.

Learn as much as you can and move on.

This place does sound a little screwy. (Unit tests are "pollution"? What???) I think it couldn't hurt for you to be very quietly looking around for something else.

Your job sounds terrible. I would get out.

From the way you ask this question, it sounds like you already know the answer.

> Background: this is my first job out of college, and I joined the startup ~9 months ago, right when they launched (I'm engineer #2, before me, the founders outsourced the prototype to an offshore team).

Generally, but never as a rule, purely non-technical founders and an outsourcing is a red flag. But again, that is never a rule, and there are plenty of good companies started by non-technical founders that later matured. Still, that does leave you with the question, of how they chose the CTO?

> Right now, we have ~1200 registered user, with about 100 active users, and we gained about ~100 users/month.

This is not a useful metric. How does this translate into revenue: for some kind of business software (e.g., optimization/recommendations for retailers provided as a service and based on subscription fees) this is great, for a destination site that is poor. Is this rate increasing or increasing?

Now to the meat of your argument: "waterfall" -- why do you call it water fall? 1 hour standups _are_ a problem, but I could imagine a scenario where this might occur for a few days in a row (although never beyond that). "Deployment update every 4-5 weeks" -- depends on what goes into the update, although it's hard to imagine this being a normal stable-state rate for an early stage (or any Internet/SaaS) company; yet for a company providing something like a database a service, it could be fine (provided you're able to push quick fixes and UI updates faster). "I tried to write some unit tests, and I was asked to remove them" -- could be several things, the you wrote tests were not very good (or were not proper unit tests, e.g., if running these tests requires additional setup beyond what it takes to build and manually test the product, they're not really unit tests), or reluctance to embrace even minimal unit testing (which is, indeed, a red flag).

Non-issues: "technology stack and job description" -- honestly I would worry less about this, unless they're literally using Perl CGI scripts, Java 1.4 and EJB 2.0 on an ancient version of a commercial database, but e.g., using Java (or even PHP) and a standard SQL database is a fairly sound (if boring) technical decision.

My suggestion is this: find a position in a company known to be functional and well regarded as far as engineering goes (to paraphrase tlb, you need to work with people smarter than you that can give you quick feedback so that you will learn!). Then you'll learn what a proper standup meeting is like, how to write good unit tests, what a release cycle is like, etc... Don't worry about what your equity percentage is, what your employee number is, etc... you have plenty of time in your career for that. The result is that you'll have a good baseline to compare to and (as a result of shipping something that ends up being successful and used by others) greater confidence/ability to introduce change in a company.

Andy Rachleff of Wealthfront has some advise along these lines too, although not oriented towards engineering: https://blog.wealthfront.com/hot-mid-size-silicon-valley-com...

The CTO is a developer, with ~ 17 years of experience, I believe. Although I don't think he wrote any substantial amount of code at all in our product (from the start).

We're an end-user consumer site, and the rate has been stable in term of absolute number (so decreasing in %).

I called the process waterfall because it's a strict requirement - implementation - QA. I'm not particularly concerned with the tech stack, that was just a personal gripe rather than anything.

Does that mean he wants to run things like he did 17 years ago?

Traditional waterfall would not be releasing every 4-5 weeks. Traditional waterfall would attempt to define all the requirements up front, freeze the specification, then implement/test, then (in theory) the product is "done."

This sounds like some form of iterative/agile development, though perhaps not ideally managed. Standups are generally not 1 hour (but they are not part of waterfall at all).

An agile process can start to look like waterfall if you zoom way in. At some point you have to define what it is you're building, then build it, then QA it. Agile just does this in short cycles based on user stories, while traditional waterfall would attempt to define (as much as possible) ALL the requirements up front.

Normally we have a scope of what we want to do (ie. Let's redo the homepage and the login page). Then the product team group up and hash out the requirement, which is then sent to the developer. Although there are iterative changes in design, I actually don't know why the changes were made most of the time (they are not because of the implemented demo by the dev, the product team only starts seeing at the same time of QA)

Do you work for a guy called Peter Smith?