TIL Zeigarnik effect

I attended a knowledge sharing session on behavioral science last week (ok, so technically, it’s not “TIL”… but as of that time, I thought “TIL!”). It was particularly in the context of designing products and services. It touched on concepts—some I’ve come across before, some new. And among the new, what piqued my interest the most was the…

Zeigarnik effect:
not finishing a task creates mental tension, which keeps it at the forefront of our memory

I guess it struck a chord because I was dealing with something that I felt I shouldn’t still be dealing with had someone done their work more promptly (which I later found out, should be corrected to “had someone done their work more correctly”). Anyways, I feel that mental tension — that extra cognitive load — brought about by that that unfinished thing that you have to have to remember.

It also made me think about some agile stuff particularly limiting WIP. In limiting WIP, the team ideally works within their capacity and will prioritize completing work over starting new work so that they aren’t juggling so many open items at a time. There’s also the lead time which is like the difference between when the work is started and when the work is completed. The longer the lead time — say when you start discussing a possible feature to the time that feature actually gets implemented, the longer you have to remember the details around that feature. The longer you have to remember stuff and the more stuff you need to remember—both are mentally taxing especially when the work piles up.

Then there’s also the definition of done. This is something that’s part of the team’s working agreements wherein you align on what has to be completed to consider the story as “Done.” And it gives some sort of comfort in knowing that once a story is done in a Sprint, you sort of have closure, and you can move on to other stories without having to worry about that story coming back to life an haunting you.

Anyways, I haven’t really read up much on the subject. It was just one of the concepts mentioned in the session, and I just find it interesting how some of those agile practices or concepts support combatting that mental tension that is the Zeigarnik effect.

Is this a bug?

This is a fairly common question that pops up in projects. It could happen when requirements are ambiguous, or when the behavior could pass off as meeting the requirements and folks are on the fence about it, or when there’s a change in the requirements or implementation that didn’t get communicated across timely enough, etc. It just happens.

But as someone who has a testing background, there are admittedly times when I don’t like it when testers ask me this question. In general, I think it’s when very little to no analysis goes into the understanding the bug (or possible bug). Especially when there are provided references.

If I were the one testing, I would expect me to exercise due diligence. I have to try to crosscheck against the user story and other provided references. I expect me to understand what I’m supposed to be testing. I’ll need to try to do the RIMGEN / RIMGEA stuff. I won’t just say “I did this and this, this happened, is this a bug?” I will try to answer that question myself. And if it’s still not clear and I need to consult with a team mate, I would phrase my question slightly differently. Probably somewhere along the lines of: “I did this and this, this happened. It might be a bug because <so-and-so>. On the other hand, <reason why it might not be a bug>.”

The more brains you pull into consultation on this possible bug, the more costly it is. It also takes away other people’s time and focus from stuff that they’re actually supposed to be doing when they’re helping you do that analysis.

That analysis is part of the service we provide as testers. That analysis is part of the value we bring in to the team.

If I could, I wouldn’t: Separate back-end and front-end user stories

In my experience with Agile projects, we usually have user stories that somewhat correspond to features. Under the user stories, there’d be the front-end task, the back-end task, the testing task, and so on. There’d occasionally be user stories that’ll only have the front-end part or only have the back-end part, and that’s done as needed by the requirement. But it wasn’t a case wherein you have that particular requirement and you split it off to back-end and front-end stories.

I guess it’s always the team’s call on how they would work. That’s what makes agile agile. But I’ve tried it, i.e., having separate user stories for the back-end and front-end part. And it’s not my favorite for the various reasons I’ll enumerate below. Maybe it’s also just me and how I agree with that Agile principle that “Working software is the primary measure of progress.” Technically, the APIs could work and they’re functioning as expected; and the screen components are front-end validations could also work. But it feels incomplete for me.

Anyways, onto the reasons….

Repetition, Overhead

There are a lot of details that we have to repeat in both stories for the same feature. Why not just link them with each other? Well, we do that but the back-end guys expect that they can just focus on the BE story, same with the front-end guys. So there’s overhead in the repetition and in keeping things consistent.

Dependencies

We have to line up the BE user stories first or a sprint ahead. Then while we’re grooming for the next sprint or a couple of sprints down the line, we have to remember whether the FE story has already been covered by a BE story. Of course, that’s what related links are for. But still, humans are human, linkages could be missed.

In case there’s a bug in the user story, but it wasn’t really in scope, typically in previous projects we’d just create the needed user story for it. We’d then decide if it’s something we can take on within the sprint, or if it’s something we’d have to defer. But in this case, we’d need to line up two user stories — first for the BE and then another one for the FE, and there’s the possibility that we can’t get them in the same sprint.

Maybe it’s just psychological, and maybe it actually is, but it feels like it takes longer to complete a user story (feature).

Bloated Backlog

You nearly have twice as much user stories. So it feels like the backlog is bloated. You see a lot of user stories and it feels like a lot of work, but it’s just for that single feature or requirement. Again, maybe psychological.

Demos during Sprint Review

There’d be demos of the FE story which is already an integration of the back-end along with it, so that’s the actual demo of the feature. But there are also the demos of the BE stories where the interface would be via Postman or via Chrome Dev Tool or via the SQL client. As a tester, you have some appreciation for it; but as someone who empathizes with the client or business, I wonder if they’re as keen on seeing that API response as opposed to seeing the integrated feature.

Coincidentally, a team mate just asked me for certain details of a user story

So while writing this post, a team mate asked me for certain details of a user story. As expected, the related API story was linked to a corresponding FE story. However, she was working on a related feature and so that one wasn’t linked to the original API story. So it had to take some searching to find the answers from her. I ended up answering from memory to give her quick feedback, but of course I had to do due diligence and cross-check with the actual story and then add the linkages. Anyway, I guess this is my cue to get back to work. Although at 1:27 AM, I think I can already call it a day.

“Potentially releasable“

[Edit Oct 22] At the end of the Sprint, I feel a better sense of accomplishment if there’s a feature that’s actually built. Not just the data model, not just the API, not just the front-end that’s blocked because it’s still waiting on the API. This ties up to the 3rd item I mentioned above. But as I was just browsing, I came across this page again: What does it mean to be potentially releasable?

• “The goal for any Scrum or agile team is the same: develop a potentially releasable product increment by the end of each sprint.”
• And of course, it goes on to describe what is meant by potentially releasable — emphasizing “potentially” meaning it doesn’t always have to mean that you release every Sprint.
• It shares and expounds on 3 key characteristics of the product increment to be potentially releasable: High quality, well tested, complete
• “…reaching a potentially releasable state as often as possible is simply a good habit for Scrum teams. Teams that miss reaching this standard often begin to do so more frequently or for prolonged periods.”

Thank goodness for that SQL training

The other day, one of the testers in the team raised a concern to the developers. He shared that he was trying to insert a record and there was an error. Now I’ve known SQL to be informative in case there’s such an insert error; and true enough, the error mentioned the problem with a Foreign Key constraint. I guess the problem was he didn’t know how to interpret that Foreign Key constraint.

This just made me appreciate the SQL training that I got from my first company. In my first two weeks in the job, I remember my SQL training consisted of being asked to read Teach Yourself SQL in 21 Days. Afterwards, part of the exercises was an existing bigass report that was programmatically generated that I had to recreate using one SQL query–down to the data format conversions.

Of course initially I didn’t appreciate the Data Definition Language (DDL) part as much. For testing, my work was more focused on the DQL and DML parts (Data Query Language, Data Manipulation Language). But, of course, as you encounter errors with your insert or update statements, you get to appreciate the DDL part as that lets you know what you did wrong in your statement.

Over (*BLEEP*) years later, I still find SQL and that basic understanding of a relational database such a valuable part of my skill set. And its value to me has definitely extended beyond testing. It helps me figure out what entities and attributes (shown or visible) would be needed to accomplish certain functionalities as I do my PO or BA work. It helps me communicate with devs e.g., when explaining how something should be retrieved or when I need to describe certain classes of objects to them. It helps me spot inefficiencies in some implementation (e.g., when they were retrieving the latest status details from a history table, or like when they concatenate something when they store it into one field then forgot they had to edit it separately).

Come to think of it, aside from being useful, SQL, RDBMS and database design are pretty interesting too. Or maybe that’s just me having learned to love my work. 🙂

---

[Edit] If anyone’s reading this, please share good references on the topics in the comments. Just maybe for reference of anyone else who wants to get started.

Reaching for goals

Heads up, this is a brain dump! But come to think of it, all my other posts are. 🙂

I think there’s often an emphasis on knowing what the goals are, and even the why behind those goals. We see a roadmap, a strategy plan, some high level visualization of what we’d like to accomplish. But the devil is in the details. It’s in the how where things get muddied (all the more so if intent wasn’t clear to begin with), and which makes all the difference whether we actually reach our goals or not.

One of my favorite quotes has always been:

A goal without a plan is just a wish.

What prompted this post is one of the Medium posts that showed up in my feed today. It’s about The four simple habits of exceptional leaders. And Habit 3 is “Becoming process orientated, not goal orientated.” The post comes with a convenient takeaway point:

“Takeaway point: By focusing on improving the way we and our teamwork to achieve our goals, and forming habits of always seeking to improve how we work, we will ensure our goals are continually met and exceeded.”

And I agree. I’m not dismissing the what and the why aren’t important, because they are! It’s just that the how is just as important. And part of the how includes the nitty-gritty stuff like

• working agreements
• communication plans
• team dynamics
• good meeting practices
• plan-do-check-act stuff
• execution details especially who does what, how to check if on track, etc.
• retrospectives
• lessons learned

And generally looking at how you’re working (or not) towards your goals including reevaluating if those goals are still relevant. Half of me feels like these are basic stuff, the other half tells me we don’t know all these by default… we get to realize their importance over the course of many projects and hopefully not too many failures. This is why leadership is so challenging when you want to do it right — it requires experience (not measured in years), knowing to be in the present and at the same time have hindsight and foresight, seeing both the details and the big picture, serving across different levels sometimes with conflicting priorities, the pull of many directions that you somehow need to balance to keep on moving forward.

Cognitive Load

You might have recently come across the term “cognitive load” (or if not, now you have) being thrown around lately. While I haven’t really read about it, I have a sort of guess of what it is but initially in the context of usability. Ages ago, I read this book entitled Don’t Make Me Think and what I got from it is the idea that the design or the implementation of a certain functionality has to be made in such a way that it is as intuitive as possible. When the design is incoherent with its purpose, that makes you think — and unnecessarily so — somewhere along the lines of “why?” or worse “WTH?” and that contributes to why a certain screen is not so usable.

Beyond usability, the idea sort of still applies.

When something feels like it lacks clarity, it’s incoherent, it doesn’t seem to make sense, it doesn’t seem to add up… those things make us think. Instead of being able to focus on moving forward or on the thing that we have to do, a part of our brain is stuck at trying to make sense out of things. So that to me is the sort of “cognitive load” that we need less of. It’s like brain activity that doesn’t get us to where we want to go any faster.

Now I can’t just be throwing around the term without at least trying to learn more about it. Just sharing this quick 20-minute YouTube video (around 12 minutes if you skip the Q&A) that gives a short and easy-to-understand explanation on it in the context of managing information overload.

A quick summary that they provide:

“We constantly need to learn. But there are limits on our ability to learn. Cognitive load theory can help us work within those limits giving us a set of guiding principles. If we manage intrinsic load by breaking large tasks into smaller ones, reduce extraneous (irrelevant) load by eliminating irrelevant tasks and distractions, and increase relevant (germane) load with appropriate repetition and varied learning context, we promote efficient learning, improve productivity and escape the horrors of info overload.”

A simple story of Nobody

This was something I picked up from high school (or maybe even grade school). I think it stuck because I was fascinated with the wordplay and its having a strong message contained in it even though it was so short and simple. The story goes (just that one paragraph that follows):

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was asked to do it. Nobody knew Everybody wouldn’t do it. Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. In the end, Everybody blamed Somebody when Nobody did what Anybody could have done.

I find that you can take it in different contexts — at work, for some chore at home, in society — and it still works. And it’s a sad story when nobody does what somebody or everybody should be doing.

The only thing necessary for the triumph of evil is for good men to do nothing.

Lessons from Leadership is Language on Feedback

That title couldn’t be any more explicit. I spoke with a colleague who shared a challenging situation she’s in. After our talk, I couldn’t help myself from thinking what if I were in that situation and had to be the one to make that difficult conversation. I also took it as an opportunity to revisit what I read about from Leadership is Language by L. David Marquet, and relate aspects or lessons from the book on to the context of giving feedback. Of course, I can’t share the exact examples here, but I tried to give close enough explanations.

---

Give information, Not instructions

• Instead of saying “You should do this or that,” try to provide the information that would reasonably lead to that suggestion (or maybe even better suggestions from them).

Focus on behavior, Not characteristics

People will have better control over their behaviors, than on characteristics they have.

• Instead of saying “You’re an ineffective ______________,” try citing the specific behaviors that led to the idea that they’re an ineffective whatever.
• Same when it’s positive. Instead of saying “You’re a great team member,” say the behaviors that you’d like to be repeated.

On the process, Not the person

While I think asking one’s self “How can I be a better <insert role here>” is good for introspection, asking that to another person might not always be taken positively. I think we are naturally defensive and we can’t expect everyone to be consciously going against that natural tendency. Asking “How can you be a better leader?” might somehow be misinterpreted as “You’re not a good leader, you suck, you really need to improve…”

• Instead of asking that, shift focus on certain processes. Say that person’s responsibility includes owning say the peer review process, then instead of asking “How can you be a better peer reviewer,” ask “How can we improve on the peer review process,” “What do you think can we try to better track the peer review comments,” etc.

Observe, Not judge

I think this ties up with the previous items on focusing on behaviors and giving information. By trying to take a non-judgmental stance, ideally we get to show that we are not condemning the person, that we are open to working with the person to address the objective information provided.

• Instead of (judging the person) “You wrote that report poorly,” or (judging the work) “That report is poorly written,” provide the observations instead “I noticed three spelling errors in the report”.

I just reused the example from the book here. With that example, it feels easier, clearer or more achievable to address the “three spelling errors” compared to a poorly written report.

On achieving excellence, Not avoiding errors

I think asking how to avoid errors is a fair question to ask because that is something you want to achieve. This also works well for me for introspection. But related to what I mentioned previously, asking that can be taken negatively even if you don’t mean it to be. “How can you avoid so-and-so” might come across as rubbing salt to the wound or might feel like the focus is on what the other person is doing wrong.

• Instead of asking “Why do you keep on missing those bugs” (which also feels accusatory and it’s often not the case that people intentionally try to miss bugs), ask “What do you think can we try to find those bugs sooner?”
• Instead of asking “How can your outputs be less buggy,” ask “What do you think are we missing in our process so that we can get things right in fewer reviews as possible?”

---

In writing about this, I have had a little more time to think about it. But the challenge I guess is making these conscious word choices on-the-fly or when the situation unexpectedly calls for it.

Lines that resonate to me as a tester

I’ve started reading this recently published book by Ozan Varol called Think Like a Rocket Scientist. I’m only at the first chapter which is about uncertainty, and I came across these few lines which I found interesting. As a tester or reviewer, you come across bugs. While it can mean a little more work for the team, sometimes you can’t help admit that some of the bugs–or whatever little things that trigger them–are cool or fascinating. Maybe it’s just me. But say hi in the comments if you appreciate cool bugs once in a while.

Anyways, here are those quotes. Those three blocks below are from the book:

---

“Discovery comes not when something goes right,” physicist and philosopher Thomas Kuhn explains, “but when something is awry, a novelty that runs counter to what was expected.”

---

Asimov famously disputed that “Eureka!” is the most exciting phrase in science. Rather, he observed, scientific development often begins by someone noticing an anomaly and saying, “That’s funny…”

---

Einstein’s younger son, Eduard, once asked him why he was famous. In his reply, Einstein cited his ability to spot anomalies that others miss: “When a blind beetle crawls over the surface of a curved branch, it doesn’t notice that the track it has covered is indeed curved,” he explained, implicitly referring to his theory of relativity. “I was lucky enough to notice what the beetle didn’t notice.”

Reaction to 9 leadership mistakes

I came across a post in Medium entitled New managers: 9 leadership mistakes you don’t know you’re making. I’m not a manager—and not even considering a managerial career path—but that really hasn’t stopped me from reading about leadership and organization. And after having read it, I don’t think the content is just for new managers anyways. Regardless of being old or new or even just about to be in a leadership role, it’s good to be reminded (or warned) of the possible mistakes you might be making so that you can do something about it.

I was initially going to react on a couple or so points, but ended up writing what Medium estimated as a 5-minute read. So below are the mistakes shared in the post. For each, I supplemented with my own points and, for some, reiterated points I wanted to highlight.

---

Mistake #1: You think building trust is about team-building.

While it is an opportunity to make a connection (but it’s still up to you to make the most out of it), it’s not enough. The post author shares this link giving the three most effective ways to build trust as a leader: (1) Show vulnerability as a leader, (2) Communicate the intent behind your actions, (3) Follow through on commitments.

Try to think about how your own leaders built trust with you (or maybe how they didn’t), and use that to amplify your own trust-building experience with your own teams.

Mistake #2: You think your team members generally know what’s going on.

We’ve heard of over-communication, or even “hyper-communication.” But this quote says it best:

“The single biggest problem in communication is the illusion that it has taken place.“

So how would you know if your message gets through? One is that you’re getting the right actions out of it, but that might take time. One other way is to maybe talk to some members of your team—include the ones who people usually talk to—and ask for feedback.

Communication is such an exercise of empathy. Try to put yourselves in your audience’s shoes, and then ask yourself what would you (as them) get from hearing what you (as them) just heard.

Mistake #3: You believe being busy as a leader is good.

Don’t wear busyness as a badge of importance or of being effective. If you’re too busy, you’re time-poor. When you continuously work like you are so pressed for time, that has high chances of taking its toll on quality. It could be on the quality of the actual outputs since you might miss some details. Or it could be on the quality of your interactions—you might leave people feel like they’re not heard or seen even if you have squeezed a whole one hour for them.

I guess there might be some who feel exhilarated with busyness. And it’s OK. Just don’t let that diminish the quality of your interactions with the people you work with.

Mistake #4: You sort-of prepare for your one-on-one meetings (when you have the time).

Nothing says you have their best interest at heart better than putting in the work to actually show it. And that includes setting aside some time to look into what you’ve previously discussed, what news can you share that’s relevant to them, what concerns have reached you that relates to them, given whatever’s happening recently what would be the right questions to ask them. Check out the link that was shared how to prepare for your one-on-one meetings.

And as you go into that one-on-one, remind yourself that the meeting is not about you or your causes or your agenda. It’s about them.

Mistake #5: You try to solve the problem yourself, because you’re the domain expert.

Sometimes people will approach you asking how would you attack a certain problem they’re experiencing. I think I’ve been lucky because folks who ask me usually have already given the problem a lot of thought and would just like to have an nth opinion. So just be there to hear them out, and give your two cents if asked. But ultimately, solving the problem will be up to them.

Being in your position though, there’d be things you know—that they might not—that could help them like certain contacts, or references, or other available options outside of what they may be privy to. So be a means to connect them. You don’t necessarily have to go out of your way setting up all the needed meetings or doing POCs yourself. Again, solving the problem will be up to them.

Check out the link that was shared on the most counterintuitive leadership tip for more insights.

Mistake #6: You think transparency all the time is good.

When things aren’t clear or when intentions aren’t communicated well, there’s clamor for transparency. But as she mentioned, “transparency can backfire if you don’t hold two concepts in view: Transparency requires context, and transparency is on a spectrum.” The link she shared on how transparent should you be as a leader is an elaboration of this. Check it out, and here’s a quote from it that I wanted to highlight:

“As a leader it’s important to ask yourself: In what cases is transparency appropriate and helpful, and in what other cases is it distracting or a burden? Are you being transparent, just for the sake of being transparent, or are you truly trying to help people make better decisions, and feel a greater sense of trust?“

Mistake #7: You think you communicate the vision in your team well.

Again, I’m reminded of the single biggest problem in communication quote. Although not quite about management or leadership, a webinar I took mentioned how high level decisions influence low level ones. And it’s pretty similar. The vision or intent that you share to the team would create the actions that would push for that vision to be realized. Say the wrong thing, or don’t say it clearly enough, you get misalignment and what you get may be results that do not support the vision at all or as effectively as you wanted.

In terms of something actionable, I guess verbalize the vision in the context of your team. It’s possible that there’s some grand vision handed down to you, and if you can, distill it so that it’s more relatable and understandable for your team. And see Mistake #2 regarding communication.

Mistake #8: You think you’re giving enough feedback.

You recognize when recognition is due with “Thanks!”, “Good job!”, “Well done!”, and so on. But I think feedback that’s more helpful are the ones that will help people improve. But it’s hard when you’re not working on the same project together. You get some high level input that the project is doing fine, but you have no idea how well your team mate is actually faring.

Maybe that’s it—maybe you should work on something together.

Maybe you can look into the available structures at work that will allow for feedback to be openly and safely shared.

Mistake #9: You’re nice.

No, this is not a mistake. But I guess “nice” means different things to people, easy to talk to at the very least. But more than that, nice to me means being kind, being considerate, having empathy, playing fair, not being an asshole, and upholding respect for others and myself.

If you want only the easy, positive, fluffy conversations, that’s NOT nice. That could do a disservice to your team. To have honest, fair and helpful conversations, that’s nice.

If you’re always people-pleasing at the cost of putting your team members on a difficult spot, then that’s NOT so nice. Throwing people under a bus is not cool. Coming up with something workable IF you can and being able to decline IF you can’t — that would be nice.

You’re buddy-buddy with your team, that’s nice. But as their leader, are you helping them find opportunities where they can flourish? If not, that’s not nice. That you do your job as a leader effectively—and that includes upholding respect for the people you lead and letting them flourish—that’s nice.

---

That was long. If you’re here, thanks for reading this far!