Copyright 2007-2011 JessicaMah.com. Theme by Cory Watilo.

Understanding Both Perspectives

Over the past few months, I've picked up a fascination for politics and the history of our past Presidents.  It occurred to me that every single American President since my birth has been put under extraordinary criticism, and none has left with a pristine legacy.  Which means one of two things -- either that every President is the idiot that late night TV shows make them out to be, or that being President of the United States is an incredibly daunting and difficult task.  While it's more convenient to think the former, I've come to realize the contrary after reading through the memoirs of many of our past leaders.  

While in high school, I remember being among President George W. Bush greatest critics.  I'd gone so far as to purchase bumper stickers that read "Impeach Bush", and I would debate with my mom about how terrible of a leader he was.  I remember her responding, "if being President is so easy, why don't you try running the country yourself!"  Being the naive high school student I was, I actually believed I could.  My anger towards our then-President grew even more, and I read any liberal commentary and criticism I could get my hands on.  Fahrenheit 9/11 was a favorite, and I remember thinking that our President wanted to go to war only for selfish monetary reasons, and I didn't trust that he cared about saving lives.  But after spending 18 months on the job at inDinero, I've grown an appreciation for all well-intentioned leaders, regardless of what others might think of them.  And the person I now respect the most is ironically George W. Bush.

How could a left-leaning liberal go from being a Bush hater to being a compassionate supporter?  For all my life, I had been trapped in a political bubble, limited by the opinions of my peers who had listened to nothing but one opinion:  that of the super liberal democrat.  There was no chance that I'd hear the second perspective, because none of my classmates or teachers were willing to consider it.  But I grew to realize that it was actually the opposite perspective that mattered most.  I took it up as my personal responsibility to learn about every decision he made that I felt strongly against:  the invasion of Iraq, our use of torture on terrorist detainees, the Patriot Act, the "tax cuts for the rich", his policy on stem cell research, among other policies that I remain ambivalent about.  The point of my research was to seek the opposite perspective, and to be open to changing my political opinion should I find truth in this new perspective.  

I began by reading Dick Cheney's In My Time, followed by George Bush's recent released book called Decision Points.  After finishing both, I was blown away by the candidness of both of our former leaders.  I learned that both had considered the opinions of many of their advisors, and that they went through serious consideration before making any major decisions. I shocked myself by reversing my opinion on multiple policies he made that I felt strongly against.

To my own disbelief, I felt compassion for a former President who I had despised for over a decade. Through high school and college, I didn't know how to feel anything other than anger towards our then-President.  But from taking only a few evenings to read through the other side's perspective, all of that anger just magically vanished.  I came to understand that I didn't have to agree with Bush's opinions.  I didn't have to like his questionable leadership abilities, and I didn't have to like him as a person.  But as an educated citizen, I felt responsible to escape the liberal bubble that I had grown up in, and to always go out of my way to understand multiple perspectives before giving judgement.

The most difficult part through all of this has been talking with friends and former classmates about this.  "Why would you care to read what that idiot Bush thinks?"  I've since had to come to the rescue for Obama, who's now undergoing scrutiny for his inability to magically fix our economy.  Scrutinizing others is easy, but finding the courage to compliment them is far more difficult.  When people criticize our former leaders, I try to pass on the saying my mom left me with many years ago.  

If being President is so easy, why don't you try running the country yourself?

 

Coming up with a business idea

Our friends at GiftRocket put together a very cool infographic on Paul Graham's "Startup Ideas We'd Like to Fund".  Back in 2008, he put together 30 problem spaces he thought startups should tackle.  

inDinero specifically attacks idea #21:

21. Finance software for individuals and small businesses. Intuit seems ripe for picking off. The difficulty is that they've got data connections with all the banks. That's hard for a small startup to match. But if you can start in a neighboring area and gradually expand into their territory, you could displace them.

I remember looking at this list in the winter of 2009, long before Andy and I had even considered applying to Y Combinator.  We already knew we were excited about this problem space, but seeing our idea on PG's list gave us extra validation that we were going after a problem that few had solved well.  But it is so vague and unspecific that it forces you to still think through the specifics of your idea, and which specific problems you care to solve.  

I remember putting together a bunch of finance-related ideas:  helping people get out of debt, helping people with their investments, replacing QuickBooks, and we came up with a list of reasons for why each idea was terrible.  And eventually settled on creating a financial dashboard for businesses.  

If you're looking for a business idea to work on, I'd start with a high-level problem space that you're passionate about, then narrow it down from there.

 

Created by GiftRocket gift cards

How much money should my company raise?

Over the past few weeks, I've come to notice that companies known for raising absurds amount of money are often founded by entrepreneurs who've succeeded multiple times before.  Off the top of my head, there's Color ($42M), Flipboard ($10M A-round, $50M follow-on), Adkeeper ($8M A, $35M follow-on 4 months later), and plenty others that raised $5M-$10M before even launching.  

At first I thought this was crazy, but I think I finally understand.  Building a good software firm is far more expensive than people may think -- yes, you could have 5 guys sitting in a living room coding, and that costs virtually nothing.  This is how inDinero was just a year ago, and we figured that everyone raising more than $1M pre-launch was crazy.  Boy were we wrong...  

Ends up that it costs a lot of money to build a real business.  You have office expenses, server costs, and employees who would rather not live off ramen-level salaries.  Building features takes 3X longer when you're no longer incubating, because you care about testing and reliablity, you're dividing your time between building features and assisting existing customers, and you now care about writing maintanable code.  All your fundraising budgets were based around time to develop functionality, and now they're completely wrong.  Before you know it, you're raising 2X-3X the original amount you sought to raise.

When I first went out to raise inDinero's angel round, we were looking to raise between $250k-$500k.  But since we were getting a lot of competition for our deal, we thought we'd raise more.  Before we knew it, we were up to $1M in commitments, and thought we had more cash than we ever knew what to do with.  12 months later, we've realized that this was the best thing to happen to us.  As one of our angel investors put it to us, "given favorable terms, raise as much money as possible."  His rationality was two-fold:  1) the bubble won't last forever, and 2) startups cost more money and require more time than the entrepreneur ever predicts.  

First-time entrepreneurs frequently ask "how much should I raise?", to which most investors respond "enough to get you to the next inflection point, which should be 12-18 months."  From a practical perspective, you should raise money in small chunks only on an as-needed basis.  But this is flawed thinking.  In order to do a successful fundraise, the entrepreneur has to drop everything they're doing, create competition and hype for their investment round, hope that the market doesn't dry up in the middle of their raise, and hope that the amount they raise lasts them until their "next inflection point".  The concept of raising money in small batches no longer seems as feasible anymore.

If I had to do it over again, here's how I'd think about the "how much to raise" question:

1 - Create a budget for 18 months of runway.  Factor in $5k/month for rent, internet, electricity.  Throw in $100k/year for servers, marketing experiments, conferences, travel, etc... Budget at least $80k/employee in payroll, benefits, insurance, and misc costs.  (you'll have to budget more if you plan on hiring more experienced talent)  edit:  we've been able to pay less than market rate purely because we offer more in equity.  But there have been potential hires who have higher financial requirements who we haven't been able to consider because of our budget restraints.

2 - Multiply this number by 2 because it'll take twice as long to execute on product roadmap.

3 - Increase the total runway by another 12 months in case the financing markets dry up. (**I believe this is likely to happen)

4 - Assume that I'll be talking to investors when I have 6-8 months of runway remaining, which means this so called "inflection point" actually needs to happen way sooner than you think.  

---

The amount you'll raise will obviously depend on how expensive your engineers are and how much revenue you're generating.  But if you run this exercise against your original prediction of how much you "need" to raise, you'll find that your intuition is probably off.  inDinero's original plan to raise $250k-$500k ended up being $1M, and though I couldn't understand why we needed that much, it ended up being the right thing to do.  

My only regret is not raising even more.

 

Day in the Life as CEO, 1 YR Later

About a year ago, I wrote about how I spent my day as a startup founder/ceo.  It's pretty interesting to reflect on it, because my role is pretty different now.  I no longer write code, I no longer do design work, and I spend most of my day reviewing progress and figuring out ways to make the company move better and faster.  Instead of building the product, I feel like I'm instead oiling and tweaking the machine that is building the product.  

I start my day around 10AM, and often have a phone call chat or early coffee meeting with a potential recruit, investor, or customer.  We hold a daily standup at the office at 11:10AM, when everyone on the product team talks about progress on their current projects.  I'll go through code reviews and designs that were submitted the day before to make sure everything is on track, and I'll spend half my afternoon working through product questions that anyone on the team has.  (remember how your professors held office hours for students?)

By 3PM, I've taken care of all immediate product needs and can finally work on new projects.  It could be designing a new feature, spec'ing out the engineering requirements of a new project, or brainstorming ways to improve the product in a certain way.  I'm often sifting through our massive list of user requests, emailing/calling/visiting customers to hear from them directly, or getting usability feedback on the design of a feature we're working on.  The team then breaks for dinner around 6PM, and I'll spend the next few hours either critiqueing design work or code that our engineers have written.  

I'll take a break around 930PM, shower up, then sync up with our remote team by 11PM.  We have about 5 people working in a different timezone, so it's the perfect time to chat with them without having any distractions from our local team.  I'll read and relax from midnight until 2, then head to sleep.  

* * * 

A few things you might notice:  

1 - I spend very little time in meetings (I'll choose two or three days a month where I'll pack my entire day with only meetings and no product work)

2 - I don't write any code and I don't design anything anymore (but I'm still very familiar with the codebase)

3 - I don't spend any time on user acquisition activities.  Since our product is still young, I decided that it'd be smartest to focus on improving product and improving word of mouth before doing anything brash with marketing.

4 - I don't spend any of my time doing operational tasks.  We have a wonderful manager (Andrea) who is handling our accounting, legal needs, HR/payroll, and other managerial work.  I also have an assistant who helps me with random chores and scheduling appointments/meetings.  

* * * 

This is probably completely different from how my life will be in a year from now.  If I had to predict, I'll probably continue to do design reviews and set product strategy, but I'll probably have all engineering-related work delegated off to my co-founder.  It's inevitable that I'll be spending more and more time doing "CEO work", which means raising more money, talking to investors, hiring and recruiting, among other things.  But in the meanwhile, I couldn't be happier leaving that to Andrea. 

If I had one point of feedback to give to the founder of a growing startup, it'd be to find your own version of Andrea.  She's a fast learner, a great generalist, and takes care of everything that isn't directly related to the product.  But even when she isn't doing operational work, she's talking to customers, helping me design new features, among other product-related tasks.  

Small Problem VS Big Problem

I've come to notice that too much of my time and energy is spent worrying about small problems in business:  among them being an intern not working hard enough, a small feature taking too long to build, a job candidate not working out, and other similar topics that don't have any meaningful impact on the future of inDinero.  Yet they seem to consume a disproportionate amount of my mind space, because these small issues stack up.

On the flip side, there are big problems that I should be spending 100% of my time thinking about:  Improving customer satisfaction, polishing product, hiring/retaining key hires, and making sure there's enough cash in the bank.  Most other topics are probably small, relatively meaningless, and should be ignored as quickly as possible.  

Whenever you're down about something, just ask yourself:  small problem or big problem?

 

My 4th Grade Mistake

Back when I was in the fourth grade, I was trying to build a web application that would allow gamers to share FAQs and cheat codes.  There were dozens of similar sites out there already, but I thought I could build a stronger community than any other out there.

To start, I bought a copy of Dreamweaver 4.  It was known to be one of the best WYSIWYG (what-you-see-is-what-you-get) website editors of the time, and I had this misguided belief that learning how to use the software would be recipe for all my project's success.  What I didn't know was real web-application programming, or how to do that via Dreamweaver.  The software had real web GUI elements, and that led me to believe that I could just build a full-fledged web application without needing any real programming skill.  This was also the biggest mistake of my first endeavor to build something resembling a company.  

To make matters worse, I had recruited an army of classmates to help me with the website.  Some were assigned to help me populate the database with complete FAQs, others were assigned to find ways to drive user acquisition.  Over a dozen classmates.  I was the only one assigned to building product, and all of their time essentially went down the drain as I made a fake attempt to build this company off Dreamweaver.

My fellow fourth grade "business partners" began to lose confidence in the company after 4 months had gone by and I was unable to provide a substantive prototype.  The furthest I got was creating manual HTML pages for each and every game FAQ produced by my classmates, but this didn't seem scalable at all.  I didn't know what I didn't know, and wondered how sites like gamefaqs.com managed to get hundreds of listings without having an army of moderators.  I just assumed they had dozens of data-entry people full-time, and this ended up being one of those unfortunate forehead-slapping moments, now that I know how trivial my misunderstanding was.

The best lessons of humility are learned early in life.  Don't hire people you don't need too early, and surround yourself with others who can help you with all the things you don't know you don't know.  

Bureaucracy in Startups

I've always thought that bureaucracy is a natural misfortune that only happens at big corporations and eductional institutions, but it seems to be pervasive among even tech startups and small businesses.  

The shocking part is that it usually comes from smart people with good intentions, who probably hate politicking equally as much as you do.  You might be dealing with bureaucracy at your own startup and not even realize it. 

My first experience with bureaucracy was from within my own company.  A few months ago, I was trying to let go of a hire who didn't work out.  Problem was, he was friends with everyone in the company, and all my partners felt I was making a fatal mistake.  I was determined to pull the trigger and have it over with by the morning after I made the decision, but it took me another two weeks to ultimately make the fire.  I begrudgingly issued a warning about his performance, and took the time to talk it over with each person on my team.  Why should it be this difficult for the founder and CEO to let go of someone she hired?  

Reason was because everyone cared.  Nobody intended to create unnecessary politics.  But since hiring and firing is the most important shared responsibility among everyone in a startup, I had to rationalize my decision better than any other I've had to make.  We discussed ways to prevent this "politicking" from ever having to happen again:  take more time weeding out hires with a bad culture fit upfront, and issue warnings so that every hire has at least a chance to change.  My partners wanted to know that they wouldn't be spontaneously fired "without cause", and I empathize with that.  

-----

My second experience with bureaucracy was actually caused by me.  A few months ago, my co-founder Andy was on the hunt to hire summer engineering interns.  He started recruiting friends from high school and math camp and wanted to get them offers as quickly as possible.  As we all know, the best candidates receive offers quickly, and hate having their future sit in limbo-land.  But there was a lot of rage from both me and my other partners because we felt that Andy was trying to make intern hires without our consent.  From our perspective, Andy was trying to bypass a "process" of interviewing that we had agreed to.  We wanted to interview every candidate to make sure we weren't making weak hires.  From Andy's perspective, the rest of us were being bureaucratic and taking too much time to give his candidates final hiring decisions.

The ultimate solution ended up being quite simple.  For contract and intern hires, we committed to a 72-hour turnaround timeframe.  This means that intern candidates would given a definitive yes/no decision within 72 hours of the first interview, whether or not everyone had the time to interview the person.  This way, everyone on the team had the ability to approve/veto an intern hire, and Andy didn't feel like he had to deal with bureaucracy from his own company.  Crisis avoided!

-----

I've come to realize that bureaucracy in and of itself isn't necessarily a bad thing.  Process exists for a reason, and politicking usually does stem from stakeholders who have good intentions for the organization.  Bureaucracy is only a problem when there's no perceived end in sight.  For example, my co-founder originally complained that he had no idea if he'd ever be able to give his future interns a definitive yes/no answer -- and that's just bad form.  With busy engineers with constant fires to put out, they'd never get to intervieiwng his future interns unless we created the 72-hour approval policy.  

Maybe none of this applies to your business.  But I've found that the more entrepreneurial and out-spoken your staff is, the more potential there is for bureaucracy in your company.  If you have a story about dealing with politics from within your small startup, I'd love to hear it.  

The CEO's Job, Part 2

We always hear that the CEO's primary tasks are to 1) make sure there's enough money in the bank to survive, 2) guide the vision of the company, and 3) hire and retain top-notch talent.  

But we rarely hear about part 2 of the CEO's job, which I think should be the next most important thing for a CEO to do:  Make existing staff more productive, and to find a systematic way to get new talent up-to-speed faster.  As you hire more and more employees, it's reasonable to expect less value per employee.  This makes sense because of communication overhead, lower commitment from non-founders, and over-reliance on executive-level staff.  (aka bureucracy)  If a CEO isn't out raising money, "brainstorming vision" for next year, or staffing up like crazy, she should focus all her energy on fixing the above problems.  

Here are some ideas that I'm trying at the company I started, inDinero:

1) Contracting help as a core competency.  From talking with my team, I found that many of them wish they had more help with their jobs.  My partner Borden wished we had an extra sysadmin to help him with server tasks.  My partner Andrea wished she had more help doing customer service so she could focus on marketing initiatives.  And as we all know, hiring top-talent in Silicon Valley right now is as difficult as is finding water in the Sahara.  It's just not going to happen.  

We decided to make it a company priority to make it super easy to staff up-and-down in a heartbeat.  Ends up that it's far easier to hire part-time contractors than it is to hire full-time employees.  We had a lot of talented people apply for full-time jobs, but they either lacked culture fit, or cost too much money.  We've also been incredibly cautious in our full-time hiring process, as we've found that it's far easier to fire subpar contractors than it is to fire someone once they're full-time.  Since deciding to staff up on contract help, we've essentially doubled the speed by which we move, and every task we need completed is actually getting done.  Every CEO experiences stress from not knowing when their ideas and vision will be executed; it doesn't have to be that way, and staffing up on contract help is a frequently overlooked solution.

2) Fast on-boarding process.  At inDinero, we've been spending a lot of time the past few days trying to make it super easy to onboard new engineering help.  It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers.  We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase.  New engineers will be brought up to speed faster, and be able to build lower priority features that our core team doesn't have time to get to.

3) Knowledge transfer.  New employees often don't know where to start, and managers seem to spend a lot of their time training new talent.  But if knowledge transfer was a priority, then any person on the staff should be able to train anyone else.

One example of knowledge transfer at its best is pair programming.  Whether or not it leads to code being written faster can be left to a separate discussion... but it's undeniable that employees are far more likely to learn the intricacies of the codebase, and the unique skills of their colleagues, if they do pair programming.  Someone who was once known as the "backend engineer specialist" can acquire web engineering skills far faster by pairing with the "lead web engineer", and vice versa.

This can be applied to pretty much any discipline:  customer service pairing (where an experienced staff member sits alongside a new hire during customer service phone calls), or design staff training business people to create high-fidelity photoshop mockups of their feature ideas.

I also think it's important for engineers and bizops staff to know what the other team is up to.  Since inDinero is only six people full-time, it's pretty easy.  But I expect that as the company grows, we're going to have to find better ways for engineers to know what the marketing team is doing, and for the design team to know how customer service does their job.  

4) Only hire generalists.  Contract out the specialists.  We have a bunch of generalists at inDinero because we found that our highly skilled computer scientist peers weren't able to contribute as much.  Someone who can do business deals, write code, and do user interface design, is 5X more valuable to us than a typical backend engineer.  There's less communication overhead, and less reliance on other people to get things done.  

But there's still a lot of help that needs to be done at a specialist's level.  My partner Borden is a pretty good sysadmin, but he's by no means a guru.  On the flip side, we don't have the funds (or the need) to hire a real sysadmin full-time.  This leaves me pretty confident that it's ideal to have generalists as your full-time hires, and to fill in their gaps with part-time help from specialists.  

--

I'm sure there are a billion other ways the CEO can make their existing team (and future team) more productive, and I'm learning more as I approach my 2nd year on the job.  It's been pretty exciting to see inDinero operate more efficiently, and I look forward to seeing these ideas play out over the next few months.

 

Making mistakes is like paying tuition.

What's neat about having an unusually young team behind inDinero is that when we make mistakes, we're quick to recover.  Instead of getting angry at myself (or at my fellow team members), we blame it on one thing:  real-world business school tuition.  The only differences are that our "tuition costs" come from lost revenues instead of from actual schooling, and that we're probably learning far more than our peers in college are.

I started thinking about how far can this go:  At what point do we have to blame ourselves instead of on inexperience when things go wrong?  But I realized that having a culture where it's ok to make mistakes is pretty awesome.  I feel like I could take risks and make bold moves, and that the worst thing that'll happen is a "shame cup" appearing on my desk.  I've also noticed that everytime someone introduces a bug to the codebase, there's very little blaming that goes on.  We immediately realize that those problems are likely to happen to us the following day, so we accept it and move on. 

Instead of regretting the mistakes you make, be appreciative of the fact that you're paying a very cheap price for important life lessons. You'll be less stressed, and be more able to focus on the things that matter.