Skip to content

Run through the finish line

I used to run cross country way back when. One of the differences between the good runners (like me) and the great runners (Dave F, Todd E) was talent. But drive was more important than talent. One of the key pieces of advice my coach gave us was to “run through the finish line”. On the face of it, it seems obvious–you are at the end of a 5k race, why wouldn’t you want to finish as fast as possible? Why waste that effort? But I can’t tell you how many times I passed (and was passed) in the last 50 feet of a race. I saw the finish line, I relaxed (as much as possible) and slacked. Or, I saw someone else doing that and knew I could move up one more place. If you’ve left it all on the course (easier to do in a 5k than some other races) it is hard to have anything left to run that last bit. But drive can provide that last bit of energy.

In a software project of any size, there’s also that “last 50 feet”. If you are developing, it’s the last 10% of the project that takes 50% of the time. If you are running a project, it’s the last few weeks when all the little things that were put off during the big build out phase come out of the woodwork and need to be dealt with. Or it’s when the project blows up 2 weeks before deadline. When you are dealing with a vendor, it’s the crunch time before you launch, when any organizational complexity ignored comes due.

If you want to get across the finish line successfully, sound of body and mind, and with your team intact, what can you do to finish strong?

Be realistic: I never ran a 15 minute 5k. So starting out at that pace was a sure way to make sure I had nothing left at the 2 mile marker, let alone the finish. Make sure you have realistic expectations at the start of your project. If you or your team don’t know how to scope the work, spend some time learning how to do so upfront.

Cultivate drive: remind the team regularly why this project is important. If there are features that you discover are harder or less useful than supposed at the beginning, don’t be afraid to shift effort. Also, refer back to previous successes or failures for motivation.

Confront complexity early: don’t save it for the finish. That’s like picking up a 40lb sandbag at the 4k mark. Derisk a project by doing the hardest parts first. In some situations you can’t (final integration of components or external system access), but try to do it as early as possible (via CI or mocking up external systems and loudly asking for access as soon as possible).

Hold a reserve: experienced runners know to save a bit for the end. Don’t ask your team to work crazy hours in the beginning or middle of a project, because they’ll have no reserve to push through the finish line. Every software developer I’ve ever talked to knows the last 2 weeks of a project will require extra effort–don’t waste that expectation by requiring more work early on.

Drive is important to finishing a 5k; it’s also important to complete a software project. Running all the way through the finish line can be the difference between a failed delivery and a successful project. Plan accordingly.

Unintended consequences, vesting edition

I was having lunch with some folks yesterday and struck up a conversation with someone who’d been in the Bay Area for most of his career, but had recently moved back to Colorado.  We talked about hiring.  He mentioned that hiring in the Bay Area wasn’t hard, the real devil was retention.  As soon as one year had passed and 25% of an employee’s shares had vested, they were poached or off to the next startup.

Why?

Because from an employee’s point of view, 25% of the offered stock options for four companies is worth more to an individual than 100% of the offered stock options in one company.  It’s diversification 101. Most startups fail, and if you can quadruple your chances of owning options worth something, why wouldn’t you take it?  Even if you are leaving money on the table by losing the 75% of unvested shares.  (Of course, the cost of exercising the shares within the time limit matters too.)

This churn is horrible for the company.  The company spends two to three months bringing an employee up to speed and only get the remainder of the year of work from the employee.  When that employee departs, they take their experience and hard won domain knowledge.  A company can ameliorate this issue by making the job better (more responsibility, more opportunity, cool tech), adding to the diversity of the employee’s pay structure (paying more cash, which may reduce the need for option diversification) or increasing stock option compensation (more options).  The latter two increase labor costs, and the former is already emphasized in the initial recruitment pitch.

This is an interesting example of unintended consequences.  Two entirely reasonable premises: “we want our employees to be invested in the success of this fragile company–give them options instead of salary, but we want them to stick around before they get the entire payoff–make it vest over a period of years” lead to employees rationally making choices that hurt the company: “I’ll stick around for the year, but then I’m outta here”.

“Are you Twitter or Square?”

This question was asked recently by someone that has seen a lot more startups than I have. The context: coffee shop business applications. In scenario, Square is absolutely essential–if you can’t take money, then you can’t serve customers (well, you can take cash, but you’ll lose a lot of business by not being able to take credit cards). Twitter, on the other hand, is mildly useful to help get more people in the door–if Twitter went away, the coffee would continue to flow.

For other types of businesses or users, the importance of these two apps is reversed. I don’t know many news journalists, but I’ve read that Twitter is absolutely crucial for keeping on top of the news and connecting with both audiences and newsmakers. Square being down wouldn’t matter at all to them (except as a story).

The point is not to praise Square or denigrate Twitter, the point is when thinking about service to sell, are you selling crucial functionality or are you selling something that is “nice to have”. If it is the former case, selling will be easier and customers will be more loyal than if it is the latter.

I’m definitely not the first to talk about these ideas, see “Is your product a vitamin or a painkiller”, but I thought the Twitter/Square/coffee shop was a nice vignette and wanted to share.

My “getting paid for the work” story

Consulting is about getting the work, doing the work, and getting paid for the work.

This is my “getting paid for the work” story.

I was a contractor helping build out an ecommerce site for a startup.  I had been introduced to this client by a colleague, and felt like I had a good relationship with the technical lead, “Bob”.  We were making progress on getting the site built out and I’d worked a couple of months with them–they were my primary client.  I believe I was billing semi-monthly.

One fall day, I got a note from “Bob” that he’s leaving, and I should send all my future invoices to “Joe”, from accounting.  I seem to recall that the project was over budget and was being shut down.  I had one outstanding invoice for about $4,000.

“Joe” wasn’t very interested in making me whole.  He probably was interested in trying to keep the company afloat and keep cash in the company’s pockets.  I was, however, interested in collecting that money.

I didn’t have much leverage since the project was shut down and my primary contact had moved on.  What I did have was persistence.  And I was also able to get “Joe”‘s skype handle.

Every two weeks I would re-send the invoice, always with the same format:

Hi,

I just wanted to send you this invoice for work I’ve done previously.  It was due on XX/XXXX.

Please let me know if you have any questions or concerns.

Dan

And then I’d ping “Joe” on skype to see if he had received the invoice.  Needless to say, it didn’t take long before “Joe” wasn’t on skype very often.  I still continued to send the invoice to his email address.

Every year I give holiday gifts to my clients as a way of saying “thank you”.  I gave a box of chocolates to the ecommerce startup that year. Even though they were stiffing me for thousands of dollars, I still appreciated the money they’d paid me and the work they’d let me do.

Within two weeks, I was paid in full.

Stripe Connect And Refunds Initiated by Connected Standard Accounts

We are using Stripe Connect to handle our payments.  Our sellers (kitchens) have standard accounts, which means they have full access to the Stripe dashboard (I believe these used to be referred to as ‘standalone accounts’).  We are using destination charges so charges run against the platform account and are then immediately transferred to the kitchens, less any application fees (this is not entirely accurate, but good enough for this post).  All well and good.

Some of the kitchens noticed they could refund a charge via their Stripe dashboard.  Refunds happen for a lot of reasons–maybe the food business was inadvertently charged or they had some issues in the kitchen.  So, the kitchens refunded, and the food businesses waited.  And waited.

Meanwhile, when The Food Corridor ran numbers looking at revenue, we saw aberrations.  There was extra money in our bank account.  Now, every business wants more revenue, but they tend to like to know the source.  So, we wanted to figure out where the extra revenue was coming from.

I looked into this and, after some investigation and emails with Stripe support, determined that the kitchens were refunding money to us.  However, it wasn’t flowing through to to the food business from whence it came.

Here is the flow of funds when a charge happens:

food business -> platform -> kitchen

When a refund happens, if initiated by the platform:

kitchen -> platform -> food business

When a refund happens, initiated by the kitchen

kitchen -> platform

Tracking down exactly which charges were being refunded by a kitchen was tedious, but easy to do if we knew which kitchen had performed the refund.  If we didn’t know that, we’d have to search through all the connected accounts for the matching charge.  It was far easier to contact Stripe directly and ask them to hunt it down with some internal tools.  Providing the date of the transfer, the amount and the id was helpful to Stripe support.

After we knew which kitchen had performed the refund, it was easy enough to find the charge, and then refund it to the customer, completing the loop.  Here’s the flow of funds for that:

platform -> food business

If you are using Stripe Connect and are using the destination charge method, and your sellers have standalone accounts, make sure they know they can’t issue refunds from their Stripe dashboards.

What can a senior developer do that a junior developer can’t do?

I saw this post about senior vs junior lawyers a while ago and it sparked some thoughts about the senior/junior divide.  I have also seen companies interested in hiring only senior developers. This is not a post hating on junior developers–the only path to a senior developer is starting as a junior developer.

Anyway, I think that senior developers will help you in a number of ways:

  • Senior developers have made their mistakes on someone else’s dime.  We all make mistakes.  One time I took 4 hours to figure out that the reason I couldn’t connect to an Amazon RDS instance was because the security group was too locked down.  But people integrate their mistakes into their experience and don’t make the same mistake twice.  When you hire a senior developer, you’re getting all their previous experience as well as their current effort.
  • Senior developers can own a larger portion of a project than junior can.  This can include non coding tasks like system setup, estimation, requirements definition and customer interaction.  This gives you leverage.
  • They are able to understand interactions between various pieces of your system.
  • They have an intuitive feel for performance impacts, again, probably because of previous mistakes.
  • They map your current solutions and problems into their existing knowledge: “Oh, this is how we handled caching at my <$JOB – 2>.”
  • They bring best practices from other companies (and can comment on worst practices).
  • They can get up to speed more quickly.
  • They can mentor other developers in areas of expertise.
  • They know the power of automation and knowledge sharing.
  • They have previously been confronted with difficult, complex problems and have an idea of how to attack new, difficult complex problems.
  • They understand that almost all problems are people problems, and that communication is a key part of any project’s success.

Junior developers, in my experience, bring value for the money as well.

  • They have more malleable viewpoints, especially with respect to tooling and technology.
  • They are typically very eager to learn.
  • When you are explaining systems to them, they can’t leverage existing knowledge.  This forces you to speak from first principles and may highlight erroneous assumptions.
  • Because they don’t have the knowledge of existing systems, they question why things are done a certain way.  Systems and processes evolve, but sometimes tasks are done only because they’ve “always been done that way” which isn’t necessarily the most efficient.  It’s hard to see that without the “eyes of a beginner”.
  • They are less cynical.

All good developers in my mind are:

  • Eager to learn.
  • Unwilling to say “that’s not my job”.
  • Accept ownership of the success of the project and the business.

If I had to sum up the differences between junior and senior developers in one word, it is would be “scope”.  A senior developer should be able to handle a wider scope of projects, responsibilities and problems than a junior developer.  How wide that scope is depends on the developer, their experience, and the problem space, but there are certain aspects of scope that are the same across domains (non coding tasks).

Useful Rails Gems: Pretender

I’m constantly amazed at how productive you can be with rails. It simply lets you work on typical webapp problems at a much higher level. At 8z, we had a web application and a customer support team. Occasionally the customer support person had to ‘impersonate’ a normal user to troubleshoot an issue. We built a piece of software that let them assume that role. (We called it ‘sudo‘, obviously.) It’s been a few years, but as I recall it was complicated and error prone, lived on a different domain and wasn’t fully functional.

I needed to add similar functionality to a rails web app, and was able to find a couple of gems that looked useful. I selected pretender, mostly on the basis of documentation and google search results placement. I followed the instructions, tweaked a few settings and was off to the races in about an hour.  (Note this isn’t a fair apples to apples comparison of the underlying technologies, due to the differences in available open source libraries between the mid 2000s and the late 2010s.)

Now, all this gem does is what it says it does. It lets a certain user or set of users in your application pretend to be another user. It doesn’t handle auditing or anything else you might want with an elevated privilege system.

But it does do what it does well.

Ask the hard questions

Do you know that moment which happens at almost every meeting or conference call, when a participant refers to a concept that you don’t quite understand?  That moment happens to me often, and has throughout my career.

“The marketing funnel is part of the sales process.”

“We can just flurbuzz the bazznod.”

“We have plenty of runway.”

That is the moment when you can ask the hard question.

“Why is that connected?”

“What does that mean?”

“I’m sorry, I don’t understand.  Could you repeat that?  How do you define runway?”

Asking these questions is important.  Otherwise you and the other parties will be talking past each other, which will only lead to pain down the line when the misunderstanding is crystallized in people, process or code.

I’ve been asking these kinds of questions my entire career.  When I worked at a web consulting company in the early 2000s, there were often company wide conference calls discussing our precarious financial state.  I got a reputation as “the question guy” because I wasn’t afraid of asking the awkward question, even of the CEO in front of the entire company.  I was interested in hearing as real of an answer (as they could share).

If you’re interested in asking hard questions, here are some tips:

  • Pay attention beforehand.  If you are asking a question about something that was just mentioned, or that you should have known, you won’t have credibility.
  • Don’t worry about looking dumb (except if you weren’t paying attention, see above).  If it is a fuzzy concept, chances are others in the room are wondering what it is.  Besides, the goal is to increase your knowledge.  Check your ego.
  • Ask the question from a place of humility and make it about you.  Maybe you just really don’t understand.  I always like the phrase: “I’m sorry, I don’t understand what you just said.”
  • Approach with positive intention.  Don’t ask gotcha questions or try to prove you are smarter than the speaker.
  • If the answer is a bit fluffy or you don’t understand it, ask a second time.  “Thanks, but I’m afraid I still don’t get it.  Could you explain it to me again?”
  • If the speaker doesn’t answer or hedges again, offer to take it offline.  Depending on who is in the meeting, you don’t want to waste everyone’s time.  But then make sure you follow up.
  • Recognize if the topic is sensitive (financial matters) you may not get a clear answer.  At that point, getting the speaker to define terms but perhaps omit numbers is a win.

Again, the goal here is not to ‘get’ the speaker, it’s to help get everyone on the same page.  Asking tough questions to pin down some of the nebulous concepts we work with every day can help everyone make better decisions.

Reference checking: not just for VCs and employers

Fred Wilson has a great post on reference checking.  From the post:

The thing I have learned in thirty plus years of making reference calls is to pay attention to how things are said more than what is said. And pay particular attention to what is not said.

As always, there’s a number of great stories in the comments, including “warm up your network” when you are going to be referenced checked, and the story of a reference check poaching a candidate.

However, reference checks aren’t just for CEOs, hiring managers and VCs.  They are a powerful tool for job candidates.  It is tedious and time intensive, but is an additional source of information about a company for which you are considering working.  LinkedIn is in particular very useful here, because if you are thinking about working for company XYZ you can find out not only who works now for them, but also who used to work for company XYZ.  You can also find out who knows someone who knows someone who used to work for them.  Yes, this takes additional time, but if you’re going to be spending 40+ hours a week at a company, isn’t it worth gaining some perspective from people who are or were on the inside?

Consider it one more method of doing your research.

 

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.