{
"$type": "site.standard.document",
"content": {
"$type": "site.standard.content.markdown",
"text": "Today is my last day working at [Talent Inc](https://talentinc.com/). I've been there four years, which is the longest\nI have ever held a job and it's the first product startup I've ever worked at. I feel extremely lucky for this\nexperience and I would like the opportunity to say goodbye and share some lessons I learned.\n\n## Having Good Users Is a Blessing, Give Them Powerful Tools\n\nWhen I first started at Talent Inc, I was working on software that was used by our internal operational team. I was\npaired up with an engineer that had been with the company for forever through an acquisition. In my first month working\nthere he said something that has stuck with me ever since:\n\n> We have the best users, we have to treat them right. They are patient and we should reward them.\n\nAfter four years here, I have to agree! That operational team works with job seekers whom can understandably be\ndemanding. Job searching is in the top 3 most stressful moments of their lives. What's incredible about both of these\nuser groups (customers & staff) is how kind and helpful they can be when something breaks. How creative they can be when\na fix is delayed to get the job done. This made my life so much easier and less stressful when the chips were down.\n\nHow can I reward this team effort? I was lucky during my tenure at Talent Inc many opportunities to build systems from\nthe ground up to empower these users. I feel that we delivered on those opportunities and the fact that we exited kind\nof validates that belief.\n\nHere are some cool tech patterns I learned around this:\n\n1. **Tagging systems are amazing.** It allows non-technical people to add metadata to records that you can later build\n technical processes around.\n2. I had never worked with a BI platform like Periscope Data and now I don't think I can work anywhere that doesn't have\n one. **The amount of SQL I've seen written by supposedly non-technical people to empower their own processes was not\n something I expected.** It allowed me to share new schemas I made with them and then they were able to make their own\n dashboards to accomplish their tasks.\n3. At previous jobs, I was likely to script up a <abbr title=\"Command Line Interface\">CLI</abbr> program to alter data\n in bug recovery mode. My definition of bugs was very loose and frequently I would become a point of failure. My time\n at Talent forced me to move these scripts to a web interface where I or anyone could run them with a press of\n a button. The next step of that is to design admin interfaces that are as close to writing to the database itself so\n that users can fix their own mistakes. **The less work I do, the happier I am.**\n\nIt goes without saying, but I will say it because it's important: **I am going to miss working with these people so\nmuch. I will never forget your kindness and understanding.**\n\n<DemoVideo\n alt=\"Kevin Durant saying 'You da real MVP'\"\n src=\"https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExMjYwYWM3ZGE5MDUwYTNhYmZmZDU0MGQ0ZGYyMTM3OWRkZmU3NmZhOCZjdD1n/ALQnCUBuggPxS/giphy.mp4\"\n/>\n\n## So Many Data Pipelines\n\nAll my jobs previous to this were mostly at consulting firms. One thing I can tell you about consulting is that you are\nsomewhat separated from the end user. My joke about consulting is the main problem you are solving is getting that\nnext check to show up. As such, your users can become adversaries in your mind. You get okay with dropping events. You\ndeprioritize bugs because it doesn't effect your bottom line. You wonder what all the bellyaching is about when an email\ndoesn't show up.\n\nThe concerns are different when you work at a customer focused startup, though. Things have to be fast, so you push as\nmuch off the request thread as possible. That stuff off the main thread needs to run reliably, so you throw money at AWS\nfor SQS and write a lot of Lambdas (which are my favorite technological discovery during my time at Talent Inc, if\nI ever start a company, it will be all Lambdas). **If you drop events, you're dropping revenue and user trust.**\n\n## Experimentation Is Crucial\n\nI'm ashamed to say that I never ran an A/B test before my time at Talent. It's just not a concern for early stage\nconsulting gigs. That changed very quickly for me and now I can't go back. We used A/B tests for everything:\n\n- You want to see which version will make more money? **Split test and let revenue tell the truth.**\n- You have a feature that's a little raw that you want help debugging? **Hide it behind a feature flag and watch Sentry,\n the users will test if for you.**\n\nThat said, there were certainly times that instrumenting an A/B test was annoying and I wished that I didn't need to,\nbut I would get over that in the long run. The thing I'm looking forward to most in my next role is what A/B testing\nsystem they use. In my time, I made an A/B testing system, used a homegrown system and Google Optimize, and feature\nflagged a bunch of stuff by roles/tags.\n\n## If It's Not In Production, It's Not Done\n\nAt previous jobs, especially the consulting ones, we followed some version of a [Git flow branching model](https://datasift.github.io/gitflow/IntroducingGitFlow.html).\nAt Talent, we followed something closer to a trunk based approach. At first, if I'm honest, I really hated the trunk\nbased approach. With Git Flow, you have time and space to perfect your code with constant merges. Only when your feature\nis ready to go do you release it to the world. With the trunk based model, once your code is in main and someone\nrequests a release, 99.999% of the time, that code is going to production ASAP and we're not cherry picking around it.\n\nTo get around this limitation, I would make massive <abbr title=\"Pull Requests\">PRs</abbr> and only put them in main\nonce I was happy. But that would cause me to ship bugs and would make it hard for larger changes to be shared with other\ndevelopers. Then I started making \"long lived feature branches\" for the larger changes that I would have teammates put\nPRs against that. That's the right move _sometimes_, but it leads to a lot of code drift as main moves ahead of it.\nFinally, our team had a rule that a **ticket/card cannot be marked as done until it's in production.** I was frustrated\nand I wanted to blow the whole thing up!\n\nIn a 1 on 1 with my boss, I brought up my issues and why I hated it. Could we change it? And this when he dropped this\nbomb on me:\n\n> You can get it to production, I believe in you, users don't have to be able to access it, it just needs to be in\n> production. You can wrap it in a feature flag, put it behind a split test at 0%, you can even disable it based upon\n> environment variables. If you get it to production, the velocity will move faster, trust me.\n\nThis was revelation! Oh how could I have been so close minded!? On my next task like this, I simply wrapped my feature\nso it was only accessible by developers and project managers and I shipped it. And wouldn't you know it, by being able\nto share this feature for feedback, my tasks got done faster and faster. Furthermore, I was able to debug production\nlevel bugs (like access issues) before users ever got their hands on it. **I was shipping stuff a lot faster and became\na little bit of a single branch zealot.**\n\nAs we onboarded developers coming from Git flow teams or teams that shipped code on a monthly or quarterly schedule,\nI got the delight of explaining that this is a little bit of an adjustment but it works in ways that you wouldn't\nexpect. It won't fix everything, but it will fix a lot of things.\n\n## Here's To Tomorrow!\n\nAs you can tell, I enjoyed my time at Talent Inc and I hope they enjoyed having me. If you're looking for your next gig,\nI cannot recommend them enough. The future is very bright there and I'm sad that I won't be around to see it.\n\nAt the same time, I'm very excited for what's next. I don't even know what is next. I only have one speed which is \"go\nso hard I burnout once a year\". I should probably work on that… I'm going to take a few weeks to establish some better\nhabits and doing a thorough job search next year.\n\n<figure>\n \n <figcaption>\n You never know when you're going to show up on the marketing website…\n </figcaption>\n</figure>",
"version": "1.0"
},
"description": "I spent 4 years working at Talent Inc, my first product & customer focused startup, and I learned so much.",
"path": "/blog/what-i-learned-working-at-my-first-startup/",
"publishedAt": "2021-12-17T05:00:00.000Z",
"site": "https://eligundry.com",
"tags": [
"code"
],
"textContent": "Today is my last day working at Talent Inc. I've been there four years, which is the longest\nI have ever held a job and it's the first product startup I've ever worked at. I feel extremely lucky for this\nexperience and I would like the opportunity to say goodbye and share some lessons I learned.\n\nHaving Good Users Is a Blessing, Give Them Powerful Tools\n\nWhen I first started at Talent Inc, I was working on software that was used by our internal operational team. I was\npaired up with an engineer that had been with the company for forever through an acquisition. In my first month working\nthere he said something that has stuck with me ever since:\n\nWe have the best users, we have to treat them right. They are patient and we should reward them.\n\nAfter four years here, I have to agree! That operational team works with job seekers whom can understandably be\ndemanding. Job searching is in the top 3 most stressful moments of their lives. What's incredible about both of these\nuser groups (customers & staff) is how kind and helpful they can be when something breaks. How creative they can be when\na fix is delayed to get the job done. This made my life so much easier and less stressful when the chips were down.\n\nHow can I reward this team effort? I was lucky during my tenure at Talent Inc many opportunities to build systems from\nthe ground up to empower these users. I feel that we delivered on those opportunities and the fact that we exited kind\nof validates that belief.\n\nHere are some cool tech patterns I learned around this:\nTagging systems are amazing. It allows non-technical people to add metadata to records that you can later build\n technical processes around.\nI had never worked with a BI platform like Periscope Data and now I don't think I can work anywhere that doesn't have\n one. The amount of SQL I've seen written by supposedly non-technical people to empower their own processes was not\n something I expected. It allowed me to share new schemas I made with them and then they were able to make their own\n dashboards to accomplish their tasks.\nAt previous jobs, I was likely to script up a CLI program to alter data\n in bug recovery mode. My definition of bugs was very loose and frequently I would become a point of failure. My time\n at Talent forced me to move these scripts to a web interface where I or anyone could run them with a press of\n a button. The next step of that is to design admin interfaces that are as close to writing to the database itself so\n that users can fix their own mistakes. The less work I do, the happier I am.\n\nIt goes without saying, but I will say it because it's important: I am going to miss working with these people so\nmuch. I will never forget your kindness and understanding.\n\nSo Many Data Pipelines\n\nAll my jobs previous to this were mostly at consulting firms. One thing I can tell you about consulting is that you are\nsomewhat separated from the end user. My joke about consulting is the main problem you are solving is getting that\nnext check to show up. As such, your users can become adversaries in your mind. You get okay with dropping events. You\ndeprioritize bugs because it doesn't effect your bottom line. You wonder what all the bellyaching is about when an email\ndoesn't show up.\n\nThe concerns are different when you work at a customer focused startup, though. Things have to be fast, so you push as\nmuch off the request thread as possible. That stuff off the main thread needs to run reliably, so you throw money at AWS\nfor SQS and write a lot of Lambdas (which are my favorite technological discovery during my time at Talent Inc, if\nI ever start a company, it will be all Lambdas). If you drop events, you're dropping revenue and user trust.\n\nExperimentation Is Crucial\n\nI'm ashamed to say that I never ran an A/B test before my time at Talent. It's just not a concern for early stage\nconsulting gigs. That changed very quickly for me and now I can't go back. We used A/B tests for everything:\nYou want to see which version will make more money? Split test and let revenue tell the truth.\nYou have a feature that's a little raw that you want help debugging? Hide it behind a feature flag and watch Sentry,\n the users will test if for you.\n\nThat said, there were certainly times that instrumenting an A/B test was annoying and I wished that I didn't need to,\nbut I would get over that in the long run. The thing I'm looking forward to most in my next role is what A/B testing\nsystem they use. In my time, I made an A/B testing system, used a homegrown system and Google Optimize, and feature\nflagged a bunch of stuff by roles/tags.\n\nIf It's Not In Production, It's Not Done\n\nAt previous jobs, especially the consulting ones, we followed some version of a Git flow branching model.\nAt Talent, we followed something closer to a trunk based approach. At first, if I'm honest, I really hated the trunk\nbased approach. With Git Flow, you have time and space to perfect your code with constant merges. Only when your feature\nis ready to go do you release it to the world. With the trunk based model, once your code is in main and someone\nrequests a release, 99.999% of the time, that code is going to production ASAP and we're not cherry picking around it.\n\nTo get around this limitation, I would make massive PRs and only put them in main\nonce I was happy. But that would cause me to ship bugs and would make it hard for larger changes to be shared with other\ndevelopers. Then I started making \"long lived feature branches\" for the larger changes that I would have teammates put\nPRs against that. That's the right move sometimes, but it leads to a lot of code drift as main moves ahead of it.\nFinally, our team had a rule that a ticket/card cannot be marked as done until it's in production. I was frustrated\nand I wanted to blow the whole thing up!\n\nIn a 1 on 1 with my boss, I brought up my issues and why I hated it. Could we change it? And this when he dropped this\nbomb on me:\n\nYou can get it to production, I believe in you, users don't have to be able to access it, it just needs to be in\nproduction. You can wrap it in a feature flag, put it behind a split test at 0%, you can even disable it based upon\nenvironment variables. If you get it to production, the velocity will move faster, trust me.\n\nThis was revelation! Oh how could I have been so close minded!? On my next task like this, I simply wrapped my feature\nso it was only accessible by developers and project managers and I shipped it. And wouldn't you know it, by being able\nto share this feature for feedback, my tasks got done faster and faster. Furthermore, I was able to debug production\nlevel bugs (like access issues) before users ever got their hands on it. I was shipping stuff a lot faster and became\na little bit of a single branch zealot.\n\nAs we onboarded developers coming from Git flow teams or teams that shipped code on a monthly or quarterly schedule,\nI got the delight of explaining that this is a little bit of an adjustment but it works in ways that you wouldn't\nexpect. It won't fix everything, but it will fix a lot of things.\n\nHere's To Tomorrow!\n\nAs you can tell, I enjoyed my time at Talent Inc and I hope they enjoyed having me. If you're looking for your next gig,\nI cannot recommend them enough. The future is very bright there and I'm sad that I won't be around to see it.\n\nAt the same time, I'm very excited for what's next. I don't even know what is next. I only have one speed which is \"go\nso hard I burnout once a year\". I should probably work on that… I'm going to take a few weeks to establish some better\nhabits and doing a thorough job search next year.\n\n \n \n You never know when you're going to show up on the marketing website…",
"title": "What I Learned Working At My First Startup",
"updatedAt": "2025-02-12T02:34:47.000Z"
}