
Y’all, I just hit nine years at Sprout Social! Can you believe it? Anytime a friend asks, "You still at Sprout?" I typically respond with, "Yeah, I’m still at Sprout." I don’t mean this in a bad way, its just that the folks I’ve interviewed and hired usually haven’t stayed even five years at an organization. Every year I go through an existential crisis of “<em>Am I providing value with what I do</em>?” I usually realize that's an annoying question, but this year is different. I’m not going to get a gold watch for my time at Sprout, but there are so many things I continue to learn in my day-to-day. I want to talk about nine lessons I’ve learned working at Sprout Social.

<ol class="list-decimal pl-8 lg:pl-12">
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be willing to adapt</h2>

Some of my biggest missteps in my career were due to my stubbornness or a “but that’s not what I’m used to” attitude. I spend a lot of time telling my team how important the ability to adapt is because things change! As an individual contributor (IC) software engineer or even a CTO, it is critical to adjust and adapt for the bottom line. A job is a job at the end of the day, but if you have resilience or grit, you’re going to be much better off than those who may be apprehensive about change.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be scrappy</h2>

This was an “old world” Sprout value, but it is an important virtue for the team I work with. Scrappy doesn’t mean “lazy,” and it doesn’t mean “hasty.” To me, being scrappy means accomplishing something with your own sense of urgency. Decision-making becomes difficult as an organization grows, but as an individual, if you have the willingness to accomplish something and the ability to sell it, you’ll be a valuable asset to the organization. Get it done however you need to get it done.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be around the right people</h2>

No engineering or management book covers this nearly as much as they should. I spent years talking about “the Sprout Game of Thrones,” which lent itself nicely to the fact that our executive squad used to be referred to as “The Small Council.” All of my growth within the organization is a direct result of putting myself in front of people that a marketing developer shouldn’t have been. You have to advocate for your worth, and it becomes easier once you really get to know the higher-ups. Some of my favorite moments at Sprout included playing shuffleboard or pool against my CEO. This isn’t easy to do, especially as a remote employee, but when you are trying to grow in an organization, it truly is about who you know. The Sprout alumni group is a beautiful example of this. I hate the “your net ‘worth’ is your ‘network’” sentiment, but especially at a company like Sprout, it’s really important to maintain relationships.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be a little lazy</h2>
Try to automate as much of your position as possible so it doesn’t require mental energy. This was easier to talk about pre-AI, but I truly think that being lazy begets being annoyed about something, which subsequently causes you to care about and finally fix it. Listen, no one loves work, but if you can be fulfilled and be a little lazy? Game over, you’ve hit the jackpot. Try to do as little as possible until you have to do as much as possible to bring you back to doing as little as possible.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be wrong</h2>

In every workshop about employee growth, they talk about the idea of going in with a “growth mindset,” and as much as I agree with this, they never really talk about being wrong. There have been so many circumstances in my time at Sprout where I was way wrong, and that’s how I actually grew. We talk about giving ICs the ability to “fail” but always knowing that there’s a life raft, but to have an IC feel like they were totally wrong? That, in my opinion, is how true growth happens.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be your own boss</h2>

I have an incredible manager. So much so that I can’t imagine leaving the organization unless she did. My manager has been my boss for over five years, and every upward-feedback review cycle I shout out that my boss has never explicitly asked me to do something. This is because I have been preemptive in knowing what my boss may ask of me. By anticipating any ask, I know that I have the agency to do it my own way, but also have the room to fail or be wrong. The most successful people on the teams I’ve led have all had the same mentality that competency for your position can and should be determined by you.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be assertive</h2>

In software development, there’s no shortage of soapboxes to stand on or arbitrary hills to die on (tabs vs. spaces, anyone?), but an important characteristic of being a team player is being assertive and knowing how to sell why you feel that way. Sometimes you’re going to be wrong, but it’s more impactful to make a decision and run with it than to have repeat conversations with the team over and over again because no one really wants to commit. We used to have the “scale of f*cks given,” which was helpful to even allow the space to be assertive. From there, leading the charge and advocating for an approach allows work to actually get done, not just talked about.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be open to feedback</h2>

I hated constructive feedback when I started at Sprout. I had the mindset of “Who are you to be giving me feedback? I’m great at my job.” The older I get, the funnier that hubris is to me. I see it a lot with more junior or associate-level software engineers. It’s important to feel confident (read: not arrogant), but the best growth happens when you start soliciting feedback. Feedback is an important value at most tech companies, and for good reason. When we talk about self-led growth or having a growth mindset, it all depends on a person’s willingness to ask for feedback and really put it into action, even following back up. Recently, I was working with a teammate who received some corrective feedback from a peer. They took it seriously, changed their behaviors and working style with their peers, and then got heralded in a casual stand-up by the person initially giving the feedback. It’s amazing to see that work and how productive they are now collaborating, and it’s entirely because that person wasn’t just open to the feedback, they knew the impact putting it to action would have.
</li>
<li class="mt-8">
<h2 class="font-sans text-2xl lg:text-3xl">Be stoked</h2>

I’m a glass-half-full person almost always, which isn’t very Virgo of me. In nine years, I’ve seen many of the same types of projects, new folks bringing in older approaches, and instead of discrediting or being negative, I love to find the opportunity in trying it again. A big thing I get called out for at work is my energy and passion for what we do. If you’re not stoked on it, then why are you doing it? Again, a job is a job, but it’s almost entirely what you make of it. Why wouldn’t you want to be stoked doing it? The more fulfillment you have in your role, the better work you’re going to do. This isn’t rocket science. Get excited! When you’re frustrated by a project or workload, really take inventory of what is important to you in your career. Paycheck? Sure, but you don’t stay at a company for as long as I have without finding the joy and energy in getting to do awesome work.
</li>
</ol>

<p class="mt-8">So that’s it. Nine whole years. The company I work for is an entirely different operation than when I started, and that’s a great thing. I’ve seen so many stages of the company, and I wouldn’t have had it any other way. The relationships I’ve built and the projects I’ve been fortunate to collaborate on have been an absolute joy. Here’s to nine more years! 😂</p>

9 years


If you haven't watched it in a while, 1998's "Armageddon" is an incredible work of art. It's part of the Criterion collection for a reason. Michael Bay is doing full-on Michael Bay, and enough Aerosmith on the soundtrack to last a lifetime. Armageddon is the story of a rag-tag oil "roughnecks" team recruited by NASA to save the world from an impending asteroid collision. If you haven't watched it, this should be the sign to stop reading and immediately fire that bad boy up on Amazon Prime. When rewatching this movie all I could think of was how good of a boss Harry Stamper, played by Bruce Willis, is. Harry is a determined leader and exhibits many leadership lessons throughout the movie. From his unwavering commitment to his team's well-being to his ability to make tough decisions under pressure, Harry's character provides valuable insights into effective leadership.

<h2 class="font-sans text-3xl">Resilience and Determination</h2>

Harry is an ideal example of resilience and determination in the face of impossible odds. Despite the overwhelming magnitude of the task, Harry never succumbs to despair or doubt. Instead, he remains resolute, constantly motivating his team members and inspiring them to push beyond their limits. Harry's unwavering determination serves as a reminder that leaders must possess a steadfast resolve, even in the most challenging circumstances, to instill confidence and inspire their teams to achieve the impossible. He exhibits the very definition of "keeping his cool."

<h2 class="font-sans text-3xl">Putting the Team First</h2>

One of Harry's most notable leadership characteristics is his unwavering commitment to the well-being of his team. Harry consistently places his crew's safety and success above his interests throughout the movie. He ensures everyone has the necessary skills and knowledge to fulfill their roles effectively. Harry also fosters an environment of trust and camaraderie, emphasizing the importance of teamwork and collaboration. His selfless approach to leadership serves as a critical reminder that a leader's primary responsibility is to empower and support their team members.

<h2 class="font-sans text-3xl">Making Tough Decisions</h2>

Harry is forced to make several tough decisions with life-or-death consequences in a dire situation. These moments highlight his ability to remain calm under pressure and make swift choices for the greater good. Harry understands that effective leadership sometimes requires making unpopular decisions, but he does so with a clear focus on the mission's success. His willingness to take calculated risks and shoulder the responsibility of difficult choices demonstrates the importance of decisive leadership, even in the most challenging situations.

Harry's leadership in Armageddon provides valuable lessons for leaders in any industry. His resilience, determination, unwavering commitment to the team's well-being, and ability to make tough decisions under pressure set him apart as an exceptional leader. Harry's character inspires his team and the audience, reminding us of strong leadership's critical role in overcoming seemingly impossible challenges. By emulating Harry's leadership traits, individuals can aspire to become influential leaders who inspire and guide their teams to achieve extraordinary results. Software engineering leadership is by no means life-saving missions to life-threatening asteroids, but there are some tidbits I'll be putting into place for my team, and I hope you do as well.

Leadership lessons from 1998’s blockbuster hit “Armageddon”


Over the past year, I've made 2 separate attempts at creating a simple web app for my wife and me to share recipes we find online and track when we make them. It also started because I was interested in seeing if I could scrape NYT Cooking and AllRecipes to store in a centralized location, not that I would do that because that's highly against their terms of service 🤫. Application sounds simple enough, right? Sure, but for some reason, I always abandon the project while I'm building because I'll get hung up on a particular feature or just generally lose interest. Sound familiar? We've continued writing down our week's dinners on our kitchen wallboard and it *works* but...

New year, new me right? I had some PTO taken while we potty train our daughter, and during naps and when she goes to bed it's off to the races for me. This time I'm taking a different approach, treating it like a legitimate project and mapping requirements, wire-framing (and even designing) before touching code. We'll see if it works!

## The Requirements

I could very well create this application in Airtable or a Notion doc, but wheres the fun in that? The application's actual responsibilities are very simple:

* Allow for multiple users to add and edit recipes
* Allow for tracking when a particular recipe is made on a particular "account"

As I type that out I'm already overwhelmed by the unforeseen complexity. Especially given the "Nice To Have" requirements like

* Ability to copy multiple recipes' ingredients lists to a "Notes" file for simplified grocery shopping
* Ability to "schedule" dinners
* Ability to look back in a calendar and see all dinners made

## The Process

On Friday evening after my daughter went to bed I dusted off Sketch and downloaded their [Elements UI Kit](https://www.sketch.com/elements) to ease in my "designing". They sure did make it a breeze.

![screenshot of sketch](/assets/img/sketch.png)

I began working on the home feed and "Recipe" screen (also I've typed "recipe" so many times over the past few days it's lost all meaning). Ideally, the application when launched "recommends" a dinner recipe that you haven't made in the last week. See? There I go again just adding more complex functionality!

The Elements UI Kit made prototyping and enacting how I wanted to display information a breeze, and not committing to code I feel was really helpful for my process, again once I'm in my editor if I hit a block, I will likely just give it up, but this allowed me to make decisions, second guess myself and quickly create a new approach. The entire evening as I was designing in Sketch I was showing my wife who acted as a fantastic stakeholder (think "make the logo bigger" but for everything).

At the end of Friday evening I got the designs to a point where I felt I had enough to really start going after it, again repeating the very basic requirements:

* Allow for multiple users to add and edit recipes
* Allow for tracking when a particular recipe is made

With those in mind, I went to bed and thought of the myriad of ways we could accomplish this technically using any sort of tech. In the next part of this series, I'll talk through my technical decisions and how I began to scope the dev work! Stay tuned!

(_Spoiler alert_, it's definitely React w/ a Firebase backend because I'm basic 😏)


👋 Howdy! My name is Justin

Recent Writing

9 years

Leadership lessons from 1998’s blockbuster hit “Armageddon”

Third Time’s a Charm (Part 1)