The situation

In 2015, I was on a large team working to skin the pages of a Drupal content management system (CMS). I'd tested a Django CMS before, but Django is built on Python. Drupal runs on PHP. Every error page I triggered was an exciting new adventure of digging into what the problem might be, and which of the ~15 developers I should bring the problem to. All but one of them hadn't worked with Drupal before either.

Half of the team worked out of the office in Brooklyn, New York. The other half of the team worked out of the office in Bogotá, Colombia. Our main coordination meeting with the whole team was the standup meeting in the morning. Each group piled into a conference room. Most of us would get a chance to yell towards the microphone across the long table, strain to hear our colleagues in the other hemisphere doing the same. The unlucky ones only got to do the latter, until another project kicked us out of the meeting room.

Imagine how well we communicated and trusted each other in such an environment.

The perspectives

Imagine now, you're a developer on the team in Colombia. Elizabeth in New York has found a problem, and she thinks it's a bug. She found it testing your story, but you don't know enough about the system to know if it's even your problem. There are 14 other developers on the team, and any one of them could have caused it.

Imagine now, you're my boss, in charge of testers on several different projects around the company. You're trying to look at Jira to get some insight into my work. You do a search for "Bugs created by Elizabeth in the past two weeks."¹ You are surprised to discover that Elizabeth seemingly hasn't found any bugs in the past two weeks.

The conversation, and my perspective

My boss came to talk to me. They asked why I hadn't found any bugs. Surely with a project as late and over-budget as ours, it must be ripe with bugs?

I had found bugs. But I didn't mark them as type Bug in Jira. I filed them as feature requests.

I'd noticed that any Bug I filed came with hours of back-and-forth about whether it was a bug, whose problem it was, and a fight about whether the application behavior should change at all. Any Feature Request I filed was eagerly picked up and built in the time a Bug fight would have taken.

The issues themselves were phrased nearly identically:

• Bug report I didn't file: When I go to the detail page from the list view, I get a 500 error. Instead, I should get the details that correspond to the title I saw in the list view.
• Feature request I did file: When I go to the detail page from the list view, I should get the details that correspond to the title I saw in the list view.

Same idea. Same code change. Different issues type in Jira. Why?

Feature requests had story points. A developer who implemented a feature request had created something we needed where it wasn't before. At the end of the sprint, the number of points delivered by each developer could be tabulated in Jira. (I don't believe this was tied to compensation, but measureable outputs in Jira -- as evidenced by my boss's inquiry -- did seem to be a social currency at the company.)

Bugs did not have story points. A developer fixing a bug would have completed fewer story points at the end of the sprint. They would also have to scream into a conference room microphone at standup the next day about how they couldn't pick up any new story because they were fixing a bug of their own making.

My boss reacted to my explanation by simply switching their Jira filter from "Bugs created by Elizabeth in the past two weeks" to "Feature requests created by Elizabeth in the past two weeks."

Lessons learned

With the power of hindsight, there's a lot more I could have dug into about a culture that uses numbers from Jira as currency. Regardless, I do think this experience made me a better, more collaborative tester focused not on getting the credit/being right/finding the most bugs, but on getting the application fixed.

I like to think back on my time at this company as my fastest learning experience. But when I was in the thick of it, all I knew I had learned from this experience is:

• Jira does not tell the whole story.
• Approaching a situation with curiosity or excitement will get you a better outcome than approaching it as a fight.
• Getting the bug fixed is more important than labelling it as a bug.
• Keeping the lines of communication open to be able to deliver a message might be more important than any particular message.

Other lessons reinforced these ideas for me. I learned from Black Box Software Testing that (paraphrasing) an effective tester is someone who gets bugs fixed. Liz Keogh's Agile Testing Days keynote in 2018 on how to tell people they failed (and make them feel great) argued in favor of positive reinforcement. In digging that link up, I found this old post of mine included a bit on keeping lines of communication open.

What political games have you played in order to get things done? When have you sacrificed credit or acknowledgement for progress? What's a worse metric to track in Jira to pit developers against each other than story points?

The way to get things done is not to mind who gets the credit of doing them.
~ Some dude

Bug, or feature request?
Photo by Timothy Dykes on Unsplash

I'd responded to an email to the whole company. "Let me know if you're interesting in contributing in any way" it said. I was interested.

The context

There was a mentorship program was part of the Girls Can Code Africa project. It connected mentees to mentors, and it was being sponsored by our corporate overlords.

A few weeks after my initial email, I received an Outlook invitation for an hour-long meeting. I showed up.

The meeting

After an introduction nearly as brief as the one above, a variety of unintroduced fellow meeting attendees started listing features for the application they wanted to build. A tech stack and architecture was declared. Goals were assumed. Scope exploded as everyone coalesced towards a solution they'd seen work in other situations before: filling a backlog with user stories to capture requirements.

But nobody was capturing these verbal requirements. I took a handful of notes in my notebook before I realized that everyone was going to need them. I switched to a Dropbox Paper document and shared my screen¹.

For the features people described, I would have estimated a full-time team of three people could get it all done in 6-8 weeks.

This is when I switched from patiently listening to asking questions to clarify my understanding:

• Do we have any time constraints or a particular deadline?
• Are we tied to a particular architecture?

I wasn't expecting either of the answers I received.

We did have notable time constraints that would completely shape the way the project: we needed to have something to show the corporate overlords and another, higher-profile stakeholder at a meeting in less than two weeks. We didn't have a team to work on this. Most others joined this meeting just as I had. They were kind, curious volunteers with nothing in common.

We were tied to the architecture. But in asking about it, I found out why: my company wanted to showcase how quickly they could build a product with their own platform. We wanted to impress the stakeholders more than the mentors or the mentees with this one. I could build a Microsoft Form that covered 80-90% of what we'd scoped down, but that wouldn't meet this goal for the final product².

That's when I had to bring our heads out of the clouds.

• There is no way we can build all these features with the given amount of time and people power. What are the most important things to build first?

I acknowledged in a straightforward way that the scope needed to be cut, and redirected the conversation to what was still unclear. As a group, we spent some time weighing the pros and cons of delivering features in a particular order. It helped everyone become more comfortable with the idea that we could deliver what we promised sooner, but we would promise less than...well, everything.

Spontaneous ensemble

We were about 40 minutes into the meeting when everybody was ready to part ways, have one person write a set of user stories to populate the backlog, and then gather together again in a day or two to review and refine the backlog before continuing with any other work.

To me, that seemed like a big gap in time if we only had 10 days to deliver. People were about to start saying their goodbyes and waving at each other over the video call when I interrupted with one last question, by far my favorite:

• Could we start building this together right now? What if we spent the next 20 minutes getting as far as we can in setting up this app?

That turned this meeting around. We immediately went from having questions we could only guess the answers to ("How much time do you really have to work on it this week? How many of these features can we deliver in 10 days?") to gaining more information about the answers.

We spun up a blank application. We started setting up the domain model. People who had expertise on a topic chimed in when we were going in an untenable direction. We didn't have a working app in 20 minutes, but we set the stage for groups of people to have a common understanding about what needed to be built. Stakeholders who hadn't seen development work with their own eyes before had a glimpse into the nitty-gritty steps of starting from scratch on a project.

Way of working

I couldn't completely change the way of working of a hodge podge of people I had never met and had no prior relationships with in the course of a 60-minute meeting. We still ended up writing a backlog and assigning user stories. When we gathered at the end of the first week to review what had been done so far, most of the stories were half-done and very few completely finished.

But we had a clear understanding of what had been done, what was left, what was most important, and confidence that we could achieve our top priorities even with our tight deadline. Our constraints gave us clarity and focus, and the ensemble helped us stop talking about the work and start doing it.

Where can you do less talking about the work and more doing of the work? Have you been stuck in a refinement meeting where you wonder if it would be faster to complete the story while you have all the right people gathered together in that (virtual) room? What are you going to do about it next time you see this happening?

An Assertive Tester at work sent me a direct message declaring that the two of us should decide which repository the tests should go into. They'd decided we were "the deciders" here since they saw themselves as the highest-ranking tester in their department, as I am in mine.

For most technologies, it makes sense to host the tests in the same repository as the code. For a variety of very good reasons I'll go into below, the API and browser-level tests for our apps are all hosted in one big, shared repository. Older browser tests were using Selenium, but some teams had started to move towards using Playwright.

The Assertive Tester wanted to decide if new Playwright tests should join the existing tests in the big, shared repository with the other tests, or exist in their own git repositories until the apps themselves could be moved to git. They set a meeting with me for a few days later.

Invite your comrades

I wasn't in the unit where most of these teams using the big, shared repo were. I didn't know their day-to-day struggles, or even if the tests in the repo were still being run.

I reminded the Assertive Tester that I wasn't an expert in everyone's context, and asked them if it would be all right if I invited the people who write tests for other teams. The Assertive Tester agreed, if reluctantly.

Ask them for their context

I posted in the Slack channel we have for the members of the big shared testing repo, inviting them to the gathering in a few days. In the thread beneath the message (mistake here, I should have made the more visible message in the channel include all my questions), I asked them to thread their response to a few questions, whether or not they could join the conversation. The questions were:

1. Is your project hosted in our legacy version-control system or gitlab?
2. What are you using for browser automation now?
3. Is collaboration across teams important for your testing framework?

The day before the gathering, I followed up in the Slack channels of invididual teams to find out about their browser tests.

Give them sufficient context

Then I started a document. Initially, it was to collect the responses to those three questions that were now scattered across a few channels. I collected them in an orderly table. I later added a couple sections at the top to make sure the gathering could be contained within the hour as scheduled. I listed what I knew about the situation for the first few years that the big shared testing repo was used:

1. Tests couldn't be stored in the same place as our apps.
2. Code for login, API tokens, things all our apps would need were maintained by one team.
3. We all worked in the same unit, sat near each other, and collaborated in an ensemble to write browser automation code together.

Gather to discuss

The Assertive Tester kicked off the meeting before handing it to me give a brief history. I gave a summary of the history and questions for our consideration. Then we went around to each participant to confirm the details in the table and find out if there was more to the story. The discussion led us to two more salient points in our history:

4. We required merge requests to be approved by the one maintainer, and later one of four maintainers.
5. We wanted people to learn Python as part of their skill set.

And several more points for our consideration:

6. The Assertive Tester found the .gitlab-ci.yml for the big shared testing repo was too complicated when it contains both Selenium and Playwright. (Finally, I discovered the motivating reason for this discussion!)
7. Teams like being autonomous! The team (not just the tester) should own the test automation code.
8. Do we want to teach/enforce how to write tests in a certain way? Would it help people to onboard and quickly use a more shared testing framework?
9. The big shared testing repo has too many files to navigate easily. It's hard to convince developers to use it.

Only point 6 reflects the earlier point in the discussion I captured before a conclusion was reached: we don't need to optimize for people moving between teams because it happens so rarely.

Looking at the table of who was using what:

• some teams had their app code still in our legacy version-control system
• some of those teams had abandoned the big shared testing repo and had their own gitlab repos for their Playwright tests
• some teams were using frameworks other than Selenium or Playwright for their tests (we added a section to capture those pros and cons)
• some teams weren't testing things in a browser

No two teams of the nine total were in the same situation. With most of the history for one big shared repo no longer applicable, the desire for developer collaboration within teams over tester collaboration across teams, and a relatively easy setup time for authentication, we decided each team should host their own tests. And when possible, put them in the same git repo as the application code.

Write things down

With the exception of point 6, the rest of these points above are captured as facts. I appointed myself note-taker and screen-sharer for this conversation. I wrote down the questions we discussed as they were introduced, and overwrote them with the answers as we decided on them. At the bottom of the document (though I should have put it at the top), I added a Decision section. It's very short: one sentence and three bullet points linking to repositories. The sentence is: Let's not share a repo for all of the tests.

Captured in this way, anyone could glance through this document, understood what we talked about, determine who was involved in the decision-making, and see how we came to the conclusions we did without having to watch the whole Zoom recording of the meeting.

Why am I telling you this? Because I discovered this kind of high-level decision across teams has a name: architecture. I made an architectural decision about the tests in teams around the company! Well, not exactly that, even better: I brought together the forces that made the decision become clear.

At BoosterConf recently, I met Andrew Harmel-Law and saw his talk called "A Commune in the Ivory Tower: A New Approach to Architecture." He is literally writing the book on anarchist decision-making in software. (He came to my open-space session about job titles after I introduced myself as an organizational anarchist. Hurrah for outside-the-box labels!)

You should really watch his whole talk. It was how I discovered I was doing architecture, but in a decentralized, non-blocking, pulling, parallelizable fashion that didn't require a consensus. The document I create to prepare for and capture notes for that meeting serves as an architectural decision record for the big shared testing repo. I consulted the affected parties and offered advice (that teams can happily ignore) without getting in the way of their work.

Andrew also happened upon this process himself as a way of not being the architect-as-bottleneck on projects. As these things go, he also discovered that this had already been discovered by Ruth Malan.

That's the whole story for today. I'm planning on reading more about anarchy and thinking about how it can influence my work, or possibly already does. For now, go forth and become anarchist architects!

I'm one of the organizers of the Friends of Good Software Conference, or as we like to call it: FroGS Conf. We've settled into a routine with our event schedule: two whole-day unconference per year on Saturdays, plus two hour-and-a-half lean coffees on weekday afternoons.

We've got participants who can only come on the weekend, or only come on a weekday, or can only come in a Americas-friendly time zone. We try to accomodate everyone, but not all at the same time. My fellow organizers and I are busy enough that it would be difficult to run events more often.

We've continued to FroGS as an online event because our participants are so global. The most important "technology" we use for the event is open space technology, which means that we organizers create a structure for everyone to hold sessions and share their ideas. You can read more about that at frogsconf.nl.

For our software tools, we've been using Welo, Miro, and Slack for all our events, and just recently replaced Google Forms and Sheets with MailerLite.

Welo

We've been using Welo as our video-conferencing tool. One of the previous organizers discovered the tool, kindly asked the founders if we could try it out, and we've been using the same goofy set of rooms by the river ever since. It lacks some of the finer audio filtering features of Zoom, but makes up for it in the visual representation of the space. You can see who's in which breakout room, so you can find people you want to talk to.

Welo video conferencing software

Miro

Miro is our whiteboarding tool. We've got a bunch of different frames that fall into two categories: locked frames with explanations the organizers have prepared ahead of time, and empty frames for participants to contribute to.

Our locked frames

Our locked frames have explanations about: the code of conduct, the laws of an unconference, how Welo and Miro work, why the rooms are named the way they are, which rooms are rooms for regular sessions vs. hallway/breakout essions.

Our empty frames

Introduce yourself

We've got a frame for participants to introduce themselves. Forget someone's name or need their LinkedIn? There'll be a little card with their name, face, and contact info to help you out. We'd tried networking or get-to-know-you type activities to start the event in the past, but 10am is not the ideal time for that. We let the Miro board speak for us while we're still drinking our coffee or tea.

Marketplace Topic Queue

We've got a marketplace topic queue that we use at the start of the morning and the afternoon. This is where participants (and organizers!) write down their session proposal, with a title and a category. During the marketplace, they get to briefly pitch their session to entice others to join them. Once they've done that, they drag their stickie onto the...

Session frames

Our session frames double as a schedule for the day, and a place to take notes within each session. The organizers have set the structure of the day - how long the sessions last, how many there are - but the participants are the lifeblood of the event: bringing topics, running sessions, and taking digital notes on the Miro board.

Other whole-day frames

We've got frames for announcements and kudos, to help participants and organizers call our particular changes or high-fives that need to be distributed before the retro. We use the retro frame at the end of the day, though we encourage people to capture feedback for us throughout the day as it occurs to them. We close the day with a brief reflection, discussion, and hang out until the last of the stragglers need to sign off.

Slack

Our Slack is very quiet. We mostly use it amongst the organizers to coordinate our activities in between events. The chat feature in Welo is perhaps not optimal, so Slack can serve as a slightly less ephemeral/confusing place to type things to each other during the event.

MailerLite

We just added this tool to our toolbelt while preparing for our most recent event. We'd wanted to email past participants to advertise upcoming editions, but struggled with the Gmail limit of sending 50 emails at a time. We didn't want to be marked as spam. We also wanted to give past participants a straightforward way to unsubscribe from being bothered by us ever again, for both quality of life and GDPR reasons. Once our free trial with MailerLite ends, we'll pay a small monthly fee to maintain our email lists we'd previously cobbled together in a variety of Google spreadsheets.

Our lean coffee is a very small version of the big unconference day. We split up into groups small enough to foster a conversation, cut out the whole marketplace aspect, and just vote on items in the topic queue to drive the discussion. The Miro board's a lot simpler, but the rest of the tools are the same.

Thanks to my fellow organizers Huib Schoots, Sanne Visser, and especially Joep Schuurkes since he suggested I overcome my recent writer's block by writing about this topic. Reach out to one of us if you're interested in setting up your own unconference, lean coffee, or other type of structured-yet-unstructured event.

We've got annual performance reviews where I work. That shouldn't be the only time I receive feedback about how I'm doing. But the company budgets are set once a year, and thus the consequential "am I getting a raise or a promotion?" conversation typically happens once a year.

Due to a power vacuum in my department, my boss is also responsible for an R&D department comprised of hundreds of people. He isn't focused on my day-to-day, and certainly doesn't remember what I accomplished a year ago. I barely do.

To prepare for my performance review, I wanted to present him with a clear picture of where I've been focusing my efforts. I have three places where I could see what I'd done, but only two were reviewable at a glance.

My focus board

With my amorphous floating-around-the-department Quality Lead role, I ask myself "what's the best thing to focus on?" a few times a week. I keep a Trello board of possible topics. It helps me remember what I wanted to start, pulls me back to what's important when I've been interrupted, and ensures that I communicate back to whoever's affected when I finish something. It also keeps me honest: it prevents me from having too much in progress work at the same time.

The Trello board has five columns, from left to right:

• Done in {this month}
• In Progress
• This Week {with the dates, including whether I've got any days off that week}
• Next Week
• Backlog

Tasks have a title and a tag (either a team or theme), broken down small enough that I can complete them within a few days. "Organize the conference" would be too big, but "draft Outlook invitation, identify and email all departments" with a conference tag would be small enough.

My goal is to keep the In Progress column down to one. Most times there's one thing in there I'm waiting to hear back on and one thing I can actively work on. At the end of the month, I take the whole Done column and move it to a completely separate Done Trello board. This way I can keep the information around without having to look at it all the time.

It was my Done Trello board I reviewed for my performance review. At a glance, I could see that much of my work focused on a shared testing repository, a side project, and helping out three particular teams.

My calendar

My calendar also gave me an overview of my effort for the year. Leadership book club, 1-on-1 coaching conversations, and knowledge-sharing sessions took small, incremental work every week or two. The work was typically too small to put on my Trello board, but still visible from the meeting titles as I paged through the weekly view of my calendar.

My notebook

Jerry Weinberg's Becoming A Technical Leader got me in the habit of journaling for a few minutes at the end of my workday. I hadn't spent time to summarize, group, or even re-read these journal entries along the way. I could have spent a lot of time reading through all my journal entries, but doing so wouldn't add much to what ended up being the ~7 minutes I had to recap my year to my boss.

In the end, nothing my boss said in my performance review was a surprise to me, which is just as it should be. I was able to remind him about some of the harder-to-see code review and 1-on-1 coaching. My boss was also able to bring to light something I couldn't or didn't see: my holistic way of thinking about our products, our department, and our company had influenced the way other people were thinking. People weren't just staying in their lane, performing their prescribed duties; they were thinking more about what all would be required to solve a problem, and how they could help.

How do you compile a summary of your year at work? Do you collect everything at performance review time, keep a brag document of all your accomplishments as you go along, or go next-level and update your resume every time you've succeeded? How do you capture the things that you invested a lot in that didn't go as anticipated?

I received a large merge request recently, with thousands of lines of code changed and a handful of bullet points explaining some of how the test automation framework had changed. "It's already been reviewed from a technical perspective," the author of the code said. "I'd like you to review it from a test automation perspective."

I'd spent a few hours dipping into the code and deciding how to approach this review. This "test automation perspective" charter came from the conversation I decided to start with the author, before leaving any written comments on the merge request. I was looking to focus my efforts in a fruitful, productive direction, where my suggestions would likely be heeded. But what were the test automation principles I should be evaluating against? What did I expect from the setup of a test automation framework? Which criteria was I using to evaluate this merge request in front of me?

The Automation in Testing TRIMS heuristic came first to my mind:

• Targeted
• Reliable
• Informative
• Maintainable
• Speedy

But there were other things I was noticing in reading the tests that made me question and identify my assumptions. I realized I needed to write down my assumptions. I wanted to come to a common understanding with the other testers in my department, rather than making decisions case-by-case, line-by-line with this author.

And thus, the Test Automation Guidelines for my department were born. Or rather, compiled from years of working on test automation code and hearing greater automators than I am write and speak about the topic.

Test Automation Guidelines

Entire repository

• Test automation code must be version-controlled and linted.
• Each function or method should do one thing and one thing only. Group functions and methods that do similar things together. “Separation of concerns” is usually how this is described.
• Code comments shouldn't duplicate information the code can provide. They should describe why the code is the way it is, and be used sparingly.
• The README should contain information on setting people up who are new to the repository to run the tests, and information about code style and contribution guidelines.

Individual automated tests

To automate a test or not to automate a test

• Tests should be automated to the extent that the effort in writing and maintaining them is less (or less frustrating) than testing the same thing through exploration.
• Automated tests contain an assert or verify. Assertions are better when they are checking something unique (an id, a name, etc.).
• If you're using automation to expedite exploratory testing and not decide something on its own, make that clear.
• Each test should test one thing and one thing only.

Readability and ownership

• Tests should be readable. The best way to make sure you are not the only person who can read them is to pair to write them. The next best way is through code review. Smaller branches are easier to review and merge than bigger ones.
• Automated tests are owned by the whole team.
• Automated test output should be readable. You should be able to tell from the output what the test was trying to do, and how far it got.

Determinism

• Don’t trust an automated test you haven’t seen fail. If you can’t change something about the test to make it fail, maybe it’s not testing what you think it’s testing.
• Automated tests should provide information we care about. A big pile of green tests only helps us if they’re testing something relevant.
• A failing (or even worse, sometimes failing) automated test should be a problem. Invest the time to make it deterministic, or delete it. Run the tests and publish the results so failing tests matter.

Resources

1. João Proença’s talk: “Should we just... delete it?!”
2. Joep Schuurkes’s blog post: Test automation - five questions leading to five heuristics
3. Joep Schuurkes’s blog post: How this tester writes code

Another department at my company had collected the TRIMS heuristic and a few other pointers (automated at the lowest level, use static analysis tools, etc.) that I linked my colleagues to rather than rewriting. Outfitted with my guidelines and theirs, I was able to go from a conversation-as-code-review deeper into the line-by-line-is-this-what-we-want-here code review.

I encouraged the author to identify and write down their own approach to the code after our conversation. They had strong opinions about what should go in a page object, when it made sense to break a test into more than one, and how the output should read when a test failed. By writing those preferences down, I could evaluate whether they were being applied consistently. Everybody needs an editor.

Do you have guidelines you refer to when reviewing test automation code? Beyond the links I provided above, is there some other reference you'd point me to? When do you find yourself bending or questioning the guidelines you thought you held dear?

I'm going through some old conference notes again, with the aim to eventually get rid of them all. Today's edition comes to you from the Belgian Exploratory Workshop on Testing in December of 2018. Being invited to one of the most charming cities in the world to talk shop with experts from around Europe was...pretty much my dream scenario when I'd moved to this continent a few months earlier in 2018.

Coaching mindset and role definition are common themes throughout the presentations. They're also top-of-mind for me now, during performance review season, and as I shift from filling in for testers missing around the department back to thinking more holistically about our teams and products again.

Vera Baum

Vera spoke about the learning process, specifically helping coach testers on their learning journey. Learning should not be an incentive or a punishment. The advantage of not being a manager is that people were able to set learning goals without fearing they're not focusing enough on their day-to-day work. Learning goals were set more clearly for people earlier in their career, they need more of a scaffold.

Aleksandra Korencka

Aleksandra spoke about how to be a leader without a leadership title. Even making a checklist of simple things to think about for every release helped her colleagues in the their regression testing. For Aleksandra:

• seniority = freedom + responsibility + impact
• experience = (people x technical) intuition

She went through the process of creating a testing manifesto; an inspirational vision for her team. The process of creating the manifesto proved to be more valuable than the written document itself.

Shanteel (I apologize for not writing down your last name)

Shanteel was in a spot where their developers were undervaluing testing, because everyone sees other people's jobs as easier than their own. To shift their mindset, the group discussion pointed them towards building relationships with a few allies who can help cause a revolt when the time is right.

Marcel Gehlen

Marcel found that he had more influence over testing as a manager than he did as a tester. The people in his department could test what they thought a customer needed instead of just the software. Testers did stuff that "shouldn't be done"; they "cheated". Plus they got more visibility when they had an advocate higher up in the org chart.

I also gave an experience report. It was about a certain project manager from a previous company who was so distracting and forgetful that we had to work around him. I scheduled shadow meetings that we hid from the project manager so the my developers and I could make real progress. The project manager's name became the go-to insult for the rest of the conference. :)

Shoutout to Beren Van Daele for organizing BREWT in the coziest conference location. I could have spent the whole week in that library/lounge. I am always accepting good (or even bad!) reasons to go back to Ghent and have some decent stoverij.

Our engineering teams have developers and testers on them. For our other roles, we've got specialists shared across teams: product owners, UX designers, UX researchers, data analysts, technical writers, etc. Specialists usually attend the weekly refinement sessions and sprint reviews, and skip the other sprint ceremonies.

One of our engineering teams is adding a Kafka event-driven architecture to our low-code platform. One of the specialists serving the team was struggling to understand the atomic particle of this architecture: business events. (Here's my favorite concise introduction to the topic.) They kept thinking in terms of a user interface, while the team described a back-end system.

I saw the specialist struggling in meetings as patient subject matter experts used their lingo to explain it all. The specialist still seemed lost. I met with them individually and realized why they were stuck in the UI: they didn't know how APIs worked.

I don't know how APIs work.

All the explanations from our subject matter experts had jumped from "a user does this" to "so an API does that", but this specialist didn't have a good grasp of what an API was. Any explanation that started with "you don't want the API to be tightly-coupled" did not sink in for them. Explaining it more times wasn't getting them there. We needed to start from the beginning.

I say "we", because as Quality Lead for the department, I see my role as making everyone else's work smooth and shiny. I also suspected this specialist wasn't the only one struggling with the topic.

Let's learn together.

I started scheduling optional 45-minute meetings every few weeks. I didn't have the energy to add another weekly or bi-weekly recurring meeting to my slue of calendar invitations. Ad-hoc one-by-one sessions made this endeavor manageable and opt-out-at-any-time-able.

For topics, I saw that there were a few steps I knew we should cover to get everyone up-to-speed on business events (and how they're talked about in the context of our product and company):

1. What is a REST API?
2. What is an OData API?
3. When would you choose REST over OData or vice versa?
4. What is a business event?
5. When would you choose business events over/combine them with REST or OData?

I kept all the details in the same Dropbox Paper document:

• the ultimate goal (to understand when to use business events)
• upcoming potential topics (starting with the list above, which grew as bigger questions came up during the sessions)
• the date and specific topic for the next session (we'd decide at the end of each session what the next most important step was)
• the recording of the Zoom call from the session
• the notes I took during the session

Yes, I took notes in addition to recording the sessions. Every session, I'd share my screen and take notes. My intention was specifically to help others learn, so recording the sessions and taking notes (that they could help clarify and correct in real-time) freed them from the cognitive load of both learning and remembering in the moment.

For the earlier sessions when I was explaining the topic, taking notes helped slow me down enough for the information to sink in for people who were hearing it for the first time. The notes provided an obvious place to collect links with examples of API specs or tools (like Postman and the OpenAPI web editor).

For the later sessions when the subject matter experts were explaining the topic, the notes helped me make sure I'd understood what was said and capture the answers to questions from the audience.

The notes also served another purpose later: it helped people decide if they needed to watch the recording. The extended team I invited to these sessions was seven people, and later two subject matter experts, so not everyone could make a 45-minute meeting fit in their schedule. People who can't take 45 minutes to learn something crucial about their work really don't need to spend 45 minutes watching a video to find out if they care about a topic. Glancing through the notes helped them decide if they wanted to hear the whole conversation.

Impact one year later

In the first few months, some people were learning and some people were listening to information they already had a good grasp of. It took a few months for everyone to be learning. That's when these sessions really started to pay off. Even if I felt like they'd been rambling, obvious, or useless, one of the seven participants would reach out to me to confirm that the session and the notes helped them. That feedback kept me going.

At the retro the Kafka team had looking back at 2022, there was a stickie about this specialist. It said that collaboration between them and the team had improved. I had to agree. They shared a common vocabulary. The specialist understood the concepts the team was dealing with. They could conceptualize beyond the UI to the back-end. The team goes to the specialist for little/quick quick questions in a way they wouldn't have before, because every conversation felt like starting from the beginning. Now, they hit the ground running, together.

I also want to give credit to this specialist: their remarkable improvement reflects the overall time and effort they've put into deepening their knowledge on business events. The sessions I organized were only part of their journey.

Takeaways

I think most of our specialists had enough of an idea about REST APIs when we started these learning sessions a year ago. But nobody knew as much about REST, OData, business events, and how or why to combine them as they do now.

I started with the belief that if one specialist didn't know everything, likely other people were in the same position. I had a growth mindset for my colleagues: given the right environment and the right pace, all of these specialists could absorb this information. I also had a growth mindset for myself: given enough time, I could make a difference. It was worth the investment.

Photo by Suzanne D. Williams on Unsplash

Three of the teams in my unit had new team leads start in October. The team leads split their time between engineering (they have a specialty in either development or testing) and managing (having 1-on-1's with teammates and communicating around the company).

Part of my job as quality lead is helping these teams, and by extension their leaders, be effective. I've had some similar coaching conversations with each of these three new team leads recently. The members of their teams have different skills and personalities, but each leader is facing some of the same challenges. Here's roughly what they're going through, and a couple of options we brainstormed for what to do or not do.

Refinement facilitation

What they notice

They're at a refinement meeting, noticing that two people are talking past each other, and they're also trying to take notes.

What they can do

1. Point out that there is a misunderstanding and lack of listening. Summarize the points of the two people, declare that there is a gap between their ideas, and see if that's enough for them to realize they need to fix it.
2. Ask for help. Explain that note-taker and conversation-facilitator is too many roles for one person to play for a 10-person group, and identify someone to take notes.

Objectives and key results

What they notice

The team lead has been tasked with coming up with goals for the coming quarter and year for their team, but the product goals are fuzzy and they just started at the company a few weeks ago.

What they can do

1. Point out the discrepancy in their understanding of what's going on, and what they're expected to do to their manager. Explain that they don't have enough context to understand what purpose the OKRs should serve, and without a clearer roadmap, they aren't in a position to articulate the goals for the team.
2. Ask for help. Gather information from the team about what previous OKRs looked like, what the team wants to work towards, and how much they care about this topic at all.

Role expectations

What they notice

Someone on their team has been promoted and they've been at the company for many years, but they seem to be doing fewer things (or different things) than the team lead would expect.

What they can do

1. Point out the discrepancy between the work they're seeing and what's expected. Describe the specific tasks they were expecting the team member to perform. Ask if the team lead's expectations align with what the team member understood their work should be. Compare both of these understandings with the written job description for the role.
2. Ask for help. Compare the three (lead's, member's, job description) ideas of what the team member's role could look like, and bring these ideas to the manager. Have them help you sort out which is closest to what makes sense in this context. Practice telling your team member what they need to change by giving the speech to your manager first.

Managing vs. coding

What they notice

They were hired to be a developer and a team lead. Looking at their calendar, they see that 80-90% of their time is coordinating and communicating, leaving only 10-20% for development work.

What they can do

1. Point out the discrepancy between what they expected the role to be and what you're doing to their manager. Find out if there's a specific amount of time they should be setting aside for focused development work, and see how that compares to their schedule.
2. Ask for help. Identify the tasks that they're currently taking on, and figure out which ones can be shared with particularly skilled individuals or anyone on the team. Team leads don't have to host every standup, refinement, retro, etc. They just need to make sure the work happens.

This was probably a repetitive post to read. Being a manager can feel very repetitive, especially while establishing new habits and common contexts. As long as the team members remain the same, working through these particular issues will pay off for months or years to come.

Luckily all of my team leads were already doing the work that's hardest to teach: noticing things. They weren't always sure what the next step was, but being able to recognize that uncertainty and bring it to someone to ask for help is what their job is. They don't need to solve every problem. They need to identify which things are problems, and work collaboratively to come to a solution.

A few weeks ago, something was failing. My colleague didn't know why. They reached out to me. I've copied our Slack conversation mostly verbatim, with a bit a cleanup for typos.

Here's how it began:

developer [11:35 AM] Hi Elizabeth, do you by any chance have experience with pytest exit codes in gitlab ci? {link to pipeline job output} this job on on line (316) runs pytest, and the test fails. I would expect to get an exit code 1, but as seen on line 390 it is 0.

So many good things here already. They've asked about my experience before assuming I don't have any. They've linked to the pipeline job so I can read the error message in context myself. They've also summarized what their expected behavior should be, and what the actual behavior was.

ez [11:37 AM] not really, but i thought those exit codes were a bash thing, not a python thing {link to stack overflow}

I stated up front that I didn't have the answer. This gives my developer a chance to bail immediately, in case they know a more qualified but less available expert. I used safety language ("I thought" vs. stating a fact) to reinforce that I could be wrong, but link to my source so my developer can judge for themselves.

developer [11:39 AM] pytest does describe them here https://docs.pytest.org/en/7.1.x/reference/exit-codes.html

developer [11:40 AM] gitlab indeed by default exits on error, which can be disabled with set +e

The developer has found (and read) an even better reference, the documentation for the pytest library, huzzah! That definitely trumps my Stack Overflow link. Now it's clear which reference to use. They've also brought us one step further along in the troubleshooting process, introducing the +e as a potential exit code helper to overwrite whatever pytest is doing.

ez [11:40 AM] huh, guess you know more than i do!

Recognition! Not exactly praise here, but I admit that they are more informed and on a better track. Celebrating when you're wrong and the developer's right helps build credibility and rapport for the next time when it's the other way around.

Now I want to meet them where they are, and get them one step further.

ez [11:46 AM] can i give you a call? i’m trying to figure out if the code is being logged in the wrong spot, or if gitlab isn’t responding to the code correctly.

developer [11:47 AM] yes sure

Zoom [11:47 AM] Call | Zoom meeting started by elizabeth.zagroba | Ended at 11:55 AM - Lasted 8 minutes | 2 people joined

I've spent a few minutes Duck Duck Go-ing and reading about the issue. I've got more links I've got pulled up in my browser, but rather than continuing to chat links and theories back and forth, I wonder if calling the developer will get this solved by lunchtime at noon.

ez [11:50 AM] https://gitlab.com/gitlab-org/gitlab/-/issues/340390

I don't have the recording of the meeting, but the last message I sent the developer was while we were on the Zoom. I put the link in the Slack chat so it wouldn't be lost to time or browser history after we hung up.

My theory about the exit code was on the right track. The developer assumed that if pytest exited with a 1 or a 0 on line 174, the bash script on line 175 would know that already. It didn't. We had to collect the exit code on line 174.

Only the last little piece, about needing to collect the exit code on the same line the command is executed, was new information. This technical bit was the only thing I learned that day. The rest I knew, and am grateful for:

• Ask people about their experience before diving into an explanation.
• Describe what you've tried already.
• Admit when you don't know something, or describe how deep your knowledge is. (And be kind to people who make themselves vulnerable in this way.)
• Link to the thing so your pair can see what you're talking about for themselves.
• Celebrate the good things.
• When the communication format is getting in the way, try something else.

I would definitely pair with this developer again, on any problem, whether or not I knew the answer. Every day should be so great.