
My Experience Running Development at a Startup - antjanus
http://antjanus.com/blog/thoughts-and-opinions/experience-running-development-startup/
======
madaxe_again
"CTO in training"

Danger, Will Robinson!

I followed a similar path to the one you now tread. I cofounded, and
managed/grew the dev team from me to forty folks.

Three years ago (after seven years of just "tech director"), I took the mantle
of CTO.

Error.

CTO is _not_ a technical role. To do it well, you must _be_ technical, but it
is in reality a sales and marketing role, both internal and external. I found
myself isolated from our tech team in short order, as as CTO one is the public
and board level technical face of the company - and that becomes all
consuming, and you become the perceived source of all the problems. You become
the messenger, who is much shot at, by both clients and your former allies in
your technical team. The clients shout at you for bugs. The developers shout
at you for pleading that bugs get fixed. You become that which lives between
hammer and anvil. You are no longer part of the team. You are the boss.

So - unless you want to get out of technology and want to work as a
marketeer/apology bot, don't aim for CTO. I did, it broke me.

I left my company today, as I started it for the love of tech, and making cool
stuff - and at the point of organisational development they have reached, that
is not something there's any scope for a CTO to do.

Lesson learned.

~~~
tluyben2
I became CTO quite young and I was running around doing technical stuff when
my colleague pointed out that was not what I should be doing. I was co-founder
of the company, so after I read what I should be doing (which is more like
what you say), I appointed my right hand as CTO and I became head of our small
R&D dep. That was excellent. Now i'm CTO again; older and wiser and I fit the
role now, however, when we grow more that might change. I really do want to
keep coding for fun and business.

~~~
agibsonccc
CTO roles at companies vary. Some end up doing "technical stuff" as well as
business. How large was your team that this was a problem?

~~~
tluyben2
300something. I was too involved in the projects themselves (which is what I
like(d)).

------
mknocker
The tracers over prototypes advice is a precious one. Having worked for small
and large companies, once you have a functional prototype that has been built
quickly, managers tend to be very reluctant to let you rewrite the prototype
architecture to make it clean. Using tracers you can demonstrate small but
important features to the persons involved in the project and when the project
will be given the go sign you can work peacefully on the product's
architecture.

~~~
nostrademons
I haven't really experienced this, also having worked at both small and large
companies. At the small companies, most of the prototypes failed (which is the
whole reason you're prototyping) and then the ones that succeeded usually got
rewritten because _everything_ got rewritten multiple times. At the large
ones, the prototype exists to convince a VP that this avenue is worth
pursuing, and then typically it's handed off to another team to actually do.

Could also be because I've basically always had technical management, and the
projects I work on tend to be fairly technical in nature (i.e. "can we do
this?", not "the customer wants this by Monday").

~~~
antjanus
That might be the reason but it really depends on company culture, funding,
and other aspects. I built an early prototype for our product in the first two
months. Losing two months wasn't an option for a rewrite. Even if I could get
it done in a month, it just didn't make sense. The prototype was "good enough"
to the point where it stuck.

------
pavlov
Nice article. There's one paragraph that exposes a certain bit of web dev
mindset that rubs me the wrong way:

 _" Updating things as you go also means that parts of the application that
get less love tend to be written with an older style [...] and using older
technology (like indexOf rather than contains or a for loop rather than
reduce)."_

That's not "older technology"! You're talking about whether to use some helper
methods on Array.prototype. Who cares? It's certainly not any kind of
technology choice.

It's really no different from whether you prefer to put your opening curly
brace on the same line as an if sentence or the next one. Sure, it's slightly
annoying when someone does it differently, but you shouldn't spend any time
bikeshedding your codebase over stuff like this.

~~~
antjanus
You're completely right! I meant to say that some parts of the application are
written in an older style that we don't use anymore. For loops, indexOf, etc.
are valid and there's nothing wrong with using them, we just use a more
functional approach now and use some of the newer methods for doing the same
thing.

~~~
rajangdavis
I don't think this is necessarily a wrong thing; I feel like really ground
breaking/challenging development forces you to understand what you are
building the farther you go along.

It's always ideal to have perfect code the first time it's written, my
experience is that this is never going to happen unless you have perfected
what you are building to the point that you have code generators/boiler plate
code to cover most of what you are building.

With that said, very interesting article. Thank you for sharing your
experience, it is very eye opening for me.

------
20years
I like the Tracers concept.

As for "everything is legacy a week later" \- why not stick with boring but
proven technology and frameworks for software that is crucial and you plan to
have around for awhile? That may mean not using most of the JavaScript
frameworks that are being pushed today. Sure, play with them for smaller or
non business crucial stuff but why risk building a business on that
instability?

There are so many other important things that a business or startup has to
focus on, spend money on, etc. I guess I prefer to put a lot of resources into
those things vs worrying about having to update or re-write my tech stack
every few months on the latest shiny framework.

~~~
noir_lord
I picked knockout about 3 years ago because it seemed stable then, officially
supported IE and had good docs.

3 years later I'm still using code I wrote against it (though now with
browserify) with no changes.

The switching cost when you can dump the old framework on every new project is
much lower than the "This will be around for 3-7 years".

Now I follow what is happening in the JavaScript community but I don't
consider using anything until its been out a year and is still active/growing.

Much of the churn seems to be throwing out everything for an incremental
theoretical improvement, that rarely pays off in my domain.

------
mxuribe
Excellent article! If no one else tells you: i appreciate the time you took
out of your business to write this up. This is some really helpful advice. I
have a full-time day job, and am trying to get my side business to launch as
my only job...and I can certainly learn from experiences like the one you
described. Keep on truckin' with these types of posts, and good luck to you!

~~~
antjanus
Thank you!

Some of these things seem so self-evident but they were hard lessons. I've
come to understand that there are a lot of business practices that just don't
make sense to me until I get bit in the ass by not following them.

------
leemac
"For smaller projects like microservices, isolated applications, even parts of
the UI that most users don’t see, experiment."

I agree with this part 100%. We're still rocking BackboneJS that we chose in
2011 or so. Sure it's behind the times as they say, but it's rock solid for
our uses. We're in too deep to convert now and the cost doesn't outweigh the
benefits. Clients are happy and we're happy.

In other newer areas, we're experimenting, mostly with RabbitMQ for small
things on the backend and React Native on Mobile. With UI on new projects not
in the core web app, we experiment. Works rather well and keeps us sane with
the pace of JS frameworks.

------
xxr
Your account of the state of JavaScript in this decade reminds me of this post
from a few days ago: [https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2...](https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2016-d3a717dd577f)

~~~
antjanus
I'm actually not a big fan of that article :/ or rather, I disagree with it.
I've been meaning to write my own piece on it.

But the summary is: you can make it as easy or complicated as you want it to
be.

And I mean, every technology has the same issue. Take PHP for instance. Want
to learn it? Cool, it's super easy. Want to build an app? Okay, so there these
different frameworks. Oh btw, you should know about composer. And autoloading.
Did you also hear about DI that Symfony uses? etc. etc.

------
jpulec
I was the first engineer hire at a small startup, and have helped our CTO/Co-
founder grow the company over the past 3 years.

All I can say, is that almost everything that was said here was the exact
experience we had. Even down to the choice of Angular 1.X and rewriting all of
the IIFEs in our codebase to use ES6 imports with babel.

I also need to acknowledge that PM is something that you do fine with 2
people, but your processes will fall apart, probably as soon as you even hit 4
or 5 people.

------
fsloth
"issues with Javascript today is the idea that we have to keep learning the
latest technology and keep using it. "

I don't get it. Why? For ISV it's the product that matters. ESP:s might as
well invent filler to charge the client but what does it help in creating a
product with JS to run after the bleeding edge?

Usually we pick up a language and toolset, write the product with it, and if
there are bugs that absolutely need to rearchitect some foundational things
then then, only then is it worthwhile to ponder if some basic technical
constructs need a major overhaul.

This "update to latest hot as you go" sounds like velocity is lost in trying
to adapt to some new gimmick for no benefit.

Obviously there is some cost/benefit tradeoff here I'm not getting. What is
it?

------
nerdy
The end of the article feels like a cliffhanger for a CI-CD sequel.

------
Yhippa
The amount of real-world experience you got from this I'm still trying to get.
That to me is the value of being in tech at a startup. I enjoyed this article,
thanks.

------
knowaveragejoe
Minor typo here: "When we switched to ES2105"

~~~
antjanus
Not a typo. It's a stage -10 spec, it's so far out into the future that no one
has thought of it yet and the people to implement it haven't been born yet.

:) thanks. I'm fixing it!

------
szines
This article wouldn't be there if they choose the right tool for this job.
Typically for big apps, with Ember.js, you never have these problems what he
described.

