8 Absolutely No Bullshit Things Every Entrepreneur Should Know

whiteboard

There are a lot of bullshit posts about “lessons learned” out there. Posts that you would assume by their title should be full of helpful advice for starting and running a business, but more often than not are overloaded with rebranded self-help fluff. I think I’m supposed to be inspired, instead I always find myself wondering why there’s so much no one ever tells you about the financial, legal, and tax complications of starting a company. Why five blogs will run virtually identical stories advising founders to eat right, get plenty of sleep, and build a strong team (without ever really spelling out what that means) but no one talks about the errors that are truly startup lethal. There are screeds on hiring the best programmers, but very little on hiring a good accountant. Guides on pitching investors are published to the internet in triplicate, but good luck finding thoughts about managing corporate credit written in plain English.

So I decided to share the information I’ve gathered– in a safe, general purpose way, mind you. You shouldn’t interpret any of this as financial, legal or tax advice as I am neither a financial advisor, a lawyer or a tax expert.

But anyway, here are eight things you should definitely know as an entrepreneur.

1) Learn How to Loan Your Startup Cash
In the beginning the business will be run largely out of your own pocket. No matter what the legal structure or tax situation, more likely than not you won’t be able to pay the company’s bills without injecting cash from your own account.

Make sure you understand how to enter this in correctly in your accounting software of choice. It should be considered a loan from the owner (or shareholder loan). If you don’t specify that, it could be counted as income which the company will be taxed on.

2) Understand Revolving Credit
Best thing I ever did for Exversion was set up a separate, personal credit card for business expenses. Servers do not cost that much money; our biggest expenses are often things like my travel expenses, conference tickets, memberships to professional organizations. Things that I can easily claim as deductions on my taxes.

But these expenses were uneven too. There would be nothing for months, then suddenly I’d need to drop a grand on something. Getting a second card did two things: First, it simplified the process of itemizing those deductions for the IRS. Second, it meant instead of having some months where I had to pay thousands of dollars to avoid falling too far into debt, I could treat the debt I did have as revolving credit.

We all occasionally have expenses it will take us a month or two to pay off. This summer I moved into a new apartment and had to buy a lot of furniture for it, which got expensive. If a business trip comes up while I’m still paying that off suddenly I’m super close to maxing out my card and racking up higher interest payments. By splitting my expenses it became much easier to keep what was outstanding on each card low while making what I was paying out pretty predictable.

Plus it’s really good for your credit score.

3) Top-quality Lawyers, Accountants, and Sales People Pay for Themselves.
It’s really hard to pay thousands of dollars to a professional for something that seems so routine and boring you could do it yourself or go to a low cost alternative. But… no, a $100 accountant is not cheaper than a $500 one if he misses deductions that trim $700 off your tax burden.

4) At The Same Time, Don’t Be a Snob
H&R Block does Exversion’s corporate taxes. We’re not ready for a big accounting firm just yet and after a few experiments with independent CPAs I went back to people I trust at the Block. Finding a good accountant is without a doubt the hardest part of running a business. I’ve met so many small business owners who as their business grows think to themselves they really should stop using the McDonalds of tax prep. Real businesses don’t go to H&R Block, right?

Unfortunately, what you think is a dedicated independent professional isn’t always what’s going on. This year I spoke to two CPAs before going back to my old preparer: the first one was chronically overbooked, the second one hired interns he barely supervised to do his clients’ taxes so that he could take on as many clients as possible. In both cases I found that after the initial courtship they were impossible to contact, never followed up with me and would often refuse to answer questions or really put much time or effort into discussing options.

Meanwhile my guy at the Block would do my taxes right in front of me, explaining the consequences of each decision, and always on the lookout for a new deductions. If by some chance he screws up, H&R Block will handle the problem for me.

So don’t assume that resources that most people consider out of their reach are better than what you can find on main street.

5) Everything Important You Will Ever Do For Your Company Comes Pre-Launch
In startup land there’s a certain susceptibility to The Field of Dreams Fallacy. What’s funny about this is that almost every entrepreneur will deny it up-down-and-sideways, but when you press them for details their launch strategy starts with … well, the launch.

This was the hardest lesson I learned this year: the launch is not the beginning of the launch strategy, it’s the end. Startup mythos tells you to launch ASAP and if you don’t immediately blow up then tweak and pivot until you find the right fit.

This is incredibly stupid. Do not do this.

For one, it puts you in the position of trying to build a market, a community, and a product concurrently. You will never fully be able to determine if you’re failing to get traction because no one wants what you’ve built, because you’re missing two or three key features or because your users don’t know you exist. The fail fast mentality relies on the assumption that users will be drawn to the products and services the same way the ghosts of baseball players are drawn to a baseball field in the middle of nowhere.

So for months I’ve been working on building up our mailing list, our Twitter following, working on a little ebook to recruit contacts in a key sector … all in preparation of something new that’s in alpha testing right now. The more I work on this strategy, the more I think how stupid we were to just launch before we had established channels of communication between the people we wanted to serve.

You can still iterate fast and agile. In fact if you devote a large chunk of time in the beginning to building your userbase before you have a product, your iterations will be smarter and more accurate.

6) “Failure is not much of a thing at all. It’s mostly a point of view.”
The quote comes from Ben Pieratt’s Creative Mornings talk and nothing more poignantly sums up how I feel about the events of the last year. I’m not going to say don’t listen to advice from startup people in a blog post of advice from a startup person, but I will say don’t TAKE the advice of startup people just because you assume you will look successful or are afraid of looking like a failure. The perception of success and failure in this community is warped beyond belief. It has absolutely no relationship with reality.

Early in the year my cofounder left the company. Now, FOR MONTHS people had been suggesting to me that I really should encourage him to move on. There were different reasons why people thought that was a good idea, but the general consensus was the pros and cons of the current situation weren’t really lining up in Exversion’s favor.

But when I finally did it, nearly all of these same people suddenly started dismissing Exversion as a failure just because conventional wisdom says the loss of a cofounder signals failure. In retrospect I can’t tell you how glad I am that this decision was not made because they told me to make it. If I had I would have been pissed at this outcome.

The truth is nearly every successful company has had a period where the community labelled them a failure, a money pit, or a lost cause. I can think of two friends who had startups everyone said where “failures”, quietly working away under that terrible label until one day Google and Intel took notice and bought them. Not bad for a “failed” startup.

For a more specific example, check out what people were saying about Spotify in 2009

The startup community is a small community of entrepreneurs who understand this, and a much larger community of rubberneckers who need to generate commentary in order to stay relevant.

7) The Most Important Designs Are Empty States
What does your app/site/whatever look like when nothing’s on it? What does my account dashboard look like when I haven’t done anything? Remember that this is the user’s first impression– Not the beautiful, content-rich mockups of active users.

8) Learn to Write A Functional Spec
One of the best decisions I’ve ever made is asking a PM friend of mine to teach me how to write a spec. As a freelance developer, specs had never been a formal part of the process for me. I had no idea what a good one included or how to organize them. Now I’m a total convert, writing detailed functional specs helps me fully articulate what my expectations are, which in turn makes the experience of working with freelance, remote, and overseas developers much smoother.

Lies, Damn Lies and Podcasts

What makes Serial so hypnotic is that you end up kind of believing that Adnan is innocent, while at the same time kind of believing that the witnesses against him are telling the truth too. Maybe not the full truth, granted, but it feels unlikely that everything is a complete fabrication.

And yet, obviously, both of those positions cannot be correct at the same time. Adnan can’t be completely innocent like he claims if Jay is telling even a fraction of the truth. So the listener remains locked in this morbid fascination, looking for a clue, a hint, that will push one of these options off the table completely.

Of all the people discussed in Sarah Koenig’s Serial, the one that has always interested me the most is Jen. I can understand the reasons why Adnan would lie. I can understand the reasons why Jay would lie. But Jen is the one who doesn’t make sense to me. While Jen’s truthfulness doesn’t necessarily mean Adnan is guilty, it is certainly easier to believe in Adnan’s innocence if you can debunk Jen’s testimony.

Plus there were bits about the way Serial presented things that didn’t make sense to me. Why would Jen continue to hang out with someone who involved her in a murder investigation? Why didn’t she know the number of shovels she took Jay to clean off? Why does everyone keep talking about the “consistency” in Jay’s story when that story seems to change every time he tells it?

So I found myself going through the transcription of Jen and Jay’s police interviews and creating timelines of the various accounts of January 13th, 1999. I built a data repository to allow easy manipulation and visualization of each element that you can play with here.

The funny thing is, when people look at the various accounts of the 13th they do so under the assumption that people are telling the truth. Therefore Jen’s testimony of what Jay told her that Adnan told him is given the same weight as Jay’s testimony of what Adnan said when logically it shouldn’t. Third, and fourth hand knowledge, rumor and supposition are much more likely to be where the inaccuracies are, even if the person is honest.

Serial timeline

I could never keep all the various versions of what might have happened on January 13th and where that information came from clear. So I wanted the timelines I built to take into account both THE SOURCE of the information as well as who the information was about. Here’s the visualization of that. You can examine accounts from February 27th (Jen’s interview), February 28th (Jay’s 1st interview), or March 15th (Jay’s second interview) either arranged by person or interview. You can easily filter out one source of information and compare the various timelines against each other to see where the inconsistencies lie.

If you want to build your own visualization of the events of January 13th, you can find the data right here.

As I started breaking down the details of Jay and Jen’s stories in short place and time data points, it cleared up a lot of confusion created by Serial’s storytelling style of reporting: Jen didn’t know how many shovels there were because she was in the car, playing look out while Jay went behind the dumpster to find them, a lot of the large inconsistencies in Jay’s story come from him clearly attempting to keep his friends out of trouble … lies that in context seem less like deceit and more like misplaced loyalty and naiveté. While Jay’s first interview and his second changes up many major details, the core timeline of events remains pretty much the same … even as the state claims different.

But looking at the events of January 13th this way also raised some new questions:

– According to both Jen and Jay, Adnan called Jay at least three times between 1pm and 4pm. Twice on the cellphone and once on Jen’s landline. Jen says the landline call was the third and final call (presumably the notorious “pick me up at Best Buy”), Jay says the landline call was the second call. Obviously there was some reason why the police ruled out this information, but it’s interesting as a hypothetical nevertheless. If this important call came through the landline, then it’s possible the murder took place later– at a time consistent with Jay’s testimony rather than where the state tried to cram it in.

– The Patapsco Park bit comes originally from Jen. According to Jen, Jay leaves a message for her asking for a pickup at a park around 7pm. Jen isn’t sure what he means, calls him back for clarification, gets Adnan who claims “Jay is busy”. According to her he sounds high at the time. When the police press Jen for the name of the park she can’t remember exactly what it’s called (or rather the person doing the transcript couldn’t understand her), but the cross streets she gives indicatePatapsco.

Ritz: Where’s that located?

Jen: On [inaudible] Park Road

Ritz: Where’s that, is that Baltimore County?

Jen: Yeah, it’s off of Crosby and Chesworth I believe.

There are so many interesting possibilities here: Jen has already admitted she wasn’t sure if she understood where Jay wanted to get picked up … perhaps Jay really was in Patapsco Park at some point that day … perhaps Jay– young and naturally skeptical of the police– made up the bit about Patapsco in order to better match Jen’s misunderstood account of things because he assumed if their stories didn’t match up the police wouldn’t believe him.

– In Jen’s interview she says Jay dropped Adnan off at some girl’s house some point after picking him up from Best Buy (4ish maybe) … that’s such a weird detail to get wrong. Weirder still that it supposedly happened around the time of the Nisha call. Now, I’m not saying Jay dropped Adnan off at Nisha’s because that would be absolutely impossible given the geography, but it stood out to me for some reason.

– According to Jen, Cathy didn’t know about the murder until the day before Jen’s interview. Jen also makes no mention of Adnan hanging out with them at Cathy’s house which makes way more sense to me than this fantastic idea that Jay, Jen, Cathy and Cathy’s boyfriend Jeff have all heard Adnan has killed his girlfriend and yet still have no qualms about hanging out with him.

– There are points in Jay’s interview where he seems like he is trying to protect Jen by putting distance between them. For example he originally identifies Jen’s house as the house of her brother, and speaks about Jen the way one would speak about the sibling of a relative one barely knows.

Ritz: Okay When you arrive at [Jen’s brother] house, what do you do?

Jay: Sit down, video game out.

Ritz: Who was home at that time?

Jay: Just me and [Jen’s brother]

Ritz: Do you recall what time you arrived at the house?

Jay: No, not exactly. I know a little while his sister came in the house.

Ritz: And who is his sister?

Jay: Jen

Ritz: And how old is Jen?

Jay: Excuse me, I think she’s eighteen.

Ritz: and how old is [Jen’s brother].

Jay: 15

The more I read of the transcripts the more I think the general story Jay is telling is true but that he fiddles with the details in order to improve his position. Either to protect his friends, minimize his own involvement, or to improve the state’s case. I don’t think he made the whole thing up under police pressure, but I could buy the idea that he made up the bits about Adnan repeatedly telling him he was going to kill Hae Lee before the 13th in order to support premeditation.

Devil’s Advocate: Don’t Be Agile

Continuing our series on the pros and cons of popular technical topics for non-technical managers. We look today at the concept of Agile Development and how it will really #$%* you and your developers over.

As a developer, there are three words I dread hearing when I’m interviewing at startups:

We are agile-ish.

Or really any variation thereof: agile inspired, agile influenced, kind of agile. UGH. Going agile is like going gluten-free: doing it half-way causes more pain than not doing it at all.

So just don’t be agile.

The Spirit of Agile is Trusting Your Developers to Lead

To non-technical managers Agile is appealing because it means getting results fast. Indeed, agile promises a MVP in your hands ASAP, a quick launch, followed by growth growth growth.

Who wouldn’t love that?

But the problem with Agile Development is that most non-technical managers do not really do much research into why Agile methodology gets results so quickly. They don’t realize that Agile aims to move the decision making power out of their hands and into the hands of their developers. They think that by importing the format of Agile– sprints and scrums and whatnot– efficiency will just naturally follow. They micromanage, which is exactly what Agile Development is trying to prevent, and when delays hit they micromanage even more.

Agile Development aims to destroy the typical model of “the waterfall” where in orders of what to build come down from above for programmers to execute. That doesn’t mean that non-technical team members have no place in the process. On the contrary, non-technical team members, particularly customers and other stakeholders are a vital part of Agile Development.

But in order to work, programmers in Agile need the freedom to experiment, and to execute without getting caught up in multiple levels of management approval. Agile aims to create small teams where consensus and collaboration are easier.

What typically happens in “Agile-ish” situations is that as developers work on initial product specs, they must constantly come back to the non-technical manager for clarification or adjustment. As the non-technical manager tries to save time and money, acting as Agile Development intends– that is experimenting with one approach, collecting feedback and evolving– become nearly impossible. Building in systems to collect feedback are resources not devoted to the core product and are usually put off until “later”. Testing out new ideas is resented, as non-technical managers have already decided what they want to be built and perceive these experiment as time and money taken away from the real product. (This is particularly true when the dev team is working freelance)

Agile Development relies on the assumption that you trust the judgement of the people you’ve hired and therefore do not feel the need to dictate every element of every decision to them. After all, what does the manager’s opinion on the position or color of a button matter if you’re going to experiment with different options and choose the one that is the most successful with the customer?

But too often non-technical managers get caught up in policing their technical staff in order to eliminate waste. They are afraid of the false starts that Agile Development tells them to embrace. They want Agile, but they want an impossible hybrid of Agile where all the decisions about the product are made in the beginning and are all 100% right.

This is not Agile Development at all. The first rule of Agile Development is to assume that you’ve gotten some aspect of the product wrong and to structure your process around systematically identifying and correcting those mistakes. Even if by some miracle you do manage to get everything 100% correct the first time, business situations change. Products need to evolve.

Yet in the Agile-ish development cycle the product must first be built exactly as the non-technical manager wants it. If the non-technical manager has overlooked a decision or a problem comes up, the dev team must wait for commands. To take initiative and to try a solution without the non-technical manager’s approval is insubordination. Feedback from customers are cherry picked and reinterpreted by the manager. When one component of the product is finished, very little effort is “wasted” talking with stakeholders. It’s more important to move on to the next feature.

And so it goes…

Agile + Remote == Death

What is it that people do when they want to be Agile without actually giving up the control necessary to be Agile? They take on the structure of Agile Development without any of the philosophy and end up with an impossible boondoggle in code. We’ve all experienced the horrors of failing Agile: the 15-min stand-ups that last for two hours, the endless series of planning meetings, “sprints” composed mainly of bug fixes and tweaks because not enough time was budgeted for proper testing and code review.

Agile relies on free flowing communication between members of a small team. Co-location, while not absolutely essential, is considered extremely important.

When your team is remote, especially when they are spread out across timezones, the type of informal collaboration and communication Agile aspires to becomes very difficult to achieve. As a result the daily morning “stand up” becomes the primary (and sometimes sole) method of communication between team members. Instead of fifteen minutes touching base, these conference calls become impossibly bogged down with conversations that would have naturally happened throughout the work day if everyone was working out of the same space.

It is possible for a remote team to be Agile, but it is very difficult … especially when the team members are strangers to each other.

Becoming Agile: Spirit First, Process Second

The goal of Agile Development is to rid dev teams of bureaucracy by throwing out the restrictions of stuffy management processes. It is therefore ironic that the first thing non-technical managers do when going Agile is ignore Agile Development’s core philosophy and skip straight to implementing their processes. Agile development, when poorly done, has become the very monster it was intended to slay.

Its core principles read something like a eulogy now:

 

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

 

If you aren’t willing to sign up for that, just don’t be Agile.

Will Doctor For Food: Exploring Medicare/Medicaid Open Payments Data

About a month ago, an alert came across my desk (well… metaphoric desk anyway): the Centers for Medicare & Medicaid Services had released updated data downloads for their Open Payments program. When I followed the link through to check it out the following warning greeted me:

Some datasets, particularly the general payments dataset included in the zip file containing identifying information, are extremely large and may be burdensome to download and/or cause computer performance issues. […] Be advised that the file size, once downloaded, may still be prohibitive if you are not using a robust data viewing application. Microsoft Excel has limitations on the number of records it can display, which this file exceeds.

Indeed some of CMS files are as much as a GB of data. And here I thought “Hey, I have a company for this” (so yeah, if you want to poke through the CMS Open Payments data all of it is on Exversion right here)

APIs are nice 🙂

That being said, one wonders exactly what you can do with Open Payments data. It’s natural to look at the words Medicare/Medicaid and assume these are all medical bills, but actually it’s a lot more interesting than that: [1]

This data lists consulting fees, research grants, travel reimbursements, and other gifts the health care industry – such as medical device manufacturers and pharmaceutical companies – provided to physicians and teaching hospitals.

Well now that sounds pretty nefarious. I mean come on, we all know that the money moved around through gifts and grants influences the type of treatments doctors recommend. So now the government is giving you an opportunity to look directly at that activity.

The fact that they took something really interesting and wrapped it up in the most uninteresting way possible is to be expected. It’s a government thing.

Identified -vs- Deidentified Datasets

If you check out our collection of CMS data the first thing you’ll notice is that each data type is split into two different sets: identified and deidentified datasets. This is no–, as I first assumed– the same data with identifying information removed (I admit that this wouldn’t actually make any sense to begin with but in my defense I’ve seen the government do MUCH worse with their open data). Instead the de-identified is a collection of cases where some of the necessary data about who received what is missing or ambiguous.

Otherwise what the CMS released fits three categories:

  • General Payments: Payments or other transfers of value not made in connection with a research agreement or research protocol.
  • Research Payments: Payments or other transfers of value made in connection with a research agreement or research protocol.
  • Physician Ownership Information: Information about physicians who have an ownership or investment interest in an applicable manufacturer or GPO.

Looking At the Data: Who Get the Most Research Dollars?

Essentially what CMS has released is just a dump of their database. Each files has what feels like twenty or more columns, most of which have no information in them. The benefit of accessing this data through an API as opposed to downloading the file and trying to work with that is that we can segment the amount of data we’re looking at before committing any computer memory to the task.

The first thing we did was rearrange Research Payments to look at how much money each state received for the year 2013. Because this is a smaller dataset, we wrote a python script to iterate through each page of data returned by the API, sort through and rearrange as needed. This is not recommended for super large datasets as you will hit our api’s rate limit pretty quickly, but for this size it wasn’t an issue. We used python to write nice clean json we could copy and paste into d3.js and create an interactive map (click through to see)

interactive map

Along the way we discovered something funny. All the payment data was between the months of August and December. After a little research we discovered that this is a relatively new thing for CMS. The mandate to release this information was part of the Affordable Care Act. As 2013 is the first year, they could not collect a full year’s worth of data.

That means 2014’s files will be EVEN LARGER.

Will Doctor For Food

Anyway, we wanted to poke around this General Payments file, it seemed like the most interesting stuff would be there. But the identified version is over a GB… kind of unpalatable.

Luckily with Exversion we can take a sample and play around with that instead. How about 50,000 records? Fetching 50,000 records and analyzing them took seconds. All we had to do is add the ‘_limit’ parameter to our request:

https://www.exversion.com/api/v1/dataset/W1AUT4HQ0A6FD9V?key=XXXX&_limit=50000

I bet if I told you Big Pharma was paying physicians and teaching hospitals in FOOD you wouldn’t believe me, but here’s the breakdown of that 50,000 record sample:

Type of Payment Number of Payments Total Amount
Food and Beverage 40302 $1,037,941.01
Gift 55 $80,035.93
Consulting Fee 924 $1,917,576.16
Grant 382 $3,702,231.73
Travel and Lodging 2710 $862,276.81
Compensation for serving as faculty 90 $194,884.57
Royalty or License 100 $6,913,971.38
Current or prospective ownership or investment interest 4 $529,830.08
Entertainment 108 $5,977.24
Compensation other services 2787 $3,256,475.94
Honoraria 27 $95,666.70
Education 2436 $456,251.12
Charitable Contribution 14 $97,773.60
Space rental 61 $72,862.55

The interesting thing here is that in our sample the vast majority of payments are tiny amounts related to wining and dining doctors and hospitals, but that does not add up to the most money spent. No, much more money is spent in royalties and granst, but to only a handful of institutions.

So there you go. Now you can play around with CMS’s Open Payments data without worrying about choking your computer. Can’t wait to see what the rest of the internet does with this.

Blaming Victims: How Stats Frame Our Perspective

We all know that you can manipulate the way statistics are presented to change their meaning, but you probably haven’t given much thought to the way their presentation affects how you see the world. I’m not talking about trusting a misleading statistic and believing in a policy or position that isn’t true. I’m talking about the way statistics influence how we define problems and consequentially what solutions we spend time and energy looking for.

Consider crime. Most crimes have two sides to them: those who commit the crime, and those who are victims of the crime. But the statistics we collect are inevitably obsessed with the victims. Google “Odds of being murdered” and hundreds of reports come up with authoritative sounding numbers. Here’s one from The Economist. Here’s another from Yale University.

Now try finding the odds that you will BECOME a murderer.

That’s not nearly as easy, which is odd when you consider it is virtually the same set of numbers that we have already collected. We just need to change what we’re counting.

And yet… Here’s an informal back-of-the-napkin calculation from Deadspin on your odds of knowing a murderer. Here’s something from Reuters about gun ownership increasing the risk of suicide or murder.

There are of course studies exploring the odds that a convicted murderer will kill again. There are odds of you getting AWAY with murder. There are stats on the male/female breakdown of roles when murder’s do happen. But there are virtually no statistics on your odds of one day killing someone.

On the surface this might seem like a trivial, almost obnoxiously pedantic issue. Why would anyone ever need to know their odds of committing a crime? You can control whether you commit a crime! Being a victim of a crime involves a certain amount of chance, so of course knowing your odds and how those odds are influenced by certain factors must be useful in protecting yourself.

But there’s one very big problem with this type of thinking: it automatically focuses us on solutions that prevent (or otherwise decrease the odds of) victims becoming victims, instead of preventing criminals from becoming criminals. From an individual point of view, looking for ways to minimize your risks makes a lot of sense. As an individual you can’t control anyone else and you might have little recourse after the fact. You focus on your decisions and behaviors because that is what you can actually do something about.

However, the same cannot be said for society as a whole. Society does have the ability to tell people what to do, and the power to enforce consequences when those prescriptions are violated. One would think society would also have invested interest in minimizing the number of criminals. Criminals, generally speaking, are not fully productive contributing members of society. From the society’s point of view criminals cost way more than victims.

And yet we devote a fraction of the narrative to exploring the factors that lead to people becoming criminals. About the only time you will see any statistics on this topic is when discussing low income neighborhoods, and even then the stats are usually the odds of a person ending up in jail.

Not everyone in jail deserves to be there.

Sexual Assault and Statistics
You cannot possibly develop a solution for a problem if there is no discussion of the problem in the first place. If the conversation does not happen, people do not think about it. If people do not think about it, they do not recognize opportunities for solutions.

And in this case, by ignoring one half of the criminal-victim dynamic, we may also be ignoring the most effective solutions.

Consider rape. You probably realize already that a lot of the potential “solutions” to sexual assault end up asking potential victims to submit themselves to a ridiculous series of seemingly arbitrary dress codes, behavioral rules, and institutionalized paranoia. When those provisos fail it is assumed that the victim did not follow them carefully enough.

There are many situations that may lead to a sexual assault. Walking down the wrong street. Wearing something provocative. Getting drunk at a party. Dating a creepy guy.

Yet the same situations could just as easily NOT result in rape. For all our work collecting stats to protect victims, we actually don’t have much information as to why that is or how much this presumed “bad behavior” actually increases your risks. Unlike the lack of data on criminals, this isn’t a deliberate bias. Such data is really hard to collect.

Nevertheless, the consequences of framing the problem of sexual abuse with the odds of becoming a victim are that solutions that perspective provides are not all that effective at minimizing the rate of sexual abuse. After all, if wearing the right things, not hanging out with strange men, not going out alone, prevented abuse Saudi Arabia would have the lowest rate of violence against women in the world (spoiler alert: it doesn’t)

Really all the victim bias does is enforce a state of terror in the perceived potential victims … who in fact might not be the most likely victims in the first place (for example the majority of rape victims in the military in 2012 were men). So it’s not just a state of abject terror, it’s a state of pointless abject terror.

What would happen if instead of having stats like this beaten into our heads at every conceivable opportunity:

– 1 in 5 women will be raped
– 30% of them will be raped by people they know
– Every 2 minutes someone somewhere in America is sexually violated

…we were constantly reminded of stats like these (all made up):

– 1 in 5 men will commit rape
– You are ten times more likely to rape your partner than a stranger
– Every 2 minutes someone in America is sexually violating someone else

Even though the second set may seem unnecessarily antagonistic (almost Minority Report-esque in its assumptions) it has the unique effect of changing the focus of the problem. While there are millions of uncontrollable and unpredictable contributing factors that might lead up to a victim being raped, there’s really only one factor that leads to a person becoming a rapist. Rape is a choice– perhaps not always a MALICIOUS choice (ie – statutory rape), but nevertheless a choice. No one accidentally rapes another person. No one commits a rape because they happen to wear the wrong thing. One could argue the occasional outlier case of rape-by-miscommunication, but one can’t deny that if the focus of the public conversation was “how do we keep people from becoming rapists?” rather than “how do we keep people from getting raped?” would-be “unintentional” rapists would probably take more precautions in ensuring consent is clearly articulated, thereby eliminating these cases.

In other words, reframing the statistics changes how we try to solve the problem to emphasize decisions we actually have control over. As a woman I cannot predict what hemline is long enough to avoid provoking lurking rapists, but the rapists themselves can easily choose not to rape.

It is tempting to assume that because we theoretically welcome free and open discussion, we are able to see all sides to an issue with very little mental exertion. But really we are programmed to see certain sides and rarely if ever look beyond that. Statistics in this sense provides a false sense of security because it is not obvious how they can be framed to completely remove large parts of the situation from consideration.

Devil’s Advocate: Don’t Use Open Source

Do to the nature of our work, we frequently collaborate with non-technical organizations. This is the first part of what we’re calling our “Devil’s Advocate” series, intended to help non-technical people make better technical decisions by presenting the negative side to current tech trends.

Don’t use open source.

Don’t get me wrong, I love open source. I use open source projects and I contribute fixes back to them whenever I can. Open source is great.

But open source does not make solutions instantly better, more democratic, or more transparent. A lot of organizations– particularly nonprofits– insist upon open source because the philosophy of the open source movement matches their own ideals. Well, that’s nice, but technical decisions should be made based on technical arguments. Open source is the right solution when there’s an open source project that fits what you want to build.

Far too often nontechnical managers ask the dev team to take an open source project and completely alter the functionality without realizing that it’s harder and takes more time to do that than it would have to build something custom. The manager thinks using open source should make the project cheaper and speed up turn around time, if that doesn’t happen he gets frustrated by the work ethic of the programmers. “Why isn’t this done already?” he might ask. “The open source project works out of the box, all you need to do is just make these tiny changes.”

Granted there are considerable advantages to going with an open source solution. It is easier to onboard new devs. You benefit from an established community of devs without having to pay them. You have a mature, fully functioning platform to test various ideas on.

But that last advantage is exactly why open source might be the wrong solution for you.

As code “matures” good developers reorganize it to remove duplicate functions and make it easier to maintain. From a nontechnical mindset it is difficult to understand what these periods of “refactoring” (translation: code clean up) are really doing or why they are necessary. Too often nontechnical managers see refactoring as a period where nothing is getting done because the devs were sloppy and have to go back and fix their mistakes! But all devs, even the best in the business, write code that eventually has to be refactored. It’s an important part of how software evolves.

Imagine we had two functions: send_email which takes values from a form, generated a request to the server to send an email … and forward_email which takes values from a form plus values from a database and generated a request to send an email. We wrote send_email before we knew that we would ever want forward_email, but when someone requested the ability to forward emails that sounded like a good idea so we quickly copy and pasted send_email and changed a few things before renaming it forward_email. Now suppose that we realize we have made a mistake writing the code to generate the request. Or maybe we hadn’t made a mistake at all, maybe we upgraded to a new version of something and that required a change. Both send_email and forward_email need to be updated… but if we had created a third more generic function (say generate_mail_request) and moved the code that wrote the request out of send_email and forward_email, then we would only need to change generate_mail_request.

This is the concept of “abstraction”, building reusable bits of code that several parts of the application will use to do the same thing.

The process of minimizing and reusing code is essential to project growth. However, it can also make changing small things more difficult if the change conflicts with the way the program was designed to behave. This is why taking an open source piece of software and making “a few changes” may in fact take longer and be more difficult than writing the same software from scratch. If the open source project is mature enough it has probably been refactored a few times, creating several layers of code that effect hundreds of features and functions.

Assessing the Ease of Your Desired Change

At the same time most mature open source projects do in fact assume you will want to change things around a bit. Their programmers work in pathways where certain changes can be made quite easily. The trick is understanding whether the customizations you want fit into that system or not.

As a general rule it is usually possible to change the way an open source project looks. If the project has a templating system, there should be an easy way to override the default templates with your own.

For mature and complex projects it is also usually possible to add new, independent features pretty easily. Since these tasks leave the core behaviors alone they only need a place to hook into so the open source application knows it’s there.

The big question mark is always how much of the existing behavior can be changed, that will depend on whether what produces the behavior in question is a link in the template, client side javascript, or something in the server side code and if in the code, how deep?

Open Source as Parts of a Whole

Now that you’ve heard all the consequences of picking an open source project over a custom solution, there’s good news: the best projects use both custom solutions AND open source. There’s an open source solution for practically every major feature you need, designed to slide easily into place with all kinds of different applications. So if you truly need something unique and there’s no open source platform that fits the bill. You can hire a developer to build something custom, but fill it with open source parts so that you’re not wasting time and money building things that someone else has already built. Pop in a login system, image uploading, commenting … all areas where there are several good open source options available.

And when you’ve finished your custom piece of software … you should definitely open source it 🙂

Public Speaking Hacks for Conference Season

Two years ago I took the stage during The Feast to explain why developers don’t work with open data. My presentation took the nontechnical audience through such concepts as brute force hacking and formatting inconsistencies, got me a standing ovation, a stack of business cards a mile high, and ultimately set me down my current path.

Yesterday I returned to The Feast to give a 90 second pitch about a project I’m developing for Exversion, again it got a great response– influential people sought me out rather than me having to stalk them through the crowds– and I found myself approached by a lot of would be entrepreneurs asking for tips on giving an awesome presentation.

So I decided to write a quick guide with some of my best advice for pitches and longer form public speaking.

Find Three People

Having a crowd of hundreds of people focusing on you is really scary, so the first thing I do when I start my presentation is find three people in the crowd to make eye contact with. One on the left, one on the right, and one somewhere in the center and towards the back. Throughout the course of my talk– whether that talk is 60 seconds or 60 minutes– I keep coming back to these three people and making eye contact with them again. Usually I develop a little rhythm, jumping from left-person to center-person to right-person back to center-person, left-person… etc.

This technique has a couple of different benefits. First of all it brings the scale of the conversation down. You are no longer giving a speech in front of a massive group of people, you’re just having a conversation with three people. A casual conversation with three people is easy, right?

The second thing it does is give you a really easy way of judging audience response. Those three people will smile, they’ll nod, or they may start to fiddle with their cellphones … in which case you need to change something up on the fly.

The third thing it does is get the attention of everyone around those individual people. Think of how many times you got freaked out by someone staring at you across a room only to realize they were actually staring at someone behind you? That’s the benefit of crowds. You’re really looking at one person, but everyone around that person is going to feel like you are talking directly to them which will make them pay more attention.

The last thing it helps with is establishing a soothing rhythm for your body language. Who do you think comes off as more confident and compelling: a speaker who stands in one place, swaying nervously and staring out into the crowd, or a speaker who moves around in a smooth orderly pattern? This is true even when you’re using a podium, the speaker who turns her head to look at specific people seems much more natural than the speaker who occasionally looks up from her notes to stare into the void. Ultimately when people feel like you are talking to them rather than at them they are much more receptive to the content of what you are saying.

Memorize Phrases, Not Scripts

There are some people who can write out every single word before hand, memorize it, then deliver a spectacular presentation, but most of us end up obsessing so much over remembering the exact order of each perfect sentence that we lose the emotion and energy we need to engage the audience. The power of perfect wording is a myth perpetuated by Hollywood screenwriters. It’s not the exact words that people respond to, it’s the enthusiasm and confidence of the speaker. After the presentation no one is going to remember exactly what you said, what they will remember is how they felt while you were speaking and whether you were likable on stage.

That being said, sometimes you do have key phrases that you want to make sure you use. They maybe taglines or core concepts or they may just be good transitions. The first and last lines of your presentation are good things to plan out, the first because it is the sentence in your presentation with the most potential power, the last because the absolute worst thing in the world is to get through your entire presentation then end it with something like “uh… well that’s all I have to say, thanks.” (we’ve all done it)

So in planning out your presentation, figure out what the key phrases are and memorize those. Get used to saying them over and over and over again, so that you only need to say the first word and the rest of the sentence comes out automatically, without thought. For my Feast pitch yesterday my key phrase was “During a crisis the most expensive resource is time”. I practiced that phrase over and over and over again the day of the pitch because what I was talking about was how poor data infrastructure can delay organizations like FEMA or the Red Cross literally for days. I needed people to understand that you can’t send people into the field without any clue where they’re going, what they might encounter, or what they’ll need to help. Every minute spent trying to get the information relief organizations need to deploy is a minute spent not helping. Blankets and bottle water are cheap, time is expensive.

Treat Your Points Like Legos

As much as possible strive to make your content modular. This is essential when you don’t have a slide deck to structure your talk, but it also applies to what you plan to say within the bounds of a single slide if you are working from a deck (because Lord knows you do not want to fill up a single slide with everything you plan on saying). Since you haven’t memorized your whole speech it’s natural that in the moment you may recall points in a different order than what you originally planned on. Do yourself a favor and try to avoid chaining thoughts together. The more Point B depends on the audience understanding Point A the more of a colossal screw up it is when you accidentally forget to make Point A and go immediately to Point B.

At the same time keeping things modular means you have options when things just aren’t working. You should give yourself the ability to skip sections or examples if you find your talk going slower than you originally thought it would or when the audience doesn’t seem to be responding. It’s important to try to predict the type of audience and the tone of the event during the planning stage, but even the best speakers make mistakes in this regard. The more brittle the structure of your presentation, the more likely it is to feel like a run away train. You know it’s not working, the audience knows it’s not working but you’ve given yourself no break points where you can add or remove content on the fly.

This may seem like a huge challenge, but it’s really not that hard. Just think through what you want to say in two-three sentence blocks. Get a general idea of what those sentences should sound like, don’t obsess over the exact wording. Think of it like a mini-essay: the first sentence should state your point, the second sentence provides an example, the third sentence a solution or conclusion or restate your point (depending on the situation). Experiment with different wording each time you practice. Most people screw themselves over in their transitions, because we don’t think about the meaning of the words in transitional phrases we just say them automatically to fill the gaps between our thoughts, but when we’re trying to get a smooth, eloquent speech together we need the meaning of every word to align correctly.

As you practice stating your point, providing an example illustrating your point, then concluding you will realize there are certain transitions that you should absolutely avoid using because they paint you into a corner, leaving you with no smooth way of getting to the next point. There is no master list of phrases to avoid, it depends on what you have to say. By speaking naturally instead of from a script you will find these bad transitions as you practice and know how to avoid them.

Time Yourself Once, Then Forget About It

A little known secret of presentations: it’s very rare to pull a speaker off or interrupt them when they go over time. You always have a little clearance proportional to the total amount of speaking time, and depending on the moderator you may have even more wiggle room than that.

Interrupting a speaker is awkward, no one wants to do it and so organizers will usually put off doing it until they absolutely have to. You can get an extra five seconds out of a sixty second pitch, an extra minute out of a four minute demo, so there is no Earthy reason to obsess about time. Chill out, speak at a pace that is comfortable for you. Take the occasional dramatic pause. If there’s a clock displaying your time, ignore it. No one is going to pull you off stage with a giant hook and you certainly don’t get a prize for finishing early.

You should time yourself while planning your talk so that you know approximately how much content you can fit into the allotted block. There’s a big difference between needing a little more time to finish your conclusion and passing your limit when you still have six more slides. If the organizers get the sense that you are wrapping things up they will let you finish. If they feel like you’re just about to launch into a whole new section of material they will cut you off. Experiment with and test how much content fits inside your block. Remember that saying something on stage is a different experience from saying it sitting down in front of a computer. There are always little seconds gnawed away by the logistics of being in front of others. Your slides may not advance immediately, or you may be stopped by audience laughter or applause. If you find yourself hitting the time limit exactly, trim a little fat and time yourself again to account for these issues. Once you can do your presentation under time once (maybe twice just to be sure), throw away your timer and just forget about that aspect of it.

Own Your Stage

I was not the sole entrepreneur invited to pitch in front of the Feast this year. I was one of eight given the opportunity to come up and talk about what I wasdoing. During prep the moderator explained her plan to keep things moving smoothly: we’d all go up on stage together, lined up in the order we were presenting in so that there would be no awkward logistical issues moving from one presentation to the next.

And that’s how it went, one by one, down the line until we got to me where I did something truly shocking.

I stepped off the line, and walked towards the front of the stage to give my pitch.

When your presenting, no matter how much time you have, no matter how early or tractionless your project is, no matter how unimpressive your expertise, no matter how little physical space you actually have, YOU OWN THAT STAGE. It is yours and you need to act like it is yours until you give it up or someone drags you off!

By staying on the line, the audience had a constant reminder that the person speaking was just one of many. It diminishes you, the audience ends up distracted by thoughts of the rest of the line… how many people are left? What might they talk about? Ooo look how the guy who just went is still fidgeting! Stepping forward says this is my space and my time to talk.

After we came off stage all the entrepreneurs before me said “I wish I had stepped forward too” (and actually the moderator told me “I wish I had put you first so that everyone else would have stepped forward after seeing you do it!” haha) It wasn’t that they didn’t think of doing it, it’s that they wanted to follow the rules. They were afraid of doing something different and having their right to speak taken away. The difference between a good presentation and a great one is not language, it’s your ability to convince people that you command the stage. Which means you need to believe the space is yours and you can do with it whatever you please.

Imagine how much more authority you will seem to have when it looks like you are so important that the organizers will let you do whatever you want in the time you’ve been given to present. Imagine how much more people pay attention when they think someone important is speaking.

Principals in Practice

Here’s how I prep for a presentation. First, I don’t really put much work into it until the week or day of (depending on the length and number of slides I need to create of course). I get excited about what I want to say and that excitement is useful on stage so I want it to be as fresh as possible. For a 45 minute presentation I’ll probably do the slides the weekend before (this tends to annoy conference organizers who want a clear proposal months in advance in order to weed out bad presentations, but I get most of my invites directly from people who have seen me speak, know how good I am already and are willing to trust me). For a sixty minute pitch I’ll do a script usually an hour or two before. I never do the same presentation twice, even if I’m talking on the same topic.

I would rather have a complete meltdown on stage than come off sounding canned and rehearsed.

For that reason I abhor pitch practice and avoid the formalized practices sometimes run by organizers at all cost. I think nitpicking wording and style is the absolute worst way to coach someone into giving a good presentation. Organizers who insist on it are really only doing it for their own peace of mind– to soothe the urge to micromanage– not to help you. I am always terrible at pitch practice (ALWAYS) so if an organizer twists my arm about it, I’ll do my best to get through practice with a passing grade, completely disregard 90% of their feedback and waste no more thought on it.

For pitches (ie – talks under two minutes) I will start the prep process by writing out a script. When time is that tight every second counts so it make sense to invest the time and effort organizing your thoughts. The process of writing the first draft helps me identify time munching digressions. When you’re excited about what you want to say you’ll be able to think up all sorts of compelling arguments, however some of these arguments won’t be as easy to express in the allotted time. The script helps me find those thoughts that aren’t worth the time and energy they eat up, so that I can cross them out and focus on what points can make the greatest impact in the smallest time frame.

Once I have that script I read it through a few time, then close my eyes and make sure I can flow smoothly from the key phrases that I’m trying to memorize to the sentences where I’ve decided the exact wording doesn’t really matter. If I’ve having trouble remembering what comes next I may modify a key phrase to better setup the next thought before I start memorizing it. This isn’t as complicated as it sounds, remember you’re talking about something you know inside and out. All you need is a little hint.

That settled I then write a quick outline and throw out the script. My outline is not a proper traditional outline, but more like a list of key phrases and summary of points in the order they should probably go. This is what my outline for the Feast pitch looked like:

– time is expensive
– types of data needed
– who needs the data?
– one infrastructure
– one infrastructure that hooks into anything

Then I just start running through the pitch until I feel comfortable with it. I feel like a perfect run through just jinxes you, so I try not to obsess about hesitations or minor errors. Every time I’ve blanked out on stage it’s because I’ve over practiced. While it’s useful to have key phrases so committed to memory that you can finish them without thinking, when you’re presenting you really want to be aware of what it is you’re saying. It’s easier to recover from mistakes that way. If I feel nervous before going on (and I always do) I will look over my outline rather than trying to repeat the whole thing perfectly from memory to prove I can.

If I have more than two minutes I skip the script phase completely and use my slides to structure and guide the course of my talk. If I have any key phrases I want to use I will put them directly on the slide so that they are impossible to forget. I’ll run through the slides a few times and if there are places where I feel the transition between one idea and the next is too fragile, relies too much on getting exactly the right sentence in place, I will add a slide in between those thoughts to better lead from one idea to another. You can never have too many slides!

Ultimately the most important thing is that you feel as comfortable as possible when you’re up there. How you feel directly before you go on doesn’t matter because we’re all freaking out at that point anyway, but when the attention is on you, you should enjoy yourself.