Read: The Culture Code

Just finished reading The Culture Code: The Secrets of Highly Successful Groups by Dan Boyle. I read it even though I pretty much think the key to highly successful groups is having great individuals rallied together by a clear purpose and a selfless leader. That’s no secret — it’s just that getting that right mix is what’s elusive. Anyways, the book was a quick and easy read peppered with Ideas for Action (that’s literally the title of 3 chapters) on how you (but ideally your leader) can help in 3 things: (1) building safety, (2) sharing vulnerability, and (3) establishing purpose.

Actionable ideas

Be mindful of 3 basic qualities of belonging cues — Energy, Individualization, Future Orientation. So in your interactions with your team mates, invest energy by giving attention and being present in the interaction. Acknowledge the individual, don’t make him or her feel like he’s just another random person. Hint at a future, don’t make it feel like it’s just a hello and goodbye interaction.

Build Safety — We are safe and connected.

  1. Overcommunicate your listening – Start off with actually trying to listen, and hopefully your posture, expression, and whether you give a steady stream of affirmations (yes, uh-huh, gotcha) or encouragement to the speaker to keep going would shine through. If not, watch out for whether your posture, expression, reactions are conducive towards the speaker continuing to speak up.
  2. Spotlight your fallibility early on–especially if you’re a leader – Radiate humility and actively invite input with simple phrases like “This is just my two cents,” “I could be wrong here,” “What am I missing?”, “What do you think?”
  3. Embrace the messenger – When someone shares a truth especially bad news or tough feedback, don’t chew off their head. You have to make it feel safe for people to speak the truth.
  4. Preview future connection – Hmm… similar to above on future orientation. Maybe share some vision of the future that you have for the person (like if you see him or her as possibly the next great thing) or with the person.
  5. Overdo Thank-yous
  6. Be painstaking in the hiring process
  7. Eliminate bad apples – Bad apples like jerks, slackers, and downers just aren’t good for the psychological safety of the team.
  8. Create safe, collision-rich spaces – By “collision” he means serendipitous personal encounters. I guess this is about trying to increase the chances of interactions among the team. Could be as elaborate as setting up an extremely nice team area to something as simple as the team having coffee.
  9. Make sure everyone has a voice – Not just the loudest person gets heard. Everyone gets heard, and I guess what follows through is more important i.e., when it actually converts to change or action.
  10. Pick up trash – “Muscular humility”–a mindset of seeking simple ways to serve the group. Other examples could be allocating parking places, picking up checks at meals. “These actions are powerful not just because they are moral or generous but also because they send a larger signal: We are all in this together.”
  11. Capitalize on threshold moments – It’s not just in day one. In successful groups the author visited, they also paid attention to moments of arrival. “They would pause, take time, and acknowledge the presence of the new person, marking the moment as special: We are together now.” Think about it: A warm greeting to a team mate when he arrives versus not even batting an eyelash.
  12. Avoid giving sandwich feedback – Separate handling of negative and positive feedback — negative through dialogue, positive through “ultraclear bursts of recognition and praise.”
  13. Embrace fun

Share Vulnerability — We share risk here.

  1. Make sure the leader is vulnerable first and often – Recommended 3 questions for leaders to ask their people:
    • What is one thing that I currently do that you’d like me to continue to do?
    • What is one thing that I don’t currently do frequently enough that you think I should do more often?
    • What can I do to make you more effective?
  2. Overcommunicate expectations – People aren’t psychic and things don’t just magically fall in to place. “[Be] explicit and persistent about sending big, clear signals…”
  3. Deliver the negative stuff in person
  4. When forming new groups, focus on two critical moments – “At those moments, people either dig in and become defensive and start justifying, and a lot of tension gets created. Or they say something like, ‘Hey, that’s interesting. Why don’t you agree? I might be wrong, but I’m curious and want to talk about it some more.’ What happens in that moment helps set the pattern for everything that follows.”
    • The first vulnerability
    • The first disagreement
  5. Listen like a trampoline – Not just about nodding attentively, you add insight. “The most effective listeners do four things:…”
    • They interact in ways that make the other person feel safe and supported
    • They take a helping, cooperative stance
    • They occasionally ask questions that gently and constructively challenge old assumptions
    • They make occasional suggestions to open up alternative paths
  6. In conversation, resist the temptation to reflexively add value – Don’t try to end the conversation with your own solution. Let the discussion flow (except maybe if time-boxed or if the folks are going in circles).
  7. Use candor-generating practices like AARs, BrainTrusts, and Read Teaming – AARs are After-Action Review done by Navy Seals — It’s like our Retrospectives. BrainTrusts are by Pixar. Red Teaming is a way for exposing risks by creating a team to purposely think of ways to make you fail. One good AAR structure is to use five questions:
    • What were our intended results?
    • What were our actual results?
    • What caused our results?
    • What will we do the same next time?
    • What will we do differently?
  8. Aim for candor; Avoid brutal honesty
  9. Embrace the discomfort – “One of the most difficult things about creating habits of vulnerability is that it requires a group to endure two discomforts: emotional pain and a sense of inefficiency. But as with any workout, the key is to understand that the pain is not a problem but the path to building a stronger group.
  10. Align language with action
  11. Build a wall between Performance Review and Professional Development
    • Performance evaluation tends to be a high-risk, inevitably judgmental interaction, often with salary-related consequences.
    • Development is about identifying strengths and providing support and opportunities for growth.
  12. Use Flash Mentoring – Hours, instead of months or years
  13. Make the leader occasionally disappear – Not to be confused with toxic absenteeism. Given the right foundations and having set them up to know what to do, the team should still be able to perform.

Establish Purpose — This is what matters.

  1. Name and rank your priorities
  2. Be ten times as clear about your priorities as you think you should be – “Leaders are inherently biased to presume that everyone in the group sees things as they do, when in fact they don’t.” It doesn’t help when all the leader sees are nodding heads. Overcommunicate priorities.
  3. Figure out where your group aims for proficiency and where it aims for creativity – “Building purpose [for proficiency, machine-like reliability, usually for service] is like building a vivid map: You want to spotlight the goal and provide crystal-clear directions to the checkpoints along the way…. Generating purpose [for creativity, for empowering groups to build something that has never existed before] is like supplying an expedition: You need to provide support, fuel, and tools to serve as a protective presence that empowers the team doing the work…. Most groups, of course, consist of a combination… The key is to clearly identify these areas and tailor leadership accordingly.
  4. Embrace the use of catchphrases – No way, Jose. Corny. “They aren’t gentle suggestions so much as clear reminders, crisp nudges in the direction the group wants to go.
  5. Measure what really matters
  6. Use artifacts – “Their environments are richly embedded with artifacts that embody their purpose and identity … they all reinforce the same signal: This is what matters.
  7. Focus on bar-setting behaviors – Example given what about a hockey team that rallied their culture around a specific behavior they called “Forty for Forty” — it’s something that they do as part of their play and I guess it captures who they are in some way. I guess the closest analogy I can think of is for testers, we often said “Trust and verify.” Because that was really what was happening and what needed to continue happening. You have to take care of the relationship between you and the devs where you show them you trust them and you can be trusted; and that it’s not about distrust towards them when you do your checks or tests on their work; it’s because you have to do what you have to do i.e., to test.

That’s it. Summarized the 3 chapters (and I guess pretty much the whole book). Of course, the book can provide better context. Go buy it if you want, or buy me a hardcopy which I’ll gladly leave lying around in the office for sharing. Thanks for reading this far (or skimming this far, it’s ok), now maybe you can go over the list of actionable ideas again and this time look for what you can apply or explore further.

Reads: On skills for Product Management

This morning’s read tried to capture the job of a PM into 4 words: “Figure out what’s next.” I think in the work we do in building software (regardless of what your role is in your Agile project), we have to do a lot of figuring out. Coming with ideas or solutions independently is so important, and so is working collaboratively to further refine those solutions. Although it’s important to differentiate when it’s collaborating from spoon-feeding or unnecessary hand-holding.

Anyways, the post also enumerates 7 core skills to build for the Product Management role (actual text from the post are in bold, elaborations that follow are mine). But regardless of what role you are in the project, I think these contribute to being a good team player.

1. Taking any problem and being able to develop a strategy to resolve it — When you’re in the business of building software, figuring things out (preferably independently, with little to no hand-holding) is a critical skill.

2. Executing, getting shit done*in any role, this is valuable*

3. Communication — *same… in any role, you need this*

4. Leadership through influence

5. Making decisions, informed by data

6. Building great products, and having taste — As PM/PO/PPO/BA, you work closely with your designers. I think you also need to brush up on UX so that you don’t undo any of the good work your UX designers present to you for your feedback.

7. Always be prepared — *important for any role* I like the quote the author shared.

[Great PMs] say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.
— Noah Weiss

And I couldn’t agree more with his recommendations for developing your “I got this” aura. Over the years, I’ve worked with a few folks who would sound like they’re so unsure of what they’re doing. It just doesn’t bode well — it doesn’t give the team (or worse, their stakeholders) confidence that they’ll get the work done. I mean it’s OK to admit that you don’t know everything, because no one does — even “experts!” And it happens, I’ve gotten into countless of interactions where I really have no idea on what to do. But I guess my confidence (or my display of not panicking) stems from knowing that I have the capability and means to figure it out. (And that it’s not the end of the world if I don’t.)

So anyways, I’ve rambled on. Go check the post for the recommendations!

Brain dump: How I’d like my Agile testers to be

So I was just thinking about how I need the testers to work in our project (and maybe in any other project). This started as a brain dump and then the next thing I know I’ve got this outline already. So anyways, If I were to outline what I’d look for in testers, I’d look into the following areas:

  • Attitude towards testing
  • Technical competence
  • Being a team player

Attitude towards testing

Working on an Agile, greenfield project really needs to have testers who are quick studies, self-sufficient and proactive. Most of the time we are given just the user story and some mock-ups, so I need the testers who can model the user story in their heads or in their notes, ask the right questions about it, and do it on their own (i.e., not wait to be served the information they need on a silver platter).

I think testing is like problem solving. It’s like: Hey, you’re given this user story. How do you test it to make sure it’ll pass the PO’s review? What exactly do you need to test? What do you need to know to test it? It has a save functionality– what does it save, where does it save it, who’s allowed to save, are there stuff that needs to be derived or transformed, etc. It has a read functionality–read from where, how do I know I’m pulling the right data into the fields I’m checking, how do you get data entered to be read in the first place, do we format certain items differently, etc. Hey, look at this screen, what can I do with the controls in the screen, what can I do that I’m not supposed to, etc. Hey, I found a bug–can I consistently replicate it, can I narrow down the cases when this bug would appear, is this just a symptom of an underlying bug, is this even a valid bug, etc. There’s a fix I need to retest–what could possibly be affected, do I need to retest everything, etc. There’s a lot of figuring out and critical thinking involved.

What I don’t like is to reduce testing to an activity where we just write test cases and execute the test steps without thinking about how our work can provide value to the team, to the product, to the client, and to people who’d end up using our product. I really want the testers go into the project with the desire to make their being in the project really matter.

Technical competence

You can’t just WANT to be a solid contributor to the project, you have to BE one. You can be the most idealistic person but that won’t get you to where you want or need to be, you need to be able to execute.

For testing, I don’t necessarily equate technical competence to being able to automate. Being able to automate tests doesn’t mean so much if your tests can’t find the issues that needs fixing. We have to keep in mind that the product is the actual product — not the test automation scripts.

As I mentioned earlier, testing is like problem solving. Part of this includes modeling the application or feature you need to test — figuring out where there’d be if clauses or doing some decision tables, figuring out the data flows, state transitions, figuring out combination of valid/invalid input, etc. Figuring out what you actually need to test given that the lines defining the scope could sometimes get blurry. Then there’s instances where you have to work with the database, parse some flat files, or with some API. There are also instances when you need to simulate a certain scenario — and you have to figure how to do this right otherwise you might just bring up an invalid test case or bug. There are also instances when looking under the hood allows for more efficient testing; for instance I’ve reviewed database scripts and that reduced the effort as opposed to executing the test cases in fully black box mode.

You’ll also need to collaborate with developers and you need to be able to keep up with the discussions. You can’t rely on the layer of having the test lead interpret stuff for you. And it just saves people time from having to explain things if you can keep up with the technical discussions. When you report bugs, it is also very helpful if you’ve done your own investigation to narrow down the possible causes. When it comes to bug reporting, I always say “A problem well stated is a problem half solved.”

There’s a lot of collaboration within the Agile project. Roles of people you’ll engage with include fellow testers, devs, UX designer, BA, PO, and possibly support. You’ll need to share status updates, raise impediments, raise bugs, raise potential enhancements, raise a lot of clarifications, and possibly conduct demos of the user story. There’s going to be a lot of communication going on so you really need to know what you’re talking about, and you have to know how to talk about it.

Being a good team player

This is good to have in any project or in any team. You want to work with people who are responsible, reliable and who keeps each other informed as needed. You want people to pull their own weight in the project, and to help each other out esp when the load gets heavier for some. And it’s all the more appreciated when people help without having to be asked to help.

Meeting the Sprint goals is the primary focus, and so when needed, the lines defining the roles are blurred and folks try to contribute whenever and wherever they can. For instance, I’ve taken on the BA role while another tester has taken on the PM/scrum master role. We have front end devs who also work on back end tasks. When we needed load testing to be done and we couldn’t get another tester to work on it, one of our devs took on the task. When there were some data update needed, the team split the task among those who can help so as to get the job done faster.

Summing it up

It’s hard to come up with a checklist of traits for what I’d like in the testers in my team. Essentially, I want testers who sincerely want to contribute to the project. I want testers who can actually test, who respect testing per se, and who can build their credibility within the team. And of course, I want team players to help make the not so easy task of building software hopefully less hard. People won’t always fit the bill off the bat, but what’s important is to advance towards improving.

Ensuring quality

“A tester ensures the quality of the product.” — Probably just as much as my donations to wwf are helping me to “save endangered species.”

The other day I listened to a podcast by the Bach brothers. One of the things they pointed out as needing improvement is the accuracy of testers’ statements. As an example, they cite — and question — the familiar statement “a tester ensures the quality of the product” which many of us use to describe what we do. But then I guess it can’t be helped. Someone I follow on twitter shared that a book on software development described the tester’s task is to verify that software is correct.

Is that really what I’m supposed to do? Ensure quality? Well, it does make my work sound more powerful. It sure makes for better marketing than “find bugs”. And probably for more attractive hiring. But there’s a shred — ok, a tiny sliver — of truth to it albeit so indirectly (just as i am saving endangered species… somehow).

In the podcast, Jon Bach suggested the term “assistance.” Between “ensuring quality” and “helping” to do so, what we do comes closer to the latter. We help our SAs by spotting design holes. We help our devs by spotting errors and misses in their code. We help them when we give clear and concise bug reports — all the more when we do bug isolation and provide accurate reports. We help our team leads by providing information on the product under test. Et cetera, et cetera. Sometimes it may not be quite obvious but we, testers, are a very helpful bunch!

We do our bit, we play our part. But no matter how well we play it, by ourselves, we (testers) cannot ensure quality. I reckon it’s a team thing. What we do as members of the project team (be it testers, devs, SAs, etc), how badly or how well we do it, can either make or break our software product.

Ultimate team player

This evening, I received an exclusive pre-release article from [the] new Marcum and Smith book, “Momentum”.  They’re the same guys who wrote Egonomics.  Anyway, part of the article is on the ultimate team player — which I’m sharing here.

According to our work and research, the ultimate team player has certain characteristics that set them apart and make it easy (at least easier) to know who they are when you see them. Here are some key questions that distinguish a great team player:

  1. Do they make the people around them better?
  2. Do others offer better ideas because of their questions?
  3. Do others work more passionately because they’re around that person?
  4. Do others pay attention more when they’re in the room?
  5. Are others more engaged because they’re on a project with that person?

Here are 12 characteristics of a great team player that feed into the five questions above:

  1. We, then me mindset; works with a team first approach without losing sight of his individual talent, confidence and contribution.
  2. Devoted to progress; committed to a cause or purpose beyond himself.
  3. Speaks her mind boldly and diplomatically.
  4. Listens to feedback carefully and anxiously, especially when it’s difficult to hear.
  5. Constructively discontent; not pessimistic, but not relaxed about status-quo.
  6. Inclusive; loves diversity and talent, especially those with talents and history different than theirs.
  7. Insists on debate, and debates ideas effectively; doesn’t care who has the best idea, as long as the best idea wins; doesn’t take things personally.
  8. Open minded; not change or new idea resistant.
  9. Doesn’t allow the early warning signs of poor communication and teamwork (defensiveness, showcasing, excessive competition, seeking acceptance) undermine team dynamics and individual talent.
  10. Sees people as equals, not as superiors and subordinates. Only in accountability and performance are those hierarchical relationships visible.
  11. People trust your intentions; people know where you’re coming from when you challenge ideas, share new ideas, etc.
  12. Desire to make a difference, not just “do your job.” There is a clear performance difference between “job-holders” and difference-makers.