Now that might be perfect for a certain type of company. It might be right for a small startup that needs to ship a list of features that are not its core business: you don’t want to reinvent the wheel! A customers list, a login screen, a checkout. But when you are the manager of a group of individuals who are trying to solve a problem for the first time in their industry, or to do something in a radically different way than what’s established, your’re gonna want to fuel those Eureka moments, because you’re not looking for repetition, but rut-breaking. Here’s where you need to introduce a bit of a cognitive refresher.

Ok… but is there any real science backing this claim?

In cognitive psychology and organizational behavior, we learn that our brains gravitate to automation when they are surrounded by familiarity. We stop recalculating every step we take because we know the place well, and we start optimising for speed -that’s cognitive fluency. On the contrary, a certain level of healthy difficulties will activate deeper cognitive processing.

Increasing perceptual disfluency will prompt humans to use more analytical reasoning (study). This doesn’t mean you need to start documenting your systems using death-metal fonts, though.

Subscribe now

What I found really interesting is that this principle will not only work for individuals, but also for systems. When a team faces this kind of obstacles, they will alter their stablished protocols for problem-solving and find new ways.
For example, when less information than usual is initially available, more questions will be asked, engagement will be greater, and results will reflect that.

These controlled, harmless glitches in our boring conveyor belt system are the productive friction (also labelled as “tactical conflict”) I’m talking about.

How to introduce productive friction

I personally abide by this code-of-conduct:

• You must guarantee psychological safety. There’s no point in trying to generate debate, questions or discussion in an environment where people do not feel allowed to digress, challenge others or make mistakes.

• Don’t dehumanize your team. This is not your lab rat to play with, this is a group of humans who deserves your outmost respect -and a real business that needs to turn profit. Don’t play the mad scientist here, and stick to small changes, from a positive angle (more on that later).

• Be transparent. Tell them what you’re trying, they have a right to know and can provide feedback. Also, because some people struggle with lack of anticipation, it’s worth it to communicate what you’ll be doing and how it will work.

• Don’t go all in. If you start making changes you won’t know what worked in the end, and you might cognitively exhaust the team. Plus you’ll look like a clown. Don’t be a clown.

• This is about intellectual friction. It’s about cognitive dissonance, never about conflict between humans.

• Ditch the stopwatch. Different processes take different time, so stop counting cycles for a bit and focus on the change in the value delivered.

Now for the real “how do I do this”? Here are some examples of healthy, productive friction you can introduce:

• Introducing constraints. Challenging an engineer or a team to design a solution with a specific budget, reliability or benchmarking goal will add variables to the mix that will push them away from their usual, out-of-their-box way of solving that problem

• A devil’s advocate in a design discussion or decision-making session. Which can be you or someone in the team. A respectful, constructive counter opinion -even if the conclusion they are getting to seems the right one- often makes us look at our creation for other angles and try to polish it or make it more resilient.

• “Impact-first, solution after”. The first question engineers asks themselves after hearing a requirement is “how do I build it?”. When facilitating a design session, backlog refinement, etc, you can introduce a small game consisting on, first, spend some minutes aliging on what is the value this particular backlog item delivers? Only after the question has been answered in a way that satisfies everyone, can they jump to technical discussion. This is friction because they are not used to be required to think about the why before touching the how, it breaks that automation. You’d be surprised at the number of ideas that will get pushed to the bottom of the backlog with this exercise.

• “Cost of inaction”. This is one of my favourites and one that so often goes missing in decision documents. When facing a dilemma or a business decision, we try to be diligent and present a number of possible ways out of it, but we rarely stop to gauge the impact of not doing nothing. Asking ourselves “what if I just let this be” is an interesting way to shake up the way we solve riddles.

Other small changes you can try are rotating the facilitator role of a recurrent meeting (again, inform the individuals appropriately, this is not about catching them off-guard) so that the change meeting pace and style break communication ruts. Or changing the way you facilitate retrospective meetings or introduce constraints (i.e. let’s try to predict the next sprint retro… write the sticky notes for what you think has happened).

I’m sure you can come up with more ideas (and I’d love to read them all!). You could also play the ultimate manager-elevation card and ask your team to pick their own cognitive disfluency experiments as well: an empowered team is an engaged one. Just make sure you stay open to feedback at all times, inspect the changes with honesty, and be ready to stop when it’s enough or the team faces true discomfort. Periods of cognitive comfort are also necessary after all.

Leave a comment

Most of my time as an individual contributor, I spent it doing QA. It’s always been my favourite position in the team because it let’s you try all the jobs in the restaurant kitchen: siding with the Product peer, contributing across the stack, being consistently exposed to the coding practices of talented engineers, participating in rollouts, owning the business domain and model, impersonating the customer and working really close to their feedback. I’ve always felt a good QA has a say in everything, and an endless learning path. It’s the gift that keeps on giving. And as a cherry on top, because you don’t need to be a particularly stellar developer to implement a test suite, you can jump from stack to stack, never marry a technology and stay safe from framework cults.

However, quality -like good infrastructure, marketing budgets or workers’ rights- is one of the pillars that become less than an afterthought when profit shrinks or VCs stop picking up the phone. Struggling companies tend to get nervous and they try to impress the market with a constant drip of new features. Time to market and new contracts is everything that matters, and actually operating those features is a problem for tomorrow (or the next quater report).

Something similar happens with new-born companies: they don’t even know if the audience is going to like or understand the product, so investing money in its ability to work well, sustain traffic or comply with laws is a luxury.

And precisely in these companies, is where I see a setup that inevitably precedes what I call The Cinderella Syndrome:

• The company invests less money in salaries, so they don’t get the best talent in the market (this is code for engineers that don’t know how to, or don’t want to test)

• The pressure to launch makes up for features that are designed, coded and pushed in a hurry, and rapidly growing, obscure codebases, no time for documentation

• High churn in the team means many hands stirring the soup, low domain knowledge

• They see QA as a job, not an activity. So it doesn’t happen if there’s no QA peer on board.

And then comes the Cinderella job posting:

Innovative, industry leader company is seeking a Quality Assurance Engineer. Their main responsabilities will be:

• Automating our test suite

  Surprise: there’s two years worth of features in production, and zero tests coded. They will expect you acquire functional knowledge, identify what to test, start a test suite and catch up with the product ASAP while you test and ship code for the newly pushed features, week by week.

• Perform manual acceptance tests

  Because the job of the PO ends up in the refinement, you’ll have to make sure the coded features resemble whatever was in their minds, and sign it off

• Champion and implement quality assurance amongst the software engineers

  To this day, the manager hasn’t been able to hire people who actually test what they develop or consider quality as part of their job. So now they are pushing this responsibility to you, hoping you will teach them, coach them, watch them, and enforce a test coverage % that feels fit for an audit -in your spare time. Furthermore, they want you to lead everyone to a place they don’t want to go, without formal authority -and for the record, don’t you dare seeking formal authority as an engineering manager with a QA background: you’ll be underestimated, since you lack the pedigree of a true developer

• Perform compliance, accessibility, and localization testing (I promise you, this week I’ve seen openings for QA’s with strong Japanese, German and other languages, plus English, based in Spain)

  We’ve revoked our localization tool license and fired our legal and UX team, so now we expect you to be a catchall for everything and spare us a lawsuit.

• Requirements: proficient in Java, React, K8s, Swagger, AWS in general, Mocha, Jira and the W3C guidelines (I swear I’ve seen this one today).

  We don’t know what a QA engineer actually does, so here’s the comprehensive list of everything we use. We won’t have time to teach you, so we expect you to just land and figure everything out on day 2.

• Extra ball: strong knowledge of BDD tools and Gherkin

  Someone sold us this fantastic tool that would allow us to have automated acceptance tests, just by having the PO write them in natural language. We later found out these tools actually require 3 layers of coding/abstractions, the PO is too busy to download an IDE, and the test suite was abandoned after some developer spent two days writing login test scenarios that no one ever executes.

To summarize it, this close-fisted approach to QA as a tax has driven companies to repicture the quality engineer as a manager, a full-stack engineer, a manual tester and a subject matter expert, all in one person and very often in a context of unmanageable tech debt and lack of quality culture. If you’re a fellow QA and you’ve been there, you know it’s impossible to perform well.

But even worst than the hypocrisy of having you handle that workload, is the fact that with this twisting of the job description, we’ve also reframed the actual personality of the engineer in question. You need to be naturally equipped and interested in being on a driving position, a really strong communicator to liaise with stakeholders, users and engineers, firm and charismatic enough to introduce fundamental changes in the way the product is shipped, and of course, you need to stay technical. And this is completely unfair, since we don’t expect backend engineers, or frontend engineers, or SSREs to all be leaders, great communicators, pioneers. We understand that some engineers just want to keep working on their craft, that some will want to become architects, and others may want to jump into management -and that people will want different things during their working life, because not even climbers remain in rockstar mode year after year. But we do require that from QA engineers, and they better accept it because hey, the demand is shrinking, generative AI holds a big promise for testing, and I heard Meta doesn’t have QAs anymore. A test engineer that’s only interested in testing is generally disregarded in a way that a SE who just wants to code won’t face so often. Moreover, and this might be controversial, I think this is why there are so many women in QA roles compared to software engineer ones: we’ve traditionally accepted to invest double effort for half the return, we’ve been socialized to contribute without authorship, to lead surreptitiously, to clean up after others, and to always excel just to keep our seat. So we just put up with this kind of BS.

So there’s the Cinderella syndrome in QA: you’ll never own the house, and it seems you should be grateful for the shelter the team provides you, but in return you must do the job of a cook, a cleaner, a seamstress, a merchant, a manager, and fill the gaps that years of mishiring, rushing and stumbling have left in the product. An abusive expectation, and job that can’t be done well.

Share

For a long time, the line of thinking has focused on the benefits for employers upon hiring people with disabilities: higher retention rate, tax benefits, more diverse thinking, you name it.

How about we turn the narrative around? Can your company afford to miss a piece of the talent available in the market just because you aren't able to hire -or keep- those living with disabilities? As a manager, what's your excuse to exclude a full segment of the population?

Today, being a high-performing manager implies being able to attract any type of talent, and providing the right environment to make it thrive. Managers should be able to lead, coach and support any type of individual, at any stage of their professional life. Yet so many times we dismiss both our influence and the environmental factor. Having a disability is not a predictor of professional competency, however, the working environment and the attitude of the manager are.

Here are some key principles you can rely on to work on a management style that works best for professionals with disabilities:

• You are biased. The sooner you embrace the truth, the sooner you can shake that bias off. Most prejudices fall somewhere in the response amplification spectrum, and this is especially true for performance management. Both overstating and understating an employee's performance will hinder their professional development.

• The intersectionality factor. When disability overlaps with gender, ethnicity or socioeconomic factors, every added intersection is not a sum, but a multiplier. For some disabilities, there's a certain chance that your employee is also a caregiver for an ascendant or descendant with similar challenges.

• Some environments can be disabling. Look at the tools, practices, habits, schedules and communication in your team. Are you favoring a specific communication style, is the timing flexible enough, is it physically accessible?

• You are accountable for educating yourself. Adopt best-practices such as the use of person-first or identity-first language, operate with the assumption that you have zero knowledge on the particular disability's workplace implication, so you can stay humble and curious when asking your employee about the accommodations needed (actually, you don’t need or are entitled to know about their condition, only about their particular needs in the workplace”!).

• Disability is a lived experience. Beware of stereotypes: some disabilities will remain invisible to you, others can be dynamic -their impact will vary along the way-, and even for the ones you may think you're familiar with, remember no two individuals are the same. Your job is not to judge or verify, but to support.

In general, remember that accommodations are the least you can do. Real inclusion in the workplace can only come from a mix of inclusive cultural practices, proper leadership, specific HR policies, diverse participation opportunities, and investment in training.

RESOURCES FOR MANAGERS (and allies!)

Here you have some actionable, quick to adopt utils for your manager toolbox:

• Situations and Solutions library by the US Job Accommodation Network.

• A report about invisible disabilities in education and employment.

• Disability language style guide.

• Americans with disabilities act: a summary for managers.

• Tips for Managing Neurodiverse workers, remotely.

• Make your online meetings more inclusive (free lesson).

• Zoom's accessibility features.

• Make your Slack messages accessible.

I learnt during the past months that burnout is just the same.

I promised myself I was leaving my former employer just a year ago. I had been through a couple years of sinus waves of disbelief and reconciliation, just like in cheap romantic novels. I was in a very complex situation, a toxic mix of wanting to see the good and the bad for the sake of growth and learning, of wanting to fix the world for many amazing people who I love dearly, trying to change a rotten system that was in love with itself. I wasn’t raised to be a quitter, and thus for a long time quitting seemed like failure, disloyalty and cowardy. So I gave it everything I had to build and ship the best possible thing, in the best possible way, and making it an opportunity for everyone’s success, but at some point I just realised that that kind of effort was never asked of me, or even wanted. Yes, I felt appreciated by many peers, but results-wise, it just felt pointless. So I left and it felt like heartache, and that’s how I know I did it way too late.

I also wanted to test myself against higher stantards. I wanted to find a new role on my own, no referrals, doing technical interviews and everything, because I felt I had a gendered reputation and even people that appreciated me held too many assumptions around the kind of work I was good at. I started accepting invitations to participate in talks and other events, even though they cost my health so much, because I thought that kind of external validation was necessary.

Anyways, in the blink of an eye I found a fantastic place, exciting project, and I thought I would never look back.

But the truth is that, as down as I had been feeling, I only gauged the actual amount of harm done as I onboarded on my new role. It was a mix of frustration, anger, solitude and the heavy digestion of it all. I had gotten used to navigating projects whose code and behavior I felt more or less familiar with, small scaled, where I always knew what door to knock, and had a deep understanding of the business. That’s normal to feel after nearly 6 years at the same place. But I also started comparing experiences, and that made me angry, and that felt like being hit once again. In the past I had been mocked for my standards, my rigidness, my writings, my rawness, my high expectations… and pretty much my brain wiring, and only now was I finding out that I was feeling ashamed of “traits” that were “skills” at a proper place. I was mad at myself, mostly, for having normalised behaviors that no employer shoud permit. I was surprised to find that I wasn’t so hungry for growth when not feeling threatened 24x7. I was relieved to confirm that engineering managers out there do not manage 4, 5 or even 6 teams at a time, and that what looks like a stretch assignment, if outscaled, is just a recipe for failure, because in such a setting you will never do the job well. And that’s specially painful for someone who wants to put the human in the center, or someone that needs to do the thing right, black or white.

So I think it all just blew me up. I’ve spent a good 8 months dedicated to that new role -where I feel very appreciated and heard, have a fantastic team, and an inmense potential for learning- but outside of the role demands, I’ve been pretty much incapable to read, grow, network, or post on my small stupid blog. I’ve felt a knot in my throat every time an idea for a post came to my mind. I haven’t finished a single technical book. I have declined every invitation to events or conferences. I have been clinically sick. Eventually, I disconnected from social media because I couldn’t keep with discussions, news, and the anxiety that I was feeling from just being in the world.

I’ve focused in working with my therapist on that burnout, and understanding my conditions, and how they interact with my work setting. Trying to build some higiene and guardrails instead of wiping my back day and night. I finally got my certificate of disability, and it also forced me to discuss internally if my career should ever be in the spotlight, at least the way it has been until now -no adaptions, just rawdogging it, trying to fit and play the part of someone who’s “100% able”, whatever that might mean. I’ve been trying to be honest with myself about what kind of price do I want to pay for living on extra credits I don’t really have, and for how long is it going to work. I’ve been telling myself “no, you can’t do that”, “no, you can’t go there”, “no, you need to stop for today”, and damn, it hurts. Am I a quitter now? I’ve rebelled against myself lots of times, and I’ve tasted the sour flavor of that mistake in my own health.

How am I feeling today? I think I’m still scratching the dirt in the surface. I’m certainly many miles closer to myself than I was one year ago, because I’m starting to allow myself to be that person. Quirky, rigid, raw and a bit hyper. Someone who needs to say “no” often to preserve their health, who needs more rest than normal, but who also has big bursts of energy and can suddenly deliver 5x in one day- but then needs to stop and refill.

If you want a KPI, I’ve read 21 books in the last 8 weeks and none of them was related to tech or management. This summer I’ve delightfully fallen into any monotropic rabbit hole I’ve felt like, I have created music with a gen AI, I’ve attained a very deep tan while floating like an otter in the pool, and I have penned this post in a violent episode of inspiration on a Sunday morning. These are very me things and I don’t think I’ve been at that place since, easily, 2010.

So cheers to me.

This time around I want to dig deeper on the delivery aspect of metrics and, hopefully, provide some tips on how to use metrics that work well with humans, not machines. I won’t go into details about each…

Read more

I’ve been managing teams for 3-ish years now. During this time I’ve spanned between inspecting and fine-tu…

Read more

Not that many years ago, I took a really big leap by starting a career in Tech. I was nearly in my 30’s, divorced, raising a toddler and lacking the proper pedigree (no uni title, no professional experience…). Recipe for success.

Fast forward to 2020, I became a ma…

Read more

I started watching Ted Lasso on Apple TV last November, in the hopes of finding something easy to watch -to just unwind and warm my heart after work. I had zero trust in the ability of a white male, main character growing on me.

Now I strongly encourage every manager -this is something my own, dear leads have heard me saying a couple times already- to w…

Read more

Most of my career in Tech has developed in startup companies, and same goes for my partner and a number of close friends. This means that we had a chance to thrive fast, develop ourselves in versatile roles and witness startup graduations to scaleups or even exiting. Unfortunately, it also means that we had the chance to experiment business failure.

Read more

I woke up today to the news of the firing of Esther Crawford from Twitter.

Esther went viral some weeks ago, after Elon’s takeover of the blue bird network, after a photo was posted featuring her sleeping on the office floor. She quote-retweeted it, stating this was her way to support her team pushing through to make a deadline.

Read more

Towards the end of 2019 I committed to myself to keep pushing in this particular skill during 2020 (and to finally finish my Web Development studies). I didn't jump into #365daysofcoding or any similar challenge, because a), exercises that enforce me into this kind of discipline look revolting and closed-minded for my type of brain and b), failing at my…

Read more

Becoming a manager === receiving a promotion

Boy, this one I wish someone had explained to me beforehand. I thought that "becoming a manager" was an effective promotion in a particular field of work. The way …

Read more