Anyone can hold the helm when the sea is calm. – Publius Syrus

I often write about things I’ve learned, but this blog post is about how I’ve felt. Specifically, it’s about how I was feeling last fall as I was ramping up at my new job.

I’ll start this post by saying that if you’re one of the thousands of employees impacted by tech industry layoffs over the last year - I’m so sorry. I know how much it sucks. I was laid off last May, and I know how hard it is. If you’re still processing, I wrote about that too; I hope it can be something that helps you.

As I’m wrapping up the fourth week at my new job, I figured this was a good time to reflect on how I approach onboarding to a new role, team, and company!

Previously on Tales From a Journey Around Metrics

Mojtaba brings us another great guest post about using real estate investment as an analogy for thinking about product engineering metrics!

When deciding to come up with metrics to measure, it is helpful to distinguish between activities and outcomes and their associated metrics. One leads into another and one is best assessed in the context of another.

In a previous post, Mojtaba introduced us to the 5 categories of engineering metrics. These are appropriate for engineering teams. When combined with product and design, and looking at the organization and business as a whole, it’s important to distinguish between various levels of metrics.

The One Where Crude Team Workload Metrics Led to Fruitful Conversations

The One Where Team Workload Helped an Under-Served Team Advocate for Itself

Out of the 5 category of engineering metrics, the most used are often Service Level metrics, Team Performance metrics, and Customer metrics. The least used are often Team Workload and Team Happiness/Engagement metrics.

The One Where We Used Metrics to Increase Autonomy of Development Teams

We don’t really talk about layoffs. When you hear someone say they got laid off, it’s likely the next thing you hear from them is about the new job they’re starting. But we don’t talk about what it’s like in between those two events - which means we’re not acknowledging how traumatic it is to be laid off.

Last week, Mojtaba taught us about the 5 categories of engineering metrics. In this post, he dives deeper into one of these categories: Service Level Metrics.

As an IC and as a manager, I’ve always advocated for proactive, transparent communication from leadership. I recently heard someone say “companies always think they’re being transparent”, and it made me stop to think about what that really meant and how it affected the way that I’ve typically thought about transparency.

I’m currently in search of a new role - please read through and get in touch if you think I would be a good fit for your organization!

Previously on Tales From a Journey Around Metrics

As Mojtaba Hosseini helps guide Zapier toward being a more data- and metrics-driven engineering organization, and as teams continue to add and use metrics, he finds that they sometimes come across this question: What other metrics should I be looking out for and using?

The One Where We Discover That Bad Metrics Can Lead to Good Questions

The One Where We Realize There is a Step 0 Before the First Step

Previously on Tales From a Metrics Journey…

The One Where Executives React to Their First Metrics Dashboard

Earlier this year I had a fantastic guest post from Mojtaba Hosseini, a Director of Engineering at Zapier, talking about the 12 pitfalls of engineering metrics. As Mojtaba is guiding his current company through their journey of becoming a more metric-driven engineering organization, he’s reflecting back on his previous experiences around metrics in the hope that those lessons learned can help inform the journey at Zapier (and hopefully help you, too 😄)! So grab your favorite snack and settle in for the first flashback episode in Mojtaba’s metrics series 🍿

👋🏼 Hello!

Over the last year, I’ve been iterating my interview process as a QE manager at The Zebra. This has been my first time hiring consistently as a manager, so it’s the first time I’m really reflecting on my practices as a hiring manager and evaluating my process. I’ve written about a few things in their own blog posts where I offer more detail, but I also wanted to share a summary of the various changes I’ve made, as well as the intended mpact behind those changes.

I woke up this morning with an odd train of thought running through my brain - skincare as a metaphor for being a new manager. It was too interesting to put off for later so I did a tweet thread while I was getting ready (yes, in between skincare steps!), but I wanted to expand some thoughts and write it up in a more shareable format.

🌈 Welcome to Reading Roundup 5!

Staying organized as an IC was pretty easy - for the most part, the things I needed to track and accomplish were on my team’s Jira board. As a manager, it’s a little more complicated. My work is sometimes more abstract, there’s more of it and more kinds of it, and I don’t have a built-in place to track it. Here are some of the tools and methods I use to stay organized and accountable for the work I do!

Interviewing can be super stressful, even under the best of circumstances or the best intentions. I really want my hiring practices to be as collaborative as possible, and trying to reduce the stress of interviewing is part of that. A few weeks ago I wrote about updating our technical assessment with the promise of an upcoming Part 2 about the changes I made to panel interviews - Reader, this is that Part 2 I know you’ve been waiting for!

[Today’s article is a guest post from Mojtaba Hosseini, a Director of Engineering at Zapier!] The reasons and motivations for having metrics in engineering are well-known and well-documented, but it may suffice to refer to this quote: “What gets measured, gets managed.” However - the full quote is “What gets measured gets managed — even when it’s pointless to measure and manage it, and even if it harms the purpose of the organisation to do so”, something this post will also touch on later. The purpose of this is to share some lessons learned and pitfalls along the “metric journey” for an engineering organization.

As I was thinking back over this year, I really debated with myself whether to write this. I don’t have a pithy saying to wrap up what this year has been like. There’s no overarching theme or lessons learned that I’m grateful for. It has mostly been a very, very tough year for me. I ended last year’s review post wishing everyone a 2021 filled with warmth and light and optimism and love, and I don’t really feel like that happened for me. I’m generally an optimist, but it was really hard to find that part of myself this year.

Hiring is a constant part of any manager’s job, but I think it can be one of the hardest parts to do well. Thinking about hiring practices usually isn’t a priority until you’re actively hiring. And by the time you’re actively hiring, you’re more likely to use the system in place rather than think about whether that system could be improved.

✍🏼 Welcome to the fourth installation of my Reading Roundup series! I’ve got a couple of blog posts simmering on curiosity and hiring process, but in the meantime here are some of the articles and events that have caught my eye recently!

I’ve had some form of regular goal-setting at most of my jobs, and it’s always been a pretty lackluster process. The purpose of setting a goal was unclear, I wasn’t sure what a “good goal” was or how to figure that out, and sometimes I was required to make it relevant to the company’s goals which didn’t always connect to what I wanted.

Technology is inherently a people-oriented industry, and doing our jobs well requires constant communication. We communicate all the time in big and little ways, and these collaborative conversations help us to be more successful in our work.

Welcome to another reading roundup! I have to say, I’m really enjoying these. It’s great to get a writing “win” in spite of having some writer’s block / never-ending pandemic fatigue on my longer articles, and I like getting to share and support other people’s work! Wins all around 🥰

🌈 Welcome to the second reading roundup!

While avoiding my other in-progress blog post, I decided that it would be fun to do a “reading roundup” of various articles, panels, conference talks etc that I think are interesting or useful (it’ll also be good for keeping me accountable to my ever-growing reading list)! These roundups will mostly be tech-related, but I reserve the right to throw in some curveballs every now and then 😄

If you look up the word technical, you’ll see it defined as “relating to a particular subject, art, or craft, or its techniques.” Nothing about that description indicates that understanding programming is a technical skill and understanding people is not - yet somehow the idea of technical skills has come to mean just that, with the inverse being soft skills. This distinction between so-called technical skills and soft skills sets up an unbalanced system where people with technical skills are assumed to be valued in a way that non-technical people aren’t, and does a real disservice to the importance of soft skills.

As my old Grandpappy used to say, experience is what you get when you didn’t get what you wanted. And whew, 2020 has certainly been a year of experience, hasn’t it? There have been good moments, but I can’t quite bring myself to say that it’s been a good year.

Someone asked me today who my mentors have been, and it was an unexpected opportunity to reflect on who’s helped shape my career. Thinking back, I knew immediately that it wasn’t mentorship in a specific technology or career path that made a difference, but more generally in a way of working.

The Call

On September 3rd, I got a DM from the VP of Engineering asking me to hop on a quick call with him and the VP of People Operations (Instrument’s version of HR).

I’m currently in search of a new role - please read through and get in touch if you think I would be a good fit for your organization!

For the past six months, I’ve been leading a new initiative at Instrument: creating an internal Quality Engineering discipline within our larger Technology discipline.

I’m seeing a lot of non-Black folks seeking ways to support their Black friends and coworkers, to advocate against racism and police brutality and the systems of oppression that are becoming harder for people with inherent privilege to ignore.

Welcome to the fifth and final post in my New Managers series! I’ve talked about creating a supportive culture, tips for self-care, and what your responsibilities might look like as a new manager. For this last post, I want to talk about how to manage people effectively so that you and they can succeed!

That’s it. That’s the post. (Well, almost.)

Congratulations, you’re a manager 🎉 First step off the IC path, first rung of the leadership ladder - exciting career changes!

Hello there 👋🏼 This is the third article in my “Advice for New Managers” series! If this is your first stop, you may want to check out the original post that I wrote after getting a ton of awesome feedback on Twitter, and you can read the second article on creating culture as a new manager here.

Last week, I wrote about the new manager advice I received on Twitter. A lot of the responses fell into a handful of themes, one of which was Culture. By culture, I mean the culture that I cultivate for my people as their manager. What sort of environment do I want to offer them? What kind of culture am I building? What are my values, and how do I communicate them?

I’ve recently started in my first role as a manager! I recognize that this isn’t just a promotion from being an individual contributor (IC) - it’s a separate career path, and it requires a different way of working. As a new manager, I want to learn from the experiences and expertise of other managers! So last week, I asked a question on Twitter: Tech managers, what is something you wish you’d done differently in your early manager roles?

I’m super excited for my 🌟 2020 conference lineup 🌟 I’ll be giving my Beginner’s Guide to Test Automation talk at three different conferences, and they’re all new conferences for me! It’ll be a different experience giving the same talk at each conference - unlike 2019, when I gave 3 different talks at 4 different conferences, with 2 of them being brand new talks 😅

Through a series of conversations and interactions dealing with white supremacy and advocacy on Twitter, I’ve learned some lessons on what it means to begin being a useful advocate. I wrote a short thread on some of those lessons, but I wanted to write them down in a more permanent spot and to expand on some of them in a more meaningful way. This is mostly a way for me to continue to reflect on those conversation, but I also hope that it helps other white people be better advocates for marginalized people.

If you’re new to automated testing, you’re probably starting off with a lot of questions: How do I know which tests to automate? Why is automated testing useful for me and my team? How do I choose a tool or framework? The options for automated testing are wide open, and you may feel overwhelmed.

I’ve written about the many hats that testers wear, and the importance of collaboration between testers and engineers. My thinking in those articles focused mainly on the work that testers put into their teams, but lately I’ve been considering the other side - the effort that teams and companies put into their QA engineers and testers.

I don’t typically do a end-of-year post. In fact, I think this is my first one. I wasn’t going to write this one, either - mostly because I felt like I hadn’t really accomplished anything. But as I thought back about my 2018, I realized that I actually had accomplished quite a few things that I’m proud of. One of my goals for 2019 is to be more intentional - that is, to do more explicit planning for my path forward, and I know there are things in 2018 that I can use to inform and inspire my approaches and goals for 2019. So my first step toward that is writing this post, thinking about what I did or didn’t do, and how I can use my experiences from the past year to succeed in the new year.

I really enjoy writing about the conferences I attend - I think it’s a great way for me to reflect on what I learned, and remember which cultural or technical ideas I want to try out. I also hope that it helps someone who is on the fence about whether to attend a conference - being able to read about the content and impact can help them decide (or convince their company to pay for it)!

Earlier this week, Ash Coleman asked a question on Twitter: “Today I walked a team through several analogies to describe testing, like ‘gatekeeper’ or ‘goalie’… Curious, which analogies do you use to describe testing and testers?”

Quality assurance is often assumed to be a narrow slice of work — something that happens in between writing code and getting it deployed to production.

The relationship between developers and QA engineers is often a work-in-progress. There are some long-lasting stereotypes on both sides that can contribute to tensions – “Developers just throw the work over a wall” or “QA engineers block the work from getting deployed”. At its core, this way of thinking is a trust issue – neither one of them is trusting that the other has good intentions in how they work and collaborate.

Depending on where you work, the quality assurance engineer job title can cover a wide variety of roles and responsibilities. Are you ready to take them all on?

I saw this illustration make its way across Twitter recently, and it immediately resonated with me. This illustration perfectly captures how I feel and how I work, and what I strive for in my roles. It’s what I want every company, every manager that I work for to understand about me.

Recently, I helped spearhead our department’s adoption of centralized static code analysis. I worked with one of our mobile engineers to research various tools and create a decision matrix for comparing options. I’ve introduced new tools to my team before, but this was my first time selecting a tool that would be rolled out and used by my entire engineering department. It was also our department’s first time trying centralized static code analysis. Now that I’ve had the experience of researching and selecting tools that other people will use, I thought it would be interesting to lay out why we chose to implement centralized static code analysis, how we chose a tool for it, and maybe most important of all - how we introduced these changes to our department.

Note: This is the second post in a series about the different roles I end up carrying out as a Quality Assurance Engineer. You can check out the first post here, where I talk about wearing my Tester hat!

Quality Assurance Engineer is a broad term that can cover a wide variety of roles and responsibilities. It can refer to a more specialized role, like Automation Engineer or Technical Support. It might be used to describe someone responsible for DevOps practices, or the person in charge of Scrum Master duties and feature testing.

I was on a tech panel last night for a Women Who Code event (which was awesome!), and there were some really great questions from the audience about testing and quality assurance. One question stood out to me, because answering it caused me to reflect about my role at a team level.

Last year, our VP of Engineering came to me with a request. One of our long-term clients was having continued issues with the functionality of a website feature, and Tony needed me to do some investigating to figure out why the failures were happening, as well as make recommendations for fixing it.

I’ve written previously about my setup for BackstopJS (which I’m still excited to say is the creator-recommended tutorial for V2 of the package!). Since that article, I’ve switched from JSON to Javascript configuration, and added a Makefile as the main method of running visual regression tests with BackstopJS.

My team’s most recent project has been really interesting - it’s a JavaScript project that includes using the Serverless Framework to deploy a variety of AWS Lambda Functions (e.g. uploading to S3 buckets and making requests to the API that we built). Part of my responsibility as QA Engineer was to set up a CloudWatch dashboard in AWS. Dashboards can be created manually in the CloudWatch service, but I wanted to create the dashboards through code deploys.

Last week, I attended my first DevOpsDays PDX! I wasn’t quite sure what to expect, but it seemed like a cool conference - DevOps obviously intersects with QA work, and my interest has been peaked by articles I’ve read from the likes of New Relic, Julia Evans, and Etsy. It ended up being an awesome experience, full of interesting talks and conversations, and I came away from it feeling reinvigorated about how I do my job as a QA Engineer.

I just attended Monitorama 2017 in Portland, and I wanted to talk about my experience! I think it’s useful for me as a brain-dump and reflection about what I took away from the talks, but it’s also nice for other people to have some more insight into what the conference is about.

At Metal Toad, where self-organizing and self-managing teams are encouraged (and even preferred), there is a lot of room and trust for individuals to make change. Because of this empowerment, I’ve had the privilege to try out and implement changes. Not all of my attempts have been successful, and some have benefitted from iteration, but it’s pretty cool to know that the opportunity to affect change is something that’s offered and supported here.

Everyone agrees that developers’ work should go through QA in order to ensure a high quality of that work, but how many companies have a dedicated QA engineer to drive that vision forward? It’s kind of like the attitude around test-driven development - it’s definitely a great idea, and people get behind the theory, but it’s often overlooked or an afterthought in practice.

We are Toads

I first came across BackstopJS when I started as a QA Engineer in March. My team had a Drupal 7 project that was suffering from pretty regular visual regressions when we deployed. The visual regressions on the project were consistent only in their frustration - sometimes a deploy to the dev environment would be fine, but staging and prod would have regressions; or dev would have regressions, but then staging wouldn’t. At the time, the site had about 60 individual pages and several integrations, and it was pretty tedious to check for regressions manually.

One of Metal Toad’s continuing goals for developers centers around mastery. There are some high-level ideas and objectives around this, but part of reaching mastery has to do with enhancing and maintaining the code quality of our projects. We’ve put some workflows in place for our projects, including changing the way we deploy and QA. Teams at Metal Toad function fairly autonomously, with the ability to create the tools and processes that work best for them; so I’ll be speaking for my team, as the QA Engineer for Team Mutant Ninja Toaders (TMNT).

A few weeks ago, I joined some of my Toads at the first TechTown Change Agents, an event put on by Portland Development Commission to talk about how we can bring diversity, inclusion, and equity to our workplaces. One of the most interesting conversations revolved around the topic of culture. What makes up a company’s culture? How can a company show their culture? What culture indicators are already in place, and do they accurately represent the culture we have and/or want?

I stumbled onto an interesting Twitter conversation the other day, and I’ve been looking forward to continuing my thoughts in a broader form here on my blog.

I just finished my first week as a toad!

Developer bootcamps are popping up all over the U.S., and Portland is no exception. We have no less than five code schools, including one focused on online courses. With so many options and opportunities, how do you know what’s right for you? And when it comes to committing your time and money, how do you make sure that you take a viable path?

As I write this, I’m entering into the second week of capstone projects at Portland Code School. The lectures are done, although the learning continues, as we use our knowledge of full-stack JavaScript to build our own web apps!

I’m halfway through my developer bootcamp, filling my brain with JavaScript and preparing to transition my skills out of the classroom and into a job. Along the way, I’ve been collecting resources: documentation libraries for Orchestrate and jQuery, tutorials like Mozilla Developer’s Network and Treehouse, and oodles of bookmarked pages for projects and tips. There are an enormous number of resources out there, and they cover every aspect of development that I could want.

When I look at each day of learning JavaScript, it can be really hard to recognize how much I’ve learned since this course started. But then I realize that just five short weeks ago, this interaction on Twitter would never have happened.

Hello, interwebs! I’m Angela - it’s nice to meet you!