Blog

Institutional Startups – From Innovation to Commercialization – why the disconnect?

By jchiang | Published: April 1, 2011

I came across this interesting article about a study from the NSF on R&D is still very strong in the US as compared to other countries -

http://www.nsf.gov/statistics/infbrief/nsf10322/

Also, here’s a related blog on the topic – http://www.economyincrisis.org/content/offshoring-research-and-development that discusses how R&D is still strong in this country, with the exception of the auto industry, that has become reliant on offshore technology to power next-generation automobiles. The article argues that jobs will likely follow the R&D dollars.

Unfortunately, that’s not likely to the case. In the early 1990’s, I worked at one of the best research labs in the country … AT&T Bell Laboratories. With the AT&T monopoly on telecom, AT&T was able to finance a company that advanced US technology interests with huge advances in research. Advances like UNIX, C, speech recognition, etc. was first developed at Bell Laboratories.

However, with the deregulation of telecom, Bell Labs was charged with speeding the development of innovation into commercial products. Unfortunately, they realized that the disconnect between innovation and commercial use was too large to bridge and Bell Labs ended up being sold completely to Lucent. Very little of the basic research activity is still being done there.

Much of the reason why US automobile car companies are now reliant on overseas R&D is because they failed to invest in R&D early enough to make viable fuel-efficient products today. From a national perspective, it’s imperative to continue to fund great leading-edge research to fuel the next generation of innovation.

That said, it’s still a tall order to convert innovation into commercial products with huge revenue opportunity. Whereas US should maintain leadership in R&D, offshore firms may be a suitable and less expensive catalyst to help turn innovation into marketable opportunities.

Posted in Institutional Startups, Offshore Best Practices, SMB Offshoring | Leave a comment

Offshore Best Practices – Offshore development for cost reasons often ends in failure!

By jchiang | Published: March 3, 2011

Since I blog a lot about offshore development, many people assume that I’m a fan of the process. Unfortunately, the way that it is currently introduced and managed, many offshore team efforts have resulted in failures. For the record, I’m not a fan of offshoring purely for cost saving reasons. However, for many companies, leveraging an offshore development model can mean the difference between profitability and loss.

As I’ve mentioned many times before, offshore software development efforts that are motivated by cost savings usually ends up as failures because none of the necessary processes have been put in place to ensure it’s success. If you choose to implement offshore development teams, “Agile Offshore” is really the only reasonable way to make it a successful collaboration.

The reality of the global marketplace suggests that there are a number of factors that will likely speed adoption of offshore software development practices, including:

- Online collaboration tools are being widely adapted and leveraged for every day use. The sophistication of these tools have improved dramatically.
- Venture capital and private funding of innovation has frozen up as a result of macroeconomic conditions. Innovators are forced to look at all avenues of cost controls, while still introducing innovative solutions.
- Online gaming, virtual reality, and the generational shift to online personalities has introduced entire generations of people who are comfortable working with virtual collaborators.
- Issues related to software complexity have given way to a new generation of widely available, free, open-source software that can be leveraged to manage technical complexity. As a result, software development has become more like “putting together pieces” as opposed to “inventing from scratch”.

One recent quote from a venture capitalist: “The World is Flat, Get used to it.”

Part of making progress is understanding how the world has changed and adapting optimally to leverage those changes. It’s no longer acceptable “to bury your head in the sand” and deny that global talent is available and can be leveraged effectively for your organization.

Posted in Offshore Best Practices | Leave a comment

Hybrid Agile Offshore Model – The Myth of All or Nothing

By jchiang | Published: February 28, 2011

Offshore development is often interpreted in the worst context by most engineers and engineering managers. Even the brief mention of the word will solicit fears of downsizing and get engineers to start circulating their resumes to rival firms. However, offshore development is a very different concept than downsizing, and if used effectively for team augmentation, can even help engineers find more opportunities for growth in the company. It’s time to eliminate the stigma of offshoring — offshore development is not an all or nothing proposition.

There’s a new model called Hybrid Agile Offshoring, which maintains the top technical leadership in onshore roles, with team augmentation done at the team leader level. Instead of fears of massive downsizing and offshoring the entire team, this model maintains the technical team leadership close to the customers and company headquarters, while still allowing the company to scale with offshore team augmentation.

This model enables onshore engineers to become virtual team leaders of offshore staff. Engineers who have used this approach has found even greater fulfillment, because they are able to mentor team players and delegate the less critical and straightforward development tasks to their offshore partners. Technical team leaders assume a greater part of the overall architecture of the application system, while delegating the more junior tasks to their offshore counterparts. If implemented correctly, it becomes a huge win-win for engineers and company leadership.

It is critical to assure the engineering team that this model is not a prelude to a more comprehensive offshoring plan – they need to be comfortable in their positions and not perceive the offshore entity as a threat to their long term employment with the company. Hybrid agile offshoring is not an interim strategy, it should be part of a larger company plan.

The hybrid agile offshore model also has great benefits for the developing startup that has used onshore development resources to establish the initial traction for the company but then also wants to augment the team to scale with initial customer engagements and market traction.

Posted in Agile Offshore, Offshore Best Practices | 1 Comment

How Traditional Offshore Software Development fails Startups?

By jchiang | Published: February 8, 2011

I hear about this frustration all the time. Let me run through a typical scenario.

Someone has the next great idea for a startup. Perhaps it’s a social network application, perhaps digital media. One the first things that entrepreneurs do is to start prototyping an application to demonstrate viability and proof-of-concept to new investors, prospects, etc. It makes sense so far.

Almost immediately, they recruit “free” local talent to help develop the initial application. “Free” may be a bit of an exaggeration. Let’s face it – most startups are starved for cash and any free resources helps tremendously, especially at the very beginning.

Eventually the team grows, new interest and funding sources are identified, and the startup starts getting bigger. More engineers are hired and the burn rate jumps dramatically. Company usually has at most 18 months to meet enough milestones to attract new investments.

At earliest, this is when offshoring may be considered. If it is considered, it’s usually completely tangential to the company, with offshore resources dedicated to non-critical areas. Always the afterthought, offshoring is more than likely doomed to failure from the very start. They don’t get enough information to be successful and is seen as a threat to local development jobs. No one is incented to make the relationship work. Eventually, the whole relationship fails, and everyone blames the lack of quality from the offshore partner.

Offshore software development shouldn’t be considered the afterthought. To make it work, you need it as central tenet to the company’s strategy from the very beginning.

Posted in Agile Offshore, Offshore Best Practices, SMB Offshoring | Leave a comment

Agile Development – To Scrum or Not to Scrum?

By jchiang | Published: January 30, 2011

For the curious among you, “scrum” was a term used in rugby that referred to a tectic of trying to advance the ball down field as one unit, while passing the ball back and forth. For the tech crowd, Scrum is best known as the most widespread method of choice for agile software development. It was popularized in the mid-1990’s as a “holistic” approach that increases speed and flexibility.

Indeed, most “agile” approaches implemented today is based on Scrum. A second choice would be Extreme Programming. Other lesser known agile approaches include Adaptive Software and Feature-Driven. You may also remember IBM’s Rapid Application Development model as well.

Many offshore companies will emphasize how many certified ScrumMasters they have on staff or how strictly they adhere to Scrum methods. Most of these certifications and the like are misguided … Scrum is a tool and measuring adherence to methodology is really not a measure of business effectiveness.

The only 2 engineering metrics that matter are velocity (features defined, implemented, completed – factoring complexity of each feature) and quality (bugs and severity). If you can just show me those metrics and historical trends, it would not be difficult to draw sensible conclusions about the effectiveness of a team.

That said, to blindly implement Scrum, especially in an offshore development environment, may be misguided. Implementing Scrum may be the best starting point, but agile development includes constant process evaluation. Aspects of Scrum that do not prove effective should be tossed away or replaced, depending on measured effectiveness. The same can be said about Extreme Programming and other methods.

So, don’t be fooled about the 100% Scrum implementations. Adherence to process is good, but measurable success has to be the objective.

Posted in Agile Offshore, Agile Tools, Offshore Best Practices | Leave a comment

Great Links – for Software Entrepreneurs

By jchiang | Published: January 10, 2011

After talking to many new software entrepreneurs as well as principals who are trying to build new businesses in a corporate environment, I’ve decided that there’s a need for a list of “essential” reading material for all new entrepreneurs.

Obviously, as a major fan of the Lean Startup and Customer Development philosophies, my list skews heavily towards a more agile framework for developing new startups.

With so much information available about startups, it’s amazing that so few startups result in success.

Happy Reading!

On Funding:

Blog: Funding for Startups and Entrepreneur - Great list of funding sources for new entrepreneurs.

Website: TheFunded - Great site to learn more about each of the main Vcs and the principals in the company. The Rating system is very flawed, so I wouldn’t pay much attention to it. Pay particular attention to the No New Investments list at : http://www.thefunded.com/funds/banned

Website:OwnYourVenture - Great site to understand valuation and similar the equity dilution effects of raising VC funding.

Blog: Investor Funding Tips - Advice from real investors about how to best reach out to them and what they consider a great pitch.

Ben Horowitz’s blog– Insights to venture capitalism and startups.

Article: Interview with Niklas Zennstrom - Great advice from Niklas Zennstrom, Founder of Skype, to new entrepreneurs.

On Lean Startups and Customer Development:

Steve Blank’s Blog – a huge wealth of material about discussions related to new startup venture.

Eric Ries’ Blog – another great treasure trove of information about Lean Startups and what’s it about.

Four Steps to the Epiphany by Steve Blank – The Bible of Lean Startup movement.

Getting to Plan B by John Mullins – Great discussion on successful use of Pivots.

Entrepreneur’s Guide to Customer Development – A Cheat Sheet by Brent Cooper and Patrick Vlaskovits – on Amazon.com

Blog: Importance of “Failing Fast” by Mark Suster

Blog: Teardown the 13 Ways to get to 10 Million in Revenues - Great read on new startup business models.

Blog: Rob Go’s blog on Product Management Blog on understanding the role of Product management and how to build products that customers love. Filled with great interviews with product managers.

For Web Marketing:

Top 25 Websites for Small Businesses – This is a list of sites that are important for startups and small businesses.

Website: SEOMoz – Great source for information on best practices for SEO.

Let me know if I’ve missed anything that should be added to the list.

Posted in Entrepreneurship, Lean Offshore Startups | Leave a comment

Top 3 Issues in Transformation to Agile Offshore Teams

By jchiang | Published: December 12, 2010

Leveraging offshore software development is not as intuitive as most may think. Many companies are attracted by the cheaper costs but then quickly realize that without the right processes, offshore teams are doomed to fail. Many of the same problems repeat themselves throughout the industry. The common issues are listed here. The different management reporting structures also contribute to suboptimal communication and collaboration, and ultimately productivity.

NeoContext spends a lot of time coaching teams to help them understand and identify the key problem issues that they are experiencing. The harder part is to recommend and help implement the process changes necessary to achieve success. Sometimes, it makes more sense to abandon the current partnership and source a new team. However, abandoning an existing partner should be used as a last resort. After all, your existing teams bring a lot of knowledge and history to the partnership.

Inevitably, the answer lies in transforming the project or division into a completely agile operation, with it’s benefits in improved transparency and collaboration. However, getting to “agile” is often not easy to do. Here are some of the key culture challenges that are common in Agile Transformations.

1 – Openness with Incomplete Work – This is one of the big barriers for companies moving to Agile practices. For many technically-trained engineers, much of the traditional education training has been based on the passing of technical exams based on the reviewed material. There is usually no place for partial credit and so, interim results are never rewarded. (When’s the last time a student was rewarded for turning in half an assignment?)
Being Agile requires that collaboration partners trust each other to review incomplete work (including expected bugs, functional deficiencies, obvious usability issues, etc.) Indeed, many engineers have subjected their work to groupthink, often resulting in unattended poor consequences … feature creep, finger pointing, allegations of poor quality, etc.
It’s no wonder that engineers are so hesitant to share interim work. Historically, it has never resulted in a good thing. However, the constructive review of interim results is a necessary and fundamental component to “agile” thinking.

2 – Establishing Trust and Collaboration – Traditional meetings tend to reward participants for groupthink. In a sense, if you show up and stay silent, you’re sometimes viewed as apathetic at best and lacking leadership at worst. Meetings have sometimes evolved to help people showcase their achievements. Unfortunately, that has led to cultures that reward grandstanding and destructive critique.
Agile requires far more openness and requires the cycle of mistrust be replaced with barriers to unproductive feedback. ScrumMasters (aka process owners in agile teams) have to be enabled to limit unconstructive meetings and put process in place to provide trust and collaboration.

3 – Review, Collaborate, Review – Agile requires many more review cycles than traditional waterfall process for software development. It is also one of the main reasons why it provides better predictability in terms of achieving schedule and feature goals.
If you are used to review meetings that last a few hours, you’ll be in for a culture shock when you move to “agile”. Agile meetings should last 30 minutes to 1 hour and have set objectives about what is accomplished. There has to also be contextual definition for the purpose of the meeting – whether it’s to review accomplishments since the last sprint or whether it’s to design/define/refine for the next sprint.

Naturally, “getting it right” is the key to making Agile work for your organization. But you can also see that some of the aspects to making Agile work is counter-intuitive as compared to how normal companies currently function. NeoContext provides services to help clients transform their offshore teams into Agile teams.

Posted in Agile Offshore, Offshore Best Practices | Leave a comment

Agile Offshore – Introduction and Why Startups should care

By jchiang | Published: November 25, 2010

This is Part 1 of 4 series on Agile Offshore and how it supports new startups and entrepreneurs.

When entrepreneurs think of offshore, several things come to mind – cheap labor (like Chinese manufacturing sweatshops) and lost jobs. It’s a horrible reality, but many jobs, especially in manufacturing and automotive, have moved overseas because of the availability of cheaper, lower skilled workers. When it comes to technology, most people would definitely not think of offshore firms as innovators.

However, in the past five years, a number of factors have changed to make offshore development teams much more amenable for incubating new startup concepts. Using offshore development teams may actually be one of the more efficient and productive ways to incubate new company ideas, especially when it comes to technology and Internet companies.

Agile Offshore is a new technology movement that adopts “agile” methods in using temporary offshore development teams to incubate new startup ideas. Instead of hiring a technology team to start a new company, the initial product and technology is provided by an offshore firm, under the close supervision of the founding entrepreneurs. In fact, this new model eliminates the product development risk and allows entrepreneurs to focus on the core business and optimizing the user experience.

For entrepreneurs, the benefits are substantial. Instead of a fixed cost structure, offshore development teams can be scaled up and down, depending on the demand cycles. Many startups fail because ramping up the headcount and cost structure too quickly reduces the time the company can prove out the business model and extends the time to reach profitability.

Why hasn’t this worked in the past? Until recently, the tools to allow for intelligent and productive collaboration over the Internet were still very immature. Many companies approached offshore teams as a commodity item, leading to high levels of attrition and brain drain once the team is up-to-speed. Traditional processes that worked well in a corporate setting are poorly adapted to collaboration across geographies. There are many reasons why offshore projects have failed in the past. Agile methods, with it’s roots in engineering and rapid prototyping, have been able to demonstrate success in maximizing productivity of offshore teams.

With the RIGHT offshore team, closely matched in terms of technology and industry experience, offshore teams can be an incredibly efficient vehicle to launch a new business idea within months as opposed to years, and with limited startup funding.

Posted in Uncategorized | Leave a comment

Great Entrepreneur Lessons from Skype’s Niklas Zennstrom

By jchiang | Published: November 15, 2010

I’ve heard a lot of things about Skype, the founding of Skype, and the predecessor company called Kazaa (that made him be a fugitive from the law for a few years because of music/media copyright issues). His story is so very interesting and I wanted to share an interview from him about entrepreneurship …

http://www.wired.co.uk/news/archive/2010-11/02/niklas-zennstrom

Some highlights …

“You shouldn’t be afraid of failure” - I think this is one of the main reasons why people with great ideas don’t take even the small initial steps to put in action.

“Think globally.” - I take this to heart. It’s ridiculous to imagine boundaries for businesses, in terms of talent base or in terms of target markets.

“Often you’re the only one who believes in what you’re doing.” – This explains why there are so many professional naysayers that spend their time pointing out the negatives of your great idea. A big part of entreneurship is believing in your vision, even when no one else shares your vision.

Posted in Entrepreneurship, Institutional Startups, Lean Offshore Startups | Leave a comment

Private vs. Public Clouds – Adoption based on Cost and Security issues

By jchiang | Published: November 8, 2010

This is a quick article on private vs. the public clouds. Obviously, there’s been a lot of interest in terms of cloud computing and how it affects the enterprise, applications, and ultimately, customers.

Cloud computing comes with a great number of benefits. The most obvious is the fact that you can effectively get more processing power from the same amount of hardware, if you chose to implement a cloud infrastructure. In addition, if you chose to use a public cloud option, if provides for nearly limitless scalability, as you need it, without having to purchase and maintain hardware and computing resources directly. A huge benefit!

However, the private cloud discussion has been continuing as well. The private cloud is the implementation of virtualization software in private data centers to virtualize services and “hopefully” maximize computing power, minimize maintenance, and reduce overall power consumption (ironic that the IT industry is now a proponent of reducing power consumption).

One of the main benefits of the private cloud concept is that it reduces and eliminates the dependency on outside vendors for the storage and processing of corporate data. Hence, it is “private”. However, as the following article attests, the cost advantages of private vs. public clouds simply is not compelling enough for many firms to migrate to a private cloud in the short term.

Here’s the link to the article: http://www.zdnet.com/blog/saas/private-cloud-discredited-part-1/1204

There was also a recent survey by IBM that suggests that corporate CIOs are still very concerned about security issues, even in the private cloud environment, which suggests that cloud adoption in the enterprise will take at least a few years.

Here’s the link to the article: http://www.zdnet.com/blog/service-oriented/ibm-survey-social-mobile-cloud-are-high-risk-soa-low-risk/6108

Instead, many firms are waiting for public clouds to become more secure and to be more widely adopted before migrating internal datacenters to the public cloud. Also, offerings from outsourcing vendors like IBM provide for a hybrid solution … datacenters managed in public area (outside of traditional data centers), but operated as a private cloud (other customers do not access the same computing and data storage space).

Posted in Uncategorized | 1 Comment

Shortcomings of the oDesk Temporary Contractor model

By jchiang | Published: November 1, 2010

When you look for outside talent, where do you look? If you’re like most, you would look first to your personal and professional contacts. If you hit deadend, you would sometimes go to places like oDesk, Craigslist, and other temporary work jobsites.

Indeed, the oDesk model has grown in popularity over the years. Many early entrepreneurs and small businesses find that the people available for projects is very cost-effective and so enlist them to complete mini-projects on their behalf. Sourcing the talent is usually very fast and the transaction model is very well adopted. Recently, there’s even a movement towards “crowdsourcing”, a method in which one or more jobs is assigned to an entire “crowd”, each member of which performs a subset of the entire assignment.

For certain types of projects, it really makes sense to find the most-effective talent available to perform the job for you. However, there are some substantial drawbacks to the temporary workforce model:

- Limited Continuity – Many of the oDesk contractors are there mainly because they have valuable skills and they may be between permanent positions. When they are able to find permanent jobs, they often quit their assignments, or even worse, they continue your assignment without giving it the attention that it deserves.

- No Oversight – Since it’s mainly a vehicle for temporary assignments, it’s difficult to maintain any level of oversight over a project. Many times, you can specify the project and expect to have the next interaction when the project is completely done.

- No Knowledge Management – Regardless of the assigned task, there’s always a ramp-up period and necessary knowledge transfer to enable a consultant to be effective. Effective knowledge management enables easy ramp-up time for new members and ensures that the IP and know-how for the company is well protected and preserved. With transactional contracts, knowledge management is often impossible.

- Too Distributed – Although NeoContext specializes in implementing processes that improve the effectiveness of offshore distributed teams, we do advocate that there is some locality to the development teams. There are a number of companies that have been built up using contracted resources from many different geographies. It often becomes a model that cannot scale effectively.

- No Scalability – For many startups and SMBs that use this model, they find that the biggest issue is that if they needed to scale their operation, temporary and distributed labor becomes unmanageable after you scale beyond a certain point. The attrition alone would defeat any cost advantages to using a wholely temporary workforce.

So, although the temporary contractor model may work for some types of projects, it often falls short when you’re trying to develop into a larger business.

Posted in Lean Offshore Startups, Offshore Best Practices, SMB Offshoring | Leave a comment

For Startups – Changing Management Teams as a Pivot?

By jchiang | Published: October 27, 2010

At NeoContext, we’re great advocates of the Lean Startup approach. Instead of pretending that all is known, the Lean Startup approach recognizes that most of the success of the startup is about the customer and through experimentation and customer validation, building a business that can intelligently address their needs.

In Silicon Valley, companies are often forced to change direction. They realize that initial plans were flawed, customer projections were imaginary at best, and that customers were not adopting as fast as they had hoped. More often than not, venture capitalists force a “Pivot” by changing the management team. It definitely explains the huge turnover at startup management teams.

Steve Blank, one of the leading visionary heads to the Lean Startup movement, wrote the following blog:

http://steveblank.com/2010/11/18/crisis-management-by-firing-executives—there’s-a-better-way/

It really illustrates why pivots are so necessary through most startup evolution, even when it was practiced as a management change.

Posted in Entrepreneurship, Lean Offshore Startups, Uncategorized, Venture Capital | Leave a comment

Offshore Best Practices – How to develop a Services team?

By jchiang | Published: October 22, 2010

Offshoring comes in many flavors – i.e. Call center outsourcing, legal processing, BPO, etc. Depending the many factors, it’s impossible to implement one process that solves all problems. One major consideration to consider is the context you are using an offshore team for, whether it is products, projects, engineering, or services (the main subject of today’s blog).

Most companies want to ignore some of the complexity and suggest that all offshoring is the same. It’s perceived to be easier to address the topic in very general terms with lots of handwaving in hopes of shortening a sales cycle. However, there really is a big difference in what types of offshore models to use to assure success …. and it substantially depends on the Context.

NeoContext is service provider that implements “Agile Offshoring”, a process that increases productivity and effectiveness of offshore teams. NeoContext, as the name suggests, was based on developing different processes that are optimized based on the “context” of the engagement. NeoContext does not advocate for a one-size-fits-all approach to consulting. Most of the business is dedicated to product development, technical projects, and engineering talent augmentation.

For most service companies, the logical unit of work is usually a project for customization for a specific customer, with it’s own very customer-specific requirements. The typical service model is to concurrently execute multiple projects (for multiple customers) by staggering the assigned resources at any time (i.e. You may only need a technical architect for a small part of the project).

For Services Offshoring, the challenge is to develop an offshoring model that works and naturally extends a locally-based services team. Usually, services companies have a sales and lead consultant manage the customer engagement. For many customer facing roles, it’s really quite difficult to have an equivalent offshore model . However, the service delivery cycle (for each project) can be efficiently addressed via an offshore team.

The key is to maintain the project context in the offshore process. Instead of building a team based on a specific function (like QA only), services companies would benefit from building a team that can address the entire project lifecycle, excluding critical customer-facing roles. In that way, if you implement the right process, you can scale the offshore team as you need to – maintaining Agility.

In general, traditional product development processes do not work well in a Service Offshoring model. The only exception is the Hybrid Agile model, details are in this blog entry: The Myth of All of Nothing – the Hybrid Agile Offshore Model

Posted in SMB Offshoring | 1 Comment

Agile Offshore – Why is it so hard to go “Agile”? Why does it apply to offshore teams?

By jchiang | Published: October 15, 2010

When I introduce and mention “Agile Offshoring”, I’m often asked why these two things would go together. Agile (often times associated with Scrum) is famous for the quick, interactive, and face-to-face team meetings. Whereas offshore/distributed teams are obviously not colocated, how can “Agile” apply to offshore teams at all?

Consider this: What is the alternative? Realistically, you can not necessarily colocate all project resources in a given location all the time. For many companies, distributed teams are the norm. Multiple research divisions, separate manufacturing sites, project leaders that depend on matrix teams, talent sharing among groups – all of these are realities of a modern company.

The ability to colocate a team in one place is usually a luxury rather than the norm. However, we also do recognize that agile practices are often most effective when all team members are colocated. That said, the benefits of business agility should not be limited only to co-located teams, as this is often the exception rather than the rule.

Managing distributed teams (for one project or one product) offers many challenges that are not obvious – for example, the synchronization between team deliverables, common interfaces, business design concerns, etc. However, agile methods, as opposed to traditional waterfall methods, is usually the only RIGHT way to manage the project. Let me explain.

Many managers believe that it is simpler to clearly define responsibilities between teams and so, try to delegate specific tasks and responsibilities to each team. Clearly defined responsibilities and tasks is part of the mantra of project management. With distributed teams, the thinking is to MINIMIZE the communication necessary by clearly defining tasks specific to the location. Perhaps you’ll have one group focus on the UI and the other on the backend application environment. This scenario is probably the most common but often, the most error prone.

Whereas communication is arguably more difficult with distributed teams, efforts should be made to MAXIMIZE, not minimize, team communication. Consider this – if it’s hard to communicate already, why put processes in place that further exacerbate the problem? If communication is hard to do, is it rational to think of ways to not do it? Isn’t this purely a case of avoidance?

Alas, many projects end up as failures because of communication problems. Regardless of how carefully a project manager tries to separate responsibilities, the lack of collaboration will often ultimately doom the project.

At NeoContext, we talk to a lot of companies that run into this problem. At first, the interviewees indicate that there’s a problem at the remote site – failed deliverables, not meeting specifications, general lack of quality. My follow-on question is always: “When’s the last time you talked to the other team?” Sadly, the answer is typically “Last Tuesday”. It’s really no wonder why distributed projects fail – communication is not actively encouraged between the distributed teams.

Posted in Agile Offshore | 1 Comment

Offshore Best Practices – Do you want “great” quality? What’s your objective?

By jchiang | Published: October 1, 2010

Quality … the word evokes images of fine-tuned machines, expert craftsmanship, … the good life. Let’s face it – given the option, most would choose “great” quality over “cheap”. Quality is much like motherhood and apple pie. It’s all goodness.

Recently, I read an article by Eric Ries entitled “Good Enough never is or is it?”. Here’s the link: http://www.startuplessonslearned.com/2010/09/good-enough-never-is-or-is-it.html

The article discusses the perception of quality and how it relates to the Lean Startup concept of “Minimum Viable Product”. It argues that in many instances, releasing products early with “good” quality is often better than waiting for “great” quality. A great example is the introduction of Google Maps, an innovative product that was released very early with many bugs, but still became one of the most successful products in it’s space.

The quality movement probably began with the trade wars with Japan in the 70’s and 80’s. Much of what you hear about “Total Quality” and “Six-sigma” quality control was borne when American manufacturing was struggling against cheaper and perceived better quality products from Japanese manufacturers (especially in autos and electronics). Thirty years later, we’re still obsessed with quality, applying manufacturing concepts to all aspects of industry, including software products.

I guess the rationale is … Manufacturing jet engines is a lot like making software? Are you kidding me?

This reminds of the “potato chip vs. semiconductor chips” debate. Yes – they are different. In fact, it is so different, that it’s hard to imagine any similarities. Pretty obvious, eh? Then, why do take for granted that processes that worked for Jack Welch’s GE will work for Microsoft? or for Intuit? or for any number of software companies on the planet?

That said, I am extremely thankful that six sigma is implemented to eliminate production flaws in jet engines … Lots of bad things can happen if you have failures … But can the same be said about software? Major companies like Google, Ebay, Yahoo have all experienced widespread system failures and the impact has been …. minimal. You wait a couple more hours to access your email or search for your favority movie star. Not a big deal.

The truth is that quality is often used a “cover-your-butt” excuse for why there are delays … it’s important for a firm to have the appearance of professionalism, etc. Put your best foot forward, etc. Worse yet, no one wants to be blamed or fired for releasing a flawed product. Hence, many companies end up in a state of analysis-paralysis, often times trying to “release when perfect”, with everything thrown in, including the kitchen sink.

If your objective is to demonstrate good quality, then it is still essential to implement high quality control standards. After all, customer touch points through software products is an extension of a company brand and all would be benefit from “high quality” brand.

However, if your objective is fast time-to-market, time-to-profitability, and incorporating early customer input, quality may not be your primary concern. In fact, quality may be completely tangential to a more important objective … to win.

Posted in Lean Offshore Startups | 1 Comment

Prediction: Cloud computing will speed the offshoring and further virtualization of IT services

By jchiang | Published: September 30, 2010

I wanted to continue my thought on a blog posted 9/15/2010, entitled “What does Cloud Computing mean for you and your business?”. Here’s the link: http://blog.neocontext.com/?p=109

I pointed out some of the outstanding issues with the adoption of Cloud Computing in the mainstream. As I mentioned in the article, except for some use of virtualization in “private” data center installations, adoption of “public” cloud infrastructure for mission-critical applications has been slow. However, technology changes quickly and many of the outstanding issues, especially regarding security and interoperability, are rapidly being solved.

This all suggests one thing : public clouds will gain momentum in the next couple of years. The economics and productivity promised by public clouds is too compelling.

What does this mean to offshoring and virtualization of IT services? It promises to further accelerate the adoption of virtual service providers (like offshore developers) in the delivery and customization of IT services.

One of the major barriers to Indian IT firms in service delivery is the inadequate technology infrastructure that supports India-based technology firms. The availability of network and power is unreliable at best and requires the implementation of local UPS infrastruture as well as redundant network access points. Every one of NeoContext technology partners are required to demonstrate that their technology infrastructure is redundant enough to minimize disruptions and sapped productivity.

Even with locally-deployed redundancy, systemic failures like power outages can easily undermine a days productivity. In India, the power grid is still immature and can be fickle to the point of responding to the timing of local elections. Imagine trying to work in an environment of rolling and unplanned power outages. It’s frustrating, to say the least.

With the adoption of Cloud Computing, the development and support personnel are no longer reliant on local development and production systems. Instead, the entire technology environment can be deployed and managed 100% in the cloud, reducing the need or requirement to have locally-deployed technology infrastructure. Your development and production environments can be completely cloud-hosted.

In addition, clouds further virtualize the technology environment from local users. The former days when engineers can be found huddled together around a big server may be long gone. Cloud deployments naturally lend itself to virtual teams, further reducing the need for locality in collaborative development. Large distributed teams will likely be more of the norm; It will be more important to have the RIGHT talent available as opposed to having a physically-localized team.

The challenge continues to be in how to productively managing distributed development teams (across time zones and cultures). NeoContext believes that the adoption of agile development practices is fundamental to gaining strong ROI from your distributed teams.

Posted in Cloud Computing | Leave a comment

Comment on NYTimes article on Manic Entrepreneurs …

By jchiang | Published: September 18, 2010

Here’s a link to a NYTimes article entitled “Just Manic Enough: Seeking Perfect Entrepreneurs” – http://www.nytimes.com/2010/09/19/business/19entre.html?th&emc=th

The article discusses how people with borderline manic behavior are considered “perfect” entrepreneurs. It also goes on to discuss how VCs are often trying to find the next Zuckerberg, and in so doing, end up funding people who are hypomanic – with traits clinically described grandiosity, an elevated and expansive mood, racing thoughts and little need for sleep. Seth Priebatsch, the hypomanic described in the story, received millions inVC funding by the likes of Highland Capital Partners and Google Ventures. Here’s how Seth is described in the article:

“To keep the pace of his thoughts and conversation at manageable levels, he runs on a track every morning until he literally collapses. He can work 96 hours in a row. He plans to live in his office, crashing in a sleeping bag. He describes anything that distracts him and his future colleagues, even for minutes, as ‘evil.”

Am I the only one that thinks this is absolutely nuts? Venture investors are actively looking for people with borderline personality disorders that manifest as”grandiose” visions of technology companies to fund? If this is the case, is anyone surprised that:

- Founding CEOs practically never last, often replaced with an operations CEO if and when the company gains traction.

- Many VC-funded companies are crippled by a singular vision that often turns out to be completely unmarketable.

- Venture funds have had below-market returns for the past 10 years. There just aren’t that many Facebooks in the world.

To tell you the truth, I’m a huge fan of the work ethic of the subject of this story. I think if you’re committed to making a company a reality, spending all of your available time on it is not unreasonable. Many of the behaviors of a hypomanic are also very useful in evangelizing and selling to new customers. However, the “blinders-on”, sleep-deprived, and isolated approach is not usually a good thing for any company. In particular, it’s probably the worst for a company trying to invent a new market.

I think a return to rational investment methods may make sense for early-stage technology investments. You know … solid go-to-market plans, customer interviews, market studies. Of course, all processes should be tempered with an agile approach – lots of feedback between engineering and sales and continuous market validation.

Posted in Entrepreneurship | Leave a comment

Cloud Computing – What does Cloud Computing mean for you and your business?

By jchiang | Published: September 15, 2010

If you’re a technologist, I’m sure that you would have much ado about Cloud Computing. The term “cloud” is probably the new new thing in software technology, with lots of new software startups in the cloud space. Alas, even established firms are re-messaging around the idea of being a Cloud company.

Clouds may mean different things to different people. Mostly, it refers to the virtualization of the computing environment to the Internet. So instead of traditionally buying hardware and software to construct and run an application, all of that application infrastructure can be “leased” from a provider at a pay-as-you-go model.

If you’ve heard something similar to this, you’re not alone. Many years ago, the same messaging has been used for hosting mainframes, database scalability, hosted services, and most recently, Software-as-a-Service. The Cloud is simply the next iteration of the further virtualization and commoditization of software and hardware.

However, as with most technologies, there is far more hype than reality. There are a number of key questions that still need to be answered:

1 – Are there standards between cloud providers? The short answer is No. It’s a Wild west environment with Amazon setting the de facto industry standard as the vendor with the most mature solutions.

2 – Have security and service-level concerns been addressed for the (public) cloud? For the most part, there are vendor-specific SLAs that provide assurance of service-level for customers. However, as we’ve seen in highly-publicized cloud failures, data has been lost and execution environments have experienced downtime. Security is still a huge unknown and one the main reasons why private companies would not entertain outsourcing their internal applications to an outside cloud provider (even when the cost advantages are very compelling).

3 – Are there others who have run mission-critical applications on the cloud? Sometimes. Private clouds are virtualized environments within a private data center. So, in some instances, virtualization software from vendors like VMWare and Citrix have been used to virtualize the data center and provide for private clouds that then run mission-critical applications for an enterprise. However, I have not heard of implementations of mission-critical applications running as a purely outsourced application on the public cloud. Semantically, Salesforce and similar SaaS providers would argue that they are mission-critical. However, they are still in the SaaS space because they are mostly application-specific.

So, what this all mean to you? As an entrepreneur and hopefully, an Lean Startup practitioner, it makes sense to architect your software so that it can run optimally in a cloud environment. In fact, it’s a huge advantage to not have to procure, install, and maintain hardware and software as you develop your business (it’s a huge distraction). The key benefit is that you can leverage the cloud infrastructure to scale up as needed, when your killer application is discovered and you’re suddenly getting millions of clicks per day.

Clouds offer superior Agility … If you’re read my previous blogs, you would recognize how important I think Agility is. A simple application that suddenly gains traction may quickly be overwhelmed if you do not plan for scalability and availability in the beginning. Clouds offer the potential to scale your application at the push of a button, instead of requiring buying bigger and much more expensive hardware. Clouds can help scale intelligently with your business.

That said, cloud technology is still shaking out as part of the natural maturation process. The solutions available today do work, but much of the industry is working out the kinks as we speak. I would hope that large-scale cloud adoption and commonly-adopted standards will be available in the next 2 years (though, it’s just a guess).

From an Agile Offshore perspective, there are many projects that are started, developed, and executed all within a virtualized cloud environment. So, business owners and offshore development partners never need to coordinate on the hardware/software infrastructure needed to facilitate a new project.

Posted in Cloud Computing | 1 Comment

Venture Capital – Comment on Technology Review’s write-up

By jchiang | Published: September 1, 2010

One of the many benefits of being an MIT grad is that they send you the Technology Review, a magazine about technology that is published by the University. Another great benefit is that frequently, life is too busy, and so it’s taken me a while to catch up with the latest magazines. Anyway …

I was reading the March/April 2010 edition and happened on the article entitled “Sick Capital – Why it matters that VCs won’t do their jobs”. Here’s a link to the online version – http://www.technologyreview.com/business/24557/

It’s rare to read an article and find myself nodding along continually – I’m in complete agreement. Here are some of the points that are summarized:

1 – Funds launched in 1996/1997 experienced 80-100 percent annualized returns. Yahoo! Thanks to dot-com. Funds launched in 1999/2000 lost money. Ouch!! “Venture capital funds, as a whole, basically made no money the entire decade.”

…. I wonder how they justify the 2% management fee??

2 – Markets for new technology stocks are frozen. In 2009, 13 venture-backed companies went public. In 1999, there were 271.

…. No exits in the public markets means that exits are limited to crowded M&A from public companies with enough cash.

3 – No one buys as much technology anymore. IT enterprise spending grew at 15% during 1990s, single digit growth in the past decade.

…. Less growth in technology spending means far less companies are willing to use “discretionary” IT funds for products from new startups.

4 – There is already too much venture capital, but entrepreneurs need less funding. Cost to launch startups have fallen by order of magnitude, because of open-source and outsourced software development.

…. Too much venture capital money means that more money needs to be invested (put to work) in each portfolio company.

…. Less money is needed for each startup and so, fewer and fewer companies are a good fit for a venture investment.

5 – VCs no longer perform their historical functions: recognizing a few potentially disruptive technologies, finding great entrepreneurs who burn to commercialize those technologies, providing measured seed funding, etc. Instead, partners of the typical fund invest more money, much later, in more companies, selected according to some risk management philosophy.

…. VCs are no longer the VCs that you can recognize or have read about in the past. They are predominately growth-stage company investors, much more like traditional bankers. For growth stage companies, it’s harder to recognize the benefits of late-stage equity financing by institutional VCs over traditional debt financing from banks.

All of this leads to a fairly dismal conclusion for new entrepreneurs looking for venture capital funding. Fewer and fewer VCs are able or willing to take on the risk of an early-stage company. However, the bright side is that if you can run your company extra lean and leverage offshore talents and open source software, you may never need to take early-stage VC money and experience the high-dilution effect.

Posted in Venture Capital | Leave a comment

About NeoContext – How did NeoContext get started and why?

By jchiang | Published: August 15, 2010

I know that my bio is posted on the NeoContext webpage … http://www.neocontext.com/about-us.htm. It doesn’t quite tell you the whole story about how NeoContext came about.

After graduating from MIT in early 90’s, I started my career developing highly complex mission-critical applications for big investment banks. It was an exciting time, but I decided that I wanted to know more about how software is developed and moved to a software technology company in Silicon Valley. Subsequently, I’ve played leadership roles in product management and engineering in both startup and established software companies.

Through my experience in leadership roles, I know the pains of trying to innovate successfully, whether it’s the establishment of a new startup or whether it’s trying to develop a new business within a larger technology company. Nevertheless, innovation is the key to driving growth and it is essential for all companies, big and small, to figure out how best to accomplish it.

But this has brought me to another incredible conclusion:

—- > Much of what we know (or think we know) about how to start a company or innovate is simply WRONG.

How could that be? Simply put, the pace of technology and industry forces is so fast that the “great” lessons learned from past successes may no longer be applicable. There are enough game changers introduced that it forces us to re-evaluate constantly.

A bigger reason why conventional wisdom fails has a lot to do with who is telling the story. Human nature dictates that we try to explain the great phenomena around us, whether it’s how the Sun comes up every morning or whether it’s how Apple (insert your favorite technology success story) became a success.

Insert some MBAs and journalists into the mix and what do you have … interesting thought-provoking stories about the right “formula” for start-up success. There’s a belief, similar to the elusive unified theory in physics, that if you follow the right formulaic steps (ex. 1, 2, 3, and 4) it would automatically guarantee (or at least, increase chances of) success. Further, these formulas seem to be so broad and general that they would seemingly apply to all startup ideas, regardless of industry, domain, and markets. Quite absurd!

Indeed, entrepreneurship is probably one of the few areas that can never be formulaic, for the simple reason that everyone would be following the same formula. If the formula worked, you would see far more successful startups than is currently the case.

However, there is a positive corollary to this:

—- > By not trying, you’re guaranteed failure. So, even though there is no great formula to guarantee success, it’s more important to try and preferably, to try often to achieve success. That is the essence of what NeoContext is designed to do.

By helping clients quickly and cost-effectively develop working prototypes, we can help clients realize an idea. It’s then up the client to test the idea in the market to see if it can be successful and what can be learned. Agility is critical in the start-up phase to determine the best course to get to the “killer” idea that you can be used as a basis for a profitable company.

There are so many people with brilliant ideas that are never tested in the marketplace. Most ideas are never incubated because of lack of funds, lack of support from management, too much technology risk, lack of management experience, etc. Yet, it is these ideas that are critical to fueling the larger economy.

NeoContext was created to reduce the friction and help entrepreneurs turn ideas into real products.

Posted in About NeoContext, Entrepreneurship | Leave a comment