What I Learned as a Staff+ Engineer

A reflection of my time as a technical leader in the media industry

Professional DevelopmentContinuing EducationSoft Skills

Earlier this year, I left my position as principal engineer at the media company where I worked for seven years. Although I had previous leadership experience, it was on the management track. This position was my first time as a leader on the technical track. I learned valuable lessons, not just in technical mastery but also in understanding how to drive business outcomes, foster collaboration, and scale my impact across the organization. I wanted to get these ideas down to document some key takeaways from my experience while it's still semi-fresh.

Aligning engineering work with business goals

One of the most critical lessons was that technical work must align with business objectives. Engineering was seen as a cost center to the business. We weren't meant to bring in the revenue directly, but it was our goal to develop digital product in support of revenue growth. At this company, the primary business objective was to increase membership. Sometimes, we would also need to divert our attention to develop products to support ancillary revenue as a means of diversifying revenue streams. Especially as an engineering organization whose headcount was trending downward more than it was growing, it was important to tie everything back to revenue.

If a project didn't directly support revenue, I often sought to understand the context behind the request. Sometimes, that meant being the one to halt an idea that carried too much opportunity cost. This was extremely difficult to do sometimes because it had absolutely nothing to do with technology and everything to do with people. I learned the value of saying "not right now" instead of "no," as it softened the delivery. Work is a funny thing because everyone tends to view their work as the most important, and that can be a difficult issue to try to mediate and triage.

Even still, I hung my hat on the notion that engineering initiatives should always contribute to business success, whether through performance improvements, cost savings, or better user experiences.

Scaling my impact

There was only one of me, but my work needed to impact many people across the organization. To scale my impact, I focused on writing more and mentoring others interested in software leadership. I produced documentation not just for engineering but for other departments like marketing, which often evaluated software for their needs.

One of the most valuable practices I adopted was writing Request for Comments (RFC) documents. I learned about this from Tanya Reilly's book, The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change. I even borrowed the template directly from the work she produced at Squarespace. This practice took off beyond engineering and was embraced by other departments. We openly shared these documents and welcomed comments from anyone, giving more people a voice in what we built.

I also created prototypes and demos to generate buy-in. The prototypes led to conversations that helped raise the profile of our engineering work across the organization. Having spent most of my career in the media industry, I had significant domain knowledge and understood many of the pain points. I would often approach people with prototypes, saying, "I'm working on this new thing, and I'd love your feedback on whether it's useful to you." These interactions were invaluable for securing buy-in and often led to sponsorship from influential stakeholders.

Make the "invisible" visible

In engineering, a lot of work goes unnoticed unless explicitly showcased. From system optimizations to architectural changes, it's crucial to make these contributions visible. For example, when working on A/B tests or web performance optimizations, I produced artifacts like charts and graphs that could be included in presentations or shared in Slack.

I also spent considerable time optimizing our AWS infrastructure and shared these wins across the company. I managed to save 30% on our cloud costs and left my former employer with a strategy to continue those savings after my departure. Additionally, I outlined a plan to consolidate and migrate workloads to different EC2 instance types, which could have saved another 40%.

To ensure routine tasks didn't fall through the cracks, I created checklists and maintenance schedules for overlooked tasks like clearing caches, running performance audits, and reviewing tag manager scripts.

Asking questions

Asking questions was a key driver of progress. Whether I was inquiring about renewal rates, trial conversions, or performance impacts, the more questions I asked, the closer I got to understanding the problems. This, in turn, allowed me to suggest more targeted, technology-driven solutions. People were generous with their time if I showed curiosity about their work and the challenges they faced, which helped build valuable social capital.

Staying current

Exploring new technologies is part of staying ahead as an engineer, but it's crucial to evaluate whether these innovations add real value to the business. I've written before about my approach to continuing education and skill development and maintain an active reading and course list for topics of interest. Staying informed about industry trends ensured that our engineering team was prepared for what lay ahead. Some of my go-to resources include:

I also connected with other engineers through:

Always look for automation opportunities

If there was a task I could automate, I aimed to do so. This included things like linting and testing developer code, using Infrastructure as Code, and automating cost optimizations in AWS (as mentioned earlier). I expanded our monitoring and alerting footprint and sought ways to make common requests self-service. If a particular request came in frequently, I pushed for product development to handle it systematically, rather than repeating manual tasks dictated by the business. I also monitored hotspots in the codebase to identify candidates for refactoring using the following command:

git log --pretty=format: --since="1 year ago" --name-only | sort | uniq -c | sort -rg | head -50

Monitoring and feedback loops

Monitoring isn't just for systems; it's also for understanding what's happening across an organization. Sorting Slack channels by recent activity gave me a good sense of what was on the horizon or what issues people were working on. If I recall correctly, I believe I took this tip from Will Larson's Staff Engineer: Leadership beyond the management track, and I still do this at my current employer.