It’s a bad company to work for

When at woke up this morning, at 5am, I saw the light coming from the other room. I was wondering did I forget to turn it off before going to bed, and I realized my wife wasn’t sleeping. Immediately I knew what was going on: she was working!

I usually wake up early in the morning to work too, so what’s the difference? The difference is she didn’t sleep but had been working for the whole day. The company she’s working for is rushing to launch something new to the users. They have been working hard for the past couple of days (or weeks), fixing bugs, testing end to end, to make sure it’s a successful launch.

It sounds pretty normal, isn’t it? We all have faced that in our career, working hard to deliver something meaningful to our customer. So what’s the problem?

The problem is it’s always the same for them whenever they launch something big. My wife has been working with this company for almost 2 years, and I have seen this happens again, and again, and again. They have to work their asses off, till midnight, and then weekend. I recently asked her: “was there a launch that you didn’t work overtime but still successful”? She wondered!!

So what’s the problem here? Through our conversations, I got to know that the engineering team was struggled to provide a good estimation, the deadline kept delayed over again and again, till a point they couldn’t afford any more delays. It’s an endless loop: dev, release internal, manual test, bugs here and there, fix the bug, and here comes another bug resulted from fixing the original bug…

There are many reasons but in my opinion, the main one is that they don’t have automation tests or unit tests (or very little, maybe, I don’t know). What I know for sure is their engineering quality is far from good. But they are a start-up, you say, they don’t afford time for the fancy time to write unit tests or automation tests, you say. I don’t disagree! I was there, working for a start-up where the unit test was fancy, overtime was normal, and never get paid for that. The thing is, they are no longer in a stage that struggles to validate their idea or business model or survive. They got funding, they are expanding to other markets, but still avoid to improve the engineering quality.

I blame the leadership. Many times talking to my wife, I wondered did they ever do a retrospective and say: “It’s enough, let’s invest in improving automation tests and engineering quality, so we could be more accurate with the estimation, and less painful to launch a big thing”. I blame the leadership for not acting (or not aggressive enough) to improve their employees’ life. It’s not once or twice, it’s every single f**king time for the last 2 years. In my extreme point of view, they are just trying to reap off their employees, trying to extract as much as they can, but paying just the normal 8-hour wage.

If your leaders just care about the business, how to acquire more users, how to grow revenue, how to expand to other markets, and just ignore their staff’s mental health problems, it’s a terrible company to be with. You may say they don’t have the budget for that? I disagree. If you invest 3 months to improve the automation test suite and engineering quality, your next launch will be much less painful, your estimation will be more accurate, and your customers will be happier, your employees will have more time to learn and come up with better ideas to improve things.

I used to learn a lot from working in a startup and I keep encouraging others, especially ones who are just in the early days of their career, to join a startup. It not only provides you great opportunities to touch on many different aspects of a business but also the opportunity to be successful in both financial and career paths. Imagine you joined Facebook in the early days, you would have been a billionaire now. However, not all startup is Facebook, so you need to know which company is good to stick around. In the end, it’s your mental health matters and it’s not sustainable to maintain an unhealthy work-life balance.

If you’re interviewing to join a startup as an engineer, ask them how good is their engineering practices, do they have CI/CD setup? They may not have for now, but ask their point of view about investing in improving the engineering quality. Ask them situational questions like the situation I described above, would they be willing to block feature development for 3 months to write unit tests? If you’re already with the company, suggest them that we need to slow down in order to go faster and see how they react.

In the end, a company that doesn’t care about its employees or not constantly challenge their status quo is less likely to be successful. They may survive, but will just be a mediocre company, so what’s good for you staying (for a long time) in such a company?

3 years at Grab

20th Feb, 2017, I started my journey at Grab through a deal to acquire the team.
21st Feb, 2020, I happily left Grab to start another journey.

3 years is not too long but not short as well. I gained a lot from there so wanted to write down some key takeaways during the time, and to tribute those who played important roles in my growth.

Takeaway #1: learn the existing culture/tooling before trying to change

When first joined Grab, I was shocked by the culture here, where everything is so slow, too many processes compared to my previous company. The engineering practices were also too much different. It led to many endless debates with other colleagues, like how we should design an API, mono-repo or multi-repos, why no transaction, etc…

One of the stupidest fight of mine was about using Pivotal Tracker (PT) or Jira. We used Pivotal Tracker in the previous company. No doubts it’s a good tool and has better UX than Jira. While Grab uses Jira widely, we wanted to keep using our own tool, because I believed it would work better for us, we would show them all the advantages of PT, and finally convince the whole company to switch. Some agreed, some didn’t, including the PM, and I fought for a while, before I came to realize that’s it’s the product matters, not the tool. Not only that, everyone else from the company has to maintain 2 different accounts if they ever want to see what we are doing.

Don’t get me wrong that you should always accept the existing culture or process, even if it sucks. My point is to understand the current state and see what advantages you’re bringing to the table first.

Takeaway #2: be a product software engineer

What it means by product software engineer? It means the engineer, together with product manager, own the product, think and see the product through the lens of users. During my time developing the acquisition platform, I went to the field to understand the real business pain points, I put myself in the shoe of our users to come up with the optimal solutions. Another reason to be a product engineer is that you can give valuable feedback to PM, in term of feasibility, priority and effort. Sometime a hacking solution is better, sometime it’s worth to invest engineering effort into solving the problem properly. And you can only make those decisions if you really understand the product and the business.

However, be sure not to step on your PM colleague. A good product team has PMs and engineers look at the same direction, open minded and listen to each other, not using their own expertise or information to create power against the other.

Takeaway #3: it’s important to make people feel comfortable to work with you

I used to have the mindset that in a professional environment, I should be able to freely share my opinion without worrying about others’ feeling, as long as it’s about work, not personal. And it’s actually the source of many conflicts I had. I used to be aggressive during meetings or discussions, and it made those meetings become really intense, coming out of those meetings was really exhausted.

With feedback from my manager and reading many books about management, I realized that it’s important to maintain healthy conversations in order to reach the common goal. I learnt how to give and receive feedback constructively, what it really means by being open minded. When you’re approachable, people will likely come and talk to you, you’ll be more helpful and get more chances to be involved in more impactful works.

As an IC, being an effective communicator also creates more opportunities for you than a quiet person, because people won’t know what you’re applicable of, or they don’t think you need the opportunity more than another.

Takeaway #4: how does a good manager look like

This is the last takeaway I want to share in this post. Being a manager helped me see perspectives I couldn’t see as an IC before. I started to understand the challenges of a people manager, the decision making process, the priorities… It also helped me see clearer how a good manager different from a bad manager. In my opinion, a good manager is the one who genuinely care for people and the team under him/her. They may not be the expert in the domain but they know their weaknesses and admit that, keep learning to overcome that, instead of faking it. When there is a problem, they stay and solve it together with the team. Of course the more senior a manager, the further she/he stays hands on, but you’ll see it, and you know you can count on him/her. My last manager at Grab is the person like that.

Last words

On my last day, someone asked me how I feel. The answer was “I’m happy and satisfied”, and I really meant it. I never felt that before when leaving a company. It’s the feeling when you know you did your best to contribute to the success of the team and the company and you don’t regret anything. I wouldn’t have felt that way if I gave up and left in 2018. I’m thankful for people who fought with me, I appreciate people who supported me and mentored me. To Jon, Prem, Ditesh, Kent, and all who worked with me in the past 3 years.

Thank you and good luck.

P.S: Thanks Saba for the picture

Introducing dbcleaner – database_cleaner gem like written in Go

https://gopkg.in/khaiql/dbcleaner.v2

UPDATES: I published v2 version of the library to fix some issues in previous version:

• Allow truncate Mysql tables that have foreign key
• Fix problem of race condition
• Only truncate specified tables instead of all tables, this would avoid problem of making other tests failed because of accidentally truncate data.

If you have experience in Ruby/Rails development, you may know about database_cleaner, a 2k stars gem to clean database after each test case.

Switching to Go, you may miss the features that the gem provides during writing test. That said, having to write piece of code to truncate table after every single test case to keep the database clean is way to boilerplate. That’s why I decided to extract that piece of code into a small library that can do stuff automatically.

You can find source code and instructions on how to use in the library’s homepage. It’s a perfect combination with testify‘s suite. All you need to do is to define a BaseSuite

type BaseSuite struct {
	suite.Suite
	DBCleaner *dbcleaner.DBCleaner
}

// SetupSuite inits dbcleaner instance at the beginning of every suite
func (suite *BaseSuite) SetupSuite() {
	cleaner, err := dbcleaner.New("postgres", "YOUR_DB_CONNECTION_STRING")
	if err != nil {
		panic(err)
	}

	suite.DBCleaner = cleaner
}

// TearDownSuite closes and releases connection at the end of suite
func (suite *BaseSuite) TearDownSuite() {
	suite.DBCleaner.Close()
}

// Truncate tables after every test case. Note: sub-test using t.Run wouldn't be
// taken into account
func (suite *BaseSuite) TearDownTest() {
	suite.DBCleaner.TruncateTablesExclude("migrations")
}

By this way, you can have great degree of isolation between different test suites but also take advantage of dbcleaner.

type ExampleSuite struct {
	BaseSuite
}

func (suite *ExampleSuite) TestSomething() {
  // Have some meaningful test
  suite.Equal(true, true)
}

func TestRunSuite(t *testing.T) {
  suite.Run(t, new(ExampleSuite))
}

For now, postgres and mysql are the support drivers. Implementing new driver is straightforward as it follows the same mechanism as sql package.

Found some bugs? Feel free to submit a ticket.

Introducing React Native Progressive Input

What is this?

Small library, made for small side project.

How does it look?

Check this: https://github.com/khaiql/react-native-progressive-input

What next?

Use it if it suits your needs. Star it if you like it, appreciate 😀

Deploy Jenkins using Slack Command

Story 

You are engineer, you use Jenkins for deployment? There will be time when you are outside or cannot touch your laptop but you need to deploy something to the system, access to Jenkins web interface on mobile is a nightmare. Luckily your company is using Slack for team communication. This might save you from the nightmare by having a Slack command to trigger remote build on Jenkins.

How?

The above story was what happened to me recently, at that time I thought there must be something that help me to do what I want. Started some search on Google about trigger build remotely using Slack command. There are some blog posts about this, some open source projects on github to accomplish this too. Finally I picked up jenkins-slack-command of @joshdholtz. It’s a project written in ruby and sinatra, pretty simple, it’s also very convenient to get started as the readme has a shortcut to create an app on heroku. Just need to follow the readme and you will have a working Slack command. Great work! 

However, there is risk when you just stop at what’s being offered by the app. Everyone who knows the command can deploy everytime, no restriction, no authorization… That’s obviously not what I want. In order to overcome this, I forked there project and modified a little bit. Find my forked repo at: https://github.com/khaiql/jenkins-slack-command. 

What is the difference?

I added one more environment variable called SLACK_CHANNEL_ID. It is the ID of the only channel that members of it can trigger the build. So, create a private channel, add all people who should be able to deploy to that one. But how can you find your Slack channel ID? I made it very easy by print out all params submitted to the app via Slack command. After having your heroku app up and running, the Slack command is also available to use. Execute the command in the channel that can trigger the build. You will see an error message saying that you haven’t setup the variable properly, with others params, find the channel ID from that. Now you know what to do, right? Simply get to setting page of your heroku app, add the missing environment variable and there you go 😁.
During setting up, you may encounter error. This is because your Jenkins is asking for a known account. Config it to make it buildable with a token. This will expose your jobs to others, but they cannot build, it’s not a big problem, I think 😁.

That’s all. Wonder where is the instruction? Find in the readme, very easy. Enjoy 😁

Scott

Protected: The new year (2016) is coming and I’m writing this for you

This content is password protected. To view it please enter your password below:

Password:

Chuyển từ Rails sang Lotus, why not now?

Mở bài

Rails là gì? => cái này thôi chắc không cần giới thiệu

Lotus là gì? => nói ngắn gọn thì Lotus là một web framework mới, sử dụng ngôn ngữ Ruby, tuy vẫn đang trong giai đoạn phát triển nhưng rất tiềm năng và cũng hay ho (theo quan điểm cá nhân).

Gần đây thì trong cộng đồng đang rộ lên xu hướng chỉ trích Rails khá nhiều, đại loại là xoay quanh vài chủ đề như

• Kiến trúc monolithic, cũ rồi, mốt thời thượng là microservices kia
• Anti-pattern
• Monkey patching
• Performance kém (cái này là vấn đề chung của Ruby luôn rồi :s)
• …

Và rồi người ta rủ nhau bỏ Rails, theo Golang, hay nodejs, hay Erlang…

Từ những vấn đề được nhìn thấy ở Rails, có một vài anh siêu nhân đứng ra phát triển Lotus, một framework khác cũng viết bằng Ruby. Vì sinh sau mà, nên tất nhiên Lotus phải giải quyết được những khiếm khuyết của Rails thì mới có hi vọng phát triển. Và đến hiện giờ thì hình như các anh ấy vẫn đang đi đúng theo con đường đó. Nói lang mang nãy giờ thì chốt một câu là cá nhân tui thấy Lotus nó hay nên viết bài nhảm về Lotus thôi :)))

Khó khăn

Thế tại sao nên chuyển sang Lotus bây giờ? Trước tiên nói về những khó khăn nếu chuyển từ Rails sang Lotus

• Không quen :v, mặc dù đều là Ruby cả, nhưng lúc mới chuyển từ Rails sang Lotus thì cảm giác nó cứ kì kì thế nào ấy, tóm lại thì là do không quen :))
• Ít document, tính đến giờ thì toàn mò mò đọc docs từ github của Lotus thôi chứ chưa thấy có nhiều bài tutorial hay book về Lotus như Rails
• Gems, Ruby và Rails nổi tiếng một phần ở thư viện gem rất chi là bự của nó. Với Lotus, chúng ta vẫn có thể sử dụng được các Ruby gems, nhưng phải nói không với Rails gem. Rails gem tức là những gems mà depend on Rails ấy. Vậy nên nếu giờ làm Lotus thì… chắc phải tự viết khá nhiều 😦
• Vẫn còn chưa hoàn thiện, nếu so sánh với Rails thì hiện tại Lotus vẫn còn đang chưa cung cấp đủ các công cụ cho người dùng. Ví dụ, Rails có lệnh rails generate, Lotus cũng có lotus generate. Cơ mà Lotus thì chưa có lệnh lotus destroy như rails T_T, phải xóa bằng tay. Cơ mà chắc là chưa có thôi chứ không phải là không có.

Lợi ích

Khó khăn chồng chất, tuy nhiên, nếu chuyển sang dùng Lotus bây giờ, bạn sẽ nhận được gì?

• Vì thiếu docs, tutorial nên khi nào gặp lỗi hay gì gì đó không chạy thì phải lọ mọ vào source code của Lotus để đọc xem nó được implement như nào, có phải bug của Lotus không hay bug của mình. Xem nhiều đâm ra hiểu, mà hiểu thì sẽ triển khai hiệu quả hơn => biết đâu còn có thể contribute cho Lotus
• Vì thiếu gems nên phải tự viết, ví dụ như trong rails mình có devise, quá khỏe, cơ mà lotus thì không, tự viết đi nhé. Tuy có hơi cực nhưng bù lại mình hiểu chính xác mình cần cái gì, và chỉ implement vừa đủ dùng, không thừa, không thiếu. Vì thiếu gem nên biết đâu siêng siêng viết một cái gem cho cộng đồng, sau này lại được người ta dùng nhiều => một cảm giác thật là sung sướng :)).
• Thiếu tutorial => nên giờ làm Lotus rồi viết blog, chia sẽ kinh nghiệm cho cộng đồng, lỡ sau này Lotus phát triển mạnh thì blog của bạn được người ta vào xem nhiều nhiều, tăng view, được nổi tiếng, hú hú :)))))

Rủi ro

Lợi có rồi, hại có rồi, giờ đến risk. Vì hiện tại Lotus vẫn đang trong gia đoạn phát triển, version mới cứ ra đều đặn vậy đó, dùng bây giờ sau này phải update chắc mệt lắm :-s. Ví dụ như hiện tại Lotus đang ở version 0.3.2, nhưng vài ngày nữa là launch version 0.4.0. Không biết khi official launch có thay đổi thât hay không nhưng mình có xem trước thì structure của 0.4.0 khác so với 0.3.2 :v. Cái risk nữa là lỡ bây giờ xài Lotus mà sau này nó chết yểu thì… (cơ mà chắc không đâu).

Kết bài

Mấy cái khó khăn, lợi ích, rủi ro lung tung trên kia là do mình đang mò mò làm Lotus, tự rút ra thôi, đúng sai không quan tâm. Bài viết nhảm đến đây là hết 🙂

Project đang mần nè: https://github.com/khaiql/ss-tweets

Debug Ruby/Rails application with byebug

1. Introduction

Nói đơn giản ngắn gọn thì byebug là một gem cung cấp các commands để hỗ trợ cho việc debugging ruby applications. Về chi tiết cụ thể, các bạn có thể xem thêm trên github của byebug. Các tính năng chính của byebug:

• Stepping: thực thi các câu lệnh theo trình tự. Nếu trước đây bạn sử dụng các IDE như Visual Studio, Eclipse hay RubyMine, bạn có thể debug application step by step, ví dụ như step over, step in, step out. Tuy nhiên, nếu sử dụng text editor (sublime, emacs…), bạn không có sẵn các tính năng đó, cài thêm byebug, bạn sẽ có :).
• Breaking: tạo breakpoint, conditional breakpoint…
• Evaluating: Basic REPL functionality
• Tracking: theo dõi sự thay đổi của variables hay các dòng lệnh khi thực thi

2. Commands trong byebug

Command	Aliases	Subcommands
backtrace	btwhere
break
catch
condition
continue
delete
disable		breakpoints display
display
down
edit
enable		breakpoints display
eval
finish
frame
help
history
info		args breakpoints catch display file files line program
irb
kill
list
method		instance
next
pp
pry
ps
putl
quit	exit
restart
save
set		autoeval autoirb autolist autosave basename callstylefullpath histfile histsize linetrace listsize post_mortemstack_on_error verbose width
show		autoeval autoirb autolist autosave basename callstylefullpath histfile histsize linetrace listsize post_mortemstack_on_error verbose width
source
step
thread		current list resume stop switch
tracevar
undisplay
up
var		all constant global instance local

3. Hướng dẫn sử dụng cơ bản

Phần này chỉ giới thiệu cơ bản cách sử dụng, để xem hướng dẫn đầy đủ, các bạn có thể xem tại trang guide của byebug. Trong phần này sẽ chỉ giới thiệu cách debug rails application. Khi muốn debug một dòng nào đó trong ứng dụng, bạn chỉ cần đặt câu lệnh byebug ở ngay phía trên dòng muốn debug. Về cơ bản, có thể xem bản thân lệnh byebug như là một breakpoint. Ở đây mình có một name_cards_controller và mình muốn debug action create (tạo mới một name card), nên mình đặt dòng lệnh byebug ở ngay dòng đầu tiên bên trong action create. Tiếp theo, tiến hành chạy rails server, thực hiện hành vi sẽ gọi đến action create, tức là tạo mới một name_card object. Lúc này trong cửa sổ terminal của rails server, execution sẽ dừng ở dòng byebug. Lúc này bạn có thể evaluate giá trị của các variable trong context hiện tại. Các commands bạn có thể hỗ trợ cho bạn:

• next: move đến execution của dòng tiếp theo, ví dụ ở đây đang ở dòng 26, khi gõ next, con trỏ sẽ nhảy đến dòng 27
• step: nếu tại dòng 26, bạn gõ step, byebug sẽ nhảy vào definition của method create_params, tương tự như khi bạn sử dụng step in trong các IDE phổ biến
• up: tương tự như step out, sau khi step in tại dòng 26, debugger nhảy vào method create_params, muốn nhảy ra lại, các bạn gõ lệnh up
• pp: viết tắt của pretty print, giúp bạn xem value của một variable nào đó đã được format cho dễ nhìn.
• continue: thoát debugger và tiếp tục execution của app.
• help <command>: xem description của command

Ngoài ra các bạn cũng có thể đặt thêm breakpoints bằng lệnh break, gõ h break để biết cách sử dụng.

4. Sử dụng byebug với sublime text

sublime-debugger là một project được phát triển từ byebug, cung cấp khả năng debug trực tiếp ngay trên sublime text như đặt breakpoint, next, step… Xem thêm cách cài đặt tại website của sublime debugger.

5. Hết bài

Restore mongo database from remote to local in single command

If you are developing rails application with mongodb, sometime you may want to synchronise your production database, or remote database to local for development or testing purpose. The following command will help you do that:

mkdir tmp-dump && cd tmp-dump && mongodump --host [YOUR_DB_SERVER] -u [DATABASE_USER] -p [DATABASE_PASSWORD] -d [DATABASE_NEED_TO_RESTORE] rake db:drop && rake db:create && mongorestore && cd .. && rm -rf tmp-dump

Firstly, open terminal and change current directory to your rails app folder. Next, replace content in square brackets (and the brackets as well) with your corresponding information. Press ENTER and wait for the job done 🙂

Credit: Li Soon – techlist developer

(adsbygoogle = window.adsbygoogle || []).push({});

Các giai đoạn đầu tư, phát triển của một startup

Như thông thường, đầu tiên sẽ có một phần giải thích lý do của bài viết. Bài này thì không viết, phần lớn là dịch lại và biến tấu sơ sơ, vẽ vời chút ít cho vui từ bài viết gốc: How Funding Works – Splitting The Equity Pie With Investors. Tại dạo gần đây cứ suốt ngày nghe mấy cái funding rounds, như seed, rồi Series A, B, C, rồi exited, blah blah, mà không hiểu bản chất của nó lắm, vậy nên google. Thấy bài này viết hay, nội dung sinh động, cộng với việc đang bị rảnh cuối tuần nên viết cho vui. Vào chủ đề chính, vì đa phần là dịch lại nên đơn vị tiền tệ trong bài viết là dollar, ngữ cảnh cũng sang chảnh cỡ bên Mỹ, vậy nên đừng ai comment bảo, sao tiền nhiều thế nhé J.

Vào bài

Giả sử chúng ta có một startup kiểu mẫu, họ được đầu tư khoảng $15,000 từ gia đình và bạn bè, sau 3 tháng, họ được nhận thêm $200,000 từ angel investor, và $2 triệu từ một Venture Capital 6 tháng sau nữa. Nếu mọi thứ đều ổn, từ giả sử trên ta sẽ vẽ ra được infographic như hình bên dưới:

Đối lập với khái niệm ‘funding’ là ‘bootstrapping’, nghĩa là các công ty startup phát triển dựa vào nguồn vốn nội lực. Một vài công ty điển hình cho mô hình này là MailChimp và AirBnB.

Mỗi lần kêu gọi đầu tư, bạn sẽ phải chia bớt một phần cổ phần công ty cho người khác. Càng được đầu tư nhiều, lượng cổ phần bạn phải san sẻ càng nhiều, và mỗi người sở hữu cổ phần đều trở thành co-owner của công ty.

Bạn có thể liên tưởng cổ phần công ty như một cái bánh, và mỗi lần nhận được đầu tư, rõ ràng bạn phải để dành cho họ một phần của cái bánh (hay gọi là miếng bánh). Ban đầu thì cái bánh của bạn nhỏ xíu, nhưng qua mỗi lần đầu tư, cái bánh sẽ to dần lên, và một miếng bánh của cái bánh to to chắc chắn sẽ nhiều hơn so với cái bánh nhỏ xíu ban đầu của bạn.

Ví dụ như Google, Larry và Sergey, mỗi người sở hữu khoảng 15% của cái bánh, nhưng bạn thấy họ giàu như thế nào đấy :3.

Các giai đoạn đầu tư

Idea stage

Giai đoạn đầu tiên chỉ có mỗi bạn mà thôi. Bạn có một vài ý tưởng mà bạn cho là hay, rồi sau một thời gian đau đầu nhức não, ban quyết định chọn một ý tưởng tiềm năng nhất có thể để triển khai. Lúc này bạn sỡ hữu 100% cái bánh, nhưng mới là bánh vẽ, chưa có giá trị thực sự. Thực tế thì lúc này chắc bạn cũng chưa nghĩ đến chuyện mở công ty hay phần trăm cổ phần cổ phiếu gì đâu.

Co-founder stage

Khi bắt đầu triển khai, bạn sẽ nhận ra rằng việc triển khai một mình sẽ rất tốn thời gian, và cũng khó khăn nữa. Vậy là bạn quyết định tìm một người đồng sáng lập. Người này thường là ai đó mà bạn thân thiết, tin tưởng, hiểu được tiềm năng của ý tưởng mà bạn muốn làm. Sau một thời gian tìm hiểu, làm việc, bạn cảm thấy họ thật sự tâm huyết với dự án của bạn, bạn đề nghị họ trở thành co-founder của dự án. Lúc này thì cái bánh vẫn còn là bánh vẽ, và cổ phần cũng chỉ là thứ mơ hồ, không tiền, thứ quyền lợi duy nhất mà bạn có thể mang lại cho người bạn này sẽ chỉ có thể là, again, cổ phần. Mặc dù là mơ hồ nhưng nếu dự án thành công, mọi chuyện sẽ khác, bây giờ bạn cần quyết định bạn sẽ share bao nhiêu cho người đồng sáng lập? Lúc này bạn sẽ nghĩ, idea là của bạn, vậy nên bạn sẽ được hưởng % cao hơn so với người kia, đây cũng là suy nghĩ của chính mình khi offer 40% cổ phần cho một bạn co-founder trong project mà mình định triển khai. Tuy nhiên, nhờ đọc bài viết gốc, mình nhận ra rằng suy nghĩ này hoàn toàn là sai lầm. Cụ thể, ở thời điểm này, dự án của bạn cũng chưa có gì nhiều, tất cả chỉ có idea, nhưng ở thời đại mà 10 ý tưởng chỉ đáng giá một cốc bia, việc nghĩ rằng ý tưởng của mình là độc nhất vô nhị quả thật là thiển cận. Người bạn đồng sáng lập cũng phải bỏ ra công sức gần như bạn, cũng sẽ chịu những rủi ro nhất định, vậy nên bạn nên chia cho họ 50% cổ phần, nếu không bạn sẽ làm giảm động lực của chính người co-founder. Trong hợp tác, ta cần tôn trọng đối tác của mình, và bản chất của tôn trọng trong trường hợp này chính là sự công bằng.

Nếu cả hai bạn vẫn đi làm công việc full-time để có chi phí trang trải cuộc sống, dành thời gian còn lại để phát triển idea thì không có gì đáng nói. Nhưng nếu như vậy thì khả năng dự án fail, hay thời gian phát triển bị kéo dài ra là rất cao, bởi bạn sẽ không còn đủ thể lực để tiếp tục làm việc sau 8, 9 tiếng làm việc ở cơ quan. Thông thường, bạn và co-founder sẽ sử dụng khoản tiền tiết kiệm được để sống sót trong khoản thời gian làm việc full-time để phát triển sản phẩm. Cho đến khi… cả hai cùng hết tiền. Lúc này bạn nghĩ đến việc kêu gọi đầu tư để có thể tiếp tục thực hiện ước mơ của mình. Bạn có thể tìm đến các vườn ươm, hay các nhà đầu tư mạo hiểm (Venture Capital), tuy nhiên, ai sẽ đầu tư cho một sản phẩm thậm còn chưa có hình hài cụ thể. Vậy nên bạn nghĩ đến những nguồn đầu tư khác, gọi là

The Family and Friends Round: ngay từ tên gọi, đây là lúc bạn có thể kêu gọi đầu tư từ chính gia đình hay bạn bè. Giả sử như chú của bạn rất giàu, bạn chấp nhận đổi 5% cổ phần lấy $15,000. Vậy là bạn có thêm tiền để sống và phát triển dự án trong vòng 6 tháng tới. Bên cạnh gia đình hay bạn bè còn có một dạng nhà đầu tư gọi là ‘accredited investors’, là những người có từ 1 triệu dollar trong ngân hàng, hay có thu nhập hàng năm vào khoảng $200,000, là những người đủ thông minh để có những đầu tư khôn ngoan, mạo hiểm. Tìm được đầu tư từ những người như vậy chủ yếu dựa vào quan hệ xã hội của bạn.

Đăng ký công ty

Để đảm bảo tính pháp lý cũng như quyền lợi cho người chú đã đầu tư cho bạn $15,000, bạn cần phải đăng ký công ty của mình với cơ quan chức năng, quy định rõ người chú sẽ sỡ hữu 5% cổ phần. Ngoài ra, bạn còn để dành 20% cổ phần cho ‘những nhân viên trong tương lai của bạn’, gọi là option pool. Bạn không nhất thiết phải để dành lượng cổ phần này, tuy nhiên, việc này không phải không có lợi:

1. Những nhà đầu tư sẽ muốn có một phần option pool
2. Bạn và co-founder có thể sử dụng lượng cổ phần này khi cần làm việc gì đó

The angel round

Với số tiền $15,000 của ông chú giàu có, 6 tháng tiếp theo nhanh chóng trôi qua, và tiền lại hết. Bây giờ để tiếp tục có thể phát triển dự án, bạn cần phải kêu gọi thêm đầu tư. Các lựa chọn bạn có thể có lúc này:

1. Các vườn ươm doanh nghiệp, hay một vài doanh nghiệp hỗ trợ startup – tại đây bạn sẽ được cung cấp tài chính, nơi làm việc và cả advisors. Tuy nhiên nguồn tài chính thì khá hạn hẹp, khoảng $25,000, chỉ chiếm khoảng 5 đến 10%. Ở TP HCM thì có SHTP ở khu công nghệ cao, hình như MLab cũng dạng này, tất nhiên Google is free, nên nếu bạn quan tâm có thể tìm hiểu thêm.
2. Angels – thiên thần – Am I talking about Di Maria? Đùa thôi, angel ở đây là các nhà đầu tư. Mức đầu tư bình quân ở angel round là khoảng $600,000 (theo số liệu HALO report). Tuy nhiên, các ‘thiên thần’ cũng không phải là nhà đầu tư mù quán, họ chỉ chịu bỏ tiền nếu họ thấy công ty của bạn đáng giá khoảng 2.5 triệu đô. Làm sao để biết công ty của bạn đáng giá bao nhiêu? Không biết, việc của bạn là cố gắng chứng minh tiềm năng và những gì bạn đang có, càng nhiều càng tốt. Giả sử bạn có thể show ra vài prototype cho dự án, và bạn tìm được một angel nào đó. Họ đánh giá dự án của bạn khoảng 1 triệu đô, vậy nên họ đầu tư vào $200,000, great \m/

Vậy cổ phần mà bạn phải chia cho angel là bao nhiêu phần trăm? 20% không phải là câu trả lời đúng. Tổng giá trị công ty của bạn lúc này sẽ bằng giá trị trước khi được nhận đầu tư, cộng khoản tiền sẽ được đầu tư:

Như vậy, lượng cổ phần bạn phải chuyển nhượng cho angel là 200,000/1,200,000 = 1/6 = 16.7%

Chia lại cái bánh

Bây giờ bạn phải chia lại cổ phần cho mọi người, bao gồm bạn, co-founder và ông chú. Vì angel sẽ có 1/6 cái bánh nên lượng cổ phần còn lại của mỗi người sẽ bị trừ đi 1/6 (xem infographic).

Oh man, miếng bánh của bạn vừa bị giảm đi, liệu có đáng lo? Câu trả lời là không, vì mỗi lần nhận được đầu tư, cái bánh của bạn sẽ to hơn, do đó lượng giá trị bạn sở hữu cũng sẽ tăng lên. Tuy nhiên, mọi sự việc đều có tính chất hai mặt. Vì qua mỗi vòng đầu tư, bạn sẽ mất dần quyền quản lý công ty của bạn. Vậy nên, hãy chỉ nên kêu gọi đầu tư khi cần thiết. Chỉ nên nhận tiền từ những người bạn tin tưởng và tôn trọng.

Venture capital round

Cuối cùng, dự án của bạn cũng gần hoàn thiện, nhờ các khoản đầu tư duy trì trước đó, đã đến lúc bạn phải release version đầu tiên ra thị trường. Bạn bắt đầu tiếp cận đến các nhà đầu tư mạo hiểm, VCs. Các VCs sẽ cho bạn bao nhiêu? Không dưới $500,000. Giả sử lúc này công ty của bạn được đánh giá khoảng 4 triệu dollar, họ quyết định đầu tư cho bạn 2 triệu, công thức tính toán cổ phần của VC và những người đã tham gia trước đó cũng tương tự như angel round:

Bây giờ công ty không còn là của bạn nữa, nó đã thuộc quyền kiểm soát của nhà đầu tư. Vòng đầu tư đầu tiên từ VC gọi là Series A. Sau này bạn có thể kêu gọi thêm các nhà đầu tư khác, tên gọi các vòng tương ứng sẽ là Series B, C… Đến một lúc nào đó, sẽ có một trong ba trường hợp sau đây xảy ra:

• Bạn xài hết tiền của nhà đầu tư, không ai chịu đầu tư thêm nữa => bạn die
• Bạn nhận được lượng tiền đầu tư đủ để xây dựng lên một đế chế khiến cho các doanh nghiệp lớn phải e ngại, hoặc thích thú, và quyết định mua lại công ty của bạn.
• Sản phẩm của bạn rất tốt, mọi việc đi đúng hướng, mang lại lợi nhuận, sau nhiều vòng đầu tư, bạn quyết định công khai doanh nghiệp (go public), niêm yết công ty lên sàn, hay gọi là IPO.

Tại sao lại IPO?

Về bản chất, IPO chỉ là một cách khác của việc kêu gọi đầu tư, nhưng lần này bạn có thể nhận tiền từ hàng triệu người. Thông qua việc IPO, công ty có thể bán cổ phần trên thị trường chứng khoán, và ai cũng có thể mua cổ phần của công ty bạn. Do đó, bạn có thể nhận được tiền đầu tư dễ dàng hơn thông qua việc bán bớt cổ phần, đây chính là lý do đầu tiên.

Lý do thứ hai, trước khi IPO, những người tham gia vào dự án của bạn, bao gồm cả bạn đều giữ những cổ phiếu giới hạn – restricted stock. Bạn không thể chỉ đơn giản mang những cổ phiếu này ra chợ và bán để lấy lại tiền, vì chúng chưa được chứng thực bởi cơ quan chức năng. IPO sẽ làm việc này. Vậy nên, trước khi được kiểm chứng, ai dám chắc bạn không treo đầu dê bán thịt chó, ai dám chắc những người mua cổ phiếu của bạn sẽ không bị lừa đảo. Chính nhờ IPO, bạn và các nhà đầu tư khác có thể bán, biến lượng cổ phiếu này thành tiền thật.

Ngoài ra còn có một nhóm người muốn bạn thực hiện việc IPO – những nhà ‘investment bankers’, không biết dịch ra tiếng Việt như nào, nhưng đại loại là những công ty trong lĩnh vực tài chính có uy tín, ví dụ như Goldman Sachs hay Morgan Stanley, xem thêm định nghĩa tại đây. Họ sẽ gọi cho bạn, đề nghị được hỗ trợ cho bạn toàn bộ những thủ tục hành chính, giấy tờ liên quan đến IPO, chủ động liên hệ với những khách hàng tiềm năng và bán cổ phiếu giúp bạn. Tất nhiên, không ai làm không công cả, đổi lại, investment banker sẽ được hưởng 7% tổng giá trị bạn thu được thông qua IPO. Như trong infographic, startup của bạn raised được $235,000,000 trong đợt IPO, như vậy họ sẽ nhận được 7%, tức là khoảng 16.5 triệu (chỉ trong vòng 2 đến 3 tuần làm việc của một team khoảng 12 chuyên viên ngân hàng). So great!!

Trở thành nhân viên đầu tiên của một startup

Nội dung cuối cùng của bài viết, đã bao giờ bạn nhận được lời mời tham gia phát triển startup, và được hứa hẹn chia cổ phần chưa? Chắc rồi. Thông thường, ở thời điểm đầu của dự án, bạn không thể trả lương cao cho nhân viên được, ngoài ra còn cả những rủi ro cho nhân viên trong trường hợp công ty của bạn fail chẳng hạn, vậy nên bạn đồng ý chia cho họ một phần miếng bánh, để họ làm việc cùng với bạn. Và IPO chính là thời điểm đổi đời của người nhân viên đó.

The end.

P.S: bài dài mà ít hình quá, chắc ế, lol