

Snaptalent Lessons Learned - Lesson Three - Spend Time on Things That Matter - jamiequint
http://jamiequint.com/lesson-three-spend-time-on-things-that-matter

======
tdavis
We mitigated these sorts of issues in TicketStumbler by having clearly-drawn
lines for who was responsible for what. This was easy for us because we had a
two-man team consisting of one technical person (me) and one
business/everything else person (Dan). I would occasionally explain technical
decisions to Dan, especially if they were going to take a while to implement
(rewrites, etc.) This had the added benefit of forcing me to talk out an issue
and better justify it to myself.

This made for some fast decision-making. The only downside has been that
following his death I am still being charged for services I wasn't even aware
we had and for which I have no non-violent method of cancelation. However,
this is obviously a rather extreme edge case that most people won't have to
deal with.

The main issue highlighted in the post regarding cell plans is a bike shed-
style decision. These are problematic because anybody can take a few minutes
to research the space and come up with valid arguments for/against another
person's recommendation. Generally, the best thing to do in these cases is to
simply defer to whoever broached the topic and have them make a decision; they
had a head start on research and cared enough about it to bring it up so it
makes sense for them to own it.

------
chime
I gotta admit it takes a lot of guts to fess up things like this. I looked at
the "Stupid Things We Did" and was shocked at how stupid some of it really was
considering that these people were calling themselves founders and even had
investors. But then I suddenly got reminded of how I once spent a week
creating a scrollbar from scratch in ActionScript for a product that nobody
cares about now. I've also spent a lot of time writing my own libraries
because they are cleaner/more-efficient than existing utilities out there only
to throw them out completely because the specs changed. Had I used a slightly
bulky off-the-shelf library, I would have saved a lot more time and could have
replaced it with my own code if the library caused a bottleneck.

As I work on my new project now, I keep asking myself "Is this actually going
to matter to anyone except my OCD-self/ego?" If yes, then I do it. I've wasted
too much time because I'm a stickler for file-naming-conventions or got stuck
with one weird bug that only affects 0.1% of my target users.

------
colinplamondon
I think that everyone pre-revenue is almost by necessity focused on the wrong
things, because there's no way to quantify actions. Post-revenue, everything's
easy.

"Does it make sense to buy a $3,500 27" iMac for someone whose development
effort generates $35,000 a month in value?" "Uh, duh".

Before revenue everyone jerks off about being founders. After revenue,
everyone focus on building more income. When you have investors, you have to
worry about the optics of how it'll look to your investors, instead of just
doing whatever's going to make more money. When you're profitable it's hard to
focus on the wrong things.

------
JoelSutherland
It's scary how often the decision making process is more expensive than making
the wrong decision.

------
gsaines
Really appreciated this one. We've been guilty of spending too much time on
stupid things, mostly business related to date. Time spent building features,
building tools to measure user engagement, revenue, and ways to optimize
conversions, all good uses of time. Talking to a potential synergistic partner
about a cross promotion and significantly disrupting workflow for a day or
two? Not worth it. Actually, I would add to this and say that if you are just
starting out, avoid partnering if you can, especially with bigger companies.
It takes forever, and what you really need to answer isn't something they can
offer up front and that is: will the partnership make us money soon? At this
point we still get partnership offers from folks but instead of having big
discussions about it anymore, we tend to just shoot back and say "That sounds
cool, why don't we try something out next week and do X, measure results and
see from there." It weeds out people who want to discuss their six sigma with
you and selects for people who want to make money and get stuff done.

Boy, we wasted a lot time. Thanks for sharing the Snaptalent lessons.

------
maxklein
Either that, or just have one person who is the leader and who has override
authority on everything. Team consensus is not really a way to build a company
- in the end there will have to be one overriding vision.

~~~
notauser
That's a really good way to destroy a team.

A better setup is to have someone who makes the decisions for any particular
area (on a notify-but-don't-ask-permission basis). Then the others can
challenge if they really care, but won't for anything immaterial because they
know they delegated those matters.

