Tag: cto
Now that our federal government is back at work and the short term debt ceiling thing is resolved, it should be no surprise that the news cycle is now obsessed with Obamacare and its flawed implementation. Over the weekend I must have seen a dozen articles about this online and in the NY Times, and then I woke up this morning to a bunch of new things about the Healthcare.gov site underlying tech, how screwed up it is, and what / how the Health and Human Services agency is going to do to fix it.
The punch line – a tech surge.
To ensure that we make swift progress, and that the consumer experience continues to improve, our team has called in additional help to solve some of the more complex technical issues we are encountering.
Our team is bringing in some of the best and brightest from both inside and outside government to scrub in with the team and help improve HealthCare.gov. We’re also putting in place tools and processes to aggressively monitor and identify parts of HealthCare.gov where individuals are encountering errors or having difficulty using the site, so we can prioritize and fix them. We are also defining new test processes to prevent new issues from cropping up as we improve the overall service and deploying fixes to the site during off-peak hours on a regular basis.
From my perspective, this is exactly the wrong thing to do. Many years ago I read Fredrick Brooks iconic book on software engineering – The Mythical Man-Month. One of his key messages is that adding additional software engineers to an already late project will just delay things more. I like to take a different approach – if a project is late, take people off the project, shrink the scope, and ship it faster.
I think rather than a tech surge, we should have a “tech retreat and reset.” There are four easy steps.
- 1. Shut down everything including taking all the existing sites offline.
- 2. Set a new launch date of July 14, 2014.
- 3. Fire all of the contractors.
- 4. Hire Harper Reed as CTO of Healthcare.gov, give him the ball and 100% of the budget, and let him run with it.
If Harper isn’t available, ask him for three names of people he’d put in charge of this. But put one person – a CTO – in charge. And let them hire a team – using all the budget for individual hires, not government contractors or consulting firms.
Hopefully the government owns all the software even though Healthcare.gov apparently violates open source licenses. Given that, the new CTO and his team can quickly triage what is useful and what isn’t. By taking the whole thing offline for nine months, you aren’t in the hell of trying to fix something while it’s completely broken. It’s still a fire drill, but you are no longer inside the building that is burning to the ground.
It’s 2013. We know a lot more about building complex software than we did in 1980. So we should stop using approaches from the 1980s, admit failure when it happens, and hit reset. Doing a “tech surge” will only end in more tears.
I love getting post board meeting emails that are retrospectives from execs in the meeting. This one came a week ago from Jeff Malek, the CTO and co-founder of BigDoor. They’ve been on a tear lately and are in the process of a massive set of Q1 launches for new customers.
We had a solid board meeting, but I suggested they were being too casual about a couple of things, including communication about what was going on. This is NOT a casual group and I knew using the word casual would press a few buttons. And they did – the right ones. Jeff’s retrospective is awesome and he was game to have me share it with you to get a sense of what’s inside a CTO’s head during and after a board meeting.
I have a retrospective addiction. But as a result of looking back at our meeting today Brad, words like ‘casual’ still ringing in my ears, I recognized I’d let some of my own assumptions drive away potential opportunities, maybe even creating some problems along the way. I’ve always run under the assumptions that :
- your inbox is an order of magnitude more onerous than mine (quite)
- the best way to respect and value your time would be to limit email/communication
- you and Keith have regular communications complete with bits about what I’m up to and thinking
- you know even in the absence of communication from me that I’m working like a madman, doing everything I can to make it happen
- you also know through some process of osmosis how much I value you, Foundry, your approach, feedback, etc
Just so you don’t get the wrong idea, it’s not that I took your feedback and concluded that I needed to give you more BigDoor insight, or that you needed more info in general to get a better picture – that’s what the numbers are for.
So while all of the above assumptions are probably true to some degree, here’s the new protocol I’m going to start optimistically running under:
- thanks to your candor and aversion to BS, you’ll tell me to STFU as needed
- you’d like a concise ping about whatever, whenever from me
- you’ll give me feedback if/when it makes sense to, and I won’t expect a reply otherwise, unless I’m asking a direct question
- doing so is likely to benefit both of us, one way or another – hopefully more candid feedback will ensue
- you know that I value your time highly, and mine specifically in the context of devoting most waking hours to making BigDoor a success
- you know that I am incredibly grateful to know you and have you as an investor
Those are my new assumptions. I felt like giving this topic some time and thought, glad I did, will keep it (mostly) short going forward but hopefully you know a bit more about where I’m coming from, out of this.
Thanks again for the time today, I thought it was an awesome f-ing meeting. I always leave them on fire.
As Finance Fridays continues, we are introducing the concept of the Cap Table. We recognize that we are still at the very early basics stage, but as we are taking a case study approach to this we feel like we have to set up all of the pieces before we get into the messy guts. Hopefully you are staying with us and finding this useful – feedback welcome!
Jane and Dick, our fearless cofounders of SayAhh, have set up an accounting system and created their first set of financial statements. This week they set out to create their cap table and hire a CTO.
The founders each have common shares that will vest over four years. The vesting schedule protects each of the co-founders in case one gets hit by a bus or decides to drop the project after a short period of time. Also, there is an important tax election called an 83(b) election that they made which allows them to recognize and pay taxes for very small income of the value of the shares. Later, if they sell, the low tax basis and capital gains tax rates result in a lower tax liability than if they didn’t file the 83(b) election.
Equity is split 55% and 45%, but where is that officially recorded? It is not in the three primary financial statements (the Balance Sheet, Profit & Loss, and Cash Flow Statement.) Rather, it gets recorded in a document called the Capitalization Table (or “Cap Table”), which shows the ownership stake each person or entity has in the business.
Below you can see Jane and Dick own 55% and 45%, respectively. As first time entrepreneurs they did not create an employee options pool; we’ll fix that in a little while.
Jane and Dick want to bring in their friend Praveena as CTO, but they don’t know how to structure the compensation. They come up with two options:
- Hire Praveena as an employee and offer her stock options.
- Bring Praveena in as a founder and offer 10-20% of the company as stock.
The benefit of hiring Praveena is they think they could keep more equity and control of the company. But, Praveena hails from the land of big paychecks and is not ready to leave that without considerable equity. With the funds Jane and Dick have, a big salary is not possible. Praveena wants to invest $20,000 and get 20% equity.
After several discussions (and more beer), Jane and Dick agreed with Praveena to bring her on as a cofounder where she invests $20,000 and also gets 15% equity. Praveena is just like the other two founders, where her equity will vest over 4 years. Time to update the cap table.
When you read the cap table, think of it as a series of events that add new columns to the right. Now there are two events: the initial issuance of founders common shares, and then issuing new founders common shares along with creating an options pool. In this manner, you can see both the current equity distribution of the company, as well as historically what the equity holdings looked like.
If the full pool were to be given out, the dilution is fairly significant to the founders. They would own from 55% and 45% down to 36% and 29%, but until options are exercised they are not diluted. Jane and Dick contemplated a small option pool because they had read about the risk of an option pool shuffle, but ultimately decided to make it 20% based on feedback from their friend Josh, a Boston-based venture capitalist.
Our (now three) co-founders begin building out their product. The co-founders have savings to live off of and cash will be conserved by not having any salaries. Next week we will fast forward to when they have a beta product and they build a model to pitch to investors.