This past Saturday, a group of fans and aspiring creatives of all kinds gathered together in the basement level of Silicon Valley Comic Con. Outside this room, the convention bustles noisily with costumed characters, video games, and the murmur of human voices. Inside it is a rather drab and gray setting for one of the most prolific and influential creators in the comic book industry, who incidentally, is running just a few minutes late.
Michael Golden is probably best known for creating the X-men character “Rogue” while at Marvel, but his comic works also include “The ‘Nam,” “Micronauts”, “G.I. Joe Yearbook”, “Dr. Strange”, and much more. His diverse commercial portfolio ranges from Nascar to Nasa, to Universal and Warner Brothers. In a few moments, the man himself approaches the stage. I suddenly recall that a wizard is never late, nor is he early, he arrives precisely when he means to.
“Rule number one is: people are stupid,” Golden says in his deep voice that is both gravel and soft butter all at once. This is not a man that wastes a lot of time in coming to his point. He is older, gray-bearded with glasses, and firmly clutching a Starbucks cup in his right hand. He smiles knowing that he has hooked us with surprise and continues, “Whoever you are trying to sell is ignorant of your story, and it’s up to you to give them the information. Make it dramatic, concise, involving, and understandable. People get bored easily, and they don’t come back.” There are only two explicit rules for success, apparently, and the second is a rule of no rules. “You hook them by sticking to who, what, when, where, why, how.”
At the age of 65, with a career spanning over 40 years, Golden’s longevity in this industry is unusual. “This industry will chew you up and spit you out,” he says. He credits his ability to stay ahead of the twenty-somethings to his discipline to keep learning and stay productive. “With commercial work, you no longer have the option to be in the mood.” A typical work day starts at 4:00 AM and ends at 8:00 PM. Golden forces himself to restrict creative work to the early part of the day. “By around 2:00 I really start to slow down. By 8:00 PM I am done, tired, wasted, and needing a drink.” He used to take Saturday and Sunday off without fail, but thanks to the Internet, Golden now works seven days a week.
When asked how he learns and draws inspiration, Golden says that he learns by doing, but he admonishes the audience to do as he says and not as he does. “Learn everything you can, go to school. Learn design, learn layouts, and learn color theory. There will be plenty of time later for Photoshop and Illustrator. Technology is just a tool; it can’t make you great.”
Although he does not say this, I start to realize there is something else going on here too. It is evident to me that, from his full work schedule to his penchant for learning and problem-solving, Golden is immersed in his work. You begin to get the sense that his favorite part of the day is in the pure flow of the creative process. This seems like it could be the real secret — being in love with your work — even after years and years.
Of course, being uniquely talented and globally recognized probably helps in the love-your-work department, and it may even account for some of Golden’s lack of burnout. But you can hear the underlying truth tinged everywhere in Golden’s story. Talent is only part of the equation. Success came after a lot of sweat, dedication, discipline, hard work, and long hours. “There is no formula!”, says Golden
Building marketplaces is hard, just ask Bill Gurley of Benchmark about the complexity of identifying good opportunities for marketplaces in the Internet economy. This was further evidenced today when I received a little email hand grenade from the CEO of Upwork, a leading online marketplace for freelancing.
In the wake of the ODesk-Elance merger, Upwork is inflicting a higher “Upwork tax” on customers and freelancers for the overwhelming majority of jobs, and is also levying a new financial processing fee. At the same time, Upwork is also lowering fees on higher dollar transactions, and introducing a processing fee.
Here is how Upwork CEO Stephane Kasriel’s explained these changes:
We help you build your business by acquiring clients, helping you connect with the right opportunities, and providing services like payment protection. On small projects, the costs we incur outweigh the fees charged; because they aren’t profitable, we haven’t been investing in growing the number of these projects. At the same time, client relationships that result in larger, repeat projects incur fewer of these costs because of the trust that’s been developed, and we want to pass those cost savings back to our users. – Upwork CEO Stephane Kasriel
I did have a good laugh at that. For those of you who not well versed in deciphering the charismatic double speak of startup CEOs, please allow me to translate: You need us. We see no reason whatsoever why Fiverr should be allowed to make 20% of client money while we make only 10% for same size transactions. Therefore we are increasing our prices because, frankly, we can. We are under pressure to make more money. This is a carefully calculated risk we think we can take because the market for freelance work is growing faster than we can count dollar bills.
What I found interesting is that this change highlights the fragility and complexity of marketplace revenue models. Marketplaces like Upwork are fundamentally middlemen. Middlemen exist in markets where they lower transaction costs for buyers and sellers. More specifically, middlemen exist when their fees are lower than the corresponding costs of buyers and sellers who transact with one another directly. These models begin to break down when their fees approach direct transaction costs. If you are a middleman, determining the true direct transaction costs between buyers and sellers is pretty important, since it determines in part whether or not buyers and sellers transact business with you instead of each other.
So what are the direct costs to freelancers and their clients, and how does Upwork know that the low end market will bear these higher fees? I am sure there is one hell of an Excel model at Upwork HQ, but one clue is the pricing of competitors. Upwork must believe it can charge as much as its competitors in the low end of the market. That might be a dubious assumption. Competitors like Fiverr have optimized the user experience for the low end transactions. These jobs are just harder to do on Upwork, period. By raising its prices in the low end of the market, Upwork opened itself to any competitor willing to step in and deliver a slightly better experience at Upwork’s old price. Why lower any barrier to entry at this stage of the game?
Which brings us to the really big strategic play. Upwork is betting that its future is to be the premier marketplace for large freelance projects. Obviously, the cries from larger clients that Upwork’s 10% fee was already too expensive did not fall on deaf ears. By lowering its fees to 5%, it believes that it can further disrupt traditional suppliers of short term talent. These include recruiters, temp agencies, and small consulting firms. Temp agencies have profit margins ranging from 1.4% to 8.8%, with the industry average being 5% according to the latest report from Barclays. Upwork is betting that it can disintermediate these existing middlemen by further reducing friction for buyers and sellers. If this strategy is successful, then Upwork probably secures its exit through one of these suffering middlemen. Pretty smart, and pretty risky. I like it.
I am a big fan of freelance marketplaces, having sourced many thousands of dollars of work on projects ranging from software development, writing, advertising, and even illustration for a children’s book. Given the usability friction for low end jobs on Upwork, I’ll probably just use something else for these jobs from now on. However, now I see no reason not to float much bigger contracts to Upwork in the near future now that the fee is 5%. I get the feeling that this is exactly what Stephane Kasriel would want me to do.
When I first started my business in the fall of 2008, I was faced with a classic founders dilemma. What type of entity should I incorporate, LLC, C-Corp, S-Corp? There are hundreds and thousands of articles with mediocre advice regarding the various tradeoffs of these entities. In this article I will share some real world experience with you creating my company 2008, and how our entity decision impacted us much further down the line. Before I go further, understand that I am not an attorney, and I am not licensed or qualified to give legal advice. Please consult with your attorney before making decisions like this one.
On day one, I chose a Delaware limited liability company. The incorporation was fast, inexpensive, and easy. As the business grew, I brought on a partner to be my CEO. We hired some of the best legal counsel in Silicon Valley, who quickly informed us that we would want to convert to a C-Corp to formalize our partnership and raise institutional money. It was explained to us that this was the preferred entity type for institutional investors for a lot of different reasons, but chief among them was the tax structure of the various VC funds. This was good advice, but I wish we had not followed it.
When we converted the LLC to a corporation, we promptly set about raising funds through a convertible note. Once we had money in the company, we quickly got down and dirty with building our new business. Ultimately we were acquired by another startup in 2011. This is where our choice of entity selection began to bite us. Our acquirer wanted to purchase our assets and not our liabilities. We entered into a purchase agreement where the acquirer gained our assets in exchange for preferred warrants. That meant that our company would go on in perpetuity with no assets other than the warrants.
One of the purported advantages of C-Corps is that their shareholder rights and governance are defined by statue, where as member rights and governance of an LLC are defined by an explicit agreement between the members. The problem with a C-Corp comes when, for whatever reason, you are unable to afford legal counsel to advise you on the statutes in question. Another problem is that C-Corps come with a lot of formalities with respect to keeping records, board and shareholder meetings, and other governance issues. These are all things that you need to stay on top regularly to ensure that your entity is in good standing and your liability is limited. But what happens when the music stops?
Now we had our C-Corp with no employees, no cash, and with no purpose except to serve as the holder of those preferred warrants for ourselves and our investors. We ended up making a subchapter S election to give pass-through treatment of our profits and losses. The accounting required for such subchapter S-Corps has many more complicated than that of an LLC. And, for two years we had to keep going right along with shareholder meetings, keeping minutes, and making resolutions. For two more years, I had to keep filing corporate tax returns, and keeping the entity in good standing with the State on the chance that we might need to liquidate the warrants and distribute the proceeds. Fortunately our acquirer was also acquired within two years. But what if I had to keep going with that process indefinitely?
What a nightmare.
In hindsight, we would have been much better off by keeping the LLC structure and amending our operating agreement as needed. The LLC afforded us a very simple and flexible structure, one that was easy to understand, and one that was very cheap to maintain. The costs and formalities for maintaining and governing LLCs are extremely limited. We could have delayed the C-Corp conversion to the point where we had a committed institutional investor who was demanding it. Or we might have been able to make an IRS election to be treated as s a corporation.
We went through the whole entity lifecycle, from LLC, to C-Corp, to subchapter S-Corp with one and the same business. In other words, we ended up back where we started, but with a lot of added complexity and expense. Seven years later investors and their counsels seem much more comfortable with the LLC entity. There are plenty of good boilerplate agreements you can modify suit your needs.
For this founder, the next entity decision will be easy.
A few weeks ago I was having lunch with a friend who half-jokingly asked me if I was ready to retire yet. I half-jokingly quipped that I was well past the age of “fundable” established by Silicon Valley venture capitalists, and would therefore be relocating to Puerto Rico in the near future. Jokes aside, ageism in the technology industry is a real phenomenon, and these perceptions are unfair on two counts. First, venture capitalists with any common sense do in fact frequently fund entrepreneurs of all ages, although there are more than a few seemingly without any common sense. Secondly, productivity and age are not correlated, but productivity, health, and wealth and probably are.
I took a wager with my friend that a cursory analysis of famous inventors would show no correlation of age to productivity. I wanted to minimize the distortions of the modern market on intellectual property, so I just took the first few off the list of famous inventors from the last century. I cannot claim that this is scientific or fully conclusive, but I do claim that someone owes me $20. The data is actually a little difficult to find because the USPTO database is not searchable before 1976. If someone wants to do a complete analysis of the famous or prolific inventors of the last century, I would be willing to reward you with the proceeds of my $20 wager. Suffice it to say that you would be unwise to “hire young” as some people have suggested, even if you were comfortable with breaking the law.
A headline reads “We gave all of our most boring and tedious work to people we never met, and here is what happened next”. Let me guess: a total failure?
Recently there have been a few rather nasty articles deriding offshore development teams. As an entrepreneur in Silicon Valley I want to set the record straight: Every successful start-up I have been involved with learned how to successfully leverage offshore teams, and several of these companies would not have made it otherwise. Some of the most talented, hard-working engineers I have ever had the privilege of working with were based in India, China, and Russia. Although there are rare exceptions where the model does not make sense, if your software company is struggling to make the model work, in all likelihood the problem is you. If your company cannot leverage offshore teams, your company cannot hire the best people in the world wherever they might be. In other words, you have a serious competitive disadvantage.
The photo every tourist is obliged to take
The reason that many are quick to dismiss offshore development is simple: Creating distributed teams that are productive together is not easy. To help understand why, I reached out to several colleagues who have been very successful building teams in Russia, China, and India, to get their perspective:
“When outsourcing begins, there can issues of confidence and trust” says Rajiv Sinha, VP Engineering, Citrix Systems. Rajiv says that developing mutual respect between development teams is essential. “You have to get someone with a face-to-face presence whose sole function is to represent the remote team. For the people in the home office, this person is the remote team.”
Avinash Agrawal, Principal Consultant (formerly VP of Engineering at Guavus, Gale Technologies) says “total two-way transparency and relentless communication” are the key to creating clear responsibility and accountability between teams. “Offshore teams often suffer from ‘remote site syndrome’, and feel excluded from information and the decision making hierarchy”.
Leaders must “endeavor to create opportunities where offshore and onshore teams get to work closely together”, says Vipin Sharma, Head of India Engineering for a stealth mode Silicon Valley big data start-up. “Regular technical summits and workshops where key team members travel to each others sites can go a long way to boost ‘one team’ spirit and overall efficiency”.
I had the benefit of working with the teams these leaders created, so I know first hand that their advice is sage. To their list, I will add this observation from years of experience: Many companies begin by trying to create a sustaining engineering model, where the offshore team is primarily responsible for bug-fixing and other maintenance. Don’t do it. You cannot hire the best engineers in the United States and relegate them to sustaining engineering, and you should not expect that people are different anywhere else. Talented engineers need hard problems to solve. Give your remote teams ownership, authority, responsibility, and accountability, and you will see results. Perception issues and blame games do arise from time to time, you have to get ahead of those immediately by facilitating communication, and cultivating mutual respect between your teams.
None of this is to say that there are not problems in every offshore jurisdiction. Finding office space in hotspots like Bangalore and New Delhi can be a nightmare. In India there are many cases where people still do not show up on their first day of work after accepting an offer. Competition in tech hotspots means that employees sometimes try to float ridiculous 75% or more pay increases. Language barriers frequently show up in source code. The power goes out frequently, sometimes 2-3 times a day every day. Different countries have a confusing myriad of employment law, intellectual property law, licenses, taxes, and permits. This is all just part of the process of doing business in any foreign country.
Let’s distill this into some clear guidance for creating offshore development teams:
- Representation needs to be formal. The remote team needs a dedicated representative at the home office. Instead of kicking an email over the wall while the remote team is sleeping, this person is always available for face-to-face communication, and up to date on all development status. A senior engineering manager or product management person is ideal, it needs to be someone with incredible communication talent, patience, and persistence.
- Daily communication is key. Teams should be in daily contact at the leadership level, preferably twice every day. It feels ridiculous having to say this in 2015, but get video conferencing running. GoToMeeting is great, and Fuze is wonderful. There are no excuses for not videoconferencing in this day and age. Seeing people, their body language, their expressions, keeps you on the level of human beings instead of keystrokes. Of course, it should go without saying that you should also have a chat system like Slack, where engineers and product teams can communicate instantly ad-hoc. Bug tracking and other collaboration tools like a wiki need to be open, accessible, and performant. Put those babies in EC2 or Digital Ocean with high bandwidth and unfettered access.
- Frequent travel is mandatory. Your team is on the other side of the world, not on another planet. As a leader, you need to get yourself there to meet, plan, and share your vision, strategy, customer success, and customer failure. If has been more than 100 days since your last visit, you are very, very late. There is no substitute for frequent face to face interaction, because too much is lost in written communication, and there is frequently a language barrier to overcome.
- Empowering offshore teams is essential. This is so important that it bears repeating: Hire brilliant people and give them hardest work you have to do. You need great leadership on the ground to hire the best people, so begin your offshore team by finding that leader, and giving them complete authority to make hiring decisions. Set the tone with the rest of the company that you are finding and hiring the best people in the world, and share their successes with everyone.
In the 10 or so startups I have helped build since 1995, one of the biggest challenges we always faced was the “scale problem”. Scale is a problem of success, a great problem you get to solve when you succeed at creating some initial value for your customers. If the measure of a software company’s ability to innovate is the velocity of software creation, then the measure of a web software company’ s ability to innovate includes getting that software through testing, integration, and successfully deployed into production. The scale problem can impact each of these functional areas differently and sometimes in surprising (and interdependent) ways. Often, the resolution of one scale problem simply reveals another previously unknown scale problem, leading to a seemingly unending list of issues and remediation activities.
Over the last 10 years creating value in web software applications, and scaling them up, has become a lot easier. The growth of agile software development practices have greatly accelerated software development, testing, and delivery. At the same time, the advent of cloud services like Amazon, Google, and Azure have reduced the time to acquire and deploy web infrastructure to near zero. Continuous integration and deployment has taken hold as an operations and architecture style, automating test and integration processes, and reducing the overall time between development and customer benefit. Today, software startups can build world-class web applications, scale them to millions of users, and ensure their availability for less money, time, and with employees than ever before.
These advances in scale have not been without tradeoffs, however, and a new set of problems has emerged around development and operations complexity. While the horizontal scaling pattern increases capacity along with the number of application server instances, the difficulty becomes managing the sheer number of application server deployments, along with their configuration and dependencies on other infrastructure and services. This also has severe implications for continuous integration and deployment processes, where functionality often has to be “stubbed out” owing to differences in the production and development environments. While further infrastructure abstraction in the form of platform-as-a-service can improve developer workflows and further reduce operations complexity, these issues are not simply negated by PaaS. As it turns out, many of the startups who initially adopted PaaS have eventually moved on to more traditional infrastructure models as they have scaled, owing to better economics, and increased flexibility to manage problems and make changes. These problems and complexities are at the root of why so many people are excited about containerization, and more specifically, Docker (the de-facto containerization standard for Linux).
One of the major benefits of Docker and containerization is that they enable an architectural style known as immutable infrastructure. In an immutable infrastructure, components of the infrastructure are never modified once deployed, but rather they are replaced by new components generated from a pristine state. For example, in the “old world” of 2008, an upgrade to the Java version across an infrastructure of 1000 servers would require:
- logging in to each server
- downloading the Java release
- installing Java
- restarting the application servers.
To deal with the scale challenge, these steps would be automated through scripting (ssh for loop), configuration management (Puppet, Chef), and other external systems. The problem of course being that this type of process works when it works, except when it doesn’t work, requiring teams to discover differences between systems and environments and recover on the fly.
In the new world of immutable application containers, applications are built in place with their dependencies and configuration. Wherever those containers are deployed, they run with the same dependencies and configuration. Containers are absent infrastructure dependencies, such as hostnames and IP addresses, which are injected at runtime when the container is deployed on a target host. This delineation provides a very clean separation of concerns between the application and the host infrastructure, and ultimately reduces the number of configuration endpoints by orders of magnitude (to just 1).
The benefits for software development are vast. Already, Docker (and others) are working on various new forms of service discovery, in order to solve the infrastructure dependency injection problem, and consequently the “awareness” of dependencies between application components on different servers and infrastructure. This means that in the future, development teams can focus on creating and maintaining micro services, another important scaling pattern for software development process. Micro services are discrete functionality packaged as network-available services, often through REST interfaces, which are completely independent of other services. By leveraging the immutable architecture style, integration testing becomes a matter of deploying the necessary micro services from their pristine state in the repository and executing the test harnesses against the complete system.
For operations, the immutable style provides a means to deploy major releases fractionally, testing them with small portions of the user base before rolling them out across the entire infrastructure. Containers themselves can be automatically introspected to derive dependencies on other containers, networks, storage, and other systems. Rolling upgrades backwards requires merely deploying the previous version of the container(s) in question and terminating the more recent version.
In the last few months there has been a relentless outpouring of new orchestration systems for Docker containers, including Kubernetes (Google), Mesos (Mesosphere), as well as PaaS capabilities from Flynn.io, Deis, and OpenShift (RedHat). As these new tools continue to emerge and mature, all of these developments will ultimately translate to a lot less software startup equity being spent on overhead and lot more software startup equity being spent on creating value through working software that scales.
That is a huge win for start-ups, their founders, their employees, their investors – and their customers.
Here at Dell Cloud Marketplace, we’re creating a new generation of tools to help IT and developer teams compare, consume, and control cloud services. Emerging technologies like Docker and containerization are a big part of what we’re building and we’re excited to showcase some of our progress in the forthcoming public beta of Dell Cloud Marketplace.