Pros
- Avalara compensation is very generous in the Seattle market. I came from a much larger tech company in the city, and I was pleasantly surprised by how much my salary increased. (However, health benefits were less generous – I had to pay significant out-of-pocket copays for even basic things like prescriptions.) - The company has been performing very well, which is evident in both the stock price and recent earnings. This is because Avalara was founded on an undoubtedly good idea in a niche space (sales tax) that has seen few major competitors attempt to enter. - Avalara’s covid-19 response has been positive, and leadership has signaled that they will allow telecommuting for the foreseeable future. My remote onboarding experience during the pandemic wasn’t always a cinch, but people were accessible to help address questions and concerns as they arose.
Cons
In lieu of listing cons, I am sharing most of the letter that I submitted to the CEO and CHRO when I quit after four months, as my concerns are spelled out in that letter. A few points I’d like to make first: 1. Setting aside my issues with the role and company culture, all prospective employees should simply be aware that sales tax SaaS can be a dry space, a fact that even Avalara acknowledges in its recruitment efforts. Depending on the type of person you are, this may negatively impact your experience, as was the case for me. That said, had the leadership and culture of the company been positive, I would have stayed longer than I did. 2. If you are a prospective employee, I would urge you to look at the Avalara Ratings and Trends data on Glassdoor. While the company tracks a 4.1/5 stars right now, the Overall Trend bar shows that the company was below a 3.2/5 back in March, which is around the time that senior leadership began a campaign for current employees to submit positive reviews in a bald-faced attempt to improve a flagging score. Make of this what you will… 3. I would not normally share a resignation letter publicly, particularly given that I only worked at Avalara for four months. However, I learned that one day after I sent the CEO my letter of resignation, leadership retaliated by firing my manager. The “rationale” offered for this termination was that “the team was moving in a different direction.” I remain outraged at the injustice of the situation, and these events further illustrate that senior leadership operates with impunity and retaliation, lacking any self-awareness that they are contributing to a toxic culture and only they work toward fixing it. On a smaller note, the CEO responded to my email with a thumbs up emoji, which I found to be incredibly unprofessional. Below is the main substance of my resignation letter: Lack of role clarity — I was never clear on what a Program Manager at Avalara owns, nor was I clear on the core responsibilities of this function. While the theory was that Program owns “execution” and Product owns “strategy,” in practice this is a confusing distinction when in fact engineering teams are responsible for the execution of software development. This also means that in practice, Program Managers spend much of their time executing clerical tasks to make up for poor engineering discipline — such as following up on tickets and chasing down updates — and serving as administrators to schedule meetings and share updates to leadership. Effectively, Program Managers are plugging up organizational gaps rather than owning true programmatic deliverables. But despite how little Program Managers own, they are seemingly accountable for much of the end-to-end software development lifecycle, including elements of Product Management (e.g. user testing, go-to-market strategy) and Software Development (e.g. quality assurance, ticket hygiene). I have seen multiple conflicting RACI charts that attempt to clarify the guardrails between the different functional areas, but I do not believe that all managers are on the same page with what a Program Manager is meant to own and do, versus a Product Manager, versus an Engineering Manager, versus a Scrum Master. This is further complicated by cross-functional programs, which borrow engineering resources from multiple scrum teams that each have their own Program and Product owners. Leadership has not set nuanced expectations across different types of programs that clarify what a Program Manager is meant to own and do, which has been a major source of my dissatisfaction with the job. Lack of strategic priorities for the organization — From my vantage point, senior leadership is eager to be in the weeds for all programs and ongoing engineering workstreams, at the expense of articulating a longer-term strategy and driving systemic, process-driven change. As a major example, a biweekly engineering update mechanism was exclusively focused on format and templates during my tenure, with leadership asking each week for a new view of every granular detail across all programs, down to each sprint deliverable. While new dashboards could serve a valuable purpose, leadership could never agree on how they want information visualized and to what level of detail, so the focus remains on retooling the templates week to week. I have never seen the same template used in more than two of these meetings. Instead, I would expect leadership to synthesize information and probe strategically on programs that report Red or Yellow, to unblock dependent workstreams that require leadership escalation and decision-making. Most recently, this in-the-weeds approach culminated in the ask for every Program Manager to send out daily email status updates for every program they own, regardless of whether there are updates, amounting to dozens of granular daily emails that boil the ocean. This is a non-value-add ask that implies that leadership both/either 1) does not trust its employees, and/or 2) does not know what insights or information to gather from its programs. While it is valuable for leaders to operate on multiple levels and get deep into details when appropriate, I have never seen our leaders operate except in the weeds, which is not encouraging to see personally, as someone who wants to make an impact in the organization and learn from senior leaders. There is also an issue of scale — as Avalara continues to grow and its engineering organization expands to support evolving business needs, leadership simply cannot be in the weeds to this degree for every single initiative, and most instead turn to a longer-term strategy. Furthermore, there are many process gaps that individual Program Managers have called out, including clarity around end-to-end integration testing, the nuances between deployments and releases, and change management. But rather than assigning Program Managers to ideate on these organization-wide opportunities and force multiply the impact of a single contributor, leadership instead throws headcount at the problems caused by these gaps on a case-by-case basis within each engineering workstream. In practice, this causes all programs to develop in silos, encouraging Program Managers to develop tunnel vision solely on their immediate programs’ priorities while minimizing the opportunity to up-level the discussion and tackle broader organizational priorities. This speaks to leadership not having a clear understanding of what these priorities are, or at least not understanding the most prudent way to solve for critical pain points. Engineering organizational culture — Finally, I witnessed troubling instances of a toxic culture within the organization that were caused by the behaviors of senior leaders. I routinely received feedback indirectly through intermediaries, rather than from the leaders providing feedback, which suggests a culture of secrecy and backtalking. Direct feedback that is behavior-driven, specific, and actionable is critical for individuals and organizations to grow, and this organization is not comfortable providing direct feedback. I have also observed that our leaders are not receptive to feedback from individual contributors, either — I was once castigated for questioning a particular ask from a leader, in spite of prior lip service paid to being an open and inclusive team that was receptive to ideas from all people. The specific guidance I received was, “When the big boss asks for something, the big boss gets it.” This focus on hierarchy, rather than ideas and solutions, is problematic and not something I look for on a team. However, there have been other moments where a sort of public “feedback” has been offered in broader team meetings, wherein individual Program Managers are publicly berated by leaders for not having a satisfactory answer for a given question. While I cannot comment on whether the feedback is warranted, the approach and tone that I have seen — particularly in such a broad forum — promotes a toxic, non-inclusive culture that discourages people from speaking up or from failing publicly.