Story recorded in March, 2020. Learn more about Dan on his blog, Twitter, and Linkedin.
Tell us a little about your current role: your title, the company you work at, and generally what sort of work does your team do?
I’m a Staff Engineer at Squarespace. Squarespace is the leading all-in-one platform to build a beautiful online presence: websites, domains, online stores, marketing tools, scheduling appointments, etc. I also operate as the Team Lead of the Internationalization Platform team, which is responsible for building and maintaining the foundational primitives of internationalization across Squarespace products. Engineers use the tools and libraries we own to create localized products.
What does a Staff-plus engineer do at Squarespace? How do you spend your time?
I think in practice the day-to-day responsibilities of Staff-plus engineers vary, depending on both your precise role and how your responsibilities map in the organization.
My position as a Team Lead means I’m fully accountable for the output of my team, both from a business and technical perspective. On the business side, I spend a lot of time meeting with different teams and functions across the company. These stakeholders include product, strategy, customer operations, etc. I want to ensure that I have as many inputs as possible to validate that my team’s roadmap reflects our company’s most important priorities.
On the technical side, I often find myself reviewing technical documents or scoping work in front of a whiteboard for my team’s work in flight. My role has evolved to less hands on coding work and more asking probing questions about architectural decisions and deployment strategies. One irony is that as a Staff Engineer I actually code significantly less than I did as a non-Staff. By no means is that universally true across the role, but in the context of my team, closing vim and operating in more of a strategic/oversight role was the highest leverage use of my time. I’m lucky in that my team is already composed of awesome engineers so my specific code contributions are less material to our output.
But many Staff-plus engineers at Squarespace are not Team Leads and code a lot. Others focus on engineering process and culture. In general I’d say Staff-plus Engineer responsibilities are highly contextual.
Some of Dan's writing on engineering leadership
Where do you feel most impactful as a Staff-plus engineer? What’s something you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done in earlier roles?
I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature. As a hypothetical example, I’d feel comfortable surfacing what I perceive as shortcomings in the engineering onboarding process in this type of meeting. It can be hard to attribute a topic like engineering onboarding to a specific team but a lack of formal ownership doesn’t make it less important. I think a key responsibility of Staff-plus is a willingness to own all of the things that contribute to (or block) engineering output, which includes both technical strategy and culture.
Regarding something that’s changed, on an everyday basis my title affords a high level of credibility at the outset of conversations. While I’m not advocating for a culture that values titles over ideas, I’d be lying if I said it didn’t help me escalate or push through issues that I previously might’ve had a harder time getting through.
Do you spend time advocating for technology, practice, process or architectural change? Can you share a story of influencing your organization?
I don’t really think about advocacy in terms of categories. I mostly just want our engineering team and product to be the best it can be and address things that experience tells me I can help change.
Some examples:
- When I first joined the company we were in the midst of enormous employee growth, and I noticed it felt hard to get to know anyone on other teams unless you happened to work on a project together. As a result I created a slack room — #connect-engineering — that uses a bot to randomly pair two people in engineering for coffee every two weeks. That room has been pairing people for coffee for over two years now.
- I knew based on personal experience that engineering leadership roles can feel isolating and talking to coworkers I could hear some of those feelings of loneliness. As a result some peers and I created an unofficial Engineering Management Book Club, open to Team Leads and Engineering Managers. There are now two self-organized book clubs with ~10 participants each, providing a safe space for both new and experienced leaders to support each other. The feedback about book club has been enormously positive.
To be fair, neither of these examples required a Staff-plus title. But I do think part of being an effective Staff-plus engineer is caring about and addressing cultural gaps as much as technical gaps.
You first got the title Staff engineer at Squarespace. What was the process of getting promoted to Staff?
I was hired as a Senior Software Engineer II (one level below Staff). I was fortunate to land on a team working on a high impact project that I was able to contribute to immediately. The hardest parts about the project concerned a problem space I was already familiar with — wide, sweeping changes across codebases — and I proposed, prototyped and eventually shipped an alternative architecture that I felt would better position the company for success. That became our frontend translation system, which I wrote about on our engineering blog: Building a System for Frontend Translations.
I also owned the communication and education effort around the new translation system, presenting the architecture at internal meetings and sending relevant emails about the status of the project. Grouping this technical contribution to some meaningful cultural initiatives — other internal presentations, #connect-engineering, etc. — my manager had a good case for promotion that was agreed upon by the Engineering Directors.
What about a piece of advice for someone who has just started as a Staff engineer?
I feel like progressing up a career ladder is an additive exercise in forcing you to care about more things than you previously cared about. Caring about more things is hard.
As a trivial example: The intern cares about the small aspect of a feature they can build in three months. The full-time engineer on the team cares about the entire lifecycle of that feature. The team lead/manager cares about the suite of features that compose a product. The director cares about the suite of products owned by their organization. And so on.
Every rung up the ladder means you care about another layer of abstraction, in addition to caring about all the layers beneath your current one.
I feel like a Staff Engineering role is similar in that you’re leaving the comfort zone of a specific technical domain to a more general problem domain: engineering. And as leaders you’re leaving a potential technical comfort zone to the realm of the system of challenges that impact engineering output. What are the biggest problems holding back engineering teams that fall between the cracks of team ownership? Those are your problems now, in addition to all of the problems of your technical domain.
So while Staff is an aspirational title to achieve, it also includes significant added responsibility. You’re a leader now, whether you want to be or not.
How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?
I think sponsorship is a key responsibility of any senior role and material to the growth of any engineering organization. I suppose the definition of “sponsorship” varies, but to me one tangible way is to provide opportunities for exposure. For example:
- Giving less senior teammates the opportunity to own and present their work at wider meetings.
- Reaching out to a team who just shipped an awesome feature to write a post for our engineering blog.
- Encouraging someone I met in a #connect-engineering coffee who has unique experience or perspective to give an internal presentation.
- Ensuring that meetings are not dominated by the perspectives of a vocal minority and soliciting opinions from everyone in the room.
- Giving public kudos in a large slack room to someone who just did something great that everyone didn’t see.
Lara Hogan has a great post on sponsorship in practice: What does sponsorship look like?
Talks by Dan Na
Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?
Yes, and I still actively consider it. I know it’s more convenient to think about the two ladders as mutually exclusive but I don’t.
I still enjoy both shipping code and running teams, and I think the ability to do both at a high level is critical for long-term engineering success. Charity Majors has a fantastic blog post on this topic that I recommend reading: “The Engineer/Manager Pendulum”.
Charity argues that “manager career path vs engineering career path” is a false dichotomy, and taking time to alternate between both roles makes you better at both. This maps to my own experience. I’m a better manager because I know how terrible it is to be an IC on a poorly planned project, and I’m a better IC because I know how and when to sound an alarm when a project is going poorly.
I think one of the most important strategic skills for building software is the ability to converge towards pragmatic decision making. A failure mode I’ve seen repeatedly is when a product manager comes with business requirements and an engineer comes with technical pushback and neither are willing to budge. The ability to empathize with both sets of incentives and navigate that tension is the only way to get anything done, and the best way to build that empathy is to sit in both seats.
To specifically answer this question: my previous role prior to joining Squarespace was an Engineering Manager. I love being an Engineering Manager but I wanted to keep my technical skills sharp so I accepted an IC role. Then I was promoted to Staff.
What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?
In the context of engineering leadership, two books stand out.
My favorite engineering leadership book of all time is High Output Management by Andrew Grove. I pick it up from my bookshelf once a year and end up unintentionally re-reading it. Many ideas from Grove’s book have significantly shaped how I view work and leadership: “the measure of a manager is the output of the organization underneath them,” “delegation is not abdication,” the concept of engineering/managerial leverage, etc. In terms of communicating the tactical aspects of engineering leadership I still think Grove’s book is best.
On the human side of leadership, I really loved Lara Hogan’s book: Resilient Management. I had the absurdly good fortune of starting my NYC tech career at Etsy in 2013 where Lara was my first engineering manager. Lara is a master of unpacking and addressing the hardest parts about navigating emotions and personalities, fostering psychological safety, and sponsoring coworkers. And having worked directly under her for close to four years, she is totally the real deal and practices what she preaches.
In terms of non-books, I subscribe to and enjoy reading “Irrational Exuberance,” where Will Larson regularly blogs about engineering management with a highly pragmatic and strategic perspective. I’ve also recently discovered and enjoyed reading Marty Cagan’s “Insights Blog,” mostly because product leadership is a domain I’m less familiar with and am interested in learning more about.
My role models are some of the amazing coworkers I’ve worked closely with over the years. I sat next to Daniel Espeset for four years at Etsy and learned an immeasurable amount about coupling technical execution with cultural impact. I learned a lot watching Lara do things like advocate for and achieve pay equity across our engineering group. I learn a lot watching current coworkers like Tanya Reilly institute and evolve our engineering processes to match our ever-growing scale. I’m inspired most by people whom I’ve personally witnessed have the courage to change companies for the better, despite whatever friction they encountered along the way.