Incident Management

When I joined FireHydrant's recently formed marketing team, they were trying to supplement a slowing outbound sales pipeline by ramping up inbound leads. I was responsible for rapidly re/designing and re/building touchpoints that supported this effort.

Within my first 30 days, I redesigned and rebuilt the entire marketing site and shipped a brand-new "data story" campaign. In my first 60, I helped launch an all new documentation site, and overhauled the FireHydrant visual identity.

To meet velocity required, I had to adapt fast — relying heavily on my past experience, both technical and otherwise, while collaborating effectively with a new, unfamiliar team.

Adaptability

While interviewing with FireHydrant, the business outlook was fantastic... Almost immediately upon starting that had changed. So much so, that within my first month, there was a round of layoffs that impacted ~20% of the company.

With that came the need for action, fast. This left little to no time for onboarding; I was coding and shipping my first week.

To add to the stress, the existing marketing site was cobbled together by an external agency using a framework I was unfamiliar with along with a complete mismatch of styles, and a dumpster fire of a CMS.

To recap, the brand was rough, the site was a mess, the team was new, the outlook was bleak, and time, non-existent. So naturally, my first suggestion at FireHydrant to rebuild the entire marketing site initially sounded wild.

Rebuild and refine

Getting up to speed on the framework, detangling the CMS, and unifying the styling across the existing site would take longer than just rebuilding it from scratch. With that, the unfamiliarity would linger for months, adding time to future projects.

To qualm fears, I took a gamble and promised the rebuild to take three weeks or less. There was still some hesitation, so within my first week, I rebuilt the homepage overnight using my favorite tools.

This exercise helped communicate a few things. First, it provided a clear example of what the site could look like and that a massive jump/change in the brand itself wasn't needed. Specifically, it ensured the brand could benefit from it's existing recognition. Second, it built trust that I was capable of delivering on my promise. Beyond that, it showed the code itself was easier to work on, maintain, and understand by the greater team.

The rebuild was approved and I got to work. I was able to deliver on my promise, and the new site was launched within three weeks improving uniformity, accessibility, performance, maintainability, and the overall brand.

• 300+ pages updated across site in total
• 25+ custom page templates rebuilt
• -50% less dependencies in the codebase
• 56%+ increase in Lighthouse scores

Technical experience

The key to all of this progress in a short amount of time was my direct experience doing these exact tasks: designing and building brands, campaigns, and websites from scratch for lean SaaS companies targetting enterprise customers.

Remixing and rebuilding a site like this wasn't a new experience. I had just finished doing this same thing, a couple of times, while at Rewatch. This gave me the foundation needed to move quickly without over-analyzing every micro decision.

For decisions like choosing an SSG or how to approach the CSS structure, or even something as complex as building out the navigation, I had a direct frame of reference. This exercise also gave me another opportunity to further refine those previous approaches to design and code along the way.

Informing design

Most SaaS products and brands that are achieving excellence through design today are simply doing a better job at embracing the tools used to build it. Understanding this doesn't just lead to better quality, it also results in efficiency, collaboration, and, ultimately, revenue.

Whether it's in Figma or the front-end, that means knowing how to make the box-model beautiful. In either case, the greatness of this model is its simplicity and reliance on design fundamentals.

Fortunately, I was schooled in traditional print design. This education gave me an appreciation for visual design intricacies like value, white space, and typography that are often forgotten but foundational in achieving success through the box-model.

Pairing the understanding of what "makes" a design unique with the ability to technically break those properties apart helped me comprehend how great design is being created and then remix it toward the current problem I was trying to solve.

On the dev side, this understanding helped me choose tools and approaches that cater to these design requirements. For example, tools that make experimenting with and altering a grayscale across an entire site simple to nail value and contrast, or fine tuning line-height and letter-spacing to achieve the amount of optimal white space, site-wide.

In regards to FireHydrant, this knowledge and approach helped me quickly build and arrive upon a strong visual direction to an engineering-focused brand that was scalable while maintaining enough similarity to the existing direction to maintain brand recongnition. So much so, that the team wanted to find how to align the product to it, ASAP.

Collaboration

To enable collaboration is to open up processes, making them approachable and easy to understand — within reason, giving every team member the ability to express, build, and share their ideas in a format that progresses work vs. picks it apart.

At FireHydrant, a major hurdle in the site rebuild/redesign was the existing product UI. Honestly, it was just bad — so much so that using it within marketing assets felt like a deturrent for prospects weighing the tool against competitors.

Major hurdles

To get around ugly product UI, I decided to polish up a few key product screens on-the-fly and stub them into the new site —unintentionally sparking chaos and outrage 🙈.

The VP of Product Design was not happy. Unbeknown to me, and most of the company, they had been working on a redesign for the past six months. The examples I had put together were in direct conflict with that work and, to some extent, forced that hidden work to be seen by the greater team.

I was hoping to clean up the nav, color usage, and table stylings – and support light/dark theming.

Adding to the awkwardness, once shown, the direction of the silo'd product redesign was not well received nor was there much progress for the amount of time that had been spent on it.

All of this was happening around my 15 day mark. To be fair, it was probably odd that a "web developer" working on marketing stuff was proposing product design. Looking back, gaining historical context and insight into what lead to the current state of the product would have been helpful. In any case, things got even weirder a week later when the VP of Product Design was let go during a round of layoffs...

At this point, the site rebuild was blocked by need for better looking, more aligned product UI. The remaining product design team was also relatively new — which left two unfamiliar teams in a fairly awkward situation that had to be solved rather quicky.

Removing silos

To get past the awkwardness and engage the other team, I visualized the problem in a way that resonated. I replaced the polished UI with 1:1 screenshots of the product. Simultaneously, I converted the pages I had designed in code to Figma so that the product design team could easily experiment with solutions that they too felt good about.

This approach worked. Most importantly, it familiarized the two teams while unlocking cross-functional collaboration. Beyond that, it expedited the project; allowing the product team to work on visuals while I continued with other aspects of the site.

Building for teams

I documented my work thoroughly for a couple of reasons. First, the process of forcing oneself to present what they're doing acts as a check on logic and reasoning. Secondly, by sharing that documentation, it enables others to understand and build upon the work while also reviewing it, preventing silos.

At FireHydrant, this paid of quickly. Using the documentation I put together for the marketing site, a sales engineers was able to build out an MVP for a new Product Docs site within a couple weeks — effectively removing a costly help-center tool from the stack and leveling up the quality of the Docs themself.

After syncing up on the project, I helped with some final touches on the design and then they shipped it.

Inspiring the organization

At the time, the rate at which the new marketing and docs sites were shipped along with the quality that was met, was a positive change of pace for FireHydrant. Seeing how these projects were built inspired the rest of the team.

Shortly after parting ways with FireHydrant, they shipped a new, fully redesigned product that was built within weeks 🚢.

I eventually boomeranged back to Rewatch and was fortunate enough to continue working with this delightful team on an ongoing, contract basis.

Key Takeaways

While my time at FireHydrant was brief, it was impactful and loaded with new experiences that I learned from. Here are a few of the key takeaways:

Seeing is believing

I learned it's easier to get people to believe in, trust, and advocate for something that they can see and interact with, vs. something they can only read or hear about. Sometimes, building an example is a better first step than asking for permission.

Lead through action

Aside from leading and managing the company, Robert Ross, the Co-founder and CEO of FireHydrant, regularly pushes code, writes blog/social posts, and records videos to market the product. It was inspiring to work with and alongside him. I learned to lead in similar ways, demonstrating empathy and understanding through first-hand experience, doing the work.

Solutions > Problems

I found that focusing on how or why something is problematic is easier than finding a resolution to make it work within those constraints. Though, almost always, finding that solution is going to be more valuable and rewarding than basking in problems, even if the situation it was built within is less than ideal.