4 Steps to Working Efficiently at a Startup
When I joined the Alarmy team, managing my workload wasn't easy. The team's sprint process was totally different from my previous company. While I used to focus intensely on one or two tasks before, the Alarmy team handled multiple tasks simultaneously. Because of this, I had to balance my progress and carefully make sure nothing slipped through the cracks.
Step 1: Calendar View + Daily To-Do List
For the first month, I created a daily to-do list using a calendar view in my personal Notion. Since I was using the calendar view, I didn't need to log dates—I just had to jot down what I needed to do that day. However, even though I allocated tasks based on my available time, I was always running short on time.
Where on earth did all that time go? Did I take too many breaks in between? Were there any inefficient tasks? There were too many possible culprits. Eventually, I decided to track my time to figure out exactly what the root cause was.
Step 2: Calendar View + Daily To-Do List + Work Log
As soon as I got to work, I'd create a document and log the start and end times for my tasks. Here are the pros and cons of this Step 2 format.
Pros
Instead of saying "Time flew by and I did nothing," you actually get to know what you did to make the time fly by. There's no way time just vanished while you literally did nothing.
You can figure out roughly how long each task takes. In other words, by comparing your estimates with the actual results, you can see how big the gap is.
Cons
While it's convenient for viewing the workload completed in a single day, it's hard to tell how much time was actually spent on a single task. Usually, a task isn't finished in one day but is broken up across multiple days, yet the documents are written on a daily basis. Therefore, to figure out the total time spent on one task, I had to manually add up the hours logged across different documents.
Step 3: Automatically Summing Logs by Sprint
After using that first work log format for a month, I felt the cons outweighed the pros, so I made a few improvements.
Here is the newly improved work log format:
1. Document Creation
Create a document on a weekly basis
Document title: Month M, Week W + QN Sprint S
2. Document Content
Sprint task list: A list of tasks to complete during one sprint
Surprise: Unexpected tasks that pop up outside the planned workload
Monday – Friday: A log of tasks done that day, time spent, and my physical/mental condition
Meeting log: Progress notes for each meeting held that week
I don't even have to manually enter the sub-tasks or time spent in the "Sprint Task List."
That's because I set up a relational database linking to the "Sprint Work Log." For the time spent, I just use the table's sum function to see the total hours consumed.
The same goes for the related tasks logged daily in the "Sprint Work Log." There's no need to type them out separately; I just connect the "Sprint Task List" via relation, search for the relevant task, and click it. A pro tip here: don't create separate tables for each day of the week. You need to copy the link for the "Sprint Work Log" and enter everything there until the final day of the sprint so that all the data accumulates in one place.
By using this template, the logged tasks are categorized automatically, allowing you to see at a glance how much time you spent on your work without calculating anything manually.
After improving my work log, I started writing it publicly on the company Notion. This meant others could see what I was working on at any given time. Originally, we had a separate Daily Scrum channel running on our company Slack. It wasn't mandatory, but all the squad members posted there. The format was basically a to-do list noting what you did yesterday and what you planned to do today.
I figured I needed more practice in estimating my resources before I could run my workload smoothly just by writing a to-do list. Since sharing work context is one of the most crucial elements of collaboration, I created this separate method to share my work with my teammates.
My work logs were written in the design group's Notion, meaning anyone could drop in and read them. After about two months of doing this, it was decided that we would adopt this work log as a part of the design group's culture.
At the time, the design group was always strapped for resources and constantly working against the clock. This work log format made it crystal clear how much resource was being poured into each task, so it was easy to see if the design group was working within available hours or overworking. And just like that, the design group started keeping work logs.
From then on, the design group could see exactly how much extra resource we were actually burning compared to our previous estimates, making it possible to manage tasks within each person's available time during sprint planning.
Step 4: Finding the Time Sinkholes
Through keeping multiple work logs, I got pretty good at estimating the required resources, and yet, even when running sprints based on those estimates, I was still short on time. Why was this happening? A task that clearly should have taken two hours always ended up taking three. Feeling that my work log alone couldn't fix this, I started digging into self-help and productivity books.
Here are two of the books that helped me the most.
The first is "The To-Do List Formula" and the other is "Make Time".
Both books introduce ways to manage your time and workload efficiently.
If you're working in the tech industry using a sprint-based methodology, I highly recommend the latter.
What I realized from reading these books is that when you switch from one task to another, there is additional time consumed outside of the actual working hours. Basically, it's a switching cost.
UC Irvine and Gloria Mark discovered that it takes people 23 minutes and 15 seconds to return to their original task after shifting their attention. This means if you have a 30-minute meeting on your calendar, the actual time it eats up isn't 30 minutes, but at least 70 minutes. That 70 minutes accounts for the time it takes to transition from your ongoing task to the meeting, plus the time to transition back to your task after the meeting ends.
This reality is also highlighted in an essay on time management for Managers vs. Makers by Y Combinator's Paul Graham. It shows that in resource management, what matters isn't just the sheer amount of time, but how you arrange that time.
If you want to dive deeper into how time management differs between the Maker and Manager roles, the articles below will be super helpful.
Armed with this new knowledge, I started taking meeting placements into account when estimating sprint schedules, which allowed for much more efficient resource management. On top of that, hoping to help other teammates with their own resource estimations, I shared these insights company-wide. By sharing this, I was able to provide a solid rationale for why I measured resources the way I did, and from what I remember, communication between teammates became way more streamlined. Had I run my sprints without sharing this, people might have questioned, "Why did that person block off 70 minutes for a 30-minute meeting?"
Here are a few other particularly great methods I picked up from the books.
Categorize your tasks into your most important task, your second most important task, and finally, miscellaneous chores. Note that you should only write down one item for your top priority and one for your second priority.
By capping the amount of work you can handle in advance and setting strict priorities, you clarify your scope of work and are forced to stick to those priorities. It was a great way to check if I was managing my personal sprints well.
Scheduling Email Time
This literally means blocking out "email time" on your calendar. Knowing you have a dedicated slot for it makes it way easier to avoid wasting time checking emails constantly. If you schedule your email time right before a hard stop like a meeting or clocking out, there's the added bonus that you won't drag out your inbox processing.
Blast through as many emails as you can within the allotted time, and then move on to the next task.
Resetting Expectations
When you limit your email processing time or intentionally delay your response times, you also need to manage the expectations of your colleagues and others.
"I am currently prioritizing a few critical projects, so my response may be delayed. If it's urgent, please send a text message."
Using Paper
Using paper cuts down on the time spent pausing your work and hunting through browser tabs to do something else.
I kept my Burner List on paper so I could look at it anytime without opening an app. And every time I tackled a task, I made sure I was staying aligned with my true priorities.
Beyond books, I got a ton of help from my squad teammates. During every sprint retrospective, we shared how each of us was measuring resources effectively and how we could improve. Among the tips I picked up, blocking off upcoming tasks in my calendar in advance and updating my Slack status message were especially useful. Both methods alert my peers to what I'm working on while signaling whether I'm available for an immediate response, allowing me to fully focus when I needed to.
Later on, other teammates asked me to share my work log template, which I passed along a couple of times. Experiencing this give-and-take of help through such simple sharing really brought home to me how vital sharing among teammates is.
"Let's Do Scrum"
After trying various methods and going through some trial and error, I eventually reached a point where I could manage my resources quite efficiently, and my sprint estimates rarely missed the mark. Because of this, maintaining a detailed work log was no longer a necessity for me.
Also, whenever I had free time after logging my tasks, I used to drop into the Daily Scrum channel on Slack to read updates from other teammates. But since I wasn't posting there myself, I'd sometimes forget to even check the channel, which bugged me. For these reasons, I decided to stop keeping my private work log and asked if I could start posting in the channel, too.
Obviously, there was no reason why I couldn't, so I started posting there the very next day. I broke out of that phase of just quietly observing—thinking I wasn't ready to post yet despite wanting to—and that was how I finally wrapped up my journey of improving my work logging.
There Is No Right Answer, Only Improvements
What I felt after testing out multiple methods is that, in the end, it’s all about continuous improvement to forge the method that fits you best.
Since everyone’s workflows are shaped by completely different contexts and environments, finding a one-size-fits-all solution is practically impossible. You have to patiently execute the methods you think are good one by one, determine what works for you and what needs tweaking, and then run it again based on those judgments. This is basically the same process as the product experiments we run all the time in the tech industry. Set a hypothesis, run an experiment to test it, measure the results, and judge whether your hypothesis was right. If you repeat this cycle, you'll eventually discover the most optimized method for yourself.