This story was recorded in July, 2020. Learn more about Kasa on Linkedin.
Tell us a little about your current role: where do you work, your title and generally the sort of work that you and your team do.
I’m a Staff Engineer at Mailchimp, working in the Data Services engineering group. Data Services can be seen as the home of data engineering within the company. Our group builds systems that primarily support our data science and analyst teams (i.e. product analysts, finance analysts, marketing analysts, etc.).
I have been serving as one of the tech leads in this group where I focused on building scalable data processing pipelines that power our internal analytics platform and supporting the advancement of critical business intelligence initiatives. I have been performing a significant portion of the Eng Manager responsibilities for the team as well (although I wasn’t formally the Eng Manager). After almost 2 years in this role, I am actively transitioning it to another engineer.
What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?
At Mailchimp, once you become a Staff Engineer, you’re a member of “Engineering Leadership”. Since a formal engineering ladder was implemented only a couple years ago, the answer to “What does it mean to be a Staff Engineer?” or “What does it mean to be a member of Engineering Leadership?” will likely vary.
In my view, it’s about thinking globally. That means partnering with other members of that cohort to understand the company–wide business / product strategy and distill that into an Engineering–wide technical strategy that seeks to enable execution for Product, Marketing, and our peers across other functions. That means partnering to improve on processes like hiring, onboarding, cross–team communication, and production operations. That means partnering to grow the entire department’s technical and social skills.
It’s about taking that global thinking and applying it locally. That means aligning your team’s (technical) initiatives / roadmaps to the Engineering–wide technical strategy; and being intentional about when you veer off of that path to serve the needs of your team’s immediate stakeholders. That means collaborating with your team’s managers in adopting successful practices in hiring, onboarding, and production operations from other teams; and sharing practices from your team that would be beneficial for others. That means taking context from company–wide business / product strategy and translating that to how it impacts your team’s immediate projects. That means being intentional about creating opportunities for your team’s individual contributors to grow their skills, get visibility, and access to others across the company.
Of course, I don’t get it right all the time. But it’s been a successful mode of operation for me.
How do you spend your time day-to-day?
As mentioned before, I have been serving as one of the tech leads in Data Services (and performing a lot of the Eng Manager responsibilities).
As tech lead, I was responsible for defining, and accountable for execution of, my team’s technical strategy and approach. I worked to underpin this strategy in its value to our internal customers (or the business) and effectively communicate that across the company when needed. A couple of times a year I reflected on what progress was made, and if anything had changed within the business that required adjustments to this strategy. I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sustained “hand to keyboard” work to ensure that my technical strategy (and other macro–level decision–making) was informed by the on–the–ground experiences of the rest of my team. A focus for me was growing and developing the other engineers on the team as a result of the technical direction I set. More concretely: I worked to help my teammates (via mentoring or coaching) understand how to approach technical decision–making and how it should be underpinned by the customer / business problem it’s solving and the value it’s providing; I worked to help them understand how to drive engineering projects from problem statement to production release / long–term operations; I worked to help them understand the proper communication practices for different audiences (i.e. engineering peers, vs. engineering management, vs. non–technical stakeholders, etc.). In aggregate, I worked to help them get to a level of self–sufficiency where they can operate and communicate in a way that aligns with my technical strategy, direction, and approach without me having to be in the room or in the conversation.
Our group doesn’t have product managers. But those needs around things like understanding internal customer needs and stakeholder management still exist. The recently hired Eng Manager for my team is accountable for this; but we shared a lot of the responsibility here. I did a fair amount of chatting with internal customers, answering quick one–off questions, understanding needs for new pieces of work (i.e. new datasets), recommending paths forward, setting expectations around when we’d be able to execute on the new piece of work, etc.
Our group doesn’t have project managers either. But, again, those needs exist. I believe in empowering each team member to own the project management responsibilities for their assigned project (i.e. status updates to stakeholders, etc.). I did a fair amount of coaching on project management tactics like proactively communicating risks / blockers so that I can help unblock them and how to continuously deliver incremental value to maintain momentum.
I spent a good amount of time building passive internal customer and business context. I’d occasionally read merged pull requests for repos that I didn’t maintain; I’d read tech specs and proposals that are shared publicly; I’d occasionally attend various internal presentations from the data science and analyst teams where they presented projects they completed or ideas they’re exploring. All of these are small tactics, but they aided in my situational awareness and was one key input into my team’s quarterly planning activities.
As a tech lead, I was a member of the Eng Tech Lead Cohort. It’s a formal group of all of the tech leads across the Engineering department meant to share context, talk through ideas, and help advance the Engineering–wide technical roadmap. There’s some ad hoc conversations and work that may come out of this group from time to time. There’s also a recurring call for all Staff, Senior Staff, and Principal Engineers meant as a space to surface and discuss problems, assign owners and actions items when needed, and generally build community with each other. We have a close partnership with Google; they serve as our cloud provider. Occasionally, I’d spend time talking with our assigned partner team about challenges we’re running into, plans we have, proper approaches to solutions, formal training that would be helpful, etc.
As I’m transitioning out of the tech lead role, there will definitely be a change in how I spend my time day–to–day. But I’m honestly not sure what that will look like.
Where do you feel most impactful as a Staff-plus engineer?
It’s always a rewarding feeling if I can end the work day and feel like I’ve helped my peers get unblocked and maintain momentum.
That can mean helping one of my Data Services team members think through options for solving a complex technical problem and trade–offs like providing immediate value versus being sustainable long–term. Or helping them think through how to deeply investigate a new technology and if it can be applicable to solving one of our top 3 problems.
That can mean helping a peer on another team think through their deliverables over the past quarter, whether those deliverables provided real business / customer value, and how to build a narrative around that impact to make the case for promotion.
That can mean identifying that a short–term piece of “org work” is at a standstill because consensus wasn’t achieved, encouraging an involved peer to take ownership of making a decision (with proper feedback from interested parties), and drive it to completion.
This is a feeling I’ve always felt throughout my career; I enjoy the success of my peers as much as I do my own. But taking on the tech lead role certainly elevated the importance of doing it. It morphed from something I just liked doing, to something that I liked and was also important for the health of the team I was responsible for.
Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?
As mentioned before, once you become a Staff Engineer at Mailchimp, you’re a member of Eng Leadership.
It’s noticeable that Staff+ Engineers generally have more agency and ownership of their time. They encounter less resistance when they make time for work outside of their primary responsibilities. This has certainly been my personal experience.
I’ve also had a lot more organic opportunities to coach, mentor, and generally support more peers outside my team. It was something I was certainly doing before being promoted to Staff Engineer; but it noticeably increased. It’s definitely a rewarding part of my work day, so I welcome it.
Often industry peers tend to make the case that titles don’t matter. But I disagree 100% with this statement; my personal experiences and observations across the companies that I’ve worked at have shown me otherwise.
There is a popular idea that becoming a Staff engineer requires completing a “Staff Project.” Did you have a Staff Project, and if so what was it?
In some sense, I guess.
I joined Mailchimp as a Senior Engineer. I was immediately added to a project team (which included an Engineering Director and two Principal Engineers) meant to build out Mailchimp’s first internal, self–service analytics platform.
A key aspect of this project was being effective and executing at a high level. For better, or for worse, having two other Principal Engineers meant expectations for me likely weren’t that high. But I was able to jump in immediately and start contributing to core aspects of the project with very little hand–holding from them; by the end, I was one of the key contributors on the team. I would ultimately be formally installed as a tech lead to help continue shepherding that project work as it was absorbed into my current engineering group, Data Services.
Another key aspect of this project was a lot of visibility across the company. The project team’s work was categorized as a company–level initiative. This meant a lot of executive–level visibility; and, of course, the associated pressures of that. But the overall project team was able to sustain good momentum throughout and ultimately succeed in building out an initial iteration of the analytics platform. Also, my manager and the team’s Principal Engineers were intentional about creating opportunities for me to present the work of the project team; I ended up presenting at an Engineering All Hands, a company–wide All Hands, and co–delivering a tech talk at an Engineering recruiting event. Because of the visibility of the project and general culture at Mailchimp, I was able to collaborate with engineers at all levels in the company and engage with analysts from other departments in a very short time after joining—which is something most folks take a year or so to have the opportunity to do.
So, it was a combination of doing good work and being really effective alongside more senior engineers; and those senior engineers (and others) being intentional about giving me visibility and access across the company even though they were the technical leaders on the project.
Important note: The promotion didn’t come until I had also served some meaningful time as tech lead and delivered a lot of value there. But this project was definitely the firestarter.
Can you remember any piece of advice on reaching Staff that was particularly helpful for you?
First was from my manager, Marc Hedlund. He told me to write my performance review in the third person. The idea being that you’re more likely to praise others, and be less critical, when giving them a review. It’s pretty simple, but has been super useful to me. Oddly enough, it’s played a part in helping me understand how to build a coherent narrative around the work I do and the value it provides to the business.
Second was from Dan McKinely, one of the senior engineers on the “Staff project” I talked about. He provided direct feedback on my strengths and weaknesses when I asked for them. He noted that my strength around building relationships across the company is an important skill to have since the people / social aspects of engineering don’t go away; in fact, they are key to getting anything done.
Third was from Coda Hale, the other senior engineer on the “Staff project” I talked about. He talked about scaling your impact. Specifically:
first, effectively setting technical direction for other engineers; second, mentoring them and developing their talent as a consequence of the work you’re structuring for them.
This advice is core to how I think about my role as tech lead; like, really being intentional about creating opportunities for the team to extend, flex their skills, and learn a lot.
What about a piece of advice for someone who has just started as a Staff engineer?
Don’t think you’re going to solve ALL of the Engineering department’s problems; from what I’ve seen, it’ll get exhausting and you’ll get jaded pretty quickly. Slowly build up to those things. Hopefully, you were promoted because you were already operating at the Staff level; so you shouldn’t have to do anything dramatically different. Continue to do the great work that got you to this title. Once you feel like you’re settling into things, extend from there.
Communication and building narratives are key. Make sure to write … A LOT. When thinking through problems or ideas, write it down (even if you don’t intend to share them). Usually when I can’t capture a problem statement or idea in a coherent, concise paragraph it means I need to do more research and / or I’ll have a rough time trying to convince others it’s a worthwhile investment. Also, the written word allows you to scale your ideas and discussion around them more effectively; much easier than scheduling a meeting with every possible person to pitch the idea.
Try to make your managers’ job easier. Don’t just bring them problems; also bring them (multiple if possible) recommendations / suggestions for solutions to that problem and ask for their feedback. This way, the manager doesn’t have to do all the work of solving the problem for you (they likely have enough on their plates) and they have an opportunity to draw from their experiences to help you rule in / out your suggestions. Funny enough, it’s probably much easier for someone to provide feedback on why your solution is bad than it is to come up with a fleshed out solution on their own.
Start thinking intentionally about creating opportunities for other engineers you work directly with to grow their skills and get access and visibility to others in the company that they usually wouldn’t.
Build relationships early. It can help in situations where you need to spend some social / political capital to take a stance on something. If the first time you engage with someone is when, as an example, you’re fighting for opposing solutions to a hiring problem, you’re already starting from a deficit with that person. To be clear, you should never look to “people please”. But your working relationship and ability to collaborate productively on future endeavors with a specific person can be significantly easier if a relationship was built up beforehand.
Frankly speaking, trying to apply all of this is a lot; and it’s just one person’s opinion. Treat it like a restaurant menu; choose what resonates with you and try to apply it. Then, pay it forward by sharing your experience with the next person trying to make it to Staff.
Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?
I get asked this regularly.
I do have a goal of being a CTO; but that’s more of a directional thing to ensure I don’t get complacent about my career progression. In the context of Mailchimp, getting promoted to Principal Engineer would satisfy that goal for me. I’ve been able to deliver real, tangible business value at my current level; so I think I could continue that and continue to feel rewarded by sticking with the individual contributor track.
Also, I had been fulfilling a lot of the responsibilities of an Eng Manager for my team (without formally being the Eng Manager). So, a lot of the things I would have wanted to start doing if I switched to management, I was able to put in practice and get that experience. So, I’m sure that satisfied any itch I had for the time being.
What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?
Verbal communication about technology with various technical and non–technical audiences is a skill. It’s one that I try to cultivate and hone everyday. One person that I watch for a visual on how to do it right is Kelsey Hightower. Another is my college professor for a couple of my Software Engineering courses. He rarely ever came to class; but when he did I usually learned more about software development than I have in any other academic setting. They both know how to explain things well and tailor it to the audience.
There are a couple blogs that I’ve come across that have helped me hone, and fine tune, how I develop a technical approach and strategy. The first is ”Delivering on an architecture strategy” from Pete Hodgson that presents a framework for achieving a sustainable balance between feature delivery and foundational architectural work. The second is “Stepping Stones not Milestones” from James Cowling which is about delivering real value with big architectural initiatives.