My lessons from a startup
Almost three years back I started at a digital media network startup as the head of their business applications. I was giddy at the prospect of working at a startup. In B-school they talk a lot about startup experience. Back then I was a newly minted MBA with a major in Entrepreneurship and significant experience working for Fortune 500. Plus, the CEO mentioned during the interview process that this role will evolve into the CIO position once the company was big enough. Well, that was enough for me to start there without any increase in pay or stock options (They did promise that they may offer some at a later stage…”the investors…” they said).
Early this year I parted ways. The company had moved from “start-up” mode to “wind-down” mode. Looking back I realize that startup experience is like dog-years – everything that a larger company goes through happens here in a really short span of time. Sometimes, the company becomes a mid-size or even large company in the process. But, most often it is a footnote that is very quickly forgotten. Here is some of my learning.
Business:
1. Be willing to question your own ideas
In business schools this is one thing they drill into you. Often people think that they have created a sure winner. Chances are a lot of people have come up with the same idea and passed on. And, they did it for a reason.
The true cost of installing our service was about 3-4 times what was projected/ assumed in the business plan. The size of the company at its peak was more than the projected maximum. Yet, no one thought it would be worthwhile to do a break even analysis with the new numbers.
2. Evaluate, plan, act and measure
Startups suffer from a different from the big company “I know it” syndrome. Some think that there is not enough time to stop and think (“our competition will eat us alive”). So, they embark on initiatives that have no purpose, plan or a way to check point and commit hara-kiri.
3. Just because the market demands it does not mean you do it
Strategy is about focus, understanding your strengths and weakness and positioning accordingly for success. The startup I was in decided to launch a new service because one market seemed to show lot of interest. The next six to nine months the company spent lot of time and energy creating the service. And, as soon as they launched it they were hit with a lawsuit on patent infringement by a competitor. What more, they soon found out that the way they had priced their core offering (free) did not work well for this service because the cost of rolling it out was a lot higher. In another six months they stopped marketing the service. Meanwhile the lawyer fees alone for the discovery related to the lawsuit had run up to a few million dollars – a very costly distraction.
4. Even if it is 4th and long, have a plan
I find it funny that I am writing this a day after Brett Favre of Minnesota Vikings threw a “Hail Mary” pass with about 4 seconds left that saw them trounce San Francisco 49ers. Favre is gifted and, flawed as evident by his number of touchdowns and interceptions. I would take Peyton Manning or Tom Brady any day.
Our startup laid off some folks in October of 2008. Then, they did it again in Jan 2009, start of 2009. The reason was the market had not improved. Hello, nothing really happens in the last two or three months of the year. So, why did they not plan for it? Last I heard they were still letting go of people every two to three months.
5. Business value of IT depends on what you put in
I am yet to meet an executive who does not think that IT is not strategic to their business. And, I rarely find executives who are willing to give IT managers some of their time leave alone engage with them early regarding a business initiative. So, you want to see how much the senior management values IT, ask for a meeting, provide them the details and see when you get on their calendar. If you happen to get on their calendar in the next two weeks time, your organization may be in the grey area. So, see how prepared are they when they show up for the meeting, i.e. if they show up for the meeting.
People:
1. Loyalty is a double edged sword.
On one hand you get people you can count on. On the other hand you are in a subjective situation – you have folks who might rarely question the line of thinking. So, like lemmings they march off the cliff.
2. Bozo effect is for real
Hire people who are better than you otherwise soon you and your money will be parted
3. Incent people for right behavior
When I joined the startup as the head of IT the laptop I got was a hand me down. It used to be the CEO’s laptop and then the Head of Sales’ laptop. Needless to say there were a number of files left on it, including compensation discussion between the CEO and the Head of Sales. Turns out that the Head of Sales’ base salary was about three time that of mine (and, as I later found out about as much they were willing to spend for IT in a year) while his bonus percentage was about one third of mine. Hey, I am the one in an internal support role. Don’t even ask if the Head of Sales delivered. Hell no, his entire team did not.
4. Be honest
True for all but very important for startups. When you do not have money to throw or time to waste you need to make sure that everyone involved is motivated. The way you interact with your employees and partners become very important.
5. Culture should be built and nurtured. It should not live in just PowerPoint presentations
Everyone wants to build a “unique” culture. However, quite often it does not make it beyond the PowerPoint presentation. I recall asking the CEO what kind of organization he wanted to build and getting a PowerPoint. If you are not ready to talk about the culture and walk the talk you are doomed to fail.
6. Open doors and closed ears just waste everyone’s time
This is another one of those things that executives love to mention all the time – “My door is always open.” Great, even better …if you are all ears. Otherwise, you just wasted everyone’s time. A closed door would have been better.
Process:
1. Less is more.
2. Keep asking – what is your Next Best Alternative (NBA)?
3. And, has this action improved on your NBA?
4. Do not automate bad processes. Corollary, don’t even try to automate “no process” situations
5. Systems cannot and should not drive the process. It can only support it. People should
6. Systems cannot and will not communicate the processes. People should
7. Always, try and have a non system specific process
8. Build for Standard operating procedure (SOP), then the alternatives and rarely for exceptions
9. “Flexible” does not mean unplanned or no rules
10. “Base” does not mean “minimum acceptable by me.” It is the minimum to run the business process and achieve the objectives
Cloudy or Saasy…which way?
I think it is going to rain… I am not sure what. Everyone is talking about clouds these days. I mean cloud computing. It seems it was just the other day that every one was talking about SaaS – software as a service. Now, even Salesforce, the company that has a legitimate claim to the honor of starting SaaS is talking about cloud computing with its Force.com platform. And, they are not the only one who seem to mixing the two.While there are similarities between cloud computing and SaaS, I think there are big differences.
SaaS, started off as a way for companies (usually, small to mid size) to have sophisticated applications without incurring the capital and ongoing infrastructure and man power costs. Basically, you rent the application. So, your initial costs are low and remain constant. You do not need to have servers, server management software and personnel in-house. You might not even need in-house development staff.You get access to the latest updates and upgrades of the software.
Now, SaaS worked fine when the application met all the needs of the customers and was siloed. Total number of applications that fit this profile = 0 (zero). Sooner or later everyone wanted to customize some or all of the application. They also wanted to integrate this application with other applications and processes. Lo and behold – we now have a need for a development platform and developers (or, consultants). In Salesforce’s case the first one is called force.com.
Cloud computing takes this further – it is a platform without a defined application. It is like the utilities – you pay for what you use and you decide how to use it. It is great for situations where there is going to be spike/ significant variation in infrastructure needs – e.g. software distribution, CPU power to index large content etc… However, the application has to be built by the user. So, it might not be for small and medium businesses.
So, you are an Enterprise Architect. What exactly do you do?
I have in more than one occasion run into people who seem to confuse between an Enterprise Architect and an Enterprise Application Architect.
Wikipedia defines Enterprise Architects as “practitioners of enterprise architecture.” And, the same source has this for “Enterprise Architecture” – “the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.” But, Wikipedia entry on Enterprise Architecture begins with this line “…refers to many things.”
An Enterprise Application Architect on the other hand is an Application architect. Granted that the application they are responsible for might be an ERP or CRM system. Yes, these applications do tend to support multiple business processes and cut across various departments in an organization. However, the focus of an application architect is the present – an implementation or enhancement of the application. And, their involvement in this is very detailed.
The focus of an Enterprise Architect is the future and their task is to roadmap the present to the future. Their involvement in specific project initiatives is likely to be limited to consultations rather than daily involvement in the details. I have come across Enterprise Architects and companies who tend to talk more about their current state, how they went about documenting it rather than on the future state and how they plan to get there. Knowing where you are is important to create a roadmap to bridge the current with the future. However, to dwell on the current state is to lose an opportunity to make the future state a reality.
Traditional vs. Agile
I often (though, these days it is less frequent*) come across folks who have practiced the traditional application methodologies, have heard of Agile development and are wary of Agile development. They all have their favorite pet peeve with the various flavors of Agile development – “two people coding together is a waste of resources”, “building before completing the entire design is surely a recipe for failure”, and so on…I have pondered this for a while and come to this understanding. The traditional methodologies are output driven (so many documents, checklists etc…) while agile development is outcome driven (does it work, does it satisfy the need, do the users want to use it?)
I was once on a “traditional” project for a large insurer. We completed the design (or, at least, we thought so), got the signoff and were waiting for the start of development. The client called us back and told us that on review against their methodology (which, they had licensed from a big consulting house which by then had stopped using that methodology in-house) they had found 20% gap in our design. I never figured how they came up on this 20%. My guess is that they reviewed the outputs against a list provided by the methodology and found some gaps.
Next time you are on an elevator and someone engages you on a traditional vs. agile discussion, try telling them that the difference is “output driven” vs. “outcome driven.”
Separated
The New Year got off to a rough start for me. I returned from a month long vacation (half of it was unpaid and the rest was all the vacation days that I had shored up for this trip to India) to work to find that I have no work. My boss (the CTO) of the company told me that due to financial difficulties the company was going through another round of layoffs. Since they had decided to stop all IT initiatives they did not need someone to define and manage IT initiatives.
So, here I am looking for a new job. A recruiter that I talked to mentioned that I should not use “eliminated” or “layoff” as they have negative connotations. Instead, he suggested, I should use “separated.” Well, “separated” it is even though it does not change the reality. Someone else told me that averaging 2 yrs at a job does not sit well. True. I would not hire someone who changes jobs every two years. And, in the first 8 years of my work I was a sucker for the newest technology. I changed jobs every two years to work on the latest thing. In the last 10 years it has been the economy and the companies who have been prompting my job changes. One company that I worked for kept laying off people every 3 months that I finally quit after being there for 6 rounds of layoffs; the other decided consulting was not for them; the next two failed (one of them managed to sell themselves before it went under)
Someone once asked me – “How long can a ‘start-up’ call itself a ‘start-up’?” I had no answer for that one. My former employer has been in business for 3 years and is down by $35MM. In B-school they say investors look for 3×3 or 5×5 returns (i.e. 3x returns in 3 years etc…) I bet this is not what they had in mind. Anyway, what do you call a ‘start-up’ that is in this state? Wind-down.
Back to the job hunt.
"IT Enabled" vs. "IT Driven"
Pretty much all companies these days claim that IT is **very** important to their business, offers competitive advantage, blah-blah-blah… All these companies and the IT vendors were very upset with Nicholas Carr for suggesting that “IT doesn’t matter.” However, it has been my experience that there are broadly two kinds of companies – ones that are “IT Enabled” and ones that are “IT Driven.” To put it simply, being “IT Enabled” is good and being “IT Driven” is not so good (may even be bad).
So, what do I mean by “IT Enabled”? An “IT Enabled” organization is one where the business strategy and business processes are defined, communicated and adopted without the involvement of IT systems. The IT systems enable the employees to complete the business process faster, better and even improve the business processes. This is an organization where every group, department, cost/profit center knows its role in the business process, communicates and co-ordinates with other groups without relying on IT systems. This is an organization that has a clear understanding of where it is going, how IT can help it and engages IT early and often. The IT organizations in these companies do have an opportunity to make a difference to the company’s bottomline and/or topline and often they do. You may have interacted with some of the companies – where you ask customer support for something simple but special and they know how to complete the request. No, the IT system may not have been built for it but they know the business process. They know who to call to get the answer.
An “IT Driven” organization, on the other is one where the business process is defined as part of the systems/ application development and it is communicated as part of the systems rollout. Needless to say, in these organizations IT plays a very reactive role and the employees do not have a full understanding of the entire process. The only documentation of the business process is possibly in one of the documents created to build the application. These organizations tend to be very reactive, often silo-ed and rely on IT systems/ applications to “communicate” across groups, departments etc…The IT organizations in the companies are constantly in a reactive mode with no/limited insight into the company strategy and strategic initiatives.
Guess what, there are a whole lot more of “IT Driven” organizations than “IT Enabled” organizations. Having the capability is not enough. What you do with the capability is what will differentiate you from the rest.
I am confused …when did PC mean Microsoft
I have long argued that Apple’s “I am a Mac” ads cause confusion in the minds of viewers. Almost all viewers think Apple is taking a dig at Microsoft. Yes, they are. Not, they are not taking a dig at just Microsoft. User experience is not derived from just the operating system but also from the hardware and the software that the user tends to use the most. The Mac advertisements are about user experience.
An integrated platform like Mac where the hardware, the operating system and most of the software comes from a single company (in this case, Apple) allows Apple to offer a “better” experience. (Note: I have not used a Mac in the last decade so I really cannot say whether it offers a better experience). The PC, the Windows Operating System and the applications that run on it are discrete pieces that are created by different parties, assembled by different and experienced by a single user at a given time. All these companies contribute to the user experience – the good, the bad and the ugly.
I was quite surprised to hear of the “Iam a PC” campaign from Microsoft for many reasons. For one, it looks and feels like a knee jerk reaction from Redmond. Then, I don’t think Microsoft has ever had a memorable product name leave along an ad. campaign. So, why waste money. Last but not the least, when did PC mean Microsoft. Yes, Windows run on about 80-90% of the PCs but there are PCs running Linux, Unix and <<you name it>> operating systems. Does Microsoft make PCs? Last time I checked… No. So, shouldn’t Dell, HP, Lenovo, Acer, Asus along with Microsoft do the “Iam a PC” campaign. I guess they are not as stupid as Redmond. A fool and his money are soon parted. I guess that is true for corporations, too.
Is Enterprise Software different from Consumer Software?
I think the answer to it is – yes. I worked for a company where the CEO was often sympathetic to the complaints of the sales people about the sales management system. His refrain was – “Look at the stock price of Google and Apple. They are what they are because of their focus on the interface.” The reality of the situation was neither Google nor Apple made any enterprise software application. So, I could not suppress a chuckle when I saw this article here about an ex-Google employee saying that the company is not suited to making an enterprise application.
I am not discounting the value of a well-defined user interface or discrediting the success of Google or Apple. However, I think there are some fundamental differences between consumer software and enterprise software applications.
I think consumer software applications have functions that are atomic in nature. Users fire up the software or the site and do a function or two. These functions have clear boundaries that allow users to exercise it at different times and for software developers to improve it over separate release cycles. Enterprise software functions are more integrated and this results in larger feature sets and need to manage and update features in a feature set in a release.
The other big difference is the usage. Here again consumer software usage tends to be atomic. So, it is easier to learn/ grasp. And, it does not require inputs from others. How often have you as a consumer software user waited on/ depended on someone else to provide some inputs or do something before you can do what you have to do? I think many of the angst people have with Enterprise software is because the scope of the usage is larger and more complex. The user experience is impacted by the quality of training on the **process**, the system, quality of other users and systems that integrate with it.
The last difference is the difference in expectations. The cost difference between consumer software and enterprise software is significant and hence the expectations associated with it. The issue here is while consumer software and enterprise software are kinds of software they are not in the same category and should not be compared. You cannot compare $300 Spreadsheet package with a $100K ERP package.
iPod Effect
Over the last two decade computers and IT solutions have become common place in the workplace. Over the last decade or so the growth of the Internet and personal computing devices have made just about everyone opinionated about software, websites and technology, in general. However, I think no single technology product has made “experts” out of “idiots” like the Apple iPod and iTunes.
It used to be that there were a few, learned and well meaning human computer interface experts working to improve devices and interfaces. Then, there were a few more Mac bigots who in some cases worked on user interface and user interaction but in most cases were experts on style rather than substance. Mercifully these folks almost never worked on Windows or Linux PC or business applications. So, the scope of their opinions and its audience was limited. Today, we have a big group of people who are on iPod/ iTunes and working on regular PCs and business applications at the workplace. These folks feel the fact that they have an iPod and use iTunes make them an expert on product design, user interface design and all things “intuitive.” Their typical complaint about PC applications and usual business applications is – “It is not intiutive.” Ask them to expand more on it or explain their statement they will repeat the statement over and over again or point to their favorite products – iPod and iTunes.
I recently was in an ERP implementation where the users were comparing the ERP system to Excel (yes, they were forced to move from Excel to an ERP system) and complaining that the system is not “intuitive… flexible.” The business heads were not in a position to do their part in driving adoption – Encouragement and Enforcement. The CEO, when presented with the adoption issues, would say -”Look at Google and Apple. They have high valuations because they develop intuitive interfaces.” Now, neither Google nor Apple have a real enterprise business application.
So, how do you get user(s) to realize that they are not experts on user interfaces and product designs? Using a well designed product or application does not make someone an expert on its design.
*ilities that get lost in translation
A lot of words that get thrown around during discussions between business and technology folks are “overloaded” – used to mean different things for different parties. Often parties involved do not recognize this and think that every one is on the same page until the outcome proves otherwise.
Every Technical architect knows the importance of stuff like – availability, reliability, scalability, flexibility and performance. Together these are often called – *ilities and mastery of these is a sign of a good architect. Now, as you move up from the role of a pure Technical Architect to an Enterprise Architect and beyond you have to take an organizational view rather than a systems centric view. Often these require conversations with business heads on their business processes and pains. Sometimes these conversations will include some or all of the *ilities but they mean different things to the business.
Let us take a look at what they mean to both parties
Availability (Technologist) – System uptime.
Availability (Business) – It includes system uptime. It also includes “accessibility”. Is the system available when I am on the road? Is the data available on my phone?
Reliability (Technologist) – What is the accepted “Mean Time Between Failures” (MTBF)? Reliability combined with Availability gives you the acceptable downtime per day/week/year. To a lesser extent this also answers the question – Is there enough system safeguards to maintain data integrity?
Reliability (Business) – Rarely do the business users link “reliability” with “availability” the way the technologists do. For them reliability is all about data reliability and data freshness. Can I rely on this data? When was this data last updated?
Scalability (Technologist) – Can the system architecture handle the growth in data/ transactions. What is the scale out strategy – vertical or horizontal?
Scalability (Business) – Can the system handle growth in business locations (new offices, new markets, new countries etc…)? When do I need to add people to handle transactions in the system?
Flexibility (Technologist) – Are parts of the system behavior configurable? Can changes be implemented easily without having to rewrite/ recompile large parts of the system?
Flexibility (Business) – Can the system handle changes to “business processes” on the fly?
Performance (Technologist) – What is expected and acceptable response time for the system for a specific action under a specific load condition?
Performance (Business) – I need the system to respond immediately to my action.
Most of the challenges I have encountered with business users is around – scalability, flexibility and performance. I think the “scalability challenge” can be easily overcome if we understand what the business user is asking and we drop the system centric view to take an organizational view. The “performance challenge” is also relatively easy – it is about getting the users to qualify the actions and quantify the acceptable time to complete the action.
I think the greatest challenge is around “flexibility” - often (not always) what business wants is a system with rules where rules can be changed on the fly. This would break even a system that has a user-friendly rules engine. And, just because they ask for it does not make it right. It is important that the business understand the concept of standard process, alternates and exceptions. It is also important for the business to have release cycles around business processes just like IT has release cycles for systems. Changes to business processes involves communication, collaboration and confirmation.
