Drawing Lines, Not Dots

A dot on a graph with no context is often fairly useless unless you have already established a sense of context. A good example from my last job: if I tell someone that they used 200 kWhs last month, for the large percentage of the population, that doesn’t mean anything unless they also know how much others are using, or how much they used in the past. Another situation where this has come up for me is when living in countries that use Celsius for temperature. Is 30 degrees hot? cold? shorts? pants? shirt? no shirt? — after living there for a while, you get a sense for it (30 is pretty warm by the way), but without having spent one’s life getting familiar with it in the same way as Fahrenheit, it’s a complicated proposition.

To give credit where it is due, the concept for this post was inspired by a post from Mark Suster on entrepreneur/VC relationships (which is also worth a read).

dot with linesIt can be helpful to remember this when presenting yourself to others or evaluating your own performance. Without comparisons to others or your past performance, a single piece of information leaves a lot to be desired. As Mark points out, when evaluating a company for investment, meeting an entrepreneur a single time tells you very little about the company. Are they high revenue, but trending down or flat? or are they low revenue, but doubling every month for the past 6 months? With a single point, you can make up whatever trajectory you want from your data.

This same concept can be applied to job hunting, dating, and any other interpersonal situation where you are looking at a long-term outcome involving people. Mark covers this thinking pretty well in his post, so I won’t re-iterate here.

This same type of thinking can also be applied usefully to self-evaluation to provide better perspective, and for driven, hard charging people, it can help provide some checks to negative self-evaluation or frustrations with progress. For example: say I’m an athlete looking to perform my first body-weight pull up, and I’ve been trying to reach this goal for 6 months. I’m still not there. Looking at my current state (can’t do a pullup unassisted) and comparing it to where I want to be (can do a pullup unassisted), I could very well look at that as a failure. That’s a point on a graph. Now, let’s back up six months to where I didn’t have the strength to deadhang on the bar for more than 5 seconds. Now I can not only hang on the bar for more than 40 seconds, I can can perform assisted pullups using a stretch band. Suddenly my hopeless situation becomes a trend line which is strongly going in the right direction. That’s a much different story.

Again, the same concept can apply to skill building, working out, relationships, etc.


I’ve noticed a few situations where this model can break down if not observed.

Moving Cohort

cohort movementComparing one’s self to a group can be a great way to get a sense of where you fall in within the group’s skill set, but can be terrible when measuring improvement in your own skills. For example, I’ve always worked in startups with smart, ambitious young people and thus find myself comparing my skills and abilities to the highly skilled and intelligent people I work with. As a result, I often feel that I’m not progressing. What is in fact occuring is that our entire cohort is progressing and improving together. So when I look to my local cohort, I find that it often looks the same month over month. What I’m failing to realize in this case is that the cohort itself is moving in relation to the outside world.

Looking to Extremes

local trendsWith limited, discrete data points, evaluation can be flawed by sampling error. An example of this in life would be: evaluating sport proficiency after having lost of game or relationship success after having broken up recently. These are both likely going to be relative minimums, and not representative of the overall trends. Make sure your sampling isn’t being biased by current state of mind and that your time horizon isn’t  distorting your trend line.

Looking Out

I’m sure I haven’t covered all the possible ways this could go wrong, I’d love to hear if any of you have other thoughts on avoiding false interpretations and ways to better use lines and not dots in keeping yourself happy, healthy, and wise.

Prioritizing Tech Debt and Opportunity Cost

Last week I found myself arguing with one of our engineers at Simple Energy about the ‘correct’ implementation of a feature. This argument centered around the issue of accruing ‘tech debt.’

(If you’re not familiar with the concept, check out the wikipedia page.) He argued that a longer implementation time to add additional functionality would save us time in the future. I argued for a shorter, less full functioning solution which was ‘good enough,’ but would likely lead to a small number of distractions for the engineering team in the future. We have very intelligent and highly capable engineers at Simple Energy, so I knew when we couldn’t reach a mutually agreeable conclusion, that I was missing something.


One of the most difficult things to work into any engineering workflow — in all the startups I’ve worked at — has been tech debt. This issue becomes highly charged at times because it is painful to deal with for the engineering team, but often hidden or difficult to see for the business decision makers. Having previously coded and led engineering teams, and now leading a product management team, has given me perspective into both sides of this argument, yet I still found myself frustrated trying to explain my position.


Then suddenly it hit me. The engineer was convinced that his side had merit because in spending extra time building this feature right, he would be saving more time than he spent in the future. There was a clear net gain, so why would we not build it? The answer is actually relatively simple: opportunity cost.


Opportunity cost is an economic concept used to address the allocation of a scarce resource towards mutually exclusive investments. In the tech debt scenario, our scarce resource is developer time and the mutually exclusive investments are specific instances of tech debt.



Let’s look at an example to bring some clarity to this. Let’s assume that I have 1 engineer across a four week period and 4 pieces of tech debt with estimated paybacks over the next 18 months. (Granted it’s never this black-and-white in the real world — maybe just try to put it in hours, days, weeks, months instead.)

Item Initial Cost Time Saved — over next 18 months
Issue A 3 weeks 5 weeks
Issue B 1 week 4 weeks
Issue C 3 weeks 8 weeks
Issue D 6 weeks 5 weeks


Looking quickly at this list, we can see that Issue D should simply never be address. It has a net value of -1 week of productive time. From there it gets trickier though. We have 3 issues, all of which will provide net productivity gains from completion.


Yet we don’t have infinite resources; we have 4 person-weeks of time. Assuming the repayment of the debt is simply evenly distributed across the next 18 months, we will want to make sure that those limited resources are being used to address the largest gains possible first. In this case, Issue B wins by providing us with a 4x multiplier on our investment. Following this, Issue C gets us a 2.67x multiple and Issue A returns 1.67x. Therefore, our best option is to invest our 4 weeks into issue B followed by Issue C, returning a total of 12 weeks of benefit for our 4 week investment.


Looking at this through the lens of opportunity cost, we see that addressing feature A comes at the cost of not addressing 2 higher return issues, leaving us with a less-than-optimal outcome. This means our best choice is not to address issue A0 at all in this scenario.


This is the piece I was missing while explaining why I didn’t believe we should have been addressing the issue raised by our engineer. While building this feature ‘right’ would cost us roughly a week and likely save us 1-2 weeks of wasted time in the future, there are a number of other items in our tech debt backlog which we could be spending time on which will provide higher-than-1-2x multipliers on time investmented. Those are where we should be focusing our time, or we will lose ground with competitors, or worse, run out of capital before we reach our goal.


Coming Soon:
All this theory is nice, you may say, but how the hell do I intelligently put tech debt into my feature backlog? Well, that’s for another blog post.