

This Startup Built Internal Tools to Fuel Major Growth - mountaineer
http://firstround.com/article/This-Startup-Built-Internal-Tools-to-Fuel-Major-Growth-Heres-Their-Approach

======
arthurjj
As someone who has been a product engineer and internal tool engineer I really
appreciated that they made the distinction. Some other points to think about.

1.In the first version of the tool don't have the tool make a decision, just
have it generate information, not make decisions. So if it is telling you
which sales lead to pursue, first have it generate metrics on why you should
pursue a lead

2\. Once you have a tool that makes decisions always have a way to let a human
override the tool's decision

3\. Start with a process then add a tool. It's almost always either to work
out bugs with people then software

~~~
noahbrier
Noah here from Percolate. I agree and what's interesting is I also think these
are pretty classic values for enterprise (or b2b) software in general. Without
the centralized data it's really hard to build any of the workflows or other
tools.

~~~
arthurjj
Agreed. That's why I like to start with a process and then build a tool. If
people find the process valuable enough to follow it then you know the tool
will be providing real business value

------
silentmars
One downside to this approach is that it can tend to create status or power
rifts between the product people and the tools people. In traditional shops,
the "skills that pay the bills" product people often get better treatment,
higher status, greater advancement opportunity and stronger job security than
tooling people, who are often seen as being on the cost side of the business.

Startups that go down this route should be on the lookout for this potential
for divisiveness and culture fragmentation.

~~~
inthewoods
The approach they seemed to take to deal with this was bringing in an outside
developer. I'm not a fan of this approach for a number of reasons - but mainly
because then you've got a dependency on a single outside person or firm to
maintain that application going forward.

~~~
noahbrier
To answer both: On the division side, we have found a number of people who are
simply more passionate about building products for their peers than building
products for customers. I interviewed one last night, so I can confirm this is
the case. Because the job includes a bit of product management and a bit of
design, it ends up being something fundamentally different than what we ask
engineers to do.

As for the outside devs, I agree that is a challenge and one of the things
that ultimately led to us hiring internally to help support and continue to
grow those internal products.

------
pbreit
Seems to be working for them but I would typically advise against too much
energy spent on automation and internal tools too early. Tools can really slow
you down in the early going when things are changing rapidly. And you can
typically throw inexpensive bodies at many of the tasks that are otherwise
candidates for automation.

The one thing I do like is that building tools gives more employees experience
in building product.

~~~
noahbrier
I would generally agree with that and we had many instances where we chose to
have people perfect workflows prior to fully automating them (and there are
lots of situations where that remains the case now). With that said, and I
don't know that it was perfectly expressed in the piece, I do think there's a
concept that engineers take for granted around the attitude that goes into
creating products and automation that needs to be pushed hard throughout the
whole organization.

~~~
calinet6
Have you looked into W. Edwards Deming at all? His ideas on quality and
systems are echoed almost perfectly in this article and in what you're saying
here, especially in bringing systems thinking to the entire organization, not
just engineering (where abolishing repetitive tasks using scripting comes as
second nature). Really astute stuff.

I think he'd reply on the point above, that it's far better to build the
system and have it be less than perfect than to rely on a brittle process.

"A bad system will beat a good person every time." \- Deming

So, it will probably not be a waste of time. Has your experience proven this
out in general?

~~~
noahbrier
Haven't read any Deming, but will check it out. Any particularly good place to
start?

I'd say in general it has proven out, though there have certainly been some
cases where we tried to build products prior to fully defining the
challenge/process and they were basically DOA. Again, here internal tools are
just like external products: Without a tightly defined challenge/opportunity
it's really hard to deliver a useful product.

------
toisanji
would love to see examples of other companies being built like this. This
could be built as an incubator.

~~~
devonkim
It really depends very much upon how the company's built and how its people
work culturally, but I think this is absolutely more important for larger
companies than smaller ones just because communication overhead far exceeds
pretty much every other barrier (regulatory and compliance included).

I'd hesitate to go this route if the product is aimed mostly at an audience
used to structured communications such as engineers (github issues, IRC
channels, and even wikis are far more structured than the usual e-mail chain
like in a mailing list). This is part of why companies with usable CRM like
Salesforce have done so well in providing value to their customers.

So, I'd totally do this if I was going to start something that's aimed mostly
at enterprise users or with potential to have a need for lots of cross-
functional communication like a start-up operating in a highly regulated
space.

