
Ask HN: How do I know if the startup I'm working at is dysfunctional? - viredfox
Background: this is my first job out of college, and I joined the startup ~9 months ago, right when they launched (I&#x27;m engineer #2, before me, the founders outsourced the prototype to an offshore team). The company is working on ecommerce&#x2F; affiliate model with a small twist.<p>Right now, we have ~1200 registered user, with about 100 active users, and we gained about ~100 users&#x2F;month. On the development side, we have a straight up waterfall process with 1 hour &quot;scrum meeting&quot; everyday, we have 5 developers right now. We have no automated testing at all, a deployment update every ~4-5weeks, and a tech stack&#x2F; jobs advertisement that would look like it&#x27;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&#x27;t want git to be polluted.<p>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&#x27;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&#x27;s not slow, with which I firmly disagree. So the question I&#x27;m wondering is, how could I judge the state of the startup right now?
======
tlb
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.

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

~~~
endlessvoid94
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.

------
TheBiv
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.

~~~
viredfox
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.

~~~
TheBiv
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!

~~~
viredfox
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"

~~~
pfitzsimmons
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.

------
Eliezer
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.

~~~
viredfox
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?

~~~
opendais
> 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.

------
zjgreen
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.

------
nthj
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.

~~~
viredfox
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).

~~~
avelis
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.

~~~
jf22
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.

------
letstryagain
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.

------
steveklabnik
> 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.

------
tomasien
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.

~~~
viredfox
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.

~~~
tomasien
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.

~~~
7Figures2Commas
> 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.

~~~
tomasien
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.

------
overgard
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.

------
contingencies
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?_

------
opendais
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.

------
uptownhr
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.

------
viredfox
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?

~~~
ipince
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.

------
tfarmer
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

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

Learn as much as you can and move on.

------
ScottBurson
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.

------
lbarrow
Your job sounds terrible. I would get out.

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

------
strlen
> 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...](https://blog.wealthfront.com/hot-mid-size-silicon-
valley-companies/)

~~~
viredfox
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.

~~~
ams6110
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.

~~~
viredfox
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)

------
ziffusion
Do you work for a guy called Peter Smith?

