Diana Pojar

Staff Data Engineer at Slack

This story was recorded in April, 2020. Learn more about Diana on her 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 Data Engineer and the Technical Lead for the Data Platform team at Slack. I joined Slack in February 2016 and I was one of the first engineers in the Data Engineering team. I was heavily involved in building many of the tools and infrastructure to make data available for long-term analytics. When I joined, the team had just made the decision to use Thrift as the logging format. If anyone wanted to get insights, they had to schedule cronjobs on top of the read replicas of the production MySQL database.

The purpose of the Data Engineering team at Slack is to enable anyone in the company (data science, engineers, product managers, etc) to access data, so they can compute insights, drive business decisions or build new features. The Data Platform team focuses on building services and frameworks that work at scale to empower everyone that needs to process or use data in the Data Warehouse. Some things that our teams own are: the Data Discovery service that exposes task, table, column lineage and general metadata, the event logging structure and the pipeline that consumes the events and exposes them in raw tables in the Data Warehouse.

More from Diana

What does a Staff-plus engineer do at Slack? How do you spend your time day-to-day?

The role of a Staff-plus engineer depends a lot on what the team needs and also what the particular engineer strengths are. From my experience the responsibilities of a Staff-plus engineer can change over time, but usually their main focus is working on projects/efforts that have strategic value for the company, while driving technical design and up-leveling their team.

There are two big categories that I’ve seen Staff-plus engineers fall into: focus more on depth (specialist) or focus more on breadth (generalist).

For the first category, folks that focus more on depth are usually experts in a particular domain and most of their time is spent on writing code or working on technical design documents to find solutions in their area of expertise. Companies deal with unique challenges and subject matter experts are needed to drive technical solutions for these extremely hard problems. For example, at Slack, as the company grew and our system needed to scale and perform, there is a principal engineer that his main focus and passion is to detect and fix performance problems.

Folks that focus on breadth usually work more closely with the leadership team, influencing the org or company wide technical vision, improving processes and culture. Due to their breadth, they are more flexible and can work on different areas of the engineering organization based on the company priorities and needs.

Personally, for now, I enjoy and focus more on breadth and how I spend my time depends a lot on what my team and organization needs. I would say that so far this year, about 50% of my time is spent on technical leadership and talking with people about larger technical investments that we should focus on, and 50% of my time is focused on mentoring, reviewing code, writing code, jumping on incidents and fixing critical issues, etc. The ratio does change quarter by quarter.

Where do you feel most impactful as a Staff-plus engineer? What’s something you’ve done as a Staff-plus engineer that you wouldn’t have done earlier in earlier roles?

Personally, I feel that it’s quite noticeable the increase in trust and respect from people that did not work with me before my promotion / title change. Having the title strongly correlates with one's ability to influence the organization/company roadmap and priorities - basically you get to be in the “room where it happens”.

I get to be part of building things that have impact for the direct success of the company. Advocating for such projects and being part of them was not something that would’ve been achievable in earlier roles.

I’m also able to uplevel others that are more junior and make their voices heard. Having a Staff+ title brings some privilege that others don’t have and I try to leverage that to help uplevel my team / peers.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for?

A significant amount of my time is actually spent on advocating for technical solutions, processes, architectural or cultural changes - it’s not only all about writing code. I'm constantly involved in the technical design review process for many of the teams that need to build systems that rely on the Data Engineering tools and services. Besides being involved in advocating for technical projects, an area of my focus is to improve culture or process changes.

One area that is dear to my heart and that I believe I had a significant role in my organization is around Incident Management and Analysis. I’ve been involved with the company’s resilience team to improve our Incident Analysis processes, but for my Data Engineering organization I was very involved in driving our general oncall expectations and structure, while also adopting the company’s Incident Response Structure.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

Sponsoring is actually an important area for me, as I focus on building amazing relationships with many people that I work with and I strongly believe that we need to lift each other up. Through my journey to get to Staff Engineer and fighting with my own impostor syndrome, I had the opportunity to work with amazing people that sponsored me and had a huge impact on my growth. A couple of people that I worked with and have been my mentors and role models over time are Josh Wills, Stan Babourine, Bogdan Gaza and Travis Crawford.

Mentoring and growing people around me has always been important to me and being in a Staff+ role, you have a type of privilege and power that others don’t have and I try my best to use this to help and uplevel people around me.

You first got the title Staff engineer at Slack. Were you hired as a Staff engineer? If not, what was the process of getting promoted to Staff?

I joined Slack as a mid level engineer and after one year I got my Senior promotion. As a Senior Engineer I had the opportunity to work on multiple projects with org/company wide impact, many of them that were directly tied into how our company business metrics are being computed, which were critical for getting the company ready to go public.

After being 2 years in the Senior role, my manager told me that I am operating at the next level and that he believed there was a strong case to make and he planned to put me up for promotion. At Slack, the Staff+ Engineering promotions need to have a promo package put together that illustrates with clear details and measurable information that a person operates at a certain level. The main areas of focus are: Technical Quality, Impact, Collaboration and Execution. We worked together to write and fill in all the necessary details for the promotion package. As an IC, I highly recommend, if it’s possible, to work with your manager and write this document together: it should be a team effort. After the packet is ready, the promotion package is evaluated by a special promo committee where some leadership and staff+ engineers from the whole company are present.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

As I look back and contemplate on how I felt and thought about this when I was a junior engineer, the main factor to get to Staff Engineer is to actually believe that YOU CAN DO IT and don’t let the impostor syndrome win.

In general, I’ve always tried to be very intentional with my career choices and usually I spend some time every year to think about what I’m doing and the areas of growth that I want to focus on. I’ve found this extremely valuable, because it makes me take a step back and assess what I am currently doing, to ask if I’m still growing in my current environment and think about new opportunities.

So at the end of 2015, when I decided I wanted to leave Twitter, I found out that Slack was starting to build their Data Engineering team. Being able to build and design from scratch the systems, services and frameworks was extremely exciting for me. Joining a newly-formed team at Slack was a unique opportunity that definitely contributed to reaching Staff Engineer. It gave me the opportunity to work on projects that had org or company wide impact. For example, the first big project I worked on moved about 25% of the load on the production MySQL database off to the Data Warehouse, saving the company millions of dollars.

Another critical factor that influenced my path to become a Staff Engineer were the people around me, as I was lucky to have amazing role models and mentors in my team. When I joined Slack, I was the 4th person in a very senior team (everyone else was Senior Staff), which contributed to my desire to prove myself and show that I belong. Building a track record of mentoring, visibility and technical quality in every project also contributed to my path towards Staff, I did not see my job as just a job, but I’ve put a lot of passion into every project or problem we tried to solve.

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?

No, I did not have an assigned “Staff Project” and that is not something that it’s part of the promotion process at Slack. There is a career ladder that describes the general expectations and scope of impact for every level and with Staff+ levels this level of scope starts to expand from org wide impact towards company wide impact.

I usually always try to challenge myself and I was always looking to drive change and impact in my organization. I think the most impactful project that I worked on and contributed to my path towards Staff Engineer was being involved in thinking through and implementing the technical design on how our company business metrics (ex: ARR) are computed to make sure the process is reliable, scalable and most importantly, reproducible. This was a critical initiative as Slack was completing a public company readiness process.

Can you remember any piece of advice on reaching Staff that was particularly helpful for you? Looking back, is there an easier path to Staff that you could have taken?

Something that I felt was extremely helpful was to understand that a Staff+ Engineer’s work and responsibility is more than writing code. Basically what got you to senior level will not get you to Staff+. It’s important to understand the expectations of this role in your company, but also in the industry as a whole, as there are some differences between companies.

Work with your manager or more senior peers to find projects that will challenge you and increase the scope of your work. Something that was extremely helpful to me is that I started investing in developing my leadership and communication skills more. I also started framing and thinking about certain things in a different way, when I was starting feeling stressed or unsure of my own abilities, that’s often a sign that I’m growing and stumbled into an area that offers a lot of growth opportunities.

What about a piece of advice for someone who has just started as a Staff engineer?

Reaching Staff Engineer brings a lot of responsibility and you should always be a strong advocate for your peers. As an IC, I think execution and being hands on are always the “easy” thing to do and the hard things are actually driving change and impact in your organization.

I think that in different moments of your tenure as a Staff engineer, you might see yourself focusing on different things and that is ok and expected. There’s not a single clean cut definition of what a Staff Engineer should do.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

This is actually a question that I ask myself every couple of years. Every time that I self-reflect and think about the answer to this question, the answer, for now, is no - I don’t want to be a manager. I love coding too much and I strongly believe that to be a successful manager you should not write code, and should instead be fully focused on growing your team. I like being involved in technical decisions and thinking about technical solutions way too much to give up this hands-on experience, even though as you get in more senior roles, the time you spend coding will decrease.

Not being an Engineering Manager doesn’t mean that you cannot influence and help people grow. As a Staff+ engineer you do need many of the core management skills, even though you are not a manager and I have found reading management books extremely helpful. I actually think that these two roles, even though they are on separate, parallel tracks, they are closer to each other than people think.

It’s possible that at some point in time, the answer to this question might change and that is ok.

What are some resources (books, blogs, people, etc) you’ve learned from? Who are your role models in the field?

I use Twitter extensively, but I’m mostly a consumer and follow many people in tech. I usually follow people that I saw talking at conferences or I worked with and I find their content relevant to me. Here’s a couple, in no specific order: Camille Fournier, Lara Hogan, Josh Wills, Vicki Boykis, David Gasca, Julia Grace, Holden Karau, John Allspaw, Charity Majors, Theo Schlossnagle, Jessica Joy Kerr, Sarah Catanzaro, Orange Book.

I also enjoy reading (I read about 50 books each year) and since last year, I always try to leave a mini review on my Goodreads account for every book I read, but here are a couple of books that I found useful:

That's not an exhaustive list!

Ready to read another story?

If you've enjoyed reading the stories and guides on staffeng.com, you might also enjoy Staff Engineer: Leadership beyond the management track, which features many of these guides and stories.