Beginners Guide:

• Getting Started with Ruby on Rails by Jan Varwig, Smashing Magazine, Part 1 and 2
• Learn Ruby the Hard Way

References I need from time to time:

• Ruby on Rails API
• Ruby on Rails Guides
• Ruby on Rails Tutorial Book
• The Pragmatic Programmer’s Guide: Programming Ruby

Related posts:

1. Daily Annotations: Peter Thiel’s Startups Notes

I have organized the notes here, and you can click to read them from Blake Masters’ site:

• Class 1: The Challenge of the Future
• Class 2: Party Like it’s 1999?
• Class 3: Value Systems – This set of notes triggered an article by David Brooks entitled “The Creative Monopoly“, which puts an interesting spin on the confusion of capitalism with competition. In Brooks’ words, “We tend to think that whoever competes best comes out ahead. In the race to be more competitive, we sometimes confuse what is hard with what is valuable. The intensity of competition becomes a proxy for value.”
• Class 4: The Last Mover Advantage
• Class 5: The Mechanics of Mafia with Stephen Cohen, co-founder and Executive VP of Palantir Technologies, and Max Levchin of PayPal and Slide.
• Class 6: Thiel’s Law – A startup messed up at its foundation cannot be fixed.
• Class 7: Follow The Money with Roelof Botha, partner at Sequoia Capital and former CFO of PayPal, and Paul Graham, partner and co-founder of Y Combinator.
• Class 8: The Pitch
• Class 9: If You Build It, Will They Come?
• Class 10: After Web 2.0 with Marc Andressen
• Class 11: Secrets
• Class 12: War and Peace

with Reid Hoffman (co-founder, LinkedIn & partner, Greylock Ventures).

From time to time, I will update some interesting annotations and ideas arising from the notes itself. The way how the notes are presented utilized abstract principles from philosophy and pragmatic ideas from economics. For the layman, it might be best to read it a couple of times to distill what it is being said, for example, the ideas on competition and capitalism being challenged in class 3. It’s similar to other well-known lecture series like the Richard Feynman’s lectures of Physics, Thiel’s notes are very similar that it might be preached for the layman or undergraduates but it may be more insightful for people who are practitioners or have taught the craft to students as well.

Related posts:

1. Daily Annotations: Ruby on Rails

Video of the talk in JFDI Asia – credits to JFDI for recording it

• Part 1 – Product Development: Product development is only one part of the product cycle. That’s the part I will focus on this article. Managing the product from feedback of users and marketing the product are also tied to build up the start-up as a sustainable business but we will talk about that later. How shall a team of co-founders start in their product development cycle? The answer is a product roadmap from the very start with a clear vision and mission of the company in how it solves the one important problem from the user.
• Part 2 – Product Marketing: So, in order for a product to go to market, it needs to overcome two barriers: (a) How will your customers hear about your product? (b) How do your customers access or buy your product?
• Part 3 – Product Management: Product management is probably the toughest of the trio, and that’s why I leave it to the last. The essential aspect of product management is to sew the threads of development and marketing with data measurement, customer feedback and team execution.

Image Credits from Lokas Software.

Related posts:

1. 3 lessons on Innovation & Experimental Marketing in Asia
2. 5 Principles for Agile & High Speed Development @ Open Web Asia
3. Seperated By a Mental Bridge: Thoughts on the Iskander Development Region

• Less frequency of acquisitions for tech companies in Asia due to technology arbitrage and pricing: First of all, most owners of Asian companies or conglomerates are thrifty and less expansive in their acquisitions. Our environment is less sophisticated as compared to what you see in Silicon Valley. If you see the acquisitions of Gowalla and Friendfeed which are examples of acqhire, the rationale is to hire talent on Facebook. They will put a price on the founders and then pay the rest with the stocks of the parent company. That’s also the reason why Twitter rejected the bid from Facebook four years ago, because the amount for payout was too low, based on rumors at that point of time.
• Asian companies only buy one talent and not an entire team of players: To an Asian owner, it’s too expensive to buy a team. Just buy the top guy and it’s enough. Unfortunately, if we examine the acqhire cases in Silicon Valley, it’s pure acquisition of teams of engineers. Probably, one case stood out, was the acquisition of Ngmoco by Gree, and the sole reason was the founder who was a former employee of EA. The cost to buy a team will be less appealing to Asian owners who feel that it’s too expensive, and the technology arbitrage argument kicks in.
• Your investors does not know how to sell: Most venture capitalists in Asia are not sophisticated enough to sell their portfolio of companies to potential acquirers. So, do you think that they are smart enough to structure a acqhire deal with the companies? Another argument is that in the web-tech space, the big four companies (Google, Facebook, Apple & Amazon) together with Microsoft are all located in the US, and hence it’s difficult for Asian investors to get them to acquire. While we see more Chinese & Japanese companies extending their reach to Southeast Asia, the investors are rarely involved in structuring these acquisitions. Usually in Asia, the entrepreneurs do the work most of the time. Time and time again, it’s easier to remind most readers that most venture capitalists in Asia are a bunch of bankers who have no operations experience and that’s why they cannot structure deals in the way how the US guys does it.

In conclusion, it is not difficult to fathom why acqhires are ridiculously difficult to execute for Asian companies in simple words: price, arbitrage and sophistication.

Related posts:

1. Thinking about Expansion out of Singapore to Asia & US

Environment and Circumstances

“A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes.”
- Hugh Downs

In Southeast Asia, it is a much difficult and different battleground for tech start-ups. The issue is often the entrepreneurial ecosystem that is established by the local community around the environment. As the years go by, when I see some investors from so and so famous venture capital firm pass by Singapore, I realized that they have often come to the same few conclusions with a set of pre-conceived biases and prejudices about the Southeast Asia market. To name a few, one, SEA is a fragmented market and two, there are no exits greater than US$30M that justify any one of them to come here. While some signs indicate the potential rise of Indonesian market, it is still a tough ride ahead for tech companies in this region.

We often hope for the eye of investors who looked at a large and heterogeneous market and the investors & older entrepreneurs to have a mindset of those in Silicon Valley & Zhong Guan Cun. The reality is totally the opposite. It also creates the constant platitude lingering in my mind that it would have been much easier if I have been in Silicon Valley, getting the millions to burn from the investors there and create a billion dollar company. In actual fact, we have only one strength but many deficits in the start-up scene. The only strength if you match founder to founder from Southeast Asia against Silicon Valley or Zhong Guan Cun, you won’t see much difference. The difference comes to the employees whether they can scale up to be part of the dream and the ecosystem being more friendly to help one another.

The problem with that thinking is that we can never able to move up the chain without self belief. If we accept the circumstances of our environment, the problem exacerbates in its own way that may be detrimental to how we should move forward despite the difficulties we faced. It may be luck of where you are that might determine your success. Personally, I have to fight against that viewpoint not with anyone but with myself. It’s something really hard to overcome.

Luck and Execution

“Greatness is not primarily a matter of circumstance; Greatness is first & foremost a matter of conscious choice & discipline.”
- Jim Collins, Great by Choice

Somehow, reading biographies of people (Steve Jobs by Walter Isaacson) and companies (In the Plex by Steven Levy) and various books (Jim Collins’ “Great by Choice” and Simon Sinek’s “Start from Why”) helped me to overcome the lingering whim which seem to dominate most of my thought processes. It’s probably easier to explain via three simple arguments:

• Every challenge is difficult and continues to exist whether the success rate is 10% or 0.1%: Here’s a way to think about the ecosystem in Southeast Asia against Silicon Valley and Zhong Guan Cun: the success rate with a good entrepreneurial ecosystem (which takes years to build) may be 0.1% for Southeast Asia and 10% for Silicon Valley or Zhong Guan Cun, with three essential components: one, finding good talent to help you scale your company; two, the abundance of funding from angel to high levels & powerful tech companies in the vicinity from Google to Baidu; and three, a positive feeling and a lively debate within the ecosystem. We will have to constantly be challenged if we are to take on the system fraught with difficulties and obstacles. If it’s that easy, everyone can be an entrepreneur. It’s actually dependent on how hard we keep thinking about the problem and constantly question the “why?” rather than the “how?” and “what?”. Even we fail in our present endeavors with the current start-ups, we can try again. Someone told me that it’s hard for me to try again if things don’t work out for what I am doing now. While hearing that really demoralizing and somewhat insulting comment, I was answering in my mind, “I don’t think so and I am going to try again whether I am 40 because I want to do what I like.” The central idea here is not whether one should try again. We just have to learn from our mistakes and try again even if the environment is not going to be friendly with us. The real lesson is that we have to accept the difficulty of our challenge and focus on solving the problem as hard and to the best we can.
• Overcoming the increasing prevalent view that successes owes more to circumstances and luck than to action and discipline: Probably Jim Collins sums it in his book “Great by Choice”:
  

  Life offer no guarantees. But it does offer strategies for managing the odds, indeed, even managing luck. The eseence of “managing luck” involves four things: (1) cultivating the ability to zoom out to recognize luck when it happens, (2) developing the wisdom to see when, and when not, to let luck disrupt your plans, (3) being sufficiently well-prepared to endure an inevitable spate of bad luck, and (4) creating a positive return on luck – both good luck and bad – when it comes. Luck is not a strategy but getting a positive return on luck is”

• Being resilient and figuring out how to execute the stormy present are keys to success: Having a clear vision and strategy armed with flawless execution still remains the way to build things whether it’s a project, enterprise or company. Sometimes, people give up when they are so close to getting the break. I have given up thinking about what life would be if I am not an entrepreneur. But in the end, I realized that it’s no point in looking back but looking forward to your next challenge in life.

Reflecting over the year, without a rigourous debate with my spouse and wife to be, I could not overcome the greatest enemy which is myself. Probably, we can never cease to learn and that’s what I hope this post here will remind me now and sometime in the future, whether success or failure.

“Good research advances understanding but never provides the ultimate answer; we always have more to learn. And Life offers no guarantees.”
- Jim Collins, “Great by Choice”

No related posts.

Asia Tech Teams and their Cultural Nunances

Probably, if you have the time to speak to various founders of a technology start-up in Asia, you will hear this common feedback from them about their teams, be it outsourcing through a vendor or programming house or building internally:

• They over-promise and they cannot deliver: This is common but there are two sides to the comment. The first is from the perspective of the business owners. They want to get the product out quickly but the problem is that they under-estimated the amount of scope required to build the product, and usually they introduce scope creep to the product without confining the scope of the product properly. The problem lies in the business owners’ lack of familiarity on the technology aspect. To cure that problem, the business owner should do three things: (a) talk to friends who are product managers or CTOs to get some realistic gauge of the product that they are building, (b) read books on project management, agile software development and get some thinking from web design blogs, for example, Smashing Magazine, to learn some best practices about web design and (c) reducing the scope of the product to three features of the prototype and stick to it.

  The second perspective is from the technology people who are often either too honest or too ready to get business. The “too honest” group will get fed up with the business people for full of scope creep, and the “too ready to get business” group will end up taking the project without realizing that hell has just begun.

• They can build the feature but the product is imperfect: Sometimes, the management team dictates how the product is built and to the credit of the technology team, they build it. However, the product can work for the test case but failed for the other cases. How can that happen? The problem is that there is no planning on the technology team to provide adequate unit testing or even instructions to the layman how they can use the product.
• They cannot imagine beyond the technical scope of the product: In harsher words, I often hear my western counterparts or fellow Asians educated either in the US or Europe saying, “They can’t think.” I do agree with the “they can’t think” given the Asian hierarchal culture nuance of “obeying your elders”. However, as product owners and managers, we should encourage to work out how the product works and then put questions to the issues which they might be facing before they start coding. The missing link between the engineers and the business people is the social practice on how the feature is delivered. To mitigate that risk, the engineers should code the feature with an internal discussion on brainstorming the problems which might arise from usage and let the business people test and offer feedback. The tech team should look at several examples of how the same feature is delivered through other web services or mobile

It is important to note that all project managers or business owners should know that they should add a 2x to 5x to the number of days which the whole software development project take. So, if your programming house tells you that they take 100 days to finish the project, be prepared that it will be 200-500 days. The best programming house will finish it within 150-200 and the rest follows. Most outsourced programmers and freelancers will give up the project if they exceed 300 days. So, here’s a rule of thumb. Why does this happen? In a project that you outsourced to a vendor, you have to pay half the money upfront first and then the rest upon completion of the project. In some cases, the payment is split due to the completion of milestones. It’s a problem of economics when the vendor or freelancer takes half the payment and then runs away by the time when they realize that it’s too much work and it’s never going to end because of scope creep. What happens in the end, both loses. The business owners have to salvage the situation and look for another vendor, ending up paying twice the amount. The vendors walked out burnt too with their teams not paid properly and all hell broke loose.

The real challenge is …

The best way to deal with the scope creep is to be really honest about what you want and what you can’t have. Draw up a list of 20 things you want on your site, then systematically eliminate and prioritize which ones come first. Then in the end, focus on the 3-5 things on the list that really matter to the business. If something can be added without hassle, you can get the software engineer to add them later. Life is never perfect, and half the time, you are trying to constrain resources to deliver the highest amount of impact. Business people should learn that the perfect product should have lesser features but works in a seamless way without hassle. The best way to explain this to them, “You can create a feature of buy and add an e-commerce element to your platform, but what’s the point if your payment page keeps getting errors because you don’t spend money to perfect the experience of users buying the stuff from your site?”

Related posts:

1. Building & Managing Technology Teams in Asia 1: The Tech Conundrum
2. Building a (Mobile-Web) Start-up: the 2011 way

Practically the first hour of the start of my day, I usually check into Google News to look for the headlines of the day and then to Google Reader. While that is happening, I have a twitter feed that collects all the news sources on a list so that I can get a real time perspective of any breaking news. With the amount of information I need to catch up on product development (mainly in the mobile and web space), technology news relating to my area of interest and interesting local news annotated by various aggregators in Singapore. Despite with so much information we processed through reading them, how much are really of value to us? That is not adding research reports from analysts in different industrial sectors which will totally flooded your reading list. The answer is not to get more sources or more data, because it is not possible to read everything. Then what should we do?

If you are trying to solve a problem, be it a business, social or personal, what are the essential pieces of information do you really need? Whenever I read my students’ research assignments, a common pattern can be spotted across most of them. They are trying to squeeze every ounce of information. In the end, they did not answer the question which I have put forward to them. The same goes for businesses, when knee jerk reactions can happen because of irrelevant information that derail the strategic objective of the company they are building. So, the conversation with my Singaporean friend in China came down to the following things which we deem to be essential in any area of interest to solve a problem:

• What is the problem you are trying to solve?: This is the hardest question for me because it dominates my train of thought everyday, whether it’s a business or a research problem. Most people are able to state the question but do not really break the question down to what can be solved or not solved. Breaking down the problem is usually lacking in most people, which also explains why most people are overwhelmed by too much information. You can get a lot of information about a problem, but making on a judgement or forming an opinion on how the problem is solved is what is lacking in most people.
• What are the essential pieces of information that you really need in the process of solving the problem or react to external circumstances which render your solution useless to the market?: Here’s how we frame the problem solving parts with the economics concept of demand and supply. In business, we should be asking whether there is a demand for the problem to be solved and then worked from the supply. If you are in the natural resource business like my friend do, his day to day problem to ascertain whether he should buy an develop the natural resource is dependent on whether people really need the problem. In addition, he provided an additional example by recounting his meetings with many wealthy individuals. The question he posed is: what do they really need? The answer seems to be ridiculously simple: (a) how do they grow their wealth more, (b) how do they ensure that their future generations can benefit from the wealth, for example sending them to good schools and (c) how they can have a better life, for example, better housing. In his words, because the needs are so simple, it’s almost difficult to sell them anything else if you focus on these objectives. The other piece of information after demand and supply, is essentially the external threat, whether there is something disruptive that can render your solution useless.
• What should you not care about?: Usually, the problem with people getting updates from different sources is the inability to filter things that are irrelevant. Most of the time, they spend a lot of energy to work out what they care about. The same process can be made more efficient if they do the reverse, i.e. which of these pieces of information are just noise or irrelevant that you can chuck it out of the window immediately?

Ultimately, in everyone’s case, dealing with information inundation is pretty straight forward. The trait of a successful person, be it an entrepreneur or a research scientist, is to make the correct call to major decisions based on a few basic pieces of information and not matter whether lots of data can help or deter you.

No related posts.

If you are a fan of Douglas Adams, the first thing you will notice that the whole biography of Steve Jobs is written in 42 chapters. The author started the book with an introduction to how the book came to be. In the whole book, Isaacson undertook the tough task to reconstruct the life of Steve Jobs through the lens of many people ranging from his family, his friends, his fans and his competitors and forty over interviews with the man himself who was dying of cancer. It examined the legacy of Steve Jobs and provided a glimpse on how he perceived the world. It sheds a lot of details behind the creation of various innovations that Apple has produced from the personal computer Apple II to the iPad. While I have read two other unofficial biographies of Steve Jobs, this biography has shed a lot of light on how Steve Jobs has made his manoeuvres to come back to the company which he co-founded.

Throughout the book, Walter Isaacson built an interesting contrast between Bill Gates and Steve Jobs. Despite their complex love-hate relationship, they both eventually came to the realization the different business models they each have on software were right in their own way. Probably, life is fair in such a way that if you truly believe what you are doing, you will probably show that your model dominate for a period of time, but a competing paradigm will eventually take over for a different time. Isaacson has built this contrast between both men very well as he traced the history of their rivalry from the 80s all the way to the present.

Probably, here are some interesting tidbits of the biography which I thought might be interesting for reflection:

• The importance of building a great team and how the Apple pushed Steve Jobs back: The interesting back story in how his team convinced him to build a iTunes and iPod support for Windows was probably extraordinary. Despite how much he did not agree based on his own personal bias, he was able to make the decision to let it happen. Probably, in the whole book, Tim Cook has summarized elegantly, “I realized very early that if you didn’t voice your opinion, he would mow you down … He takes contrary positions to create more discussion, because it may lead to a better result. So if you don’t feel comfortable disagreeing, then you’ll never survive.”
• The trials and tribulations of building a product: Probably the story on how the iPhone was built remained an interesting tale for all of us who have witnessed how it changed the mobile industry. The backdrop on how Steve Jobs betted on a touch screen design was probably something that it was easy to judge now on hindsight, but tough at that instant of time.
• There’s just one more thing – Steve’s last word: In the last part of the book, Isaacson provided Steve Jobs the platform to summarize what his philosophy in life and why he was driven to do the things that he did. It might be an interesting reflection for us to think about some of the things we do in businesses and acknowledge that building one is difficult. Steve Jobs provided his final thoughts on why companies such as Microsoft and IBM failed to innovate based on the reasons that they relied more on sales to drive revenues rather than building great products.

Whatever it is, if you are passionate about building a product or business, this is probably one that you should read. Steve Jobs is not perfect but what made him different is that he has managed to engineer a comeback which not many people can in the face of their failures and built interesting products that have changed the world across three decades. That, in itself, is why we come to admire and mourn his passing.

No related posts.

Why Companies outsource and the cost effective reasoning does not work

In a typical start-up particularly one in the mobile-web technology space, should you build your own technology team or outsource your technology building to someone else? If the technology you seek to build exists, it is likely that an Asian business owner will pay a programmer to clone it. Why is it cheaper to clone? On a macro-economical scale, the Asian business owner is trying to perform a technology arbitrage where he or she clone something and execute the same business at a lower costs. You will hear about the thousand Groupon clones in China, or the AirBnB clones in Southeast Asia or Middle East funded by a few group of people.

The common thinking among people with business but no technology background (particularly those with MBAs) is to outsource. Of course, if you are Asian (or even American), you will typically hear everyone telling you to outsource the job to Indian programmers. In fact, the common case studies most people will cite are the multi-national corporations from Microsoft to Nokia claiming success in outsourcing their operations to India. Unfortunately, when you start talking to start-up owners even if they are trying to clone a Silicon Valley start-up, you will start to hear the following about Indian programmers: (a) they are lazy and very hard to manage if you are far away, (b) they don’t seem to understand your instructions because they seriously cannot communicate and (c) they don’t get what you want to do correct and worse, they made a mess out of it. This is not intended to insult or dissuade you against using or hiring Indian programmers. The same problem spread across most Asian programmers. Very few and good Asian programmers exist but chances are, the lure of a giant salary from an investment bank or a multi-national company will draw them away.

One must be wondering why most Asian companies (even for start-ups) have consistently perpetuated the myth that outsourcing is good for building web and mobile technologies. Cost effectiveness is often cited as the main reason. If you are outsourcing specific operations which are mechanical, the reasoning is correct. However, some people with business backgrounds (particularly MBAs who were former consultants and investment bankers) tried to map the same reasoning into building their start-ups. The eventual result is that most of them crash and burn because they did not have a proper technology team or worse, not even a technologically inclined co-founder. The same goes for middle to large businesses in Asia. Why is that so? Why are these people did not want to invest more resources in building proper technology teams in Asia and wasted money later to repair large scale IT infrastructure or technology failures?

(Credit: SydesJokes.com)

The Intangible Cost of Technical Debt

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
- Ward Cunningham

The management from any start-up or company often justifies their outsourcing of technology based on the argument of cost effectiveness. It’s a very one dimensional argument and we can’t really fault them because their intention is to take the product (a website or a mobile application) to market at the shortest time possible. What they end up discover later, is that the solution that they are building is not entirely what they have intended or some failure in the IT infrastructure which they did not foresee like database crashes or security breaches.

What business theory did not teach them is the problem of technical debt in building a web or mobile technology. When a business owners builds a website by outsourcing it to a freelancer or a programming house, they often rely on them to pick the correct technology to implement the solution. What they don’t realize is that the business model for freelancers and programming houses is that they need to make a profit by working in several projects at the same time. For a start, both your business objectives do not align, because you have no awareness of your technology and you are being held hostage if problems happened by the vendor. Since we know that if the team you are outsourcing to is not focused, it results in three things: (a) lack of focus and hence poor code written to build the features on your site, (b) selecting the wrong database infrastructure or frameworks which may not align with your business objectives and (c) drop their hands off the project if you are not paying them enough and ended up you wasting more financial resources to repair the problems you have. So, when you outsource your technology building, you have actually incurred more technical debt with a higher interest as compared to those who start off by spending more money in building their own technology teams but reducing the interest rate of technical debt. The problem will come back to bite you in the future.

Precisely, the cost effectiveness argument fail because in the longer term perspective, the technical debt that was incurred in building cheap will come back to bite the business owner. In most cases, it will trigger a rewrite of the code, which the business owner is reluctant or have no choice to pay or they have to give up on the entire technology platform.

Dealing with the “I can’t hire any tech talent” problem

Another common excuse for most business owners is that there are no technical talent available. As a matter of fact, this is a common problem endemic not just in Asia but also in technology clusters such as Silicon Valley and Zhong Guan Cun. According to some, the problem is worse because the better engineers in Silicon Valley will prefer to work in the bigger companies like Facebook and Google rather than with start-ups unless they are on the ascendency. The correct way to phrase this is that there is no software engineer which fits criteria of your choice. In my experience working in a research institute, most researchers usually enter with no relevant software programming skills. The problem is exacerbated in Asia because most software engineers don’t fit basic requirements. Not just software engineers, the same can be said of user interace and user experience designers for web and mobile.

Why is Asia having so much shortage of good engineers? The key reason is that IT programmers are treated like digital coolies, a term which is used for labour workers in trading ports during the 18th and 19th century. There is a lack of incentive for innovation because people do not spent time or provide any incentives to help engineers to upgrade themselves or a feasible and decent career path. As a result, we have a shortage, and the better ones decided that it is better to service clients on a project basis and become freelancers. As a result, due to a mis-alignment of objectives, the problem of technology talent in most Asian countries has grown worse in the past decade.

There are ways to build a technology team in Asia but it requires configuration changes in not just building them from scratch and providing some allowance for error. In the next post, I will discuss a few models on how one can build and manage one with also the correct incentives and objectives. However, it requires some resources and a change in business owners’ attitude in Asia.

Updates

• Sanjay Anandaram (adjunct faculty from INSEAD and also co-founder of Jumpstartup Venture Fund) provided two interesting references: (a) TechCrunch, Should Tech Startups Outsource Product Development? and Serious Changes in the Global Startup Ecosystem where he contributed some thoughts on the issue.
• Patrick Turner (Professor of Entrepreneur from INSEAD business school) wrote this comment to me via email, “Outsourcing to project-based engineers works much better for start-up teams that have a solid full-time CTO on board. This is obviously because that person is able to control for the deficiencies of remote coders in a way in which teams without such a person cannot possibly do”.

Author’s note: This article is written in conjunction to a similar talk I have given in Barcamp Singapore 7 on 10 Sep 2011. The author thanks the audience, particularly several founders from various start-up companies in Southeast Asia for their feedback and lively debate on the topic. The picture used here is credited to LGB06 from Flickr under a creative commons licence. If you want to republish this article, please contact me to seek my permission first.

Related posts:

1. Building and Managing Tech Teams in Asia 2: Cultural Nuances & Scope Creep
2. Building a (Mobile-Web) Start-up: the 2011 way

No related posts.