When doing a startup, don’t forget to calculate emotional runway as well as financial runway

When I joined The Food Corridor, the concept of financial runway was well known to me from my consulting days.  You figure out your monthly expenses, your savings, and any income you have coming in.  Divide your savings (or at least the amount you want to spend) by the expenses less the income, and you get the amount of time available to work on the startup before you run out of money.

You definitely want to pad this a bit, because if you run out of money, you’ll need some time to find another source of income.  You can also pad this with debt, selling other assets, part time work, investment, etc.  Heck, maybe the startup will even make some money too.

But the goal is to have an idea of how long you can go before you have to call it quits for financial reasons.  Then you can see if you think you can build the company in that amount of time.  (Hint, it’s going to take longer than you think to build the company.)

Emotional runway is another key aspect of surviving a startup.  Startups are full of a lot of stress.  Some examples:

  • Making decisions on limited data
  • Dealing with a product that is broken because of the speed at which you built it
  • Screwing up and apologizing to customers for said screwup
  • Dealing with financial uncertainty
  • Hiring
  • Firing
  • Limited or nonexistent support structure
  • Trying to figure out how to build a company
  • Personnel conflicts
  • Missing family time because of work
  • Lack of vacation/benefits
  • And, of course, the possibility of running out of money

All of the above make it tough to ‘tough out’ a startup.  These are all costs that you will have to bear.  Just like you only have a certain amount of savings to spend down, you also only have a certain amount of emotional wealth to spend.  (There are times when a startup will deliver emotional wealth too.)

One of the hardest parts of the current startup for me is keeping an eye on my emotional runway.  Taking some time off, celebrating successes, being open about the stresses with co-founders and family, and just being aware of what puts “money” into the emotional piggy bank and what takes it out are all ways I’ve dealt with this.


Railsconf Call For Proposals

Railsconf, a conference focused on, well, Ruby on Rails, is happening in Pittsburgh in April this year.  I attended last year and it was a fantastic experience.  I enjoyed the people I met, the problems I saw discussed, and the size and content of the presentations and workshops.  It definitely had a vendor experience (thank you, Heroku, for the t-shirts), but wasn’t too explicit.

Railsconf organizers are now accepting proposals for workshops, panels and speaking.  For some reason the CFP isn’t on the website, but I noticed it was announced via twitter.  I just submitted, so I can’t speak to the entire process, but the initial submission was pretty painless, just few sections on what you’re interested in presenting and why you might be a good fit.

They actually have a blind submission format, so I had to edit my initial submission to remove any reference to my identity.  Seems like a good idea.

So, go forth and submit!


Do your research

The internet makes some things frighteningly easy.  Trolling, for example.

But the fact it makes research easy is a win for everyone.  James Altucher has a post on how research helped him win a deal.  I remember when research meant you had to head to the library, look in a card catalog and/or ask a librarian, and skim through books.  If you wanted to take the information home, you used to have to check out the book.  Some books were too valuable to leave the library, so you had to make photocopies of relevant pages.

That’s all changed, obviously.  Now you can research a person or entity without leaving your home, though you still can leverage what libraries provide.  And you can research non famous people in far more depth than you ever could in the past.  When you meeting with a potential business partner, interviewee, or client, you can google the heck out of them.

The benefit of doing so is twofold.

  1. You have a better idea of how the person operates and how serious they are at whatever endeavor you are discussing
  2. You can connect to them and discuss their needs and ideas more intelligently

These are both worthwhile goals and will lead to better outcomes.  If you don’t do any research, that sends a message as well–“I don’t care much about this meeting” or “I’m too busy to do any research.”  That may be OK, but be aware that you are sending these messages.

So, if you want to do research on someone, how do you go about it?

I’d start with setting a time limit and a goal, otherwise you can get bogged down or sidetracked.  An example: “I’m researching this client and want to know their key business goal.  I’m going to invest an hour of time in this.”  Write this down, and check back in as you do your research to make sure you are heading towards your goal and not down a rabbit hole.

Then, start digging.  I used the term “google” above to refer to searching, but I’d suggest using more than one search engine, as they each give a slightly different view of the web, and I’ve definitely had useful results pop up from Bing or Duck Duck Go.  If this is a business meeting, LinkedIn connections can be useful.

If the client maintains a blog or social media account, spend some time reading that.  You don’t have to read every tweet, but getting a feel for what’s on their mind, especially in recent posts, can be illuminating.

The amount of effort to put into such research depends on how much it will help you and how important the interaction with the research subject is.  That is, if you are discussing going into business with someone, research the heck out of them.  If you are interviewing for a very interesting job, spend some time.  If, instead, this is a random coffee meeting, you may not want to invest any prep time.

You may find something disturbing in your research (a conviction report for example).  Integrate this into your decision making process, but be aware that the content may not be accurate, or may not apply to the research subject, or may be far enough in the past to be irrelevant.  Also be aware of any discrimination laws that may apply, such as employment laws.

If you find an interesting blog post or article that is relevant to my audience, you can promote it before the meeting (post it to Hacker News or Reddit, tweet it out).  Your research subject probably won’t notice, but if you’ve already done the research and found something of value, you might as well share it.  And on the off chance they do see the post, they’ll likely be flattered.

When the meeting occurs, feel free to casually mention some of the research.  I’ve been on the other side of it (someone read a blog post I wrote and mentioned it in an interview) and I can tell you it was quite a pleasant surprise.  And it can be a great starting point for a conversation.  But don’t get bogged down in discussing something the person wrote years ago, just use the research you found as a way to connect.

No matter how thoroughly you research someone online, realize that online we are all painting some kind of picture of ourselves.  Some people and companies are more transparent than others, but the mere fact that you have to pick and choose what to post means that you’re getting a curated view.  Non verbal communication matters too  If you’ve done the research, you’re ready to go into that meeting and take the connection and the relationship to the next level.


Useful Rails Gems: dossier

Writing reports is something that is crucial to any business application.  There are a number of nice reporting solutions.  I haven’t done a survey recently, but I know that Pentaho has an offering and Crystal Reports is another one.  Note that the gorilla in the room is MS Excel, because most anyone doing a report is going to want to pull it down and do additional data manipulation.  You should never try to compete with Excel.

For The Food Corridor, we didn’t need a full featured reporting solution, but we did need to pull data from the SQL database and expose it in CSV and HTML tables.  The dossier gem takes care of this.

What I love about dossier is that you can write the reports in either Active Record syntax or in SQL.  I know SQL pretty well, so it’s easier for me to use that avenue, but if you’re just getting started with Rails, I could see how the Active Record syntax would be helpful.  After writing the query, dossier takes care of much of the grunt work of CSV generation or HTML table generation (there are other output formats, but I don’t use them, so can’t speak to them).

You can preform arbitrary formatting on the SQL response, including hiding columns and running ruby code on the value pulled back from the database.  The report class is just a ruby object, so you can also reuse chunks of logic or SQL across reports.  Column names are turned into report headers.  (I wrote previously about testing such reports.)

Authentication is a bit weird out of the box but works.  There’s also documentation for other authentication/authorization options.  Dossier can also take database configuration from the initializer file so you can easily offload your reporting traffic to a read only replica.  (We’re not there yet in terms of traffic, but I can see the day coming.)

The dossier gem is so easy to user that I can get a full featured reporting solution created in only an hour beyond writing the SQL.


Knowledge in software development: what’s your wood lot?

Gene Logsdon, who passed away in 2016, was a farmer and a wise man.  In a recent repost (originally written in 2008), he discusses why wood is more valuable than gold.  From the post:

You can’t eat gold like you can the bounty of trees in fruits, nuts, maple syrup, and various edible mushrooms and herbal treasures of the woodland. You can’t warm yourself with gold. You can’t bask in the shade of gold. You can’t make fence posts out of gold. A gold house would be mighty expensive. You can’t make a windbreak out of gold. You can’t make furniture, violins, guitars, wall paneling, picture frames, gun stocks, tomato stakes, flooring, barns, chicken coops, and hog houses out of gold. You can’t mulch a garden with gold leaf. Gold does not take in carbon dioxide and give off oxygen to preserve an environment we can live in. Gold does not provide habitat for millions of wild animals and zillions of insects necessary for a sustainable environment. And in fact, you can make methane out of wood much more efficiently than ethanol out of corn. All gold can do is go up and down in price and invariably it turns out to be a poor investment, as many panic buyers learn the hard way.

This resonated with me.  Of course when things go awry, as they did in 2008 and 2001 (in the USA), having a pile of cash feels good.  But money is not wealth (this article covers that, as well as some other key points about capitalism).  Money can come and go, but wealth, whether knowledge, relationships or wood lots, remains with you.  Some forms of wealth require more care and feeding than others, but they all have the attribute of providing value in the real world.

When you are in software development, knowledge is a common form of wealth.  I always tell teams I lead that almost every problem we’re facing is a new one, because if it wasn’t new, it most likely would have been automated or turned into a service or library that we could use.  So there are plenty of chances to gain new knowledge.

There are a few categories of software development knowledge.

  • Domain knowledge is understanding the real world problem domain.  So, if you’ve worked, as I have, in a real estate brokerage, you understand how the business works.  Who pays for what, how money and effort flow, who the main players are and what they are called.  All of these are valuable should you work in that domain again because you can come up to speed more quickly, and you understand how the real world maps to the software system.  This type of knowledge may change, but on the order of years or decades.  (I haven’t worked in real estate since 2014, but if I went back, there’d still be many of the same concepts.)
  • General technology is fundamental to software development.  I’d put abstractions like algorithms and data structures, specific technologies like distributed systems, database indices and HTTP, and best practices like automated testing and requirements gathering into this bag.  Having this type of knowledge will let you understand a typical system even if you haven’t seen the nuts and bolts of it.  Of course, the type of general technology that is most useful to you depends on your domain, to some extent.  The general technology of a chipset engineer is different than that of a UX designer.   Within the same domain, this knowledge is good for years.
  • Specific technology knowledge are the keywords that recruiters put on job postings, and what some consultants chase after.  Elm or Elixir, Rails or React Native, Kubernetes or kvm.  These technologies are very specific.  I’m of two minds about this knowledge.  On the one hand, if you pick the right tech, you can be in very high demand and get rates commensurate with that.  On the other hand, new specific technologies are constantly being born, and keeping up with all of them, let alone becoming an expert in them, requires large investments of time (perhaps the reason for the premium).  However, I have sympathy for folks looking for specific technology expertise.  Yes, any competent software developer can pick up any language in a few weeks, but the idiosyncracies, libraries and community practices take time.  Depending on your budget, you may find it cheaper to pay someone who has acquired that knowledge elsewhen.  This knowledge ages quickly.
  • Leadership knowledge is orthogonal to software knowledge, just like domain knowledge.  Since software is built by human teams, knowing how to lead such teams toward business goals, whether formally or informally, is a valuable skill. This can include specific techniques like agile development and ‘one on ones’ and more general areas of knowledge like how to connect or communicate people and how to navigate politics.  This knowledge has a long half life and can pay dividends throughout your career.

In addition to knowledge a software developer can accumulate other forms of wealth like books, videos, and relationships.  These can all serve as credentials for a new position or (occasionally) generate passive income.

As we head into 2018, think about how you can build longer term wealth in your career by picking the right kind of knowledge.


Last week in AWS

If you are interested in AWS, you have to subscribe to ”Last Week in AWS”, a newsletter which covers, well, much of what has happened in AWS recently.  Both posts and news from the AWS team and external sources are covered.  There is a lot of snarkiness, but a ton of knowledge as well.

The newsletter is out every Monday and is run by Cory Quinn, an experienced AWS consultant.


Saying Thank You

Sometimes it’s a good idea to stop and say thank you.

Thank you to my parents, who instilled a love of learning in me and trusted me to make my own decisions. Now that I have my own children, many of the choices you make seem even wiser now.

Thank you to my wife, my biggest cheerleader and BS detector. It’s a joy to walk through life by your side.

Thank you to Dave B, who took a chance on someone who didn’t have any real software development experience. I still remember troubleshooting winsock issues.

Thank you to Bryan B, who offered me an internship after college and then a job that I couldn’t believe I was getting paid for. The friends and connections I made at that job have reverberated throughout my adult life.

Thank you to all my consulting clients over the last decade plus, from Mike M and Pat M to Brian T to Corey S and Andy P to Josh G, Chris H and Matt K. I always have loved the rush of “I need to deliver but don’t have any idea how to do this” that happens two weeks into every consulting engagement, and I appreciated your patience.

Thank you to Anthony F and Lane H. I learned so much about software development, building a business and how to act from my years working for you.

Thank you to Ashley C. Building something from scratch is a wild ride.

I want to leave you with this comic, from the great Nathan Pyle.

By Nathan Pyle

Thank you.


Heroku pipelines and asset_paths and font downloads being cancelled

My font downloads were being cancelled when I was using a CDN in front of a rails app hosted on Heroku.  I was testing out using heroku pipelines, which lets you promote a slug built in one environment directly to another.  Rails was also serving the CSS/JS/font files, but was behind a CDN and config.action_controller.asset_host was set to the cloudfront URL, so most clients were pulling from the CDN.

The issue I ran into was that in order to get my fonts to show up correctly when I was compiling my slugs on production deploy (before I moved to heroku pipelines), I needed to use erb and the asset_path tag. So my font css file looked like this:

@font-face{
  font-family:'FontAwesome';
  src:url(<%= asset_path('fontawesome-webfont.eot?v=3.0.1') %>);
  src:url(<%= asset_path('fontawesome-webfont.eot?#iefix&v=3.0.1') %>) format('embedded-opentype'),
  url(<%= asset_path('fontawesome-webfont.woff?v=3.0.1') %>) format('woff'),
  url(<%= asset_path('fontawesome-webfont.ttf?v=3.0.1') %>) format('truetype');
  font-weight:normal;
  font-style:normal }

However, this caused the asset_path in this CSS file to be set to the full CDN hostname plus the asset path, something like https://d123.cloudfront.net/assets/fontawesome-webfont.eot (when the slug was compiled on staging). When the slug was compiled on production, the value was set to https://d256.cloudfront.net/assets/fontawesome-webfont.eot. When I was using heroku pipelines, the slug was unchanged between staging and production, just as advertised. However, this meant that the CSS was being served off of the production CDN host (d256) and the fonts in that CSS file were referencing the staging CDN host (d123). Browsers didn’t like that. This question indicates that this is due to cross resource permissions not being set correctly.

What were my options?

I could return to deploying slugs by compiling them on staging and production. However, I like the concept of pipelines and the immutable artifact.

I could try to find some way to post process the slug and change that link in the font CSS. But that didn’t seem possible, based on documentation, and kinda defeats the purpose. I did discover the heroku release phase.

I tried some of the other solutions outlined on this question to tweak how the asset pipeline compiled the font references, but nothing else worked.

I could have tried to set the permissions correctly for the font download. One worry there would be having the production environment depend on the staging CDN. Never a good idea to mix environments.

I also could have tried relative paths to the font files in the CSS file. I didn’t do this because I thought of my final solution first.

The solution I finally went what was using a CDN that hosted the font files of the correct version and used those. I also chose this solution because we won’t be using these fonts (which we primarily use for icons) for long–in the near future we’ll be removing the icons from the application.


Evolution of admin features

Time is short in a startup and the edge cases are many.  I have noticed that when I am building features for The Food Corridor, especially admin or edge case features, there is a progression based on frequency of feature need.  An example of this is something like handling a refund, which is not a core use case.

  1. The first time, the issue is handled via a developer.
  2. If it happens more than once, the process is documented in a google doc.  It might be triggered by an email from another part of the system.  We have an entire google folder called ‘operations’ which is full of such documents.
  3. The developer automates the process via a rake task.  The rake task is a thin layer around a service class, which is tested.
  4. Non technical admins get access to the process via a web interface.  The web interface plugs into the service class as well.  This web interface may handle only part of the issue, and require access to other systems (in the case of a refund, access to the payment processor).
  5. Non admin users get access to the process via a web interface.  This web interface is fully fleshed out.

For core functionality, you obviously want to push the ability to self serve to the end user as soon as possible.  It simply wouldn’t make sense for us to build out the ability to schedule bookings, limit it to a developer or admin user.

But for a lot of functionality, this progression is helpful.  The developer has time to fully understand the issue by handling it him- or herself.  The documentation generated by handling the issue manually is a great start for the requirements document.  And if an issue only pops up once every quarter, or even more rarely, a minimum amount of developer time is spent on it.  If something happens often, it is far more likely to get automated.


The power of December challenges

I am in the final stretches of my December blogging challenge.  I’ve done this with other challenges in the past (exercise, meditation).

While some folks start their New Year’s Resolution’s in January, I find that December works better for me (maybe July will be better for you).  A challenge is different than a resolution, because a resolution has no end date, where a challenge stops.  Also, because of the holidays, this month is already choppy.  That means if I take some time each day to do something new, it’s not going to impact other obligations as much as it would in a less choppy time.  December is also the darkest month in Boulder; having a task to ‘check off’ every day feels like progress, and that feels good.

You can either pick a new thing or a task you’ve tried to do in the past.  All of my experience is with the latter.  New things are often exciting enough for me that I don’t need any kind of push to experience them.  But something I’ve tried lackadaisically that I intellectually know is worth exploring–that kind of challenge is perfect for a month.

A month is long enough to give a new habit a chance and to learn some of the benefits and warts of it. It’s also short enough that you can gut your way through it.  I read about people doing challenges for a year, but I am not sure I have the mental stamina to commit for that long.  After some December challenges, I was happy to drop the activity, because I didn’t get much value from it (or not enough for the effort).  Others I picked up later.

As far pure mechanics, I’ve found that a PDF calendar that you can ‘X’ out each day is helpful.  Post this someplace you will see it (by your bed or your desk).  Get a big sharpie and enjoy the ‘X’ing out process.

I also think it’s important to publicly state any kind of ‘I’m doing this for a month’ goals because that external pressure will help you when encountering a day where you really don’t want to do the task (like today, for me. haha). “Public” can mean announced on Facebook, Twitter or a blog, but it could be a conversation with your roommate or SO or family members.

I know that this is a bit late for December 2017, but hopefully it will inspire you in the future–there are plenty of months for a challenge in 2018.



© Moore Consulting, 2003-2017 +