Tommy Ku's Method Stub

Reading and thinking

Leaving EventXtra with 26 lessons learned

Posted on 2017.01.16

On January 2017 I am leaving EventXtra, a Hong Kong-based event management solution which I have been working for since 2016 (discounting Jan-Apr 2016 when I were on student exchange).

This place is full of people having unique characters. I had fun working with every single one of them. From whom I learned a lot through observation, collaboration and even dispute.

To those who are already tl;dr at this point, the following list of lessons learned, in no particular order, serves as the table of content:

  1. Trust
  2. Focus
  3. Vision
  4. Value
  5. Communication
  6. Observe
  7. Self-improvement
  8. Respect
  9. Listen
  10. Acknowledgement
  11. Process
  12. Obsession
  13. Fun
  14. Take a stand
  15. Hardware
  16. Expectation
  17. Ask
  18. Compromise
  19. Responsibility
  20. Social network
  21. Information
  22. Family
  23. Sharing
  24. Confidence
  25. Take small steps
  26. Automation


Trust and Rome both weren’t built in a day, it takes time. Having mutal trust between myself and my coworkers enables everybody to know what to expect from each other, thus invariably make collaborations more pleasant.

When I meet a new colleague or enter a new environment, establishing trust with my fellow coworkers is automatically my first priority. I am always in need of knowing what a colleague of capable or incapable of such that I can adjust my working style with that person.

For example, I might give slightly more hints or send some useful links when I know the person responsible for a task is new or uncomfortable with that task.

From my experience the best way to build trust is to let go and assist only when prompted for so that it becomes easy to judge how well that person can manage the task single-handedly. You may even feel surprised of the outcome that’s beyond your expectation.


The Pareto principle, also famously known as the 80/20 rule which means that 80% of the effects come from 20% of the causes.

I picked this up from the book The 80/20 Principle: The Secret to Achieving More with Less borrowed from a coworker on a boring plane trip to Taipei. After which I began considering what are the 20% and what are the 80% in my life and my work.

The point is to identify where 80% of the outcome come from, and keep practicing the action that leads to that outcome, which would be the 20%. In my case, web development takes only a fraction of efforts in comparison to Android development. Thus it’d yield more if I focus on web development instead of doing both together.

Android development was in turn handed over to colleagues who are more good at Android development than web development. Yes, by outsourcing/automating the 80% of work that yield merely 20% of the result, we can better focus on the 20% input and reach more preformant outcome.


We see thousands of new business prospects every day. Sharing econonmy, big data, AI, bots, IoT… People are raising/making millions out of these new ideas while we humbly keep doing what we are doing–event management solution.

One is easy to get lost and wonder off from our original plan and goal.

There are company vision and mission which everybody sticks to while planning for the next feature and the next prospect. Don’t pivot prematurely, too often, stick to the vision and mission — that we are to make events simple and impactful.

Thinking of myself as a company, what are my visions and missions? How do I stay focus while actively seeking opportunity to grow myself? I’ll have to consider that.


People work to chase moeny while feeling depressed even with a above-average salary. To me, there’s a threshold which when exceeded (that it sustains my living standard and funds my personal growth/interests), job is more than a mere job.

Job becomes a passion pass that threshold, that one is passionate in bringing certain value to the company/team/customers. I think Peter Drucker’s famous quote on employee motivation expresses more or less the same notion.

Accept the fact that we have to treat almost anybody as a volunteer.
— Peter Drucker

What value are you eager to bring to your organization aside from your job descriptions (those are the basics)? Does your current role encourage or discourage you from bringing that value?


At one point everybody in the team has done a DISC questionnaire to determine our own communication style.

This pretty much summarizes it all (retrived from TSE 126)

The majority of the sales were Steady, meaning they are great listeners and empathic. Half of the engineers are Compliant while the rest are split by Dominant and Influential.

Well I am the Dominant guy and pretty much still am nowadays.

Being able to identify the communication style of a person, whether they have filled in the questionnaire or not, is important in knowing what we are expecting from each other.

For instance, dominant guy wants their voice heard, so much so that they missed out much of the background information, leaving the listener baffled. Influence people may be rather impulsive when raising idea, leaving out unfilled details those Compliant people always want.

Communication would be smooth and pleasant when we all know what to expect from each other and how to communicate effective with different types of people in the DISC framework.

Details on DISC are available on discprofile.

edit: I renamed DiSC to DISC thanks to Bullwinkle pointing out their difference


Sum the CEO guy who got competitive in playing PS3 GVG Extreme VS in office after lunch/work revealed his secret to mastering the use of God Gundam (by that point he pretty much beats everyone in the company) is to watch the games of experts. In fact, he stayed overnight in office watching YouTube and practicing the combo.

Software engineers prefer learning from examples in addition to theories. We learn from clean ingenious abstractions in open source projects; tutorials and boilerplates code written by the experienced, etc.

If I have seen further it is by standing on the shoulders of Giants.
— Isaac Newton

Even insects know the importance of observation.

By observing the approaches taken by the experts, beginners find it easier to advance in an art, be it software development or competitive gaming.


“Rule of 1.01” 1.01365 ≅ 37.8

This rule that went viral on social networks comes from the book “成功のコンセプト~Principles for Success” written by 三木谷浩史, the CEO of Rakuten. Precision aside, the rule means that one could go from 1 to 38 in a year if with slight improvement as small as 0.01 everyday.

Within a year, the field of software engineering has seen exciting advancement in technology from deep learning powered AI, mass-market VR, IoT with physical web, bots…etc.

It isn’t only about the technical skills that we should improve ourselves upon. Geeks in the office always came showing off their latest gadgets from VR headset to DJI drones; the sporty invites everybody for a Muay Thai trial lesson, ping pong (until the last ball in office accidentally ended up on the wrong side of the window), regular swimming and squash; and the latest subject of interest has been Rubik’s Cube (we got 2x2, 3x3, Pyramorphix, 12 sides and even irregular).

Everyone is an expert in something and according to the observe section, there is no better and cheaper way than your office to improve yourself on random matters by observing the experts.


Being respectful is more than just acting politely.

Would you please go to hell?

Polite, yes. Respectful, not quite.

What’s the deal? Being respectful implies a wish to be treated with respect in return. For example, I keep the meeting as short as possible to respect the time of those joining the meeting in hope of not being trapped in a needlessly long meeting tomorrow.

Thus in a way respect feels even like karma. I confess: I fail to respect people occasionally, perhaps due to things not working out or I was rushing for a deadline. I totally feel the guilt as I am writing this. Sure, karma does come back and bite you. What else could I say? Be a decent person.

Despite some of the rules are outdated (those are Victorian!) George Washington’s “Rules of Civility & Decent Behavior in Company and Conversation” is still a good reference to behaving respectfully.


Listening skills in essential to effective collaboration at work and interpersonal relationship. Missing or misinterpreting a message may lead to big mistakes.

Have you played a game called Chinese whispers? People queue up in a line, the first person receives a message which has to be passed down the line. Limitaions may apply such as the listener cannot speak while listening. Error and miscommunication occurs almost every game no matter how hard the players try.

The Chinese whispers game teaches us the fact that listening alone is difficult even for a single message. Consider how much information we receive and pass on to other people at work?

Tricks on effective listening, which I have developed through practice with people of different communication styles are:

  1. wait until the speaker finishes speaking, give visual signal (e.g. raise hand) when you must interrupt
  2. do not join an on-going conversation asking for background unless the speaker spontaneously does that
  3. take note on comments/questions you’d raise later
  4. rephrase the speaker’s message for confirmation


Ging! 👊
— kudos given by someone

People feel more motivated in doing something when a performant outcome is achieved according to expectancy theory. By performant outcome I mean achievement, compliment, kudos, acknowledgement…etc.

Our project manager does so by showing a blurred profile pic bubble on top of the features we developed on our company-wide quarterly update. Sir, I have no complain except for pics being blurry.

But I digress. By humbly giving acknowledgements to coworkers, people tend to becoming motivated at their works, also helps with deflating unintentionally inflated ego.


People dread process when it becomes bureaucratic and inflexible while the other end of the spectrum is haphazard procedures that nobody has idea what is happening and what is the next step to take. It is suboptimal at the two ends of the spectrum.

A resaonable amount of process acts as both guidelines and promises. Process is guideline for those unfamiliar with how information flow and how tasks are handled. Process is for everybody to make reasonable expectation on the time-frame and result that comes out of it.

Tech team needs Agile development process to ensure features are shipped and the feedback comes in to the right person to decide what to do next. Likewise sales team needs the pipeline to win deals and evaluate performance. Admin needs a process so everybody gets their paycheck on time.

Process should be well documented and stored in a centralized location available to the relevant personnel. For example, the process of deploying a new release to production is documented and even recorded in video, available to developers in the project repository.


Have you been so obsessed with something that you have to write up a demo for it even though it is 2AM and you have sat in front of the computer coding for over 8 hours? Oh, to make things worse, there is a 9:30AM team meeting coming up too.

Sometimes you just can’t stop doing something as if it is the only thing matter to you at the moment?

For a period I was obsessed with a certain technology (which I cannot name because it is related to my work), so much so that I coded up a tech demo overnight and showed to my coworkers.

Such obsession is what drives us forward. Some may question the difference between passion and obsession. A quick Google search does not give me an explanation short enough so I have to make it up myself.

Passion is what you actively pursue in long term.

Obsession is what you frantically pursue for a short period of time.

Obsession occurs only on occasion, like sudden burst of inspiration. The best one could do is to hold on to it, and develop it before it withers. Do not procrastinate on something if you find it interesting and worth working on.


Work without fun could be dull and exhausting.

Side effect of work

Work hard, play hard. In EventXtra there are many kinds of fun, with which we bond and relieve stress:

And many more which I couldn’t recall.

Take a stand

To avoid the weird atmosphere spawning from disagreement, or see it as inappropriate to challenge the superior, people would stay quiet even when facing something they don’t agree on.

Until one day someone told me, if I don’t take a stand for myself nobody would. There should be someone leading an opinion and when there is none it might as well be myself.

Taking a stand and challenge the opposite helps raising the standard and reaching a compromise such that both parties are satisfied relative to one side having to swallow what they don’t want.

This does not mean one should challenge everyone on every matter. People should step up and take a stand when the potential risk of a decision hasn’t been fully discussed and understood. Taking a stand is a way to open up discussion and let others see what you see.


Do you use the best tools money can buy?
— #9 of The Joel Test, one of many ways to rate a software team

First off I must say whenever I consider whether my current hardware set up is good enough for my job, this question from the Joel Test pops up in my mind, but then the “best tools” part is arguable so I rewrites it into:

Do you use the most cost-effective tools the COO is willing to source for you?

I do not need a workstation just to develop in Rails or compile Android app. When I do discover the need to upgrade my hardware, the COO would always suggestion other cost-effective alternatives.

So I ripped a 8GB RAM module off my co-workers’ Mac mini (with permission from the COO, of course) because an admin person does not need 16GB of RAM to do edit spreadsheets. An extra 8GB RAM saved my Mac from freezing while compiling Android apps.

2 monitors, Mac mini (2012) at the back, FILCO NINJA 2 (brown switch)

When the company is incapable or it is unjustifiable of buying you an expensive equipments, it is up to yourself to source it. I brought my own set of headphone and mechanical keyboard to work simply because it works better than what was offered.

Therefore, I am adding another argument to my version of Joel Test#9:

Do you use the most cost-effective tools the COO is willing to source for you; or that you would prepare them yourself for the best interest of yourself and the company?*

* not a valid reason for the company to not prepare hardware of accepable spec


Under-promise and over-deliver.

Managing expectation, both to teamamtes and to customers, are difficult. Rule of thumb is that one should under-promise and over-deliver.

I am skeptical toward this proposition because under-promising is like telling customers we couldn’t offer something while we actually can; if customers stayed, they would be (arguably) surprised over the outcome exceeding their expectation; but if customers turned away from us because we under-promise, it doesn’t work.

Managing expectation by under-promising when customers asks for a fix is rather valid because developers do need some margin for task switching, testing the fix and deploying it.

To coworkers, especially the project manager, I tend to provide them with the accurate picture as it’s the project manager’s task to schedule tasks and guarantee delivery.

When it comes to manageing expectation, there is no rule of thumb to accurately- or under-promise. The most important point is not to over-promise and under-deliver.


Many dread the feeling of being rejected when they ask people for something, be it a small favor, undocumented information or an unordinary request.

Sometimes all you have to do is ask, and it can lead to all your dreams coming true
— Randy Pausch

Pausch’s quote above which I read from his book “The Last Lecture” helped me a lot when I was an exchange student in UC Davis. The voice inside my head reminds me: “It costs nothing asking.”

Most of the time people are generous in offering help or useful information.


Don’t be like Team Plasma

Compromise is common in everyday life: you make way for others, hold the doors, take the next train instead of squeezing into this one…

When designing software and coping with product manager, compromise often takes place. This is seen the most effective way of us getting there where both parties want to go.

Our product manager welcomes counter-offering. When we are short of time or human resource, scope is reduced and features altered to avoid overnight death march and ensure product manager has something to deliver. Of course we had to make up for the compromises later but the openness and initiative to counter-offering help the team run smoother.


Rule 82nd “Undertake not what you cannot Perform but be Careful to keep your Promise.”
— quoted from Rules of Civility & Decent Behavior in Company and Conversation

One should be responsible for what he promised. I’d take that as the bottom line. For the same reason I do not prefer over-promising. Unable to deliver what was expected is depressing for everybody.

In fact, we pledged to many things without even noticing them. Say, one is expected to do housework; to come to a meeting on time; to watch out for the coworkers and lend them a helping hand when needed…

Not that we signed a contract or made an oral promise that we should do them, they were simply the expected behavior that we practice and by practicing them we are responsible.

Let’s take another example, when a bug is located on a certain feature, slipping in a fix on time isn’t explicitly requested but is usually expected. Walking away from work and not responding to text and phone during work hour is far from being responsible unless there’s an emergency.

Social network

Building a social network early in career helps discovering and leveraging opportunities afterwards. In fact, I became an intern in EventXtra because of a personal contact who was a previous intern there.

When you start looking, the world is unexpectedly small. When my friend studying HKUST went to Silicon Valley for an internship, his roommate was another friend of mine from CUHK! This is called Six degree of separaion, where you can reach anyone in the world by asking your friend, then your friend’s friends, and so on for 6 times.

My freelance jobs usually come from referral, and they are not necessarily from my tech-savvy people list. I’ve once had a client coming to me because I am a classmate of their highschool schoolmate, almost felt like magic.

But ask any accomplished CEO or entrepreneur or professional how they achieved their success, and I guarantee you’ll hear very little business jargon. What you will mostly hear about are the people who helped pave their way…

— quoted from Never Eat Alone

Social network is an important element in both career and every day life. Just like there’s a go-to person when you need something, your go-to people also have their own set of go-to people, and thus the wider and heterogeneous your social network is, the higher the odds that you could seek help from your network.


Many people ask before at least googling for something. Although this way they could get the information relatively effortlessly, it is distracting and simply shifting the googling part to another person, giving rise to the phrase ‘Let me google that for you’ or ‘LMGTFY’.

With the power of googling even a lay person can perform a task as if he’s experienced. One instance of which has been documented in another post Doing things the layman way.

However, the web is swarming with content farm and fake information. The ablity to assess the credibility of information, just like what we were taught in college, is becoming crucial in decision making.


Family is the community one most committed in. One gives the most to and received the most from family.

Yet as a working adult it became easy give excuses like ‘this feature must be shipped this week’, ‘it would be more convenient if I eat outside’, ‘I must take a break during weekends’…

Ignoring your family would come back to bite you when you suddenly find your parents growing white hairs and their health are going downhill, or that you failed to witness the growth of your sister.

One should care for his family because those are the closest people in his life that would unconditionally love and care for him. Naturally, he should do the same.

Help with housework, cook a dinner, go out for a family day trip, buy little presents every now and then and talk to each other, see how’re their lives and what difficulties they face.


It became a habit for me to share useful articles and videos I saw online to whichever community I was in. I opened a Google Space community within company, and I share links to smaller chat groups I with my friends on Telegram and Messenger.

Not everyone follows websites and blogs on RSS reader like Feedly, or join multiple developer communities on Facebook. There are 700-800 new posts every week on Hacker News according to HN stats and who’s there to filter them and send only the relevant ones to our internal chat group?

Well, it turned out I am a sucker for online articles and whenver I find one useful I share it to the group. It was rewarding seeing comments and articles being posted by other users in the group. Keep it up and you’ll have an active community sharing knowledge and everybody helps improving each other.


Impostor syndrome, a situation where one feels inferior to his fellow colleagues and members in the community. One feels lack of confidence, motivation and fear of showing his work or producing any new work to the public.

We all have suffered from some degree of imposter syndrome haven’t we? We think we are faking our work, our work are not as good as other and thus we don’t worth what we were paid for.

Recall the days when you felt a sense of accomplishment with a mere ‘Hello World’ program, they days when you were an amateur.

To quote Austin Kleon from his book “Show Your Work!:

The world is changing at such a rapid rate that it’s turning us all into amateurs. Even for professionals, the best way to flourish is to retain an amateur’s spirit and embrace uncertainty and the unknown.

And previously he claimed:

Amateurs are not afraid to make mistakes or look ridiculous in the public. They’re in love, so they don’t hesitate to do work that other think of as silly or just plain stupid.

To defeat imposter syndrome, one should retain an amateur’s spirit, try things out and never afraid of failing. Failing isn’t necessarily a bad thing, it promotes learning from our own mistakes, and thus improves our performance. Then there, comes confidence.

Take small steps

People procrastinates on one thing or another don’t they? Especially when a task seems too large, or too time consuming, or too boring, or I-have-got-other-things-for-now™.

I too procrastinated until I discovered this nice trick to overcome it: take smaller steps.

A monolithic task seems difficult to conquer, thus we procrastinate. But we too are programmers who are good at divide and conquer. First write down in bullet points/steps what to do to accomplish a big task.

# Cooking my dinner

1. look up a recipe online, with ingredients easy to come by
2. go buying the ingredients
3. process the ingredients
4. cook according to the recipe

At this point, any one of the sub-tasks would seem easy enough to do. The trick is, by finishing the first step, there comes a sense of accomplishment that would encourage you to take the next step, and the next…before long you would find you have conquered the task that originally looked so big you had to procrastinate on.


A programmer once wrote some scripts to automate anything that requires more than 90 seconds of his time like sending a message to his wife when he’s still working at 9pm. The project went viral and has received 26k+ stars on GitHub.

This interesting news inspired me to build more aliases to shorten my work flow. It used to take 4 commands to push to qa branch, now it only takes 2.

# Before
$ git up # see
$ git checkout qa
$ git merge feature
$ git push origin qa

# After
$ alias prestaging
prestaging='git up; git checkout qa; git merge '
$ prestaging feature
$ git push origin qa

One of our DevOps did much batter than me by integrating overcommit, a tool for running rubocop and linting before a commit is committed. Gone was the time when we push and see the specs fail because of stupid reasons like tailing whitespace or missing blank lines before and after private.

It became a habit of mine to write up scripts for starting, building and stopping Docker containers in projects so I can set up once and never again having to worry about the parameters.