John Zittlau - Principal Engineer at Jobber

December, 2020 linkedin

Tell us a little about your current role: where do you work, your title and generally the sort of work do you and your team do.

I’m currently a Principal Engineer at Jobber. Jobber is a SaaS offering that helps small home service businesses stay organized, connected with customers, grow revenue, and better compete against large corporations. We provide an online application along with a mobile application for Android and iOS. The engineering team works within Scrum to constantly innovate on new features as well as maintaining the products. As the Principal Engineer, my role is to help teams with delivery of their work, ensure engineers can constantly grow in their craft and be available to “put out fires” when needed.

What does a “normal” Staff-plus engineer do at your company? Does your role look that way or does it differ?

As the only Principal engineer on the team, I suppose what I do must be considered “normal”. We have considered what it will look like with more Principal engineers and to a large degree we expect that yes, what I currently do will largely be the normal for Principal engineers.

What that means is that we believe a Principal engineer’s primary duty is to ensure the engineering organization is able to deliver work accurately and with high quality (and as efficiently as possible given the other constraints). This usually will look like mentoring and lending a coding hand where needed. Principal engineers are also expected to have a voice in long term strategy and to constantly be looking for ways to accelerate the teams through tools, processes and whatever else presents itself. Finally, Principal engineers collaborate with the development managers to help all developers grow.

Staff engineers at Jobber actually have similar expectations to the above but at a smaller scope. They should primarily be focused on helping the team they are on, but we do expect Staff engineers to also have impact beyond their team in similar ways to a Principal engineer.

How do you spend your time day-to-day?

I’m usually beholden to two teams. The Engineering Leadership Team is my primary team. And then I’m often embedded with a specific development team. This means I usually have twice the Scrum ceremonies per sprint.

Outside the Scrum meetings, I’ll typically have meetings with other development teams (at their request) to discuss challenges they are facing. I also have monthly one-on-ones with the Staff level engineers. I’m expected to mentor all developers, but have a specific focus on the Staff level.

With the rest of the day, I’ll spend some time on any work I’ve committed to with the Leadership team and finally help the team I’m embedded with to complete work on their backlog.

Despite leaving the embedded team’s backlog as the last item, my target is to spend 60% of my time per week with the embedded team. A bit of that goes to Scrum meetings with the embedded team, but the bulk should be spent coding against the team’s backlog.

While not day-to-day, I also currently have a strong hand in hiring new developers. As such, when we are in hiring mode, I’ll be reviewing take-home challenges and conducting technical interviews as needed. But to maintain scalability of our hiring as we grow, I’m actively transitioning this work to our Staff engineers.

Where do you feel most impactful as a Staff-plus engineer? A specific story would be grand.

As a Principal engineer, I have many opportunities for huge impact. Technically, I led an initiative to help our database scale that involved coordinating the work of almost all the development teams. The resulting changes had a significant impact on our scalability. But that isn’t my proudest moment.

I feel my biggest impact was with a team that I was asked to embed with. There was a perceived negative external feeling on the team’s ability to deliver in a timely way. There were also some internal challenges with the belief that some members were not delivering as expected. While on the team, I was able to help them deliver a critical new feature as well as uncover some of the root causes of the challenges they were facing.

What was understood to be an external dissatisfaction with the team turned out to have been magnified far beyond the initial “complaint”. The internal challenges were real but with some mentoring of both the people who had been on the team for a while as well as the new people and helping set expectations on both sides, the team worked through the issues they were facing in a way that allowed everyone to grow a bit.

Had I not embedded with the team and worked shoulder to shoulder with them, I would not have been able to uncover some of the issues. Had I been perceived as having more direct power over the developers (as a manager for example), some conversations would have been less frank. Being a Principal engineer put me in a unique position to maximize how I could help the team.

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?

I believe that by still primarily being a “coder” in the eyes of the developers, but having a voice in the Engineering Leadership Team, I’m in a position to both gain and maintain the trust of the developers while being uniquely positioned to effect change when needed.

I work hard to build this trust by speaking with as many of the developers as possible in informal settings. And then only using what is said in those conversations in agreed upon ways. I’ll not “tattle” to their managers, but if I think it is appropriate, I’ll ask if I can raise the subject to their managers. Happily, the culture at Jobber is such that I rarely actually have to be a middle man. It is more that I’m sponsoring someone’s career wishes and helping them express themselves to their managers.

While my technical achievements and responsibilities have grown with promotions, it is the ability to help others grow that I would not have been able to do prior to becoming a Staff engineer and then moving on to Principal. But if I had moved to a manager role, I believe conversations with other developers would have been different and in some cases limited my abilities to help them.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

Yes I do. While the Architect is primarily tasked with guiding our future technology and architecture, I work closely with the Architect at times to provide my insight.

A recent advocating was related to significant changes we needed to make to our codebase to allow for database scaling. To influence the organization, I had to demonstrate the limitations we currently faced. How and when those limitations would impact Jobber’s ability to grow and the proposed path forward with expected returns.

Since this change required significant engineering effort, it did require significant buy-in from all parts of the organization as other initiatives would be slowed down or halted as we worked on this. I laid out resourcing needs and expected durations to help the organization accommodate this work along with other current initiatives.

The project was approved and completed successfully.

How do you keep in touch with how things really work as you spend less time on hands-on development?

I still do spend a significant amount of my time hands-on. I also have regular one-on-ones with Staff level engineers to get their pulse on the teams. Finally, I try to regularly get together with other developers on an informal basis. Some Staff engineers and the Architect also find it useful to randomly check out PRs to keep track of how code is evolving over time. This obviously does not provide a complete view, but seems to at least provide clues to how things are moving.

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

Yes I do sponsor other developers, but it is generally not a key aspect of my role. The development managers are generally expected to take this on.

While not exactly “sponsoring”, I did take a specific new hire “under my wing”. This person had very limited programming experience when interviewing with us, but I felt they had significant potential. I value passion and potential very highly in new junior hires. I argued hard for hiring them and then committed to spending extra time with them to help fill in the gaps a formal software development education would have provided. They are now a highly valued asset to Jobber.

I will also provide input on an engineer’s growth when the engineering manager is evaluating an engineer on their last year of growth.

Were you hired as a Staff engineer? If not, what was the process of getting promoted to Staff?

I was hired as a Staff engineer at Jobber and was previously a Staff engineer at Intuit. I’ve been a Staff engineer for 5 years and a Principal engineer for 3.

The process to move from Staff engineer to Principal at Jobber basically followed the increasing impact I had on the engineering team and beyond to the rest of Jobber.

The engineering team was still relatively small when I started. As the team grew, my responsibilities grew. It became evident that I was doing more than was typically expected of a Staff engineer. Additionally, we had to make room for others to become Staff engineers while still having a mentor/role model for them to follow.

I actually was simultaneously promoted to Principal engineer and Staff Development Manager. For about a year, I wore two hats. I maintained a strong development role, while at the same time, the senior developers reported to me. This was triggered by our rapid growth and the need to distribute developer reporting across more managers. We eventually hired managers to replace me in that role and I again focused on the Individual Contributor side of the ladder.

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?

The primary factor in my career growth from senior to staff to principal has been passion. I really enjoy what I do and I’m constantly working to grow with side projects on my own time.

A second critical factor has been to find a niche of something important that needs doing that either no one else wants to or is able to. In my move from senior to staff, this niche was performance and load testing. We needed to prove we could handle traffic at scale. I took ownership of this. It was highly visible and important work.

My move from staff to principal was helped by me becoming the DBA of the engineering team when our database was struggling. Again, highly visible and important work.

I’ve worked with developers with formal university education, technical college education, no formal education and post-grad degrees. I’ve found strong developers and weak developers from all those backgrounds. While education will likely give you a strong grounding, I believe passion will take you where you want to go.

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?

I think that is generally true. At Jobber, we expect Staff engineers (and principal) to have impact beyond their team. This is usually via some project.

My Staff Project was performance and loading testing at Intuit Canada. The tax product receives a very high load during the last week of tax season. A lot of money is made during that week. Having confidence that the product would be able to handle that load was critical.

For Principal engineer, it was less of a project. Early on, our database was struggling and I became DBA for a while to resolve the database issues. This did not directly lead to my promotion but was a clear demonstration that I could jump in where needed and help Jobber succeed. I believe that ability to help out where needed was the driving force in my promotion.

Can you remember any piece of advice on reaching Staff that was particularly helpful for you?

This is the start of you being measured not by what you do, but by what your team does.

It is both the biggest reward and hardest challenge as you move up the ladder. While still being regarded for your coding abilities, your ability to make the team better starts to rise in importance.

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

Find a place where you can make a difference.

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

Yes I did. I was an engineering manager for a year. The Individual Contributor path called me back as I realized the parts of the week that I most enjoyed were when I got time to code.

As a Principal engineer, I do collaborate with the engineering managers and am expected to have a part in their career growth, but when I gave up my manager hat it was because it was clear my strongest contributions to Jobber would still be as a developer.

Next chapter: Alex Kessinger - Principal Engineer at Stitch Fix

Previous chapter: Greg Wittel - Principal Software Engineer at Proofpoint

Book

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.