Skip to main content

Paving the Way

Introduction

James: A few years ago, Claire, a friend from the Cambridge tester meetups, asked if I’d be her mentor. I said yes and we collaborated for around 12 months as she took stock of her role and career direction, and worked to get to where she wanted to be in both. We blogged about it in Don't be a Prick.

Then, last year, I found myself doing the same thing with a colleague from my team at work, Yasemin. We’ve just ended that relationship and now we’re blogging about it too! (Thanks to Claire for suggesting we should.)

Yasemin: Two years ago I moved from Turkey to Berlin. I know that I thrive on learning new things and challenging myself with joy, and what better way to do that than in a new culture, language, and company? And it has been an adventure: I've had brain surgery, taken a journey of self-discovery, explored new opportunities, and really pushed my limits. 

One of those opportunities was meeting James. I watched him work for a year, observing how he inclusively engaged with people and eagerly shared his skills and knowledge. I knew that I wanted to learn from him.

And so, without fully understanding what it meant, I asked him to be my mentor. Was mentoring being a boss? A city in Ohio? I had no idea. If you're still reading, chances are you know more about mentoring than I did at the time.

Both: We agreed to try an open-ended arrangement with no particular schedule except for a monthly diary in a shared Google doc. We also said that we were open to feedback on the relationship, that we would always assume good intent, that our project was not a secret although we would respect each other's confidentiality, and that we were free to end it at any time.

Yasemin

When it comes to our agreement, I want to remind both my brain and you of what I had hoped to achieve through our relationship. I wanted to reinvent myself from scratch, make meaningful contributions to work, expand my knowledge on various topics, approach problems in new ways, increase my self-confidence, push my limits, and better understand my feelings about work.

Looking back, I must admit that these goals seem quite broad and vague. In hindsight, I wish I had set more specific objectives for myself. However, I did make significant progress in one area in particular: improving my data-driven vision with the help of James.

I now feel much more comfortable using data when coding, implementing, testing, or presenting my ideas. This has allowed me to approach my work with a calmer mindset, resulting in more thoughtful and conscious outputs.

There were certainly times when I felt demotivated and unsure about my progress, but James never gave up on me. His relentless drive to create something useful every day inspired me to keep pushing myself. And in the end, I was able to achieve the promotion I had been hoping for. I did!

I am delighted to have taken the resilience of the human spirit as my guiding principle while observing James. He never seems tired while explaining his own ideas or beliefs. No matter how seemingly small or insignificant they may appear to the outside world. It is worth telling again and again. And I am grateful for the deep level of existential analysis that our mentorship has led us to.

James's guidance and mentorship have made a significant impact on my personal and professional growth. I am truly grateful for the things I learned from him and the wisdom he imparted if I was able to get them. 

It might look like just statements but please be reading with your slowest and most emotional voice.

Here are the key takeaways from our mentorship:

  • Offer and ask for support whenever necessary
  • Ask well-defined and explanatory questions without fear
  • Prepare yourself before asking questions
  • Give and receive actionable items and suggestions
  • Take structured, concise, and well-worded notes
  • Learn how to write effective tickets
  • Learn how to make effective presentations
  • Gain a broader understanding before starting anything
  • Write clear code and provide explanations when necessary
  • Encourage others and be encouraging
  • Be direct but wise when dealing with issues
  • Develop resilience in problem-solving
  • Have fun while working

I must confess that I enjoy the poetic touch, so I will conclude this part with some words that perfectly capture my growth mindset:

Yasemin continues to show how much she wants to grow herself. She is like a sponge for suggestions and ideas. I feel comfortable offering her ways to try to do things, knowing that she will take what works for her.

You already guess who said this :)

James

Looking back at our agreement I see that I only wanted to help Yasemin to achieve what she wants, and I’m very happy that she now feels she did.

I’m also happy that I was able to adapt to, and be guided by, what she wanted and needed at different stages. I played the role of  mirror, reflecting her feelings back to her in a truthful way; I reframed scenarios looking for a personal win; I empathised with her and I shared experiences that were related to hers; I prepared so that I was ready to give feedback on her performance in presentations or as a facilitator if she wanted it; and sometimes I offered it without being asked.

I felt safe to offer unbidden feedback because we had, and continue to have, a strong sense of shared trust. It feels safe to discuss any topic in our conversations and that includes things we thought might be difficult, such as interactions with our team mates. While being keen to empathise, I did not want to let our conversations slide into sessions where we slag people off behind their back.  

I reflected a little on the context I tried to set when we interacted:

  • Not judging
  • Empathising
  • Listening
  • Praising
  • Making suggestions not demands
  • Framing scenarios not making assertions about them
  • Sticking to all agreements
  • Doing more than the bare minimum
  • Being explicit about the range of acceptable outcomes

That last one is interesting, and I found it valuable in the years I spent as a manager. 

To give a couple of examples: after 12 months of mentoring I suggested reviewing our arrangement and I was clear that I would be happy with whatever Yasemin decided: stay the same, change any aspect, or stop completely. When we discussed writing this blog post I said that we could finish it and she could still decide that she did not want to publish it. 

This takes the pressure off and makes a safe space to work in. In this case, we can have an open collaboration intended to benefit Yasemin, without her needing to worry that our goals are misaligned or that I will be upset with where we end up.

Our arrangement has cost me very little. Our meetings for mentoring itself were infrequent, and we pair often anyway. Where I was proactively taking notes in order to provide feedback I’d have been present anyway. I did some occasional research, but rarely enough that it would show up in the noise of any temporal accounting.  

I liked the regular diary as a driver for reflection and introspection. As we end this relationship it’s also evidence of change, something that it can be difficult to see in the moment. By sharing the diary we also get to see more deeply what the other person is thinking. Without it I might have missed out on this lovely and poetic feedback:

I am really glad that I have James on the team as a friend and a mentor. He's always pushing me to the edges that I did not think of. He paves the way for me to shine. 

Reflection

Yasemin: If it was going so well, you might ask why I’d want to stop?

I see I achieved my goals. I feel strong confidence in what I do. I know exactly what I desire from my work: a safe learning environment that's free from negative pressure and ambition. I was inspired by James about doing my best every day and can still be inspired. Those were a sign for me to stop, for now. I'm confident that if I require support in the future, James will be there for me. This fact is based on our mutual trust.

I'd not do anything differently when I looked back. Probably I'll miss my mentor and my friend dearly. Only for this reason, maybe I should have moved on. Like James's namesake, James Clavell, said:

All stories have a beginning, a middle, and an ending, and if they're any good, the ending is a beginning.  

Now it is time to give back to the community. 

James: We stopped when Yasemin decided she didn’t need the formal arrangement any longer. At a meta level, I don’t think I would do anything differently next time. My aim was to behave in a way that was beneficial to Yasemin and acceptable to me given the context at the time. I’d do the same again with someone else, although the specifics would be, well, specific to that situation.

Although I do try to tailor my approach, I know that I am just less compatible with some people. Yasemin suggested, from her observations, that good people for me to work with will:

  • Accept help and feedback
  • Take action from learnings
  • Want to improve themselves

If we add something about being prepared to engage in self-reflection I think that’s probably right. I guess it's also just about the dream mentee!

I want to end by congratulating Yasemin on what she's acheived here. She decided she wanted to make some changes, worked out what kind of changes she felt she needed, looked around for support, took the huge step of asking for it, engaged with it in ways that suited her, made her changes, and then found another challenge.

I may have paved the way to some extent, but it's Yasemin that walked the walk.
Image: imgflip

Comments

Popular posts from this blog

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

Testing (AI) is Testing

Last November I gave a talk, Random Exploration of a Chatbot API , at the BCS Testing, Diversity, AI Conference .  It was a nice surprise afterwards to be offered a book from their catalogue and I chose Artificial Intelligence and Software Testing by Rex Black, James Davenport, Joanna Olszewska, Jeremias Rößler, Adam Leon Smith, and Jonathon Wright.  This week, on a couple of train journeys around East Anglia, I read it and made sketchnotes. As someone not deeply into this field, but who has been experimenting with AI as a testing tool at work, I found the landscape view provided by the book interesting, particularly the lists: of challenges in testing AI, of approaches to testing AI, and of quality aspects to consider when evaluating AI.  Despite the hype around the area right now there's much that any competent tester will be familiar with, and skills that translate directly. Where there's likely to be novelty is in the technology, and the technical domain, and the effect of

Testers are Gate-Crashers

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Testers are the gatekeepers of quality" Instinctively I don't like the sound of that, but I wonder what you mean by it. Perhaps one or more of these? Testers set the quality sta

Am I Wrong?

I happened across Exploratory Testing: Why Is It Not Ideal for Agile Projects? by Vitaly Prus this week and I was triggered. But why? I took a few minutes to think that through. Partly, I guess, I feel directly challenged. I work on an agile project (by the definition in the article) and I would say that I use exclusively exploratory testing. Naturally, I like to think I'm doing a good job. Am I wrong? After calming down, and re-reading the article a couple of times, I don't think so. 😸 From the start, even the title makes me tense. The ideal solution is a perfect solution, the best solution. My context-driven instincts are reluctant to accept the premise, and I wonder what the author thinks is an ideal solution for an agile project, or any project. I notice also that I slid so easily from "an approach is not ideal" into "I am not doing a good job" and, in retrospect, that makes me smile. It doesn't do any harm to be reminded that your cognitive bias

Play to Play

I'm reading Rick Rubin's The Creative Act: A Way of Being . It's spiritual without being religious, simultaneously vague and specific, and unerring positive about the power and ubiquity of creativity.  We artists — and we are all artists he says — can boost our creativity by being open and welcoming to knowledge and experiences and layering them with past knowledge and experiences to create new knowledge and experiences.  If that sounds a little New Age to you, well it does to me too, yet also fits with how I think about how I work. This is in part due to that vagueness, in part due to the human tendency to pattern-match, and in part because it's true. I'm only about a quarter of the way through the book but already I am making connections to things that I think and that I have thought in the past. For example, in some ways it resembles essay-format Oblique Strategy cards and I wrote about the potential value of them to testers 12 years ago. This week I found the f

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Test Now

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When is the best time to test?" Twenty posts in , I hope you're not expecting an answer without nuance? You are? Well, I'll do my best. For me, the best time to test is when there

Rage Against the Machinery

  I often review and collaborate on unit tests at work. One of the patterns I see a lot is this: there are a handful of tests, each about a page long the tests share a lot of functionality, copy-pasted the test data is a complex object, created inside the test the test data varies little from test to test. In Kotlin-ish pseudocode, each unit test might look something like this: @Test fun `test input against response for endpoint` () { setupMocks() setupTestContext() ... val input = Object(a, OtherObject(b, c), AnotherObject(d)) ... val response = someHttpCall(endPoint, method, headers, createBodyFromInput(input) ) ... val expected = Object(w, OtherObject(x, y), AnotherObject (z)) val output = Object(process(response.getField()), otherProcess(response.getOtherField()), response.getLastField()) assertEquals(expected, output) } ... While these tests are generally functional, and I rarely have reason to doubt that they

A Qualified Answer

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn ,   Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Whenever possible, you should hire testers with testing certifications"  Interesting. Which would you value more? (a) a candidate who was sent on loads of courses approved by some organisation you don't know and ru

README

    This week at work my team attended a Myers Briggs Type Indicator workshop. Beforehand we each completed a questionnaire which assigned us a personality type based on our position on five behavioural preference axes. For what it's worth, this time I was labelled INFJ-A and roughly at the mid-point on every axis.  I am sceptical about the value of such labels . In my less charitable moments, I imagine that the MBTI exercise gives us each a box and, later when work shows up, we try to force the work into the box regardless of any compatiblity in size and shape. On the other hand, I am not sceptical about the value of having conversations with those I work with about how we each like to work or, if you prefer it, what shape our boxes are, how much they flex, and how eager we are to chop problems up so that they fit into our boxes. Wondering how to stretch the workshop's conversational value into something ongoing I decided to write a README for me and