improve

posts/728.md

@@ -8,19 +8,19 @@ permalink: "/post/728"
 
 ---
 
-I've been at Laurel[^laurel] for a bit over three years[^time]. It is a small Series B startup, and it can be stressful. I often blame startup life for my lack of writing. That being said, one thing Laurel does that I really like is guarantee one three day weekend every month. Sometimes that's a national holiday, but if there isn't a national holiday, Laurel still declares a day off. 
+I've been at Laurel[^laurel] for a bit over three years[^time]. It is a small Series B startup, and it can be stressful. I often blame startup life for my lack of writing. That being said, one thing Laurel does that I really like is guarantee one three day weekend every month. Sometimes that's a national holiday, but if there isn't a national holiday, Laurel still declares a day off.
 
 [^laurel]: Laurel was formally known as Time By Ping. We [changed our name back in February 2023](https://www.laurel.ai/resources-post/goodbye-time-by-ping-hello-laurel-the-story-behind-our-new-identity).
 
 [^time]: 3 years, 4 months and 11 days ago or 1,227 days total to be precise.
 
 One of these days each year is Randa Day. Randa was the name of our [CEO Ryan](https://www.linkedin.com/in/ryan-alshak-72815722/)'s mom who passed away and inspired the company's creation. The company asks all employees to take the day off to celebrate her. In the words of one of our founders, [Kourosh](https://www.linkedin.com/in/kouroshz/):
 
-> Randa taught us not to never take time for granted. She pushed us to solve time for the world. Tomorrow isn’t an ordinary long weekend; it is our Randa Day. It’s the day we ask you to intentionally take a moment out of your busy day-to-day to think about your purpose and why you’re working as hard as you are to build Laurel and deliver it to the world.
+> Randa taught us not to never take time for granted. She pushed us to solve time for the world. Tomorrow isn't an ordinary long weekend; it is our Randa Day. It’s the day we ask you to intentionally take a moment out of your busy day-to-day to think about your purpose and why you’re working as hard as you are to build Laurel and deliver it to the world.
 
 I have four drafts sitting in my blog (which I will probably delete after I post this) about joining this company. I often wonder if this was the right choice, leaving a stable company like Google in the fall of 2020 to go bet on a company that hadn't figured out product market fit (and a lot of other things). I think about money left on the table by leaving when I did. I think about the low percentages of startups that succeed, and the even smaller percentages of employees that profit from a startup exit. I debate the pros and cons of being remote. I wonder all sorts of things, doubt is never ending.
 
-Given all of that wondering and doubt, I'm surprised to find that the mission of the company, which is "To return time", still resonates with me after three years. The idea that time is a truly finite resource is a fact that I think about often. The company's attempt to help those who sell their time to both accurately define their time, and make sure they are fairly compensated for how they spend that time weirdly hits home to me, which makes little sense as I haven't done much hourly billing since I graduated college. Lawyers and accountants are our main customers currently, and they are regularly painted as the villains. People think they are out to steal your money, or are a sign of government and legal corruption. I hear commentary at that level at least once a week while out and about, and I always have to pause, because these "villains" are who I spend my day trying to help. 
+Given all of that wondering and doubt, I'm surprised to find that the mission of the company, which is "To return time", still resonates with me after three years. The idea that time is a truly finite resource is a fact that I think about often. The company's attempt to help those who sell their time to both accurately define their time, and make sure they are fairly compensated for how they spend that time weirdly hits home to me, which makes little sense as I haven't done much hourly billing since I graduated college. Lawyers and accountants are our main customers currently, and they are regularly painted as the villains. People think they are out to steal your money, or are a sign of government and legal corruption. I hear commentary at that level at least once a week while out and about, and I always have to pause, because these "villains" are who I spend my day trying to help.
 
 There are probably a few lawyers and accountants out there like that, but most that I have met are just trying to do their job. They work on incredibly tight deadlines with long hours, and help people navigate the complicated worlds of law and finance. Our data shows that many of these folks under-bill their time by up to thirty percent, often because of inaccurate time keeping and the fear of over-billing (which is a crime for lawyers in the United States). We are attempting to empower these folks to be more honest about how they spend their time, and also hopefully make them some more money while doing so (you can't bill for all of your time, there are laws about that too), which may end with their customers paying a bit more money. People paying more money is always a tough sell, but think about the underlying premise: working 30% more every day than you are compensated for. If you were working the line at a restaurant, that's often two or more hours of overtime pay.
 
@@ -34,7 +34,7 @@ So given all of that context, I wanted to talk about how I have spent the three
 
 ## Migrating to MongoDB Atlas
 
-When I started there were two pretty obvious problems: monitoring was all over the place and no one understood how our datastore worked. We were running on a platform called [Aptible](https://www.aptible.com/). It was ok, but their hosted MongoDB product was not. In particular it was running an older version of MongoDB (4.0), and replicas would just forget about each other all of the time. I worked with MongoDB and Aptible to try and figure out the issues, but eventually it became clear we needed to migrate somewhere else. We chose Atlas for a variety of reasons (cost, autoscaling, availability and support to name a few), and then began migrating all of our clusters to it. We had a cluster for each customer, so migrating with minimal downtime was pretty easy, but it took a while. We have now been running happily on Atlas for over two years.
+When I started there were two pretty obvious problems: monitoring was all over the place and no one understood how our data-store worked. We were running on a platform called [Aptible](https://www.aptible.com/). It was ok, but their hosted MongoDB product was not. In particular it was running an older version of MongoDB (4.0), and replicas would just forget about each other all of the time. I worked with MongoDB and Aptible to try and figure out the issues, but eventually it became clear we needed to migrate somewhere else. We chose Atlas for a variety of reasons (cost, auto-scaling, availability and support to name a few), and then began migrating all of our clusters to it. We had a cluster for each customer, so migrating with minimal downtime was pretty easy, but it took a while. We have now been running happily on Atlas for over two years.
 
 ## Consolidating observability around Open Telemetry and Sumologic
 
@@ -56,21 +56,21 @@ We also debated moving to GCP at this time. No one knew GCP besides me, so we de
 
 So while the above migration was happening in Summer of 2022, we decided to make a pivot. Calling it a pivot is... not entirely accurate, but it was a significant enough change to the business, there is no other good word for it.
 
-In July and August, the company leadership let go ~25% of the company, including most of Engineering management. Over the next year a few more small downsizings would happen, and we would go from around 70 people to 40. The context for this was our business was not working. Our product was fine, but it was a desktop application. Our customers often would not pick up the latest version of the software for six months to a year. We would have bug fixes 18 months old that people just wouldn't adopt to fix their problems. So our solution was to rewrite most things, so there was as little on the desktop as possible, move the rest to the cloud.
+In July and August, the company leadership let go ~25% of the company, including most of Engineering management. Over the next year a few more small layoffs would happen, and we would go from around 70 people to 40. The context for this was our business was not working. Our product was fine, but it was a desktop application. Our customers often would not pick up the latest version of the software for six months to a year. We would have bug fixes 18 months old that people just wouldn't adopt to fix their problems. So our solution was to rewrite most things, so there was as little on the desktop as possible, move the rest to the cloud.
 
 My role in all of this was designing the infrastructure that the system would use. This ended up being interesting because I made some demands that drastically affected the system design. The biggest one was a tier system I adopted from my time at Google.
 
 > Tier 1: Global services which have no internal dependencies.
-> 
+>
 > Tier 2: Regional services
-> 
+>
 > Tier 3: Client Services, used by customers
-> 
+>
 > Tier 4: Internal Tools
 
 This plus other production launch requirements required that you could only depend on services with an equal of smaller tier number than yours. So for example: Tier 1 can depend on Tier 1, Tier 2 can depend on Tier 2 and Tier 1, Etc.
 
-We started the rebuild in August of 2022, launched in February of 2023, and had all of our old customers migrated, plus added new ones, by the end of January of 2024. I am still positive the rewrite was the right move, and I am glad we did it. There's a ton of stuff I would have done differently in hindsight, but none of the decisions we made I truly regret. 
+We started the rebuild in August of 2022, launched in February of 2023, and had all of our old customers migrated, plus added new ones, by the end of January of 2024. I am still positive the rewrite was the right move, and I am glad we did it. There's a ton of stuff I would have done differently in hindsight, but none of the decisions we made I truly regret.
 
 ## Conclusion