29 7 / 2011

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.  

18 7 / 2011

While many of my entrepreneur friends complain about not being able to find great engineers to join them, my team and I have been looking for more creative ways to source talent.  The most obvious and effective way we’ve been doing this is by “outsourcing” work to places as far away as Vietnam, India, Uruguay, and South Africa.  And we’ve been able to do so with pretty good success.

Just a year ago, I was against the outsourcing of anything that came even remotely close to being “essential”, but I’ve since changed my mind.  I wrongly stereotyped all outsourced, overseas help as being underpaid/under-skilled labor, when in many cases we’ve been able to find talent that’s on-par with our team in San Francisco.  The question then turned into “how do we get meaningful work out of oversees engineers with as little effort possible”?  Pretty simple — hire good engineers who don’t need to be micromanaged!  

I’ve come up with a few rules to make outsourcing actually work:

1) Don’t hire part-time engineers.  I’m yet to find an engineer who’s able to juggle multiple engineering projects at the same time.  Emergencies come up, and before you know it, they’re spending all their time on someone else’s project.  If the goal is to have your outsourced engineers be as close to an in-house, full-time hire, they need to be putting in the same long hours. 

2) Proper engineering screen.  I have a list of interview questions I ask just to test for computer science, rails, and JS competency.  The interview takes about an hour to do, and weeds out all the stereotypically bad overseas developers.  Read through their open sourced code, call their references, and treat it as if you’re hiring for a full-time role.  

3) Two week trial.  Start with a small project, have them refactor existing code.  It’s more or less an internship:  people who don’t ace the interview portion often do a stellar job at their projects, and we’ve found this to be especially true with interns.  Holding a trial period allows you to see how productive the coder is, and to test their actual intuition when it comes to industry-level software engineering.  

4) Limited micromanaging.  We don’t spend any more time with contractors than we do with full-time employees.  If we did our job correctly during the screening process, they’ll write quality code without needing us to hand-hold them on implementation details.  With that said, we still code-review all of their work before allowing it to be merged into our master branch.  The common complaint of needing to give outsourced engineers “specific and narrow” tasks simply does not hold true.

5) Daily communication.  We get a daily standup email from each overseas engineer, where they tell us what got done the day before, and what they plan on doing the following day.  They’ll list out any bottlenecks or questions they may have, and point us to the code they wrote in the past 24 hours.  This way, we have a chance to QA the functionality and run a code review before they wake up the next morning.  Highly effective and efficient if I must say.

* * *

Our hit rate is getting better and better, but we had a lot of trouble getting this to work at first.  Our churn was over 50% for our first contract hires, but we’re now able to spot a bad contractor in their first few days on the job:  a) lack of communication, doesn’t update us with progress and engineering decisions, b) shitty code, which we can quickly determine via code review.  More often than not, the reason they don’t work out is because they don’t communicate frequently enough, and that’s why we mandate the daily standup email.   

I’m fully aware that there will continue to be a taboo against outsourcing such an important role, but I think this should be irrelevant to any startup founder.  By outsourcing engineering help, you’re simply augmenting your existing in-house team, assuming you screen them sufficiently well.  While our competitors can take the slow approach to trying to recruit nonexistent engineers in the Bay Area, I’ll be ramping up my engineering team and product development faster than anyone else.

15 7 / 2011

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?

31 5 / 2011

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.  

30 5 / 2011

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.  

10 5 / 2011

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.

01 4 / 2011

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.

30 3 / 2011

It’s occured to me that everytime something “bad” happens to inDinero, it ends up not being as bad as I thought it’d be.  I’ve been trying to better understand which problems to care about, and which problems not to care so much about. 

Problems relating to servers going down or someone sending you a negative review pretty much ruin your day.

But there are more serious problems that we don’t seem to think twice about:  such as your company’s lack of revenue, or lack of product/market fit.  Why don’t those stress you out 10X more of they’re 10X more serious than the smaller fires you’re putting out? 

If you plan on stressing out, worry about the things that are actually worth worrying about.

30 3 / 2011

It’s occured to me that everytime something “bad” happens to inDinero, it ends up not being as bad as I thought it’d be.  I’ve been trying to better understand which problems to care about, and which problems not to care so much about. 

Problems relating to servers going down or someone sending you a negative review pretty much ruin your day.

But there are more serious problems that we don’t seem to think twice about:  such as your company’s lack of revenue, or lack of product/market fit.  Why don’t those stress you out 10X more of they’re 10X more serious than the smaller fires you’re putting out? 

If you plan on stressing out, worry about the things that are actually worth worrying about.

08 3 / 2011

Keynote at Web 2.0 Expo in San Francisco (March 29, 2011)I’ll be giving a keynote at Web 2.0 Expo in San Francisco on Tuesday the 29th at 4:30PM.  Topic will be “Making Money with Metrics” — I’ll chat about how we’re using internal metrics to make more money at inDinero.
Hope to see you there!

Keynote at Web 2.0 Expo in San Francisco (March 29, 2011)


I’ll be giving a keynote at Web 2.0 Expo in San Francisco on Tuesday the 29th at 4:30PM.  Topic will be “Making Money with Metrics” — I’ll chat about how we’re using internal metrics to make more money at inDinero.

Hope to see you there!