Year-End Review: A Practical 2022 & A Deepened 2023 (Part 2) — From Chaos to Systems

English Version (中文版本在下方)

As I write this, Taipei is unusually cold. Riding a scooter without gloves feels like losing sensation in your hands. The winter chill is a stark contrast to the sunny day I wrote Part 1. In a way, the weather has drawn a bold line between then and now — physically and mentally. (It’s also very clear I procrastinated for way too long before publishing this second half…)

In Part 1, I reflected on my experience at a Series A startup. This chapter picks up in March 2023, when I joined a much earlier-stage startup — about 30 people at the time, still in the pre-product phase. Naturally, the challenges and focus areas were completely different.

Funny enough, the VC firm I previously worked at happened to be one of the investors. I had actually supported due diligence on this deal, so I already had strong impressions of the market potential and the CEO’s vision.

Since this is the first time I’m publicly writing about the company, here’s a brief introduction.

Company Intro: Phase

I currently work at a startup called Phase. We’re building a digital design tool for UI/UX (product) designers. If you’re familiar with the software space, you probably thought of Figma just now.

Back in the Sketch era, collaboration between designers was painful. The best workaround was to design in Sketch on a Mac, then upload the files to InVision for collaboration. (The rise and fall of InVision is a whole story of its own…)

Figma changed everything. It let designers collaborate in real-time, online. It solved a major pain point in collaborative design.

But it didn’t solve the next one: design-to-code handoff.

Designers still spend a huge amount of time explaining to developers how their Figma files are supposed to be implemented. Endless reviews, back-and-forth clarifications — it’s inefficient and frustrating.

Phase was built to solve exactly this problem. From the ground up, our engine was designed to make design-to-code a one-to-one relationship. What you see is what you get. In short, WYSIWYM: What You See Is What You Mean.

That’s our ultimate vision. But in the short term, we are starting with a more focused entry point: motion design.

Since Airbnb popularized Lottie in 2018 — a format that lets animations be translated directly into code — we’ve seen explosive growth in animation design. And yet, there is still a major gap: no great online Lottie editor exists.

That’s where we come in.

Role Intro: Chief of Staff at a Seed-Stage Startup

I joined as Chief of Staff (CoS). Before this role, I didn’t fully understand what that title meant — only that it felt like a step up from my previous roles.

For those unfamiliar, the Chief of Staff originated in political and military contexts (like the White House or the Department of Defense), then spread to Silicon Valley. In a startup, a CoS reports directly to the CEO and handles whatever the company needs at that stage. It’s often a generalist, high-context, execution-heavy role.

But even within that, the CoS role varies a lot. There is a leveling framework that breaks it down into five types, depending on company stage and scope. I would say I fall somewhere between Level 2 and Level 3.

Since I wasn’t familiar with this role at first, I spent my early weeks on LinkedIn reaching out to other CoS working at tech startups. I cold-messaged people, asked for coffee chats, and learned how the role actually works across companies.

These conversations were hugely helpful. They taught me how CoS typically partners with the CEO, how to support other leadership members, and how to find ways to contribute across the org.

If you’re entering a new function or industry, I highly recommend cold outreach. Learning directly from those ahead of you is one of the fastest ways to ramp up.

Mandates: My Day-to-Day as Chief of Staff

On a typical day, I attend all of the CEO’s meetings. Beyond just taking notes, I help maintain a system that ensures follow-through and knowledge capture.

We use Fireflies.ai for meeting transcription. I take parallel notes during the call, then feed the transcript into ChatGPT using a structured prompt to generate a draft summary. I clean that up manually, then archive the final version in Notion as our internal knowledge base. From there, we pull action items into Slack, tagging owners, and sync those tasks into Todoist for tracking.

I also have access to the CEO’s inbox via a tool called Missive. Messages sent to the CEO on Slack are all CC’d to me as well (we call it the “three-person channel” model). All of this helps keep our information flow aligned and minimizes asymmetry between me and the CEO.

Our CEO is also a productivity nerd and a voracious reader. I learned a lot from him — not just through working together, but from the books, podcasts, and frameworks he shares.

For example, he introduced me to the Getting Things Done (GTD) system. I now use it daily. It has significantly improved my mental clarity and personal throughput. (I won’t go into the GTD method here, but I highly recommend looking into it: link)

Some standout books and content I encountered during this time include:

Some I did not finish, but all gave me valuable insight.

Projects: A Tour of Cross-Functional Challenges

Beyond recurring work, I spent a lot of time on ad hoc projects across different functions. Some examples:

At first, I found it hard to adapt. My background was mainly in sales, marketing, and finance. I had very little exposure to product, project management, or HR. But given the early-stage nature of the company, I had no choice but to get involved. In hindsight, that ended up being a blessing.

When I first joined, I had to attend every meeting the CEO did — including product reviews. At the time, I barely understood what was being said.

I didn’t know how product development worked. I didn’t know what story points were, or what unit tests did. And Phase, with its hybrid development framework combining Scrum and BDD (Behavior-Driven Development), had even more new terminology to learn — things like “example mapping,” “Gherkin syntax,” and more.

The steep learning curve made onboarding tough, but also extremely engaging. One of the books I read recently said that when learning a new model, you must go through three phases: “freeze, solidify, optimize.” That felt true for me too.

Case Study: Fixing the Weekly Program Review Meeting

One project I remember vividly was reworking our weekly Program Review meeting. This was our leadership team’s regular sync to track project progress and solve blockers.

When I joined, these meetings were low quality. Most of the time was spent syncing information, and very little was spent actually solving problems. At first, I could not articulate why it felt off. I lacked historical context.

But as I got deeper into our processes, I partnered with our Director of Project Management to diagnose the core issue.

The problem?

Our program management tool, Jira, did not reflect up-to-date project data. So we ended up using meeting time just to clarify basic status updates — never reaching the “information” or “insight” level of discussion.

Referencing the DIKW Pyramid (Data → Information → Knowledge → Wisdom), we were stuck at the bottom.

So we launched a Jira cleanup initiative. We defined rules to ensure ticket updates were current and sent out daily Slack bot reminders during standup to enforce them.

Next, we built dashboards using EasyBI. These reports helped us move from raw data to real insight. Key charts included:

(Shoutout to my colleagues who owned the technical side of this.)

What surprised me most was how similar this work was to my past experience building CRM dashboards for sales and marketing. The tools were different, but the logic was the same:

That pattern — data to insight to action — felt very familiar.

Final Thoughts

This post is already too long, and I still haven’t touched on many valuable topics: Hiring, Fundraising prep, GTM strategy, and the general management lessons I’ve learned from my CEO, who brings a uniquely Canadian-Silicon Valley hybrid style to a Taiwan-based team.

If there’s interest, I’ll write more about those in future posts.

I can’t believe it’s already Q1 of the next year and I’m just now publishing this “year-end” review. It’s even later than most public companies release their annual reports. Hopefully, this year I can keep the habit of writing and reflecting more consistently.

中文版本

在寫這篇文章的當下，台北恰巧進入異常低溫的冬日，若忘記戴上手套騎車甚至會失去觸覺，這寒冷的天氣和撰寫上篇時的陽光普照截然不同，像是無形中幫上篇與下篇畫上斗大明確的分際。（很明顯從開始落筆到發出去我拖延了非常久…）

接續上篇提到了在Series A 新創經驗，在2023年3月我加入了人數約30人的Seed stage startup（人數約40人），與之前的公司不同，這間startup的階段較為靠前，雖然已是種子輪但我加入的時候還是pre-product階段，也因此公司關注的重點與先前非常不同。

說來也很巧，我曾待過的創投恰巧是投資人之一，那時候也有支援過這個投資案的DD，因此對市場前景和CEO的回答非常印象深刻。

由於這是第一次在我的文章中提及這間公司，以下會是對她的簡短介紹。

公司介紹

我目前的公司叫做Phase是做digital design tool for UI/UX designer (product designer)。沒錯，對於軟體產業有些了解的朋友可能腦中會浮現Figma的名字。

在過去只有Sketch的時代，designer要協作是非常困難的，最好的解法是先在Mac用Sketch設計，接著upload your file to InVision，並在InVision進行協作。（InVision的崛起與倒閉又是另一個故事了…）

然而Figma的橫空出世讓designer 可以線上協作並解決了collaborative design的痛點，但除此之外，在designer的日常還有一件事困擾著他們，也就是designer和developer的交付問題，which is “design-to-code” 的痛點。

在目前的產品設計分工之中，designer除了design以外，還需要花大量時間和developer交代Figma設計稿中的細節應該如何被「正確地」code出來，因此總是需要非常多層的review以及來回的溝通。

而Phase就是為了解決這件事而誕生的，我們從底層架構/引擎的設計，就是為了滿足一件事，讓design-to-code是1-to-1的關係，意即設計稿和程式碼可以直接轉換，what you see is what you get（WYIWYM），it’s just that simple 。

以上是我們的ultimate goal，但現階段，我們會先從motion design的市場切入，因為我們觀察到從2018年Airbnb將Lottie發揚光大以後（Lottie是一種動畫格式，能夠直接將動畫轉為程式碼），動畫設計的蓬勃發展遠超人們的想像，然而Lottie格式的線上動畫編輯器卻是一個市場空缺。

經過上述的介紹，相信大家對於這間公司的vision and mission較不陌生，接下來會比較聚焦我在公司中負責的事務。

職務介紹

我加入的身分是Chief of Staff，在此之前我對這個職稱與不太明白，只知道似乎算是我先前職稱的進階版。

在這邊和一樣不太熟悉這個職稱的大家科普一下，Chief of Staff簡稱CoS，最一開始是從美國白宮和國防相關機構開始設立，中文譯作幕僚長或參謀長，後被矽谷科技業發揚光大。在組織圖中直屬CEO，並根據公司不同階段會負責不同事務，被視為generalist的individual contributor (IC)。

而即使都叫做CoS但也分許多不同等級，原因也非常簡單，為了因應不同階段公司的需求，CoS也分為不同職等，如下圖所示，光基礎分級就有五種level之分，我應該算界在level 2–3之間。（見下圖）

由於對此職位的不熟悉，因此在到職之初，我花了一些時間在Linkedin上找一樣在tech company/startup任職的Chief of Staff並主動約coffee chat，藉此請教較為資深的同位置前輩，究竟不同公司的CoS分別負責甚麼。

而這些談話對於我上手這個職務可說是起到舉足輕重的作用，藉由前輩們的經驗分享，我能夠較為清楚的了解一般CoS和CEO之間是以何種方式合作，我也從中了解到對於CoS這樣的角色，該如何與公司的其他管理階層合作，並在公司需要的時候做出貢獻。

我非常推薦所有初到一新職位或產業的人可以藉由這個cold outreach的方式，快速地跟業界前輩討教，以此更快進入狀況。

回到正題，究竟我在CoS的職務下都在負責甚麼呢？

Mandates

日常方面，我會參加CEO的所有會議，除了做會議memo以外，我們也打造了一套讓會議紀錄和next action可以很好的被follow through的knowledge management系統。

我們是利用Fireflies.ai進行會議錄音與轉譯（我同步也會記錄我聽到的重點），接著我們會把字幕分段丟入chatGPT，讓chatGPT依照我們設計好的template完成會議紀錄的draft（我會再人工edit），並建立文件儲存在Notion作為knowledge base，接著將next action items在Slack channel列出並tag人，而這些TODO也會同步進Todoist這個軟體以利我追蹤。

另外，我能夠收到CEO信箱中的所有信件，我們是使用Missive這個service來達到這件事。並且在Slack上，傳給CEO的訊息也都會cc我（like a 3 person channel）。這些措施都是為了確保我和CEO能夠有一樣的input，並減少資訊不對稱。

另外由於我們CEO是一位大量閱讀並非常要求提升自身生產力的人，我也從他身上學到許多。不僅是他推薦給我的書、podcast、影片，也改變了我許多工作習慣。

例如他本人使用的工作方式為Get Things Done(GTD)，而我在他的推薦下也開始使用，而這個習慣的養成大幅提高了我的生產力，並減少我許多意亂心煩的時刻。（本文暫不展開說明GTD，可以參閱這兩篇文章：A、B）

而在這段時間看了比較印象深刻的書籍有High Growth Management, Amp it up (by Slootman), Process of On-Going Improvement, The Phoenix project, 和Tobi及Brian Chesky的多部訪談。（有些書沒有完全讀完，但還是收穫很多）

而除了少數routine以外，我的工作也牽涉了大量的ad-hoc projects，不同時間段參與的專案都有所不同。

Projects

舉例而言，我參與過幾個不同部門的專案，包含但不限於：建立公司top level initiatives的專案管理dashboard並reformat 專案管理的會議形式，使用B2B Sales方式來改善hiring pipeline問題，進行PLG product的early GTM，協助募資計畫…等等

這樣多面向的工作內容一開始我其實蠻難適應，由於自身背景，過去比較多著墨在sales, marketing, finance，反而product相關的事情接觸的較少。但因為現在公司階段的原因，我必須（也只能）開始接觸product, project mgmt, HR的事情，這個意料之外的收穫也算是塞翁失馬。

還記的剛入職時因為要參與CEO的每個會議，常常參加product相關的會議都只能聽的一知半解，那時候不知道product develop的流程，不知道甚麼是story points，甚麼是unit test，除了這些基礎名詞以外，由於我們公司產品的特殊與複雜性，我們特別刻出了一套融合scrum和BDD開發方法的一套產品開發方法，因此有更多應運而生的名詞需要了解，例如example mapping, gherkins…等等。

這些行話與詞彙都加深了上手的難度，但同時也讓這一切變得更有趣。最近看的一本書強調在學習新模式時應該要：「先僵化、再固化、再優化」，我想我在學習這些新事物時也是一樣的。

Case Study

那時印象很深刻的專案是改善公司weekly program review meeting的形式。簡單介紹，這個meeting是我們公司每周leadership team會招開的會議，會議目的有二：一是了解目前各個專案的進度，二是識別任何可以的風險並problem solve。

但這個會議從我加入時一直有個問題是，會議的品質不佳，感覺大家都會在會議上花很多時間同步彼此的資訊，而花相對少的時間在problem solve。一開始我只覺得有些奇怪，但由於剛加入時不清楚公司過往背景和project management，因此也就無從改進起。

隨著越來越了解細節後，我和Dir. Of project mgmt.討論出關鍵問題，其一是我們使用的program mgmt. tool： Jira，沒辦法提供最up to date的data，導致會議時常流於溝通最基礎的data而無法上升到information甚至knowledge的討論。（詳請可見DIKM pyramid）

So, the first step is -> 清理Jira，讓他能夠呈現最正確與更新的資料。而一旦達成這件事，我們便可以使用裏頭的資料加上app store的第三方service建構符合我們需求的report templates。藉由這些report & dashboard，我們才能從data上升至information的呈現，並透過基於此的討論，得到knowledge甚至是wisdom。

因此我們便展開清理Jira legacy data的計畫，並設下許多rule讓大家記得按時更新ticket（建立daily slack bot notification在standup meeting追更新）。下一步的dashboard building我們是使用easyBI來建立較複雜的報表，並討論出幾個dashboard一定要有的報表形式：例如story points burn down chart, bug trends, WIP cycle time, process control chart for each tickets… (credit to 我的同事們)

而在這個專案的過程我也發現，其實這件事情也和我過往的經驗高度相關。在前公司的時候，我也使用CRM系統建立了許多sales & marketing的報表供weekly meeting使用。其實這背後都是類似的邏輯：正確的使用系統、得到第一線的data、透過建立dashboard得到information、讓會議上大家可以討論並追蹤metrics進而得到knowledge甚至wisdom。

結語

寫到這也已經快三千字，但除了上述分享的專案，我認為包括hiring、fundraising preparation、GTM strategy & execution、以及我從我們CEO身上學到的general management lesson learnt也都十分有趣且獲益良多（US vs TW，因為我老闆是土生土長的加拿大人，他花了很多時間思考，如何結合矽谷管理方法和台灣員工文化）。

如果大家有興趣的話，我之後會再一一分享！

沒想到一篇年度回顧拖到下一年的Q1才發出來，比一般公司的年度財報還晚發布…希望新的一年可以持續記錄的習慣，持續學習並持續分享。

在文末附上在去年年底生日時寫下的文字，提醒自己並留下紀錄：

失去了社會加諸於世的計數器，每個人從二十二開始算著，扣掉被國家強徵的四個月，去頭去尾也近一年半。

二十四不是什麼值得被歌頌的歲數，我也沒有什麼值得被歌頌的記事，但不以某種形式把一年的跌宕起伏回憶一遍，事情久了就會模糊，畢竟我是個記性差的人，連三角函數的公式都時常忘記。

有人說忘記的就不重要，重要的就不會忘記，但不時時心裡默念，遺忘也是遲早的事。人傾向高估短期的記憶，低估長期的決心。學會紀錄，學會移除，學會批次，學會決斷，也許這是我今年得到最好的禮物。

要說十二月生日的好處，能把生日和西元年的結束盡可能拉近是一個，畢竟年底最適合反思，在一年的其他時候總結都不免有些彆扭。只想在生日這天提醒自己，二十四已不能稱作青澀，該有些自覺，每個人即使時區不同，世俗也會推著你走，當時針被撥慢了等著，離平庸也就近了。