Ask HN: How do I know if the startup I'm working at is dysfunctional?
Right now, we have ~1200 registered user, with about 100 active users, and we gained about ~100 users/month. On the development side, we have a straight up waterfall process with 1 hour "scrum meeting" everyday, we have 5 developers right now. We have no automated testing at all, a deployment update every ~4-5weeks, and a tech stack/ jobs advertisement that would look like it's from 2006. A few months ago, 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.
I believe that a) Our rate of growth is too slow, and b) Our development process is a bit less than ideal and c) Fundamentally, something is wrong with our company (at least, from the tech side), from all the things that I've heard and read. However, I acknowledge that startup is far from the pinnacle of engineering, and even the user stats could be misleading. I talked with one of the founders about speed of development being too slow, and he (with a business background) said that from his experience with other startup, it's not slow, with which I firmly disagree. So the question I'm wondering is, how could I judge the state of the startup right now?
56 comments
[ 2.7 ms ] story [ 114 ms ] threadCommunication, 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.
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.
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.
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!
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"
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.
Not with that attitude, you're not :)
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?
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 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.
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.
This is how you know.
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.
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.
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.
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...
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.
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.
Learn as much as you can and move on.
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.
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?
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.