Awareness

My younger brother and I talk a lot about how we were raised from a very young age to think like engineers.  Our entire family is composed of engineers aside from my mom who is an accountant.  And even though I thought I was going to be a lawyer I somehow managed to come back to my roots.  No one pressured me into being an engineer, my dad did gently nudge me towards taking a computer science class, and even after I dropped out of my freshman year programming class my dad didn’t revisit the topic.  It was I, who out of a sense of failure decided to return and prove to myself that I could hack it (pun intended).

The reason I chose a path of technologist is because I believe it improves human life.  Since the industrial revolution people have been benefiting from technological advances and living happier and longer lives that don’t require back breaking labor.  Hence, my choice to pursue an engineering degree was based on upbringing, a curiosity to discover the space, and a desire to improve human life including my own.

I also had clear models growing up, which I don’t think a lot of kids have.  I knew what a fab looked like by the time I was 10, and my family’s dinnertime conversation revolved around a fascination with Wall Street and high tech.

Priorities

While most girls grow up playing with Barbies and dreaming about their wedding day, my dad banned Barbies, and I fixated on my career goals of being a lawyer, writer, and professor.  To this day I’ve thought about having a family, but it directly conflicts with the vision I have for my life for the next 5-10 years, which is one of freedom, freedom to pursue my own interests whether that’s a career, travel, or even hobbies.  To most people, men or women working at a startup is a huge time commitment.  It takes away time spent with their loved ones.  And for women who want to have a family they see their 20s as a time to find a partner and settle down, not to be working 40+ hours a week, which is the Valley norm whether you’re at a tech company or a startup.  There just aren’t many 9-5 gigs for talented engineers, but realize the compensation is commensurate.  You can’t deny mother nature and the fact that women have a shorter runway than men.  So if children and family are a priority then everything else including being an engineer must take a backseat to that dream.

Motivation

What motivates me is having a purpose and building something of value, which is why I’m in the startup scene.  I initially began as a startup engineer because I wanted to become a better engineer and I also wanted to learn how companies were created.  Next, as a startup founder, I want to learn what it takes to build a business.  Truth be told, the only thing I obsess about aside from my startup is food and staying healthy.  Everything else this year has taken a backseat to my business including dating, friends, and family.  But I knew that going in and I’m capable of staying focused for the long run, because I’m motivated to succeed.  So when people ask why there aren’t more women tech entrepreneurs they need to first ask the question, what does it take to be an tech entrepreneur?  And who is it right for?

Honestly, I wouldn’t have been capable of starting a business when I was 22.  It took me time to build up the courage, confidence, and competence.  And I’m one who enjoys being in uncomfortable situations (working at a startup, opposing arranged marriage, Bikram yoga, the list goes on…), I’m a bit of a masochist.  But that’s not true of all people men and women alike, which is why a large number of people drop out of things whether is engineering or med school and pursue easier paths in life.  It’s also the reason people give into social pressure or settle for things in life instead of trying to push the edge.

At the end of the day people can complain all they want about there not being enough support, funding, resources or peers in any community or scene.  Its up to you to create a vision for your future and amass the resources to reach that vision and it requires giving up some comforts to achieve it.  If there’s one thing that I learned from engineering school its about learning to make trade-offs!

Tweet This Post

Burning and Earning

As a startup founder, I’m obsessed with burn rate and runway.  Bootstrapping only heightens your awareness.  But taking in money doesn’t mean you have a free ride to spend as we you please.  I actually started to loose sleep once I knew I had someone else’s hard earned savings at stake.  I’ve also witnessed a lot of startups that wished they had raised less money because of the pressure associated with a large round,  such as growing a team quickly, ramping up the number of users, and getting to revenue.  Is there a happy balance?

I’m of the camp that every founder should invest some of their own personal funds into their venture.  The exact dollar amount is up for debate and depends on an individual’s comfort level and lifestyle.  A founder devoting time alone isn’t enough of a contribution, because to me money signifies an opportunity cost, as in I could be making money but I’m choosing to hold off and actually use my savings because I believe what I’m creating is valuable.  Also putting in your own money you become more thoughtful on the things you spend.

Scrappy Stack

With technology costs reducing startups can build a prototype on a shoestring budget.  At my current startup I’m using Heroku to host our web app, Google Apps for e-mail, mySQL for our database, Gmail for our mail server (but switching to MadMimi soon), GitHub for source code repository, and Pivotal Tracker for bug and project tracking.  I did purchase licenses for RubyMine bought a few external monitors (refurbished), desks and chairs from Ikea, and I try to do a team lunch/dinner once a week at the very least I’ll make dinner for my team.  I also don’t balk at the thought of sending my developers and designers to conferences.  When you’re working on a small team you need a flow of new  ideas and creativity, what better place to acquire them than at a conference.  Its also a great place to scout and recruit talent.

To me office space is a luxury.  For the past 8 months we’ve been working out of my apartment to cut down on costs, and while most people would be opposed to the invasion my startup has been my personal life for most of this year.  But there does come a time when you need office space.  For us, it was when we realized that we needed to start doing more usability testing, and having a designated space to hold meetings with customers and investors.

On the issue of hardware, I’ve been dreaming of the day I can buy each of my developers and designers their own machine.  But its just not in the budget right now.

What do I spend money on?

Employees and legal fees.  Its hard to find and retain talent.  Anyone who has tried to recruit knows this.  In a startup time, culture, and creativity drive the creation and success of a product and company, and you can’t expect success if you’re both a taskmaster and slavedriver.  Sweat equity is nice to have, but in a town where you’re competing with startups that are funded by VCs, six-figure salaries of techies, and high rent and gas prices you have to at least handle basic living expenses.

Just like a household you will need an emergency fund.  To handle calamities like machines breaking or even just being able to do something nice and relaxing with your team once in a while.  A startup isn’t a death march nor is it something you can flip instantly.  It takes time to build a team and product.  You also want to spend on little things like running simple marketing campaigns, networking events, conferences, books, or even experimenting with new technologies.

A startup is after all an investment.  As a founder it’s an investment in your potential to build something and to direct your career.  There’s no need to bet your life savings on it, but realize like an investment you have to know what you’re getting into, what the hidden fees are, budget and cut extraneous costs, project performance, and be willing to take bear a certain amount of risk for the potential rewards.

Tweet This Post

I really enjoy developing in Rails.  I think Ruby is a very terse language and Rails is framework that helps developers achieve peak productivity.  So I’m trying an experiment with BizeeBee.  The team has been through 3 iterations.  At the end of each iteration we’ve been focused on cleaning up our code base.

For this iteration our goals are:

1. Convert obtrusive AJAX queries (RJS) into straight JS, because we’ve experienced how slow RJS can be.
2. Make the DB agnostic by removing straight SQL calls and instead relying on the ActiveRecord framework, because we don’t want to deal with mySQL vs. Postgres incompatibilities.

I’ve also talked to a couple people in DevOps to get their thoughts on Rails as a framework here are their suggestions:

1. Think about  scale from the beginning because you’ll need to scale before you know it.  They seem to almost value premature optimization over no optimizations.
2. Limit the number of joins you’re performing on your database.  This means restrict the foreign key relationships and try to de-normalize your tables early on.
3. Think about archiving or aggregating historical data.  This will limit full table scans, and give users a richer experience when dealing with data that pertains to the present.  If you need to retrieve older datasets then you’ll need to design around it by messaging users that you’re retrieving older data.

As BizeeBee moves into the fourth iteration, I’ve started to think about how an open beta will result in more users.  David, my back-end developer, and I spend more time thinking about data modeling.  We know which tables we anticipate growing quickly, how we need to address the growth rat, and have started thinking about partitioning schemes to address the growth of data.  Currently our app is hosted on Heroku, which means we don’t have control over our partitioning scheme.  So if we do want to partition we’ll need to host the app ourselves.  But we like the ease of deployment that Heroku offers and how we can closely mirror the staging and production environments without having to configure them ourselves.

While I don’t anticipate us growing overnight, I think its good to start thinking about these problems early on.  I’ve also anticipated the need for caching in the short-term and will implement it depending on usage patterns.  As far as using a solution like NoSQL or MongoDB, my main reluctance to embrace it is the need for an ACID database, one that maintains data integrity.  I know a lot of startups have openly welcomed both, but my skepticism originates from the need to have a highly accurate system that cannot tolerate data glitches.  I’m dealing with transactional data that belongs to small business owners, and can’t afford for the service to be unreliable.

I’m curious to hear about everyone else’s experience and architecture regarding scaling in Rails and how their stack has morphed overtime…

Tweet This Post

Risk and Rejection

As a first time entrepreneur I understand that I’m seen as a huge risk, even though I was on the founding team of a startup that successfully exited recently.  I’ve pitched at several events and met with angels and VCs.  I don’t know if a lot of other entrepreneurs feel this way, but from what I’ve observed and read I’ve developed some empathy.  I understand that all investors are just as concerned about their portfolio companies, and delivering value to their shareholders as I as an entrepreneur am to my employees and customers.  Investors have have to raise funds, and maintain a certain return/revenue stream to stay in business.  Given the current market conditions, their past experiences, and the overly zealous and optimistic nature of entrepreneurs investors have to be cautious.

I’m a big girl, I can take rejection, and I welcome it as a challenge to the way I think and present my product.  If I wanted someone to tell me I’m awesome I would just call my mom up everyday…

Following up with Feedback

I’ve found it immensely valuable to hear from an investor right on the spot: “I understand the first part of your pitch when you explained how you were trying to solve problem A.  But I don’t understand how problem B fits into it.  Perhaps you should focus on A first.  Or make it clearer to me.”  Or the investor who tells me on the first meeting that they wanted to meet with me, but are averse to space that I’m in, or just don’t feel like they know enough to add value.  Being clear and forthright makes the process not only easier for me, but then I start to learn and understand how investors think and what they are looking for.  I also have other founder friends who are fundraising and farther along that I am that I can then refer the investor to.

Followup calls and emails are really helpful too.  I’ve received a few of these where the investor will tell me that they aren’t sure about my distribution model, think that there maybe a conflict with one of their existing portfolio companies, or want to see how customers will react to make sure that I’m solving the right problem.
I’m not saying its mandatory to give feedback.  Its just useful, and I’m the type of person who wants someone to lay it on thick.  How else am I going to improve as an entrepreneur, and build a product and company if I don’t get beat up once in a while?  I think its important for investors to do this to test the strength of entrepreneurs.
What I’ve found hard to dissect is vague feedback.  The investors who take a meeting with me and state they are early stage, but early stage doesn’t include before Product/Market fit.  Or are very excited and like the concept of my product, but want to wait and see traction.  Whats hard to pin down is their criteria of traction.  And maybe that’s just an exercise for me as an entrepreneur to discover.

Before Product/Market Fit Push Back

I’ve been bootstrapping my startup and have taken in a small amount of angel investment.  For the last 7 months I’ve devoted myself to my startup: building the product, the team, acquiring customers, fundraising, and creating a vision.  As an entrepreneur I think its important to show a vested interest and belief in your own product, vision, and risk taking abilities.  And while these are all positives I know they aren’t enough to compel investors to invest.  When faced with push back the onus of proof is still on the entrepreneur to prove they are worthy of a large round.  Go home, get more customers, refine the problem, product and pitch.  Competition and market conditions will always be against you, but those are natural forces that you have to work against, its just part of the fun of fundraising.

Tweet This Post

Engineers jump ship early for various reasons, its usually a combination of the following three: instability in management, unclear path to an exit, and work that is mindless and unyielding.  But there are those who stick around even if there isn’t an end in the near term, there are periodic shakeups in the organization, and they’re well past their vesting initial vesting period.  The reason they stay is that they are enjoying the work, being challenged, and experience the impact they are making on users.  They also have a manager who has given them the support they need to advance in terms of projects, and believes in quality of the work they are doing.  So how does an engineering manager retain talent?

Prized Projects

Managers should realize that if they have engineers on their staff that have a decent track record, have been at even one successful startup (including the present one), and can bang out code on a couple platforms then chances are they are going to be wooed all the time!  You can’t blame recruiters for trying to covet your prized programmers.  Instead you’ve got to learn to understand each of your engineers and continue to motivate them.  This is hard to do in a startup.  Why?  Because as a startup manager your time is limited and you’re under a lot of pressure to produce results and end up prioritizing it over making sure that everyone on your team is satisfied.  And even if you wanted to please everyone there are only a limited number of juicy projects to work on.  If you can’t promise a project don’t.  But if there is a chance to break up a project into parts, and divvy it up that might be the way to go.  That way you’re not playing favorites and you’ll benefit from building redundancy in the knowledge base over time.  Remember startup engineers don’t want hand-me-down projects, i.e. they don’t want to feel like someone else has built everything and now they just get to maintain it.  They want to be part of the creation phase, and if you can give them a slice of it then they’ll stay motivated because they’ll feel like you listened and cared about advancing their experience and skill set.

Communication and Coding Style

Most people speak up for what they want.  Some just go off and build stuff.  While others sit around and wait to be asked if everything is ok and are afraid to go off on their own.  As an engineering manager its important to figure out what your engineers’ coding and communication style is right off the bat.  Its perfectly ok to ask people whether they like having freedom to manage their own projects or need a more disciplined task master.   You also need to know their preferred work style.  Some people like to come in late and code into the night while others may be morning people and want time off to relax in the evening.   There are those who code away in noisy environments while others need a quiet room to think in for a few hours a day.  There are also some who work best if they just work on a single project and others like context switching or working along the entire stack as opposed to just front or backend development.  These are the types of questions an engineering manager needs to ask during the hiring phase to gauge their candidate’s personality.  It will of course change with time, which is why its important to do a monthly checkup at the very least.

Checkups

I’ve been on both sides of these, and frankly its awkward for everyone.  The manager sits there and first wants a status update then moves onto pressing issues, and then finally asks the engineer how things are going.  At which point an hour or more has gone by and everyone is exhausted.  Checkups should not be status updates.  A manager should know what the status is if they’ve reading checkins and tracking bugs.  One-on-one time is meant to place the engineer’s concerns first.  Find out if they’re stuck on something, if they’ve been exploring a new technology, how they like the project so far, or if they have any concerns with a member of the team or the company.

Rewards

Yes there are limited funds, so monetary rewards aren’t always possible.  If you can’t afford to give someone a raise then at the very least give them praise!  There are a lot of other ways to incentivize people: conferences, giving them time to learn a new technology, showcasing their latest achievements in front of their peers, and for heavens sakes tell the founders, investors, and management about the stellar job they’ve been doing!

Remember in a startup emotions runs high especially if there are periodic fires to fight.  If there is one unsatisfied engineer then chances are there are more or there will be soon.  As a manager your time is limited and its hard to motivate everyone on your team all the time.  But that’s another reason why you have to make sure the team dynamic is one where people help each other out.  Collaboration isn’t just about getting things done its about building a culture that can last through the fires.

Tweet This Post

Here are some things to think about for those on the recruiting side:

1. When to start recruiting?

Engineers love to build, solve tough problems, and make progress.  If you’re a founder who is still trying to grasp the product roadmap and create a company vision its probably not a good time to hire an engineer.  There are a lot of engineers out there who have been burned by founders who pull and push them in a variety of directions. We engineers know that need to be agile in a startup and be able to scrap code and rebuild, but want we don’t want is to have a founder who manic or aimless.

2. Sweat equity or salary?

Engineers are humans, we have bills to pay, families to take care of, friends that we want to spend time with, and on occasion indulge in the latest tech gadget.  Contrary to the way we carry ourselves we’re not robots (although I do enjoy being called a machine - but I’m not Summer Glau).  So before you ask someone to even spend an hour of their time writing code or reviewing specs make sure you can pay them in some form (coffee, dinner, laptop, etc.), and if you can’t then you better start thinking of ways to raise enough funds to be able to pay them something.  Don’t expect someone to work for nothing endlessly.

3. How to find them?

The vast majority of us are a lonesome bunch.  We like sitting at home or in coffee shops on our laptops coding away fun projects.  You won’t find us going out to the normal startup networking events or partying all night.  The best places to find us are at tech conferences or panels.  We’ll respond to recruiters on LinkedIn, but we don’t want to be treated like a commodity, and more times than not we’re very happily and gainfully employed.  While we’re willing to indulge to see what’s out there the opportunity has to be ripe enough for us to leave our current position.  Our sense of pride an accomplishment comes from being a part of a team and building something.  So we get attached to our team and product, and its hard to forsake that for another opportunity that we’re unsure of.

When people ask where can they find someone like me, it makes me smile.  The truth is I’ve been created and molded by my experience.  4 years ago I started playing in the startup space.  My motivation was to become a better engineer and knew that the startup space was where I’d learn the entire breath of the development cycle.  It was a tough 4 years filled with mistakes and hard work, but I loved it because I got to create something of value that impacted millions of people’s lives.  And over that time period I learned from great engineering mentors.

There are probably a lot more people who like me have a fire and a hunger.  They want to work hard and prove themselves.  I think its important to keep that in mind rather than always trying to covet a rock star developer with a proven track record.  It’s a huge risk to take on a junior engineer, but would you rather have someone on your team who is willing to learn, grow, commit to the company, and put in the long hours to improve themselves?  Or do you just want a code monkey?

4. Motivating Them

Engineers are motivated by a variety of things.  The most basic is a good company culture.  They  want to know that the founder cares about his team, and his engineers and will give them the resources to get things done.  They want to work on challenging projects but understand that there will be grunt work that needs to get done.  The key is to balance it out.  By letting them learn and play with new technologies from time to time.  We don’t want to work on the same things for months on end without any sort of end in sight.  Part of an engineers desire to solve problems is also a reflection of them wanting to improve themselves by becoming a better developer.  This is only possible if we have time to learn and improve our own thinking, and practice.

There is a reason people choose to become engineers, they want to solve problems mostly those related to systems, usability, and improving people’s lives on a large scale.

5. Listen to Them and Develop Empathy

I’ve seen too many engineers express dissatisfaction at changes in deadlines, product features, and increased workload without gratitude.  Or founders who want the impossible done as of yesterday.  Remember people only have two hands!  You’ve got to understand what engineers are capable of accomplishing and how quickly they can move.  If they’re coming up to speed with the product, development cycle, and company dynamics is good to let them ramp up slowly.  Yes, building software is cheap and fast unlike other products.  But there is still the overhead of testing, scaling, and securing.  So while it might seem like a simple feature should take a day to implement there is more infrastructure and thought that need to go into it before it can be delivered to an end user.

Engineers are good guys, they’re builders, refiners, and affect the course of history by improving human lives.  Its up to the entrepreneur to unleash their potential to accomplish great feats together.  Don’t think of them as code monkeys or worse yet commodities.

Tweet This Post

But then you’d take one look at Priya and you’d understand where Kumar got his brains and his drive.  Priya was the force that championed Kumar.  She had studied physics and been a great lecturer at the university level, and would have been happy to have been a spinster had it not been for a chance meeting with Shanker at the age of 30.  Shanker was 2 years her junior.  Priya was enamored with his simplicity and sweetness.  She knew that he would never leave Madras and it would mean giving up her lifelong dream of becoming a professor at a prestigious institution like Princeton.  So she like many women of her time decided it was enough to be satisfied than chase a pipe dream.  What was she supposed to do, move to America alone?  That was not only unheard of but grounds for being disowned, and her family had already had a hard time getting her married.  She intimidated all the men she met with her knowledge of physics, philosophy, which was only secondary to her beauty and radiance.  Kumar was her dream, seeing him succeed and accomplish great things is what she wanted more than anything.  But she wasn’t overbearing like the other mothers in the community who wanted their sons to go to America and send them back money so they could buy gold jewelry.  No, she wanted Kumar to explore and have options, the ones that the society of her time had not given her.

It was the night before he was leaving for America to start graduate school.  Priya walked into Kumar’s room.  She looked at him and tears started to well up in her eyes.  Kumar was a sweet boy he knew his mother would be strong, but he felt like he was going to be leaving behind a huge part of him.  His heart was torn between the life and loved ones he had lived with the last 22 years and the new life he would be starting.

“Kumar, my dear son, these are tears of joy.  I am so proud of you.  I don’t want you to think that you are leaving me behind.  We will be together once again very shortly.”

Kumar turned to his mother.  He had been preparing for this moment, but still didn’t know what to say or do.  So he just gave her a hug.  Shanker walked in, and smiled at the two.  He was the jolly one of the family, “Come now, let’s enjoy our last night together!  Your mother has made some wonderful dosas.  Let’s eat and take some good rest.  You have a long flight ahead of you my boy.”  The three of then embraced one last time before dinner.  It wouldn’t be the last time they embraced, but to Kumar it would be the last time being in the house and the room he had grown up in.

Tweet This Post

The development team at my current startup is composed of engineers and designers, basically I make everyone on the team write code  I understand that Rails’ benefit is in thinking from an MVC mindset.  But because it integrates all components its requires that all developers have some knowledge of a high level language (Java, Ruby), front-end technologies (HTML, CSS), and an understanding of databases.  While it doesn’t require them to have depth of knowledge I think the tight coupling makes it hard to separate the layers.

The following are the three limitations I’ve been experiencing with Rails:

1. Integration – when it comes time to integrate HTML or design changes, designers and front-end engineers need to work in the same space i.e. the same .erb.html file.  Yes I know it doesn’t require a painful and time-consuming compilation process like XMLC or Velocity.  But its easier for the designer to change the look and feel using XMLC or Velocity because they have defined a set of DOM objects.  With Rails designers have to understand views and partials.
2. Convention over configuration – the speed of development with convention over configuration Rails seems to come at the price of normalization, meaning there  is not foreign key construct in Rails.  You as a developer are required to configure this yourself along with other database constructs like unique constraints and indexes.
3. Deprecation – perhaps its just me, and I’m used to Java versions being released every year or two, but it seems like there are a lot of constructs that are deprecated between Rails versions.  The book publishers can barely keep up with the changes.  The other is that some of the constructs that are deprecated which I think are quite large i.e. scaffolding.

Despite these pitfalls I do advocate Rails as a prototyping platform.  The learning curve isn’t steep, and convention over configuration improves the progress developers can make in a day.  I’d also like to learn more about how people have addressed these pitfalls as their prototype matures.  What have been some of your experiences and approaches to dealing with Rails as you transition and build out the product?

Tweet This Post

Tweet This Post

For the past couples months I’ve been playing with Rails and have been building my product’s prototype with it. The last time I created a prototype for a product I wrote it in Java.  The choice to write it in Java was simply because the founder and I knew how to write Java, and were more productive in it than C++.

After that experience, I spent sometime thinking about all the pains and positives I had experienced with Java and decided it was time to explore another technology.  Initially, I just wanted to know what all the buzz around Rails was about.  Ultimately, my choice to use Rails was based on the following:

1. Simplicity of Configuration: I started off as the only engineer on the project and didn’t want to spend a lot of time writing migration scripts, files to handle ORM, and having to setup all the mappings in a MVC framework.
2. Support and Documentation: the Ruby and Rails community has a great number of forums where people are constantly communicating and helping one another out when it comes to resolving issues.  As someone starting without a development team I think thats key, unless you have the luxury of constantly stepping out of your office to talk to another developer or attend meet ups.
3. Speed of Development: I don’t spend 10 minutes sitting around waiting to compile!  One of the biggest problems I had with developing in Java and all other high level languages was not being able to being able to make a small change and see its impact instantly.  I’d have to sit through compilation or figure out ways to optimize the compilation process.
4. Flat learning Curve: Now I do know the full stack of development technologies, so it took me less than a day to get an app up and running.  But I still found it pretty intuitive to setup and I wasn’t sitting around reading documentation for hours figuring out why I couldn’t connect to the database.
5. Emulation: I was thrilled when I discovered that Rails has a lot of AJAX and JavaScript functionality built into it because it has been years since I wrote a substantial amount of JS.  The other of course is you don’t want to have to constantly switch from technology to technology in the course of writing code.

I will say that as a developer who understand and can code a full stack development, and has worked in a MVC mindset, I’m able to debug issues faster in Rails than others who are purely front-end or back-end developers.  So for anyone evaluating Rails I’d recommend getting accustomed to MVC and thinking about development from that perspective.  My other suggestion is to understand how Rails tries to emulate other technologies like JavaScript and AJAX (using .rjc) and Hibernate/ORM (using ActiveRecord).

Finally, realize that there are limitations to Rails, and its important to be aware of them and be prepared to deal with them or find another technology to compliment Rails.

Tweet This Post