The History Channel’s “Men Who Built America” documentary recaps the history of the creation of key American industries: railroad, steel, petroleum, automobile, and finance. Covering a period from roughly 1850 to World War 2 it offers reenactments of key events in the evolution of American business. It’s worth an entrepreneur’s time to reflect on the lives on Cornelius Vanderbilt, Andrew Carnegie, John D. Rockefeller, Henry Ford, and J. P. Morgan.
I got to know Edith Harbaugh (@edith_h) when she was moderating the Lean Startup Circle Group and published two guest blog posts by her: “It’s Your Execution, Not Your Idea” and “Managing Email Conversations With Customers.” I also invited her to take part in a webinar on Innovator’s DNA: Experimenting Skill. During the roundtable conversation she mentioned some lessons learned from a bicycle trip across the United States–I thought to myself, anyone willing to bike across the country is ready to become a technology entrepreneur. So when she emailed me that she had co-founded LaunchDarkly I reached out to interview her. What follows is an edited transcript.
Stormpulse has gone from an idea bootstrapped on founder savings and credit cards, to a project funded by friends and family rounds, to a small business strengthened by angel money, to a company that’s raised “meaningful” capital (our last round was just over $2 million). Here’s what I’ve learned since I’ve been able to leave the ‘drowning and can’t work on the important things’ mode.
Matt Wensing in “What I’ve Learned Since Raising Capital“
Matt Wensing has been bootstrapping Stormpulse since September of 2004 (“What Have I Been Doing?!“) He offers some short thoughts on what he has learned since raising capital and I wanted to highlight four:
Small for the sake of small is as bad as big for the sake of big.
Small for the sake of small is letting the desire for control or other perfectionist tendencies trump everything else.
The question isn’t “Stay small or go big?”
It’s: “Is the vision scalable & worth scaling?”
This is a key insight that most entrepreneurs overlook in their calculations of whether to seek funding. It’s not about whether you need it, it’s whether the plan merits and requires it.
Existential: Walking around the office, hearing other people having conversations that used to only be in my head.
If you want to scale up your business you have to share information and context and allow other members of your team to be able to have an informed discussion with you about risks and issues. And ultimately to have some of those discussions without your participation. As Hugh MacLeod observed, “scaling your business is all about having more people solve more problems for you.”
Define a great box by defining where to play and how to win; encourage in-the-box innovation.
To harness the team’s creativity define the business model and key objectives and let them experiment and explore strategies and tactics to accomplish them.
I think the key breakthrough he made was the realization that his clients didn’t want a weather map they wanted actionable suggestions predicated on an analysis of what they could do to mitigate risks against an identified asset base. He was selling against “the hapless weatherman outside in the hurricane” but it wasn’t his real competition. In December 2013 he rebranded it “Riskpulse” with the following goal:
Stormpulse Inc. becomes Riskpulse in response to customer requests for deeper risk management solutions. Because Stormpulse had a history of integrating disparate data sources and tracking rapidly-shifting factors in weather for business continuity professionals, it was uniquely positioned to develop a broader system for the whole supply chain.
Steve DiBartolomeo is co-founder of Artwork Conversion Software, Inc., an EDA software firm headquartered in Santa Cruz CA with a development office in Manhattan Beach, CA. Founded in 1989, the company develops CAD translation programs, CAD viewers, plotting software and IC packaging software. Artwork has over 5000 customers worldwide including Alcatel, AMD, Applied Materials, Agere, Bosch, KLA Tencor, Motorola, Ericsson, General Electric, Hewlett Packard, Hitachi, Lockheed Martin, Siemens, Seagate, Sony, TRW..
Q: Can you talk a little about your background and how you came to found Artwork Conversion Services?
I have a BS/MS in Electrical Engineering from UCLA (1978). My founding partner, Antonio Morawski, has a BS from Loyola and a MS from UCLA from around the same time period. I cut my teeth at TRW Semiconductor in Southern Calif starting in 1976 as a student. When I graduated I continued on there until 1980 as an RF design engineer, as did Antonio–we met at TRW.
I took a year and a half off of work and went back to college (UCSB) until I ran out of money and then in 1982 joined Avantek in Santa Clara as an international sales engineer. In 1984 my boss asked me to join a startup, Step Electronics, that would specialize in high tech import/export selling microwave and RF components and subassemblies. One of our first clients was a small software start up, EEsof, which pioneered microwave EDA on PCs. (Prior to that microwave design software ran on a $250K VAX and cost $50K – EEsof’s ran on a $5K PC and cost $7500.) I spent much of the next years selling EEsof tools in Europe (where I lived for a year in 1986) and then later in Asia.
In 1986 I needed a translator for a pattern generator in order to close a large EEsof sale in Germany. EEsof could not do it. I mentioned this to Antonio and he said he knew how to write such a translator. We took the order and delivered it 6 months later.
In 1987 I returned back to the US and tried to sell more pattern generator translators in Silicon Valley. The companies that I contacted were not interested in our translator but had lots of suggestions as to what they did need — so we slowly developed new products (on a part time basis) based on their feedback. At that time (between 87 and 89) Antonio was employed as a consultant at TRW and as a professor at Loyola. He did the programming out of a corner of his small garage.
Finally in 1989 we decided to do this full time. I left Step (which had really been an excellent apprenticeship for learning how to run a small, lean operation) and Antonio left Loyola after completing his teaching contract.
Our primary reason for starting the company was to be “masters of our own destiny” and to work on stuff that was interesting. We really only wanted to make enough money to cover our mortgages and live a reasonably comfortable life.
Q: So what were the early days like?
Between us we put up $10K each and started with that (and two years of experience and a few customers and orders in the pipeline). As mentioned, our largest initial purchase was two fax machines (at $1500 each) and a copy machine ($3000). I worked out of a 500 sq foot office in Santa Cruz and Antonio continued to work out of his garage in Manhattan Beach. We broke even from day one even if the monthly salary was small. Eventually we added a secretary and a programmer and Antonio moved from his one car garage to his father’s two car garage.
I handled all the sales which were almost 100% from Silicon Valley. I basically drove into the valley several times a week and installed and demonstrated the software. I also did tech support, marketing, technical writing … basically everything except programming.
We added employees one at a time and grew slowly but surely.
At the time we started (end of 89), the business we knew best — RF and Microwave components and design — was taking a tremendous hit; the giant build up of the early and mid 80’s (due to Reagan’s military budget) was over and an enormous consolidation was occurring. I’d call an engineer on a Monday to make an appointment and by Friday he’d be gone.
There was not yet any Internet and even cell phones were a tiny market. Things looked especially grim because no one could envision what was going to drive new designs. But somehow we ground through the first couple of years — not making much money but not losing any either and slowly adding a few products every year.
By 1995 we grew to a peak of 14 people – 8 programmers, 1 sales guy, 1 boss (me) and 3 office people. Our maximum revenues peaked at about $3 million dollars in the late 90’s.
Business took a major downturn in 2001 what with the dot-com crash which killed a whole bunch of network and chip startups that were buying our tools as well as hurting just about everybody in the tech business. I recall our shipments dropped 40% one month and stayed down for 18 months before slowly building back up again. By 2004 business was excellent again. Things stayed pretty buoyant until 2007; from that point on it seemed to drift down gradually and, of course, at the end of 2008 the downward drift became disturbingly steep. Most of 2009 was pretty awful and it was not until early 2010 that we saw the green shoots of a recovery.
Q: Where are you today?
Today we are 10 people (7 programmers, 1 sales guy, 1 boss and 1 office person – the internet nature of business no longer requires production of software other than a click). Our goals are not high growth but rather a good profit margin. As a software company we have zero cost-of-goods and the great majority of our expenses is salary. So once you are past “break even” everything after that is profit.
Q: When you look back over the last two decades or so what are the accomplishments that you are most proud of ?
We are very proud of having kept the company going for over 20 years completely on our own. We didn’t borrow a penny and every quarter we showed an operating profit.
We made several major market and technology shifts during those 20 years that kept us going:
- We started by building software for RF and Microwave designers.
- We branched into software directed at PCB designers.
- We branched into software directed at IC designers (back end).
- We moved from translators to display software (viewers).
- We moved from direct sales to end users to OEM sales to other EDA companies.
We have seen many other EDA and technology firms try to change direction, usually in response to major changes in technology or the market that either died or were badly injured in the process.
We were early Internet and web adopters and this enabled us to expand our market from just Silicon Valley to worldwide without a large sales force.
Q: What’s been the biggest surprise?
I think it was more of a gradual realization: most EDA entrepreneurs start as EDA users, run into problems doing their job, come up with a clever solution and are suddenly find themselves an EDA supplier. The surprise comes some years after you are an EDA supplier–you have stopped designing stuff and find that you no longer really understand the “problem” side of the equation and have to pester people to tell you about what problems they need solving. However this reliance on others for your critical input is never as reliable as your own (past) understanding of the problems that need solving.
Q: What were the significant changes in the environment you have had to respond to?
The internet changed everything. We jumped on it early and have benefited from our ability to be everywhere in the world from our desks in Santa Cruz. Nowadays I think WEBEX (and the other screen sharing apps) is one of the seven wonders of the modern world.
We realized that we needed to change from direct sales to OEM partnerships in the late 90’s because the big kahunas–Cadence, Mentor and Synopsys–started sucking the air out of the EDA markets. They each wanted to be all things to the customer and cut the kind of deals (we call them all-you-can-eat) that would cut off any other vendor. So we changed our focus to selling into the big EDA companies with small modules that enhanced their products.
Q: What’s the current challenge you are wrestling with?
Design is following manufacturing offshore. We’ve seen this accelerate since after the dot-com crash. It’s a lot harder for a small US based company to cover Taiwan, China, India and Singapore. The big guys set up design and application center’s in these countries.
Q: Any suggestions for other entrepreneurs who want to bootstrap a software business?
If you want to run a company you can make a living from–in other words you are not writing a business plan where the exit strategy is on the first page–then I think I can make a couple of suggestions.
- Start with a small team with common values and complementing skills – in our case Antonio was the programming guy and I was the sales/applications guy.
- Don’t take any more money–none if possible–from outsiders than absolutely required.
- Create something small and simple and quickly get it out there. You’ll get much better and faster feedback than if you try to go around asking people what they want.
- Refine it based on feedback. Document it. Do it again.
- Grow slowly. Fast growth is very inefficient since you will then have a lot of people on board that have not figured out their job.
- Staff or employee turnover has a high hidden cost since the replacements have to start over.
- Cash is king. Save some of your profits as a cushion against a rainy day.
- Spend a lot of time listening to your customer’s problems. Not every problem is one you can or should solve, but the aggregation of their issues gives you a solid base for making seat-of-the-pants decisions. You’ll never have enough information to make a MBA-style decision on new products or directions. But if you’ve listened to enough customers you’ll have a good “feel” and make better decisions.
- Beware of business plans. Have a look at some business plans that are 3-5 years old of both successful and unsuccessful companies. You’ll have a good laugh at both. The main difference between the successful companies and the dead/dying ones is how they reacted when their assumptions blew up.
Finally and most importantly: people can say one thing and do another. Only act on what people tell you if you see that their behavior is consistent with their talk. People are much better at telling you what they don’t like than at what they want. When we are developing a new product we try to get something into their hands quickly and then listen to them criticize it. The criticisms are usually much more specific and useful to defining a product.
Q: Steve thanks very much for your time.
Matt Oscamou, the founder of Frontier Bites, talked about lessons learned getting a food startup off the ground at the April 15 Bootstrapper Breakfast in Sunnyvale. Here is a short recording of his introduction, the benefits the Bootstrapper Breakfast® has offered him, and how he came to bootstrap Frontier Bites with his brother and persevere after his brother passed away in a rafting accident.
A transcript of his introduction is available at Matt Oscamou talks about founding Frontier Bites, recap from April 15, 2014
Matt Oscamou: I have a food company in Silicon Valley, bucking the tech trend. I was over at Red Rock Coffee working in the downstairs area and I saw “Bootstrappers Breakfast” on the calendar so I figure I would try to find out what that was. This was right when I was getting going. It’s been a helpful group ot bounce some ideas off of. My attendance has been relatively sporadic based on the needs of the business. It’s been good.
I started the Bootstrapper Breakfasts in Sunnyvale in October of 2006. I was fed up with attending events where the only focus was on how to raise money from investors and where aspiring entrepreneurs would talk about what they would do once they raised money but not what they were doing to move their startup forward now.
One of the things that surprised me in the first year was that people would come for a variety of reasons. Some would attend regularly, others would come only once and a large fraction would attend when they had issues that they wanted to discuss. I thought Matt captured that neatly in his intro.
I didn’t know Leonard Smith but I was forwarded a link by John McKenna two days ago to his obituary (originally published in GreenwichTime on Jan. 26, 2014) and I thought it captured the essential personality of people who bring change to organizations in trouble and often start new ones.
Here are some excerpts but it’s worth reading the whole thing (I have bolded a few sentences that highlight key aspects of the entrepreneurial personality):
Leonard Mason Smith, 86, a veteran of World War II and Korea and longtime resident of Pine Island, Florida passed away on November 27th, 2013.
Leonard Smith was a very private man. If you wanted to know his cause of death, he would have told you that it was none of your business. If you asked Penny, his beloved wife, she would tell you that he had cancer, but not to tell anyone. Although his prognosis was dire, he battled on, lived his life and survived several years beyond the experts’ expectations. He did not want his obituary to suggest that he lost a long battle with cancer. By his reckoning, cancer could not win, and could only hope for a draw. And so it was. Leonard Smith hated losing.
He matriculated at the Massachusetts Institute of Technology, where he was president of the Phi Kappa Sigma fraternity and earned an engineering degree. He joined the Army Air Corps after his first term at M.I.T., and attained the rank of colonel, but only on the telephone when facilitating personnel discharges and equipment requisitions. He was discharged as a private. After his graduation from M.I.T., he enlisted in the Air Force during the Korean War, and served in Japan and the Philippines. After the war, he began a career as a management executive. He worked for Bamberg Rayon Company, American Enka, Union Carbide, General Dynamics, Cognitronics and Computer Transceiver Systems Incorporated. By virtue of his education, training and temperament, his assignments tended to be companies and divisions that were experiencing financial or operational deficiencies. He liked the challenge.
He was married to Penelope Self on December 4, 1953 in Asheville, North Carolina. They were married for 58 years until her death in 2012. They raised five children together, living in New Rochelle and Greenwich, Connecticut. After retirement, they resided in Asheville and Pine Island, where they were active with local church groups and charities.
Leonard Smith hated pointless bureaucracy, thoughtless inefficiency and bad ideas born of good intentions. He loved his wife, admired and respected his children and liked just about every dog he ever met. He will be greatly missed by those he loved and those who loved him. In lieu of flowers, the family asks that you cancel your subscription to The New York Times.
Leonard Smith would have thought that this obituary was about three paragraphs too long.
- Willing to take on long odds and challenges.
- Understands how to navigate and negotiate around bureaucracy.
- Not afraid to address financial challenges and operational deficiencies–growing companies break what’s working as often as mature firms are faced with the need to address changes in their environment.
- Guided as much by outcomes as intentions.
- Interested in more than business: committed to family and active in the community.
- In writing, get to the point quickly.
This is a recap of the Silicon Valley Code Camp panel of startup founders who explored what’s really involved in getting a technology startup off the ground in the “Working for Equity Startup CEO Panel.”
There are a number of forms packages now available for entrepreneurs that provide templates for incorporation, investment term sheets, hiring employees and contractors, etc.. And there are several business model canvas tools that are designed to facilitate useful discussions among founders and advisors (and potential investors) about a new startup. But Nathan Beckord‘s Foundersuite is the first to offer not only forms but facilitate workflows and communication among founders, advisors, prospects, investors, and other interested parties.
I used the idea validation module for the BeamWise planning and launch and found it helpful. Nathan is a friend but I am not an investor or otherwise affiliated with Foundersuite. I think it can make you think and save you time if you are in the early market exploration stages of your new startup.
Many of us in Silicon Valley seek either to found or to be an early employee at a technology startup. If you aspire to create a startup come take part in a conversation with four startup founders about what’s really involved in leaving your day job and striking out on your own or with partners. The startup founders range from serial entrepreneurs to first-time CEOs, they will share their vision, drive and passion as they discuss the nuts and bolts of following their dreams to building something that will change the world.
Please Register for Silicon Valley Code Camp and indicate your interest in the session, this determines the size of room we will be in. We have had some great discussions not only among the panelists but with the audience–more than half the time for the session is allocated to questions from the audience–so please let us know if you plan attend so we will have room for you. There is also a Mobile Session Viewer And Planner.
While I think our panel is one of the better reasons to attend Code Camp there are another 232 sessions offered by experts and practitioners that cover a broad range of topics of interest to software engineers. Code Camp takes place all day Saturday October 5 and Sunday October 6 on the Foothill College campus at 12345 El Monte Rd, Los Altos Hills, CA. The “Working for Equity” panel takes place on Saturday October Oct 5 at 1:45.
For more information on earlier “Working for Equity Sessions” see
- Recap of Working For Equity CEO Panel at SVCC 2012
- Slides from Working for Equity Panel at SVCC 2011
- Sean Murphy to Moderate Panel on “Working For Equity – The World of Startups” at Silicon Valley Code Camp 2010
- Work For Equity Panel Set For SVCC 2010
Theresa Shafer met Ari Halberstadt at a Bootstrapper Breakfast in SF earlier this year and was very impressed with his approach to his new startup, Catalee. Ari volunteered to talk with me about Noam Wasserman‘s “The Founder’s Dilemmas” as well as Catalee. Here is a 12 minute podcast and transcript of our phone call.
Or download AriHalberstadt130404b (MP3) 12 minutes.
Sean Murphy: Sean Murphy here with Ari Halberstadt. We’re talking about Noam Wasserman’s “The Founder’s Dilemma” and Air’s new startup, Catalee. Ari, do you want to take a minute to introduce yourself, tell us a little bit more about Catalee?
Ari Halberstadt: Catalee is a startup that will help people improve their use of energy, basically reduce the use of energy in existing buildings and save people money at the same time. I’m looking at residential customers and, initially, small commercial market. These are markets that are somewhat underserved but they are quite large. There’s a large number of buildings and they tend to use energy quite inefficiently. Saving can be quite significant, cost effectively. But there are a lot of barriers to getting it done and I aim to streamline that process for the customers.
Sean: We’ve been talking about Noam Wasserman’s The Founder’s Dilemma. I was going to read a little bit from a short passage on page 331 that I thought captured the essence of the entrepreneurial journey. He says,
“The path from founding to success is a long and winding one with dilemma after dilemma forcing founders to make decision after decision all with the important, and sometimes surprising, short-term and long-term consequences.”
He elaborates on that, a few pages later, and says,
“At each fork in the road, the decision that maximizes value tends to threaten the founders control and vice versa. There is inherent conflict between maintaining control and building value in high potential startups because the latter requires value added players who demand more control.”
At this point, you’re actually looking for cofounders to help you bring Catalee to its full potential. Is that fair?
Ari: Yes, that’s right.
Sean: Can you talk about what you’ve accomplished so far, what the next milestone is you’re aiming for, and where you’re looking for help?
Ari: I’ve looked at the market, and I’m working on approaches that I think could help consumers streamline this process as well as provide potential investment opportunities. I really need to turn that into a testable product, something that is a minimally viable product as well as find some customers to start using that. I’m really in that transition from idea phase to actually having a product out there. That’s basically where I am right now, and I need people to work with me on that process.
Sean: When you look at this market, the clean tech energy-saving market’s been around for a while. I think that there’s a general proof of need. What led you to focus in particular on residential and small business?
Ari: Those are very large markets. The residential one is the largest, particularly the single-family homeowner, where you actually have a person that owns that property and could make decisions. It’s quite heterogeneous.
There are a lot of people out there who are at times neglected. Large companies that can come in and help a university or a hospital set up their energy efficiency have been less interested in helping make it simpler for homeowners to access those resources. There’s a very large market with a lot of potential savings.
The small commercial firms represent a smaller market. It’s still a large number of buildings in the commercial sector, but it also has similar needs to home owners who face challenges finding the right services to get energy efficiency projects implemented. Some of the smaller businesses tend to be quite energy intensive.
Sean: As you think about how your first offering is going to be both minimal but somehow differentiated from what’s out there, what do you see as the key difference or the two or three key differences between what you would offer and what’s already available to the homeowner or the small business owner?
Ari: First of all, it would be simpler. The homeowner would not need to spend a lot of time trying to figure out certain attributes of their property. We would also not require too much hands-on, up front, from contractors. The service would actually predict in advance what the energy savings could be for a property. That would help to save time and streamline the process.
It would also lead people through the entire process, which right now is so fragmented that people will try to upgrade and sometimes just give up. It can be a cumbersome and confusing process: I’ve spoken to people who just gave up because it’s too hard for them to go through the hassle when they don’t don’t see the benefits.
Catalee will connect homeowners with the resources, the people, the products, and the services that can help them: there are contractors, there’s financing available as well as incentives that can be hard to actually get sometimes. It’s so fragmented.
Sean: So in terms of the full product road map, that comes into play even more? You’re looking both for an insertion point and then a way to build out a much richer system beyond that?
Ari: Yes. I’m looking to interact with the entire system of home building performance. There are existing systems out there, but I want to connect them more efficiently. One of those would be a contractor. Another is the finance, which actually would have an opportunity for investment in these kinds of efficiency gains which, currently, it’s hard for them to access.
It’s actually a system that can be addressed more holistically. By doing that, you actually unlock a lot of additional opportunities.
Sean: When we talked earlier you felt that your top three strengths were technical software development, an understanding of the science and an ability to look at the problem as a system. Do you want to elaborate on that a little bit?
Ari: I have a background as a software engineer. I’ve worked in that field. That helped me see the utility in how software can analyze the information. A lot of this problem is an information problem. People don’t have the information. It’s necessary to analyze the opportunities available. There are actually tools out there, but they’re cumbersome to use. I can look at these things and say, “We need to put these things together.” Software is a way to do that. I have a background as a scientist. That gives me some understanding of scientific processes and thinking. In terms of the system, I look at the problems as interconnected components, not just one small element that often people might try to address.
Sean: When you look at all the other skills or key skills that are going to be required to build a successful first product, take it to market and close some business, what are the key skills you’re looking for in one or more co-founders to help you get there?
Ari: I need someone with sales experience, how to develop the sales and products. Somebody, more generally, with business, especially somebody with experience in the energy efficiency and energy field, would be very helpful. That’s an area I think I’m a little less experienced in. They would understand how to sell the products and develop the markets.
Sean: So you’re looking for folks that have an energy experience or some contact or understanding how that works? The ability to do more detailed financial analysis, as might be applicable to either a homeowner or a small business? And then, sales and marketing strength to help you actually go to market and close business?
Ari: Yes. Those would be key skills that would be necessary to help the business. I’ve tried to approach the problem from, rather than building prototype software, straight out, I’m actually analyzing the market, getting a better understanding of it. And looking at what existing tools I can start using to build an initial product offering. Or maybe even a service.
Sean: Is that more what they call a concierge or a Wizard of Oz model where you take existing tools and knit them together?
Ari: Yeah, that’s actually something that I’m exploring at the moment to see how I can leverage some of the existing tools. There are actually many tools out there or programs for building performance analysis. But they tend to be one off or building-by-building solutions are very time consuming for people to work with. I’m exploring ways to work with the underlying engines, for instance, to make that more efficient and streamlined.
Sean: Are there any key values you’re looking for in terms of recruiting a team? When you think about shared values or values you’re looking for, what would you say would be one or two key things you would look for in a partner or cofounder?
Ari: The one thing is I’m very dedicated to dealing with is waste of energy that’s leading to climate change. Somebody who shared that kind of a vision would be important, to understand that that’s a key element that’s driving my interest in this business and where the focus should remain.
Sean: At the Bootstrapper’s Breakfast we talk about founder who are looking for missionaries or for mercenaries. So one of the high-order bits for Catalee is you want to have an impact on the global warming problem.
Sean: You’re looking for missionaries.
Ari: Yes, and I think that these markets are big enough that we could actually have a big impact on a large scale.
Sean: Well, this has been very interesting. Thanks for taking part. If folks are interested in contacting Ari Halberstadt they can reach him at Catalee.com
John Finneran recently wrote a postmortem on a startup that aspired to be “the 37 Signals of non-profit software entitled “Fat startup: Learn the lessons of my failed Lean Startup.” My concern is the he did not learn the right lessons from failure.
Q: I was CTO and co-founder of a small technology startup that was recently acquired by a much larger firm. We have a two year earn out that I would like to collect. I see myself as a serial entrepreneur (this is my first successful acquisition but I have founded or co-founded several less successful startups in the last decade) but realize I should probably learn how to thrive in a large firm environment as well. In the next two years I would love to have learned how to operate in a public company and to have a few solid wins where I’ve shifted the acquiring company’s business in a positive direction. Any advice about keeping sane and happy, and making sure I could actually make an impact at the new company.
First of all these are a great set of goals: stay sane and happy and learn how to make an impact in a large firm. Here are a couple of suggestions:
- Attend manager / new manager training: this will allow you to meet other managers in the firm and make connections. It’s also a way to learn the “unwritten rules” of your new employer.
- Ask to be assigned another manager as a mentor for an on-boarding period (60-90 days), with mutual consent you can continue beyond that point.
- Attend the “engineering bagel meeting” or “nerd lunch” or brown bag lunches: if there isn’t a regular (e.g. once a week twice a month meeting where engineers present work that they are doing, offering to help organize an event where folks bring in lunch and can meet in a room or over Webex where one engineer presents some recent results and others can ask questions. Presentation might be 6-12 slides 15-20 minutes followed by Q&A and general networking. Rotate speakers from different groups and teams including your own.
- Attend Miller Heiman sales training or Solution Selling sales training: protecting your budget and “tin cupping” from other departments for requisitions and project funding benefits from sales skills.
- If your company was not the first acquisition seek out other CEO’s and founders whose company was acquired by your firm–whether or not they are still with the company–and ask for a coffee break or quick call to get some advice on what to watch out for and what they have found helped them.
If you missed our “Working for Equity” panel at Silicon Valley Code Camp 2012, Theresa Shafer and the four CEO’s on the panel had a lively conversation about what’s really involved in leaving your day job and striking out on your own or with partners.
For the third year in a row I will moderate a panel of startup founders sharing lesson learned bootstrapping a technology startup at Silicon Valley Code Camp. This “Working for Equity” session will be on Sunday Oct 7 at 9:15am.
Here is the announcement
Many of us in Silicon Valley seek to found or be an early employee at a technology startup. If you aspire to create a startup come take part in a conversation with four startup founders about what’s really involved in leaving your day job and striking out on your own or with partners. The startup founders range from serial entrepreneurs to first-time CEOs, they will share their vision, drive and passion as they discuss the nuts and bolts of following their dreams to building something that will change the world.
- Lenny Greenberg CTO of Assityx, Inc.
Lenny Greenberg is founder and CTO of Assistyx, leading developer of assistive communication products, including the award-winning TapToTalk app that help individuals with physical and mental challenges reach their full potential. A serial entrepreneur, Lenny has led organizations in planning and developing advanced technology-based products.
- Ruoting Sun, co-founder of Temvi, Inc.
Ruoting Sun is co-founder of Temvi, a Mountain View based startup focused on simplifying social discovery. Temvi enables users to easily find, share, and experience cool events that are happening around them, based on their interests and passions. Routing is a first time entrepreneur heading a team of 5 others in creating a mobile app that gamifies social discovery.
- Sam King, CEO of ExpressMango, Inc.
After working as a key contributor to many startups, Sam King co-founded Express Mango, a the social networking appointment system. Express Mango’s online scheduling and appointment reminders reduce no shows. The facebook virtual receptionist helps grow your business 24/7/365.
- Giacomo Vacca, CEO of Kinetic River, Corp.
Giacomo Vacca founded Kinetic River to focus on products and services at the intersection of laser optics, microfluidics and medical diagnostic devices. He earned his B.A. and M.A. in Physics from Harvard University, and his Ph.D. in Applied Physics from Stanford University. His most recent honors are having been elected to Senior Member of the Optical Society of America and to Research Fellow of the Volwiler Society at Abbott Laboratories.
- Moderator: Sean Murphy, CEO of SKMurphy Inc.
Sean Murphy has taken an entrepreneurial approach to life since he could drive. His firm specializes in early stage and emerging market technology companies who are challenged either by new product introduction or the need to diversify beyond their initial success.
Silicon Valley Code Camp is an amazing experience that has improved each of the five years that I have attended. It’s held at Foothill College (12345 El Monte Road, Los Altos Hills, CA 94022) and this year will convent the weekend of Saturday October 6th and Sunday October 7th. There is no charge to attend.
Register your interest in attending Code Camp at http://www.siliconvalley-codecamp.com/Register.aspx
Register your interest in attending the Sunday Oct 7 9:15am “Working for Equity” session at
Panel discussion with three software startup CEOs offering their perspective on the practical realities of starting and growing a company. This session is for both aspiring and active entrepreneurs, it will outline important tips and issues to consider if you are investing your time in a startup. Each panelist will give a 5 minute lightning talk on background and lessons learned, followed by a group Q&A session with the audience.
This will be the third year I have moderated this panel; the last two years it’s been very popular and we normally have a great conversation with the audience after some brief introductory remarks by each panel member.
Silicon Valley Code Camp is an amazing experience that has improved each of the five years that I have attended. It’s held at Foothill College (12345 El Monte Road, Los Altos Hills, CA 94022) and this year will convent the weekend of Saturday October 6th and Sunday October 7th.
Register your interest in attending Code Camp at http://www.siliconvalley-codecamp.com/Register.aspx
Register your interest in attending the “Working for Equity” session at
Here are blog posts about the panel sessions from 2011 and 2010
The following are excerpts from Dan Shipper’s “Why I’m Doing It All Wrong,” a blog post that I found very inspiring.
“Swing for the fences” & “Scale as quickly as possible”
These are fundamental assumptions of startup building. From these come our conventional startup wisdom:
“Leave school” & “Raise money”
For a long time I accepted the “leave school and raise money” argument because I assumed that “swing for the fences” and “scale as quickly” as possible were inviolable tenets of company building. But it turns out they’re not inviolable. They’re not even tenets. They’re just a common way of thinking about how to do a startup.
I’m naturally interested in business. I’m naturally interested in coding and design. I’m naturally interested in writing.
And so my goal is this: to be able to do those things sustainably, for the rest of my life.
Home runs by definition aren’t sustainable. They’re not predictable. Sometimes you hit one, but most of the time you don’t. That part of things is mostly out of your control.
Because it’s out of my control and not sustainable, I’m not focused on it. For that matter I’m not interested in anything that’s not sustainable.
So what can be counted on? Every successful business follows from solid fundamentals. Customers, money, funding. And that’s what I’m concentrated on.
What I’m spending my time doing now is this: learning how to build a real business. And by real, I mean a business that has money coming in the door from day one. Businesses that make money can be started in any investment climate. They don’t go out of style.
That’s why we’re holed up in an office in Philly for $650 a month working 14-hours a day this summer. That’s the goal.
I think there’s a time and place for raising money. I think there’s a time and a place to go for broke. So when I’m asked why I haven’t left school and raised money this is generally my reply:
I’m going to get into the big game eventually. But right now I’m working on perfecting my crossover dribble.
I want to get good at this stuff. And I know that I can do that without leaving school, and without raising money.
I originally posted these on the Bootstrapper Breakfast E-mail list which led Luke Teyssier to comment:
Thank you for a voice of sanity. Dropping out of college to get funding makes about as much sense as dropping out to join a baseball team. A very small few will hit the big leagues, but most would have been better off getting a solid foundation.
Ryan Waggoner wonders if the popularized approach to startups is wrong. Instead of putting health and relationships at risk, try patience and humility.
The following interview is constructed from e-mails and skype calls from February to April 2012 with Arun Kumar of Kerika. See also this video: https://vimeo.com/24502212 and the Kerika blog for more info on Kerika.
Q: Can you talk a little bit about your background
I started off as a Physics major at IIT Delhi, a little too young to make sensible life decisions. After three years, I decided to pack it in and move to the US for a variety of reasons. I ended up at Washington State University where I graduated in Comp. Sci., took some grad courses in Comp. Sci. and business before dropping out of the MBA program to move to NJ to work as a UI developer at AT&T Bell Labs.
After a couple of promotions I found myself a pointy-haired boss at the ripe age of 27, managing a staff of ~40 — all of whom were older than me, which made for an ironic situation since I was supposed to be giving them career advice, so I quit and traveled for a while in India and Europe and then returned to the US to work at a tiny software company in Staten Island that was building state-of-the-art software for handling financial market data in digital form.
I was a manager of all trades: helping to build the business, design products, build teams, etc. I spent 2.5 years completely rebuilding the back-end and front-end systems a German news agency that required a monthly commute to Frankfurt, but that was one of my best projects ever because I had complete business and technology responsibility for a major account. I then spent some time managing the installation of the first digital trading floor in Argentina.
The company was sold to a Japanese conglomerate (CSK) which asked me to help them develop their financial markets business in Asia/Pacific. I spent a year living out of hotels in Tokyo, Hong Kong and Singapore before getting tired of that lifestyle and moving back to the US to become a product manager.
I joined Morgan Stanley in New York in 1995, helping to establish product management processes for their IT department. After a couple of years, I became an E-Business strategist. I moved to London in 1999 to get the European E-business initiatives into a higher gear. While there, the big achievement was putting together a €100MM joint venture with OMX from Stockholm to launch a new pan-European stock exchange (Jiway) that would lower the costs for cross-border trading by retail investors.
I helped create and launch Jiway from scratch in just 9 months. Morgan Stanley asked me to join Jiway after it was founded, to help them safeguard their interest in the JV. Spent most of my time establishing strategic partnerships with the leading banks and brokers in Europe and US to support the new exchange and did a lot of PR (press, radio, TV, conferences, etc. across Western and Eastern Europe).
I decided to move back to the US in 2002 to live in the Seattle area and pursue my own ideas away, from financial services and back in technology.
First attempt to create the Kerika business was 2002-2006. After failing to gain enough traction, I put the company in hibernation and spent a year as a contractor at Microsoft while deciding what to do next. I joined Onvia in Seattle as head of their program management in 2007, eventually ended up managing all their IT and setting up offshore teams, but left in 2010 and decided to restart Kerika, re-imagining and rebuilding the original vision as a Web App.
That’s about it. Side-note: while I was in London, I was asked to join the board of a Swedish company (Polopoly). I remained on the board after moving back to the US, until I resigned in 2005 after concluding the relationship had become too long-distance.
You can see all this at http://www.linkedin.com/in/forArunKumar
Q: Can you talk a little bit about what led you to found your company, what was the problem that motivated you?
There was a moment of epiphany: when I was at Morgan Stanley in the late 90s, I reserved a conference room (at random) for a meeting. Walking into the room I found a large, complex diagram and set of notes on the whiteboard. In one corner, was a reference to one of the products that I was responsible for. I was astonished, because this room was in a part of the company that I had never visited before, and I couldn’t work out the reference to my product. That got me thinking: “what if I could see the world through the eyes of the people who had been in that room before?”
I spent time thinking about this problem, but didn’t do very much. When I moved to London to build Jiway, the question of effective collaboration within distributed teams became an acute problem for me: I was trying to coordinate the efforts of people in New York, London and Stockholm; people working within Morgan Stanley, OMX and external organizations; people from different departments and backgrounds.
The tools we had were from Microsoft: Project, SharePoint, and Outlook (the lowest-common-denominator way of collaborating). I became convinced that there was a class of projects/work that was not supported by traditional approaches to collaboration, and this work was characterized by almost continuous changes in strategy and tactics, practically on a daily basis.
Traditional tools didn’t recognize the fluidity of knowledge-intensive work, where you learn about the project as you execute the project. So, pretty soon you find that instead of MS Project and SharePoint supporting your work, you spend most of your time feeding the beast: trying to keep these “tools” up to date on the shifting reality of your project.
Not handling change gracefully is one flaw, the other is that task management is considered to be the key element of project management, when increasingly it is content management that drives success. And increasingly, that content is sourced externally from the Web rather than generated internally by the team.
While I was working at Onvia, I realized this problem was getting worse because of some secular trends: teams were becoming increasingly distributed, with more work getting done offshore, and managing content, particularly the combination of Web and Office content, was becoming increasingly difficult.
At Onvia we used Project and SharePoint, again, and it was clear that their basic command-and-control model, which presumes that everything can be predetermined at the start of a project with relatively little discovery taking place during the project, were fundamentally unsuited for all sorts of knowledge-intensive work.
Q: How did you get started?
I started in 2002 doing a ton of market research on the problem: I build mockups and showed them to potential users in all sorts of companies and organizations — commercial, nonprofit, governmental — both in the US and Europe. That helped me evolve the basic vision quite a bit. (In retrospect, I did way too much market research and should have started building a usable product sooner). I built a small team and decided to build Kerika as a p2p Java app that used the JXTA open-source networking technology.
We built several versions and got it in the hands of a broad range of users, with a surprising number of them overseas.
BTW, I used my savings to fund the company and never sought external investors. Not sure that was the smartest move I made…
Q: Can you give me a brief overview of where the company is today?
I restarted the company in August 2010. I decided then that the old p2p model was made obsolete by the development of a broad range of Web services, so I decided to build a Web App the second time around. I hooked up with Jon Cohen who acted as CTO and worked on the back-end; on the front-end we ended up cycling through a number of people locally in the Seattle area before finally hooking up with a very talented group of developers in India that are now the core part of the dev team.
We got a first beta version out in March 2011, and started showing it to a few friendly users that were local. We got more people using by word-of-mouth, but we focused primarily on getting beta users in the Seattle area who would let us observe their use of the product and give us direct, extensive feedback. This was enormously helpful: we learned a ton about usability of the product, and we also learned which parts of the product were more useful than others. The product improved hugely in the April-Dec timeframe, to the point where we now view it as very much out of beta. Along the way we picked up users from a broad range of backgrounds: students using it for group projects, other entrepreneurs using it for their startups, people using it for political and advocacy purposes, folks in enterprises…
The basic product is of generic use, but we think the value proposition is strongest when distributed teams have to collaborate, because then the greatest risk of project failure comes from team members not being on the same page, all the time — and not because team members are inherently incompetent or lazy. We are now focusing our marketing focused around this single message: Kerika can eliminate (or at the very least mitigate) the substantial project risk that comes from people not being aligned on strategy, structure and content.
The company is self-funded again (i.e. “me-funded”), and will probably remain that way for a little while longer: I want to see more traction before I seek funding.
Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?
Getting an offshore team working well has been a source of great satisfaction. That’s not easy, and it’s not accidental. I have learned a lot over the years about making cross-border teams work, and getting an offshore team working well takes a mix of cultural, technical and management skills. At this point now I feel I have one of the most productive teams I have ever had, and they are producing output of a higher quality than I could get from local talent.
I don’t know if Kerika is for everyone, but for some people it really does match their style of working. I love the moments when I demo the product to someone who has been looking for a visual collaboration tool for years, without even knowing that they were looking for such a tool, and their face lights up as they immediately “get it”.
Finally, there is the professional joy of being in a startup, where you have to wear so many hats: you have to take on all these different disciplines and jobs that would normally be done by some other department, if you were in a bigger company.
Oh, and getting a patent issued was a pretty big high…
Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?
With the first version of Kerika (“K1″), the biggest blunder we made from a technology perspective was relying upon JXTA. It seemed perfect when we first came across it: a beautiful architecture for p2p networking that had been designed by Bill Joy himself, which was now an open source project. However, the project was never really “open” because Sun controlled it too much, and eventually smothered it. JXTA had a number of critical flaws that we assumed would go away over time, because they were all right there on the product roadmap, but the flaws remained and Kerika 1 was inherently unstable as a result. It was really heartbreaking to see people come on board, get all excited about the product, and then walk away in frustration when they realized the communication and collaboration wasn’t reliable.
The big lesson learned there was: if you are going to use an open-source technology, make sure that (a) the technology already has everything that you think you might need, so that if it never improves in the future you are still in good shape, and (b) the product has a vibrant opensource community with a lot of active contributors. Something that is open source may yet prove to be the most expensive decision you will ever make.
With K2, we may have made a strategic miscalculation in assuming the product will be used only by small professional services firms, because we are finding unexpected interest in larger organizations. That’s going to require some changes to our product roadmap.
Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?
In Kerika 2, we have a feature that we originally considered to be considered relatively minor: you can place arbitrary text on a project page. The original purpose of this feature was to put labels on pages, but we happened to build it with a rich-text editor. This little feature turned out to have much more appeal than we had every anticipated.
It took me a while to understand what this is all about, but now I realize that formatted blocks of text (containing lists, tables, pictures, etc.) are what I would call “glass-box” documents: you can see what’s inside without opening/launching that document. There’s an 80/20 rule in effect that much of what people need can be better served with glass-box documents than with black-box documents. In other words, our “little” feature is actually more important to most users, more of the time, than our “big” feature of offering seamless integration with Google Docs.
On the business front, we originally planned to market the product exclusively to small professional services firms. But we are getting unsolicited interest from enterprises, and supporting enterprises will require some significant changes in our product roadmap. We are still grappling with this issue.
Q: Do you have some key lessons learned?
- From Kerika 1: don’t spend too much time on market research. After some point, you are not discovering anything new; you are just hearing the same points being rephrased in different ways. Move faster into building your first couple of versions.
- From Kerika 1: be very careful about what open-source products or libraries you incorporate into your own product. If the feature is really important, it’s not free.
- From Kerika 1 & 2: watch users where possible; don’t rely upon them to tell you what they are having difficulties with. People often don’t articulate problems if they think they will look stupid in doing so, and sometimes people don’t even realize what problems they are having. With face-to-face contact and conversation you can find out what people want to achieve, which is often different from what they are complaining about.
- From Kerika 1 & 2: your users will use your product in ways you never considered. That’s a good thing. When you are trying to find your product-market fit, remember that you can’t push on a string: you need to find a use case where someone is pulling on the other end. And if that particular use case wasn’t the one that you envisioned originally, that’s an opportunity not a problem.
- From Kerika 1 & 2: stay true to your vision, which should transcend details of implementation, strategy or tactics. Kerika’s vision is about getting people to understand their project’s current state, structure and trajectory. In terms of path taken to realize the vision, be very flexible: desktop app, Web app, mobile app — these are all different embodiments of the vision, they aren’t necessarily the vision itself.
- From Kerika 1 & 2: your family are fellow-entrepreneurs. If they are not 100% behind your idea of being an entrepreneur, you need to exit before you damage your family.
- From Kerika 2: build your value hypothesis, your discovery hypothesis and your growth hypothesis carefully by identifying all your leap-of-faith assumptions. Cross-check them for coherence. You will be surprised at how the corollaries of your various leap-of-faith assumptions can end up clashing against each other. Once you do that, you will be further surprised to learn that what your startup needs to succeed is not what you read about on TechCrunch, or what you think is “conventional wisdom”.
- From Kerika 1 & 2: a programmer without an understanding of computer science will build you a prototype very quickly, and possibly cheaply, but will not be able to build you a scalable, robust product. Algorithms, data structures, etc. are all still relevant topics, no matter how high-level your scripting language.
- From Kerika 1 & 2: you will almost never fire someone too soon.
- Overall : I have become much more aware of the need to get all the details right. Concepts are great, but execution is what matters, and execution is just plain laborious most of the time. I have come to understand that there are no instant successes: every successful company has a revisionist history that makes its founders look unusually brilliant. I have realized that you can fail by misfortune, but are unlikely to succeed by chance.
Q: What key skill or experience did you lack when you started that has caused you the most problem?
I knew about marketing in general, but not enough about online marketing, or marketing Web Apps or SaaS. And much of what I had learned about marketing tactics was irrelevant when it came to SaaS. That said, a lot of the basic concepts about positioning and competitive analysis are still relevant.
I had a ton of business experience, but very little of that was in sales itself. Where I had done sales before, it was at a business development level: e.g. building strategic partnerships. I really wish I had more sales experience itself: the hard-core stuff about cold calls, follow-ups, etc.
Q: You seem focused on global teams and multi-firm collaboration, what do you see coming?
I think the key phrase is “incessant collaboration”. That’s because any knowledge-intensive work (software, management, marketing, design…) is based more upon discovery during the execution phase of a project, and less on perfect planning at the start of the project.
Our project tools need to embrace change, because resisting change, or treating it always as a danger to your project model, is simply an unrealistic option. Consider SharePoint for example: when you create a new SharePoint page, you have to decide what kind of page it is — a document library, a workspace, etc. Once you decide, you are stuck with that decision. If your project changes radically — and it surely will — e.g. the entire project gets subsumed by some larger project, or some hitherto small piece (sub-project) grows to swallow it’s parent project, you are pretty much screwed: there’s no easy way to reconfigure your SharePoint pages to reflect the new reality. And the reality changes every day, because every day you discover something new: you learn more about a particular requirement, you learn more about your competitors, you learn more about your customer needs, something you thought would be easy turns out to be particularly hard or vice-versa.
But SharePoint doesn’t embrace change: rather, it actively resists it. And it doesn’t support easy management of Web-sourced content, which is increasingly more important than internally-generated content. These days, the smartest guys in the room are the best curators of Web content, not the best writers of original content.
MS Project’s even worse: it’s basic metaphor is for engineering projects, like building a bridge where the science is exact and you really cannot experiment in mid-stream, but it is used for knowledge-intensive work where your goal is not as precise as “build a bridge across this river at this precise location”, but something vaguer like “connect these two systems/organizations/communities in a way that would achieve this other goal, while discovering and dealing with constraints on the problem as you move along a path that you will have to map out on your own”.
Global teams are much harder to synch up because there are fewer overlapping timezones where you can even communicate on Skype (for example) on a regular basis, and sharing a mental model of the project’s structure, strategy and content gets much harder with cultural and linguistic barriers.
That’s our core focus: we actually believe that asynchronous collaboration is far more important than synchronous collaboration. In other words, being able to catch up on my India team’s work when I wake up in the morning is much more important than being able to chat with them in the evening on Skype, because, by definition, my Skype calls will be limited in duration in comparison to the total workday for me and my India teams.
So, if you are trying to synch up when the other person is not online, what are your options? You have (a) text: someone writes a long email, (b) linear organization tools, e.g. use Google Docs and share a document dump, (c) hierarchical organization tools, e.g. try to synch based upon a common taxonomy of collections/folders. Text/email is the worse of all options because the thread is lost very rapidly when there is more than one person involved in the conversation. I can have a very long email thread with you as long as it is just the two of us, but the moment a third person joins the conversation and hits “Reply All”, we are all screwed because there is no telling where that person’s ideas will veer.
Linear organization, which I call the document dump because that’s the basic view offered by docs.google.com, places all the cognitive burden back on the user: here are all the leaves, go ahead and assemble the tree on your own.
Hierarchical organization is better only when the taxonomy is enforced with an iron fist: precise naming conventions, very hard rules about where individual items may be placed, etc. There’s a whole class of document management tools (e.g. Documentum) that are in that business, and a whole class of users, e.g. people working on a new plane at Boeing, for whom this taxonomy works very well. But for a bunch of other people, it places a set of unreasonable constraints on the user community. The hierarchies don’t work because people don’t follow the rules, and people don’t follow the rules because the rules are viewed as peripheral to their core jobs of creating ideas and content.
Kerika believes the visual metaphor offers the least cognitive load, because it is based upon human biology: as babies, we learn to recognize faces and things long before we know their names. When you look at a Kerika page, you can very easily grasp its organization and flow. Many users have shared their private projects with me, so I have seen a wide range of styles in operation. Some people are very hierarchical, and treat Kerika as a way of creating visual folders, others put everything on one big page and rely upon clustering (i.e. spatial organization) to lay out their thoughts. The interesting thing is that it doesn’t matter what style they use: when I see their page I can, in just seconds, understand what their various projects are about. And the visual metaphor then becomes a way of accessing their content. Which means that when I get their content, I get it in a specific, useful, visual context.
When you have multi-firm collaboration, you are dealing with people from different corporate cultures, even if they are all from the same social culture. So you need some very basic, biology-based metaphor that everyone can understand. If plane designers from Boeing are going to collaborate with a PR agency when their plane is ready for launch, you are going to have a massive clash of styles that will be frustrating for all concerned. That’s where visual collaboration helps.
Q: How has your perspective changed on the available of Internet connectivity and the possibility for pervasive connectivity?
When I built Kerika 1, one of the reasons I decided to use p2p networking was that I didn’t believe there would be pervasive Internet connectivity soon enough, and I wanted to support offline usage because I envisioned my core user as someone on the road (or a plane) with a laptop.
With Kerika 2, we are not even trying to implement offline usage, because I believe there will be relatively few instances when you truly will be without Internet connectivity, and when that does happen (e.g. you are trapped in a car in a blizzard in the mountains), getting access to your Kerika projects probably won’t be your biggest problem. It’s like Apple dropping support for floppy disks before any other manufacturer, and then dropping support for CD drives: they are pretty good at skating to where the puck is going to be (although I think they misfired with Firewire).
(I think Google Gears is an example of a solution for a problem that is already disappearing.)
If you have vastly increased communication possibilities, are able to stay online more often (or, at least, whenever you want to), then the signal:noise ratio starts to become a bigger problem. There’s a ton of content available, a ton of new content getting generated, how do you sort the wheat from the chaff? I think new business models that address the signal:noise ratio will become very important in the future. I don’t see enough of that today: every startup is creating its own version of signal and assuming that it isn’t adding to the noise. (Someone could probably say that about Kerika, too ;-) )
Q: Thanks for your time
This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “No longer a startup, EVE aims for top tier of EDA players” on Mar-29-2011. I have added some additional hyperlinks in this version.
Dr. Luc Burgun is co-founder and CEO of EVE. He has more than sixteen years of experience in EDA in both engineering and executive management positions. Prior to co-founding EVE, he was R&D Director for Meta Systems, a French company acquired by Mentor Graphics in 1996 that specialized in hardware emulation systems. Dr. Burgun holds a Ph.D. degree in Logic Synthesis from the University of Pierre and Marie Curie in Paris and has been granted six patents. The following interview took place over E-Mail; hyperlinks have been added to offer some additional context.
This originally appeared in my “Entrepreneurial Engineer” column in EETimes as “Linc Jepson’s 74ze leverages Russian and American engineering talent to persevere” on Jan-18-2011. I have added some additional hyperlinks in this version.
Linc Jepson studied Electrical Engineering at Tufts and after he graduated with his BSEE he was drawn to Silicon Valley’s technology boom in 1997. He worked as an RTL design engineer at several startups including Auravision, Broadlogic, and Believe and in 2002 he travelled to Eastern Europe for two years where he worked for a startup microprocessor company). He returned to Silicon Valley in 2004 to co-found 74ze, a design services firm that leverages Eastern European engineering talent. I sat down with him after a recent Bootstrappers Breakfast to learn more about his entrepreneurial journey; what follows is an edited transcript of our conversation with hyperlinks added for context.
Q: You have a broad base of experience, what kind of work do you enjoy?
I enjoy the fast-pace of small companies, where there is not only the opportunity but the necessity to do all kinds of work. And that work has an immediate and significant impact. Early in my career I was doing clean-slate development, performance research, upgrading and debugging modules of long-gone developers, verification, 3rd-party IP integration, you name it. I didn’t realize it at the time but it was great training for consulting.
Q: Why did you pick Eastern Europe when you left the Valley?
During the 2001 downturn in Silicon Valley I decided to indulge my wanderlust a bit and to get a better feel for the foreign labor market. I had previously worked with a team of engineers in India. I had studied Russian for about four years in high school and college and had a seedling of an idea in mind about starting a services company that would have a portion of its team abroad.
In 2002 I moved over to Minsk and then Moscow for about two years. I brushed up on–OK I greatly improved on–my Russian and found a job doing RTL design in Zelenograd, Russia. Interestingly, the company had been founded by Chinese/Malay investors. I created a CompactFlash controller and a touchscreen interface. I was also making contacts and continuing to think about an outsourcing team.
I had confirmed that there is some exceptional talent there.
Q: How did you decide on outsource engineering as a business model?
We consider 74ze (pronounced 74 Zee) a services firm, first and foremost. We happen to use remote experts when it benefits a project. About a third of our projects never utilize our remote team. In school I studied International Relations as well, for a BA. Working with remote teams allows me to pursue another passion.
While I wasn’t keen on the mercenary perception that many folks have of contract engineers, I knew that there could be improvements made in the outsourcing model. Specifically, most engineers tend to shy-away from verbal or face-to-face communication. It seems easier to be non-confrontational and swap a few emails instead of picking the phone or Skype, but you can delude yourself into thinking that all will be okay. This can be particularly dangerous when you are an outsider of a company. These communication issues are often compounded by cultural issues. Merge a few factors such as a contractor being foreign and also more junior than the client’s counterpart, as is often the case with remote teams, and you often find someone who too often will dodge asking a short, potentially embarrassing question, and try to compensate by putting in more hours.
The fallout from labor globalization can be overcome with stronger communication and more global management experience. It’s not achievable in all stages of development, but someone who work effectively not only with other engineers in the same building but also with engineers in Krakow or Kiev is growing in value.
Q: How did you get started?
In 2004 I moved back to the US. We incorporated 74ze in Delaware, and then in Russia a few years later, after we had traction. One of our first two jobs was a local one. We had 2-3 people, all US citizens, on site. We only did minor work abroad, such as some analog modeling. The other early job was for a company in Europe. The job was a referral from an existing relationship. That job was done completely remotely. We only met the technical people from the client at a trade show, a few months later, where they demonstrated with our product.
Q: If you are doing RTL design and verification what EDA tools do you use?
An immediate obstacle that we ran in to when we started was the high cost of EDA tools. Right off the bat, this started knocking us out of the running for various contracts. When I was living in Zelenograd, I had used Aldec’s HDL verification tools and had a very good experience with them. After not using them for a few years, because we were using customer tools in the US, one of the guys on our team proposed that we incorporate Aldec’s tools into our next bid.
Over the years, we’ve built up a relationship with Aldec and have grown to rely on their tools quite a bit. It’s unfortunate that we didn’t get much traction in conversations with the other EDA vendors, but I think that we have found a good solution with Aldec Riviera-PRO and a solid partner for moving forward.
Q: Can you give me a brief overview of where the company is today?
We’ve shifted more towards verification in the last few years, both in terms of the jobs we’ve taken and also in terms of a conscious decision to solidify our roots in that space. While most of our early jobs were in or involved some design, and we continue to work in this field, we see that the continuing abstraction of testing is creating a very large opportunity. We’ve been honing our SystemVerilog skills in the last few years and have been doing more verification than anything else, lately.
While we are still a mix of full-time and contract-based engineers, we are a pure engineering team with next to no marketing or sales overhead. This means less overhead cost for the client, but also that we don’t have the sheen of the larger companies. When we meet with a prospective client, they meet the lead engineer in the first meeting.
The economy interfered with our plan to cycle a few younger engineers into our team. Our team has a minimum of 12 years of experience, but I expect that we’ll have an internal project running as a testing ground for some junior engineers later this year.
Q: What are the two or three things that you have been able to accomplish that you take the most pride in or satisfaction from?
We increased our role significantly with two clients over a 2-3 year relationship. With one of those companies, we joined to develop a few blocks from spec and ultimately took on a much larger amount of design work as well as key roles in integration and top-level verification. We helped carry them through full chip functional sign-off and final timing closure. The chip worked the first time. The CTO of one of those companies, Mark Indovina, became an advisor.
We nailed the deadline to get a prototype RTL processor core developed for another client, enabling them to meet the deadline for a multi-day meeting with one of their key clients in Japan. We had to make two flavors, optimizing for power and performance constraints.
I am happy that we have grown to the point where it made sense to incorporate in Russia; growing our team there was a significant milestone.
Q: What has been the biggest surprise? What was one key assumption you made, perhaps even unconsciously, that has caused the most grief?
Sales. Selling is tough. I came back from Eastern Europe and a bit arrogantly thought that as a skilled group of engineers, we would break into the contractor market easily. I have learned that selling is a process. I am not a salesperson in the least. My father was and I didn’t have much respect for the field, until I tried it.
Q: What development, event, or new understanding since you started has had the most impact on your original plan? How has your plan changed in response?
I thought that I would be spending a lot more time in Eastern Europe than I have been. We have a senior team there that runs smoothly. The last time I was there I was trying to hire another engineer for a project and was unsuccessful. Salaries were skyrocketing.
We are more local and on-site and less offshore-centric today than I initially envisioned.
Q: What suggestions do you have for entrepreneurs?
Be willing to deviate from your plan; not necessarily from your objective. I think we can (I did) envision the future too much or too specifically, such that you have a hardened mold in your mind and of how something will turn out and then work like hell to fill that mold with your progress. Sometimes there is less resistance to your goal down a parallel path.
Q: Thanks for your time.
Linc Jepson is a long time attendee at Bootstrapper Breakfasts®, and has a brief video interview up at “Linc Jepson: the main reason I come to the Bootstrapper Breakfast“