Category: Technical Leadership

Let’s Stop Making People Feel Stupid.

Let’s Stop Making People Feel Stupid.

Intro here.

There’s been a lot of interest in this talk, which I’m doing in various locations this year (details here). People have asked me to share slides, but I deliberately don’t put much content (ie text) in them, because I find it just distracts from the delivery.

So, here are some notes. And a couple of pictures of cats. 🙂

confused-cat-7-im-confus

Making people feel stupid: What does it mean?

  • People listen to what others say.
    • They overhear them judging people for not being clever enough or not knowing enough.
    • They internalise it. They worry that they will be next.

What’s wrong with me?

  • Maybe you’re quietly judging me already. Maybe you’re thinking, she’s probably not very clever and doesn’t like it when she gets exposed.
  • Maybe you’re right! I often think that about myself. But I have a maths degree, 18 years experience, I’m a tech lead with a major international consultancy, etc.
  • So, that was me imagining that you might judge me for being stupid. Maybe you did and maybe you didn’t. But the point is, I imagined that you would. Because I’m so used to people in tech judging each other for being stupid.

My story

  • I’ve always felt there was something wrong with me because I struggle to understand things unless they’re explained in simple concrete terms.
    • And yet I can do complexity.
    • I can build complex systems out of simple parts.
      • If anything, my flaw is a tendency towards too much complexity.
      • …which is why I deliberately break things down into simple parts.
      • …but I also forget complex terminology – I recall easier-to-remember equivalents instead.
    • I have missed out on jobs because people were bemused by my apparent lack of expertise.
      • I have been told in interviews that I wasn’t competent because I couldn’t respond to the kind of question that requires you to have memorised stuff.

The Impact:

Impact on the industry

  • Facts, Figures, Statistics:
    • There will be an estimated 1 million more computing jobs than applicants who can fill them by 2020. This figure was projected by Code.org, based on estimates from the U.S. Bureau of Labor Statistics on job creation and separately, estimates of college graduation rates by the National Science Foundation.
    • Only 11% of employers (US) believe higher education is “very effective” in readying graduates to meet skills needed in their organisations.
    • Some 62% (US) said students were unprepared.
    • US: There are more than 500,000 open computing jobs nationwide, but less than 43,000 computer science students graduated into the workforce in 2016.
    • In 2016, the White House claimed the federal government alone needed an additional 10,000 IT and cybersecurity professionals.
    • Source, March 28th 2017: https://www.usatoday.com/story/tech/talkingtech/2017/03/28/tech-skills-gap-huge-graduates-survey-says/99587888/

Impostor syndrome

  • Hands up if you feel like other people are cleverer / doing things better than you?
    • Impostor syndrome: “Somehow everybody has failed to notice how rubbish I am.”
  • I hate – am almost incapable of – playing the game where everything is obfuscated and translated into a language that only the elite can understand.
    • Ironically this means that my impostor syndrome is at least partially based around the fact that I don’t seem capable of doing the things that entrench everybody else’s impostor syndrome.
  • I can hit the ground running, but I keep forgetting.
    • I have to prove it to myself over and over again.

Scenario A: Meeting where people talk jargon & nobody understands

  • Me: Hi, sorry I’m late.
  • Them: It’s fine, we were just talking about the ARM processor.
  • Me: Ah right, yes of course.
    • Shit, ARM, I know I’ve heard of that before. ARM, um…
    • [some stuff I don’t hear cos I’m trying to remember what ARM stands for]
  • Me: “Look folks, I’m so sorry, but I’ve forgotten what ARM stands for?”
  • Them: “Articulated retention matriculation.”
    • Me: I have NO idea what that is. I’ll work it out as I go along.
  • Somebody else: Actually guys, I think we should be considering AMRM at this point.
  • Me: AMRM?
  • Reply: Articulated meta-retention matriculation.
  • [someone else, not me]
    • That’s a very good point! We definitely need to get meta at this juncture.
    • Oh God, I was only just following this, but now they’ve lost me. Meta? What does meta mean in this context? What does meta mean in any context? It’s one of those terms that always confuses me, I know that much.
    • Oh well, I said juncture. I love saying juncture. It’s the perfect word for situations like this.
  • [some stuff that Person2 misses cos they’re worrying about what meta means]
  • Etc

Diversity and Inclusion

  • People want to fit in.
    • Two effects:
      • They use jargon to create a shared identity.
      • They feel bad if they feel like an outsider.
    • People will leave, or not join in the first place, because they feel excluded.
      • This disproportionately affects under-represented groups.
    • Stereotype threat: https://en.wikipedia.org/wiki/Stereotype_threat
      • “…men in STEM subject areas overestimate their own intelligence and credentials, underestimate the abilities of female colleagues, and that as a result, women themselves doubt their abilities — even when evidence says otherwise.”
      • Stereotype threat has been shown to reduce the performance of individuals who belong to negatively stereotyped groups.
      • If negative stereotypes are present regarding a specific group, group members are likely to become anxious about their performance, which may hinder their ability to perform at their maximum level. Importantly, the individual does not need to subscribe to the stereotype for it to be activated.
      • It is hypothesised that the mechanism through which anxiety (induced by the activation of the stereotype) decreases performance is by depleting working memory (especially the phonological aspects of the working memory system).

Talking in jargon

  • These insecurities cause people to increase the amount of jargon they use.
    • They want to prove how clever they are.
    • Their colleagues struggle to understand them, but they pretend they do, to avoid looking stupid…
  • Complex impenetrable language is what people deploy as a kind of force field
  • Weird vicious cycle: everybody obfuscates to protect themselves from potential exposure as somebody who doesn’t fully understand.
    • In the process they confuse everybody around them, who in turn become terrified that somebody is going to notice that they don’t fully understand what’s going on, so they join in the game, make everything they say sound complicated, and so the cycle continues.
  • There does come a point where you’ve been immersed in it for long enough that only some of it is confusing, and some/most of it makes sense.
    • That’s quite a kick!
    • You have to pay your dues to get to that point, and it feels good. You feel special.
    • So you pull the ladder up behind you.
    • You had to go up it, and so should everybody else.
    • You’re in the club now, and you want to savour that.
    • So you join with your new comrades in mocking those who still haven’t arrived.
    • You make no concessions in your language.
    • You’ve learnt what it means! It was hard! Why would you waste all that hard work and abandon your hard-won vocabulary by explaining things in simple terms?
    • Explaining things in simple terms takes twice as long anyway.
  • Giving the answer you think people want to hear:
    • The hairdresser asked me whether I had straighteners and I answered Yes. Why? Because I felt like it was the “right answer”. I don’t have straighteners. I’m never going to manage this labour-intensive haircut I’ve been given.

Scenario E: When talking jargon feels good

  • I felt all pleased with myself recently when I worked out how to join in with a hangouts conversation by using words like “discoverability” and “distinguishable”. I felt less insecure, and like I was now a proper grownup, a member of the club. But meanwhile there may well be somebody somewhere hearing nothing but “blah blah blah”…

Reasonable reasons

  • Is it sometimes ok?
    • “I can’t spend my whole time teaching people, I need people who can hit the ground running.”

Unreasonable reasons

  • Many people project a sheen of knowledge.
  • Many limit themselves by seeking to preserve knowledge once they find it.
  • People focus on their own experience – making themselves look good.
    • But when they look at someone else, they have a different agenda.
    • They don’t stop to wonder whether they have ever said anything “stupid” like that themselves – and if they did, WHY?
    • Or they remember it full well and don’t want anyone else to remember, so distract attention by joining in with the attackers.
  • We identify the things we CAN remember, then we fetishise them.
    • We push them over alternatives.
    • Not necessarily because they are better – just because we feel more comfortable there.

Definition of competent

  • What really impacts on you and your team?
    • Is it lack of knowledge?
  • What does it actually take to be good at your job?
    • What is the definition of competent?
    • What is the definition of intelligent?
    • “Be curious. Read widely. Try new things. What people call intelligence just boils down to curiosity.” – Aaron Schwartz.

People who are not techies are impacted too

  • Examples of support staff, stakeholders, non-technical people… being made to feel stupid.

My personal experience – the happy story

  • How I learnt to attack new knowledge outside my comfort zone.
    • The irony is that my career – and my enjoyment of it – has improved dramatically since I started admitting ignorance.

Why Empathy is so Important

  • “They only care about making themselves look good.”
    • This in itself is judgmental.
    • Think about how it feels like to be them!
  • You can find yourself alienating others without ever having conscious malicious intentions.
  • Other people know other stuff.
    • Two effects:
      • One: When they know stuff you don’t, you feel insecure.
      • Two: When you know stuff they don’t, you can get impatient.

Conclusions / Advice

  • Maybe you see me as an idealist. Or maybe I’m a pragmatist. Over the years I’ve paid attention to what works in life and what doesn’t. What makes people ill, what doesn’t. These are all practical hints for survival.
  • Does it actually matter how much people know? Industry constantly moving, people forget stuff.
  • Some of the most important moments in my career have been the times I’ve realised that my colleagues are also confused.
    • Eternal thanks to those that admitted it.
    • People are often scared to admit confusion.
    • I often don’t know what I’m doing.
  • The range of knowledge in our industry is VERY WIDE.
    • Don’t expect other people to know what you know, and vice versa.
  • People forget things they once knew.
  • If people don’t know enough, WHY is that? What’s deterring them?
  • What would happen if we changed the rules?
      • Focus on aptitude – recruitment becomes easier.
      • Encourage people to explore and experiment and learn WITHOUT RISK.
        • Stops people pushing less optimal solutions.
      • Make explicit statements to newcomers to your team, at start of meetings, etc – have a policy towards curiosity – keep repeating that simple questions are ok, that mistakes are ok, that if somebody doesn’t know something it’s in the interests of the whole team to help them learn. Plus, active encouragement to give feedback if these aims are not being met.
      • Tweet from Tim Post (@TinkerTim) re Stack Overflow:
        • “You can’t work on problems that you’re unwilling to admit. Wanting help often means being vulnerable enough to ask for it, and that’s where we are. Let’s keep making the internet better, without hurting people in the process.”
      • WE SHOULD ALL ENCOURAGE PEOPLE TO ASK QUESTIONS.

    The Stupid Manifesto

    LET’S STOP MAKING EACH OTHER FEEL STUPID. INSTEAD, LET’S…

    • Have an explicit policy of curiosity towards all things
    • Encourage each other to shout out if we discourage curiosity
    • Ask what people NEED to know, not what they know
    • Never judge someone because their knowledge doesn’t match ours
    • Give our colleagues every opportunity to learn and explore WITHOUT RISK
    • Give new people a chance to show us what they can do
    • ENCOURAGE EVERYONE TO ASK QUESTIONS
    • Acknowledge the broad range of knowledge in our industry
    • Remember our industry never stays the same
    • Remember we all forget stuff
    • Lead by example: Be honest when we’re confused
    • Focus on aptitude, not knowledge
    • Remember what it feels like when we are still learning
    • Prioritise clarity over jargon
    • Remember this is not idealism, it’s pragmatism
    • LET’S STOP MAKING EACH OTHER FEEL STUPID.

     

    Useful resources and references:

confused-cat-10-dafuq

Let’s Stop Making People Feel Stupid.

Let’s Stop Making People Feel Stupid.

(Image / comic by xkcd: https://xkcd.com/1053/)

“I know nothing.”

“I know less than nothing.”

“I am an impostor.”

“The more I learn, the more I realise how little I know.”

These are sentences that will be familiar to the vast majority of IT professionals. But how about these?

“They know nothing about X.”

“They have no relevant experience.”

“Wow, I just discovered my colleague doesn’t understand Y. I’m shocked.”

“Can you believe, I just interviewed this dev, and they didn’t even know what a Z was?”

Over my 18-year software career, those last two have been said to me countless times. They are said derisively, scornfully, impatiently. And every time those words are said, we lose both existing and potential members of our profession. We lose them because they feel stupid; because they believe they can’t keep up; because they have given up on ever really knowing what they’re doing; because they’re terrified that people are saying the same things about them.

We work in an industry where knowledge is highly valued, and where every time we look for a new job we have to prove how much we know. We find ways of posturing to one another, of proving how well-informed we are. Sometimes we join in when others’ knowledge is criticised – relieved that we are not the target ourselves.

And yet, we know that everybody has gaps. There are a million different paths through software development, touching a million different combinations of technologies and skills. On a day-to-day level we have to specialise on one task at a time. The skills we don’t need right now are necessarily forgotten, or delegated to someone else. And that’s fine.

If somebody already feels like they don’t “fit in”, then this kind of pressure and insecurity can be the final shove that persuades them to leave the profession or not try and join in the first place. Women and non-binary people, people of colour, older people, LGBT people and many other under-represented groups are strongly impacted by intellectual elitism. But of course, ALL software professionals are impacted.

Let’s stop putting pressure on individuals to know everything, and focus instead on how teams can work together to build and provide the unique combination of skills required to deliver their current project – in the certain knowledge that whatever that combination was today, it will be different tomorrow.

Instead of knowledge, let’s focus on aptitude. Instead of judging people about what they don’t know, let’s help them to feel excited about all the new things they’re going to discover.

Instead of saying “For God’s sake, do you really not know about X?” let’s say “Fantastic, you don’t know about X! Lucky you. That means you get to learn it. What can I do to help?”

(I’m hoping to do talks on this topic at events in 2018 – let me know if you have an event you’d like me to talk at).

Fighting Procrastination (in solidarity with all teachers everywhere)

Fighting Procrastination (in solidarity with all teachers everywhere)

I used to be a high school maths teacher. It didn’t go well. I miss the energy and creativity of the young people I worked with, but apart from that I have no regrets about leaving that profession behind me.

A friend of mine has just completed his first term of teacher training, and it’s HARD. You would think that now the Christmas holiday period has started, he’d be able to have a rest. Nuh-uh. Too much work to do.

Coincidentally I’ve also been facing a giant to-do list this week, and with the festive season fast approaching I’ve struggled to stay focused. But I have various coping mechanisms, which I just shared with my teaching friend and I thought were worth preserving for my own benefit too. And if they can help anyone else (particularly teachers), so much the better:

“What you have to remember is that you’ve been working flat out for months without even the option of slowing down. Whether you like it or not, your mind and body need a rest and what’s happening right now is that your subconscious is forcing that rest on you whether you like it or not. Sadly your conscious mind knows that there isn’t really time for that rest, and that’s preventing you from enjoying it – which is a shame.

So…

1) Accept right now that the workload is impossible. Therefore it’s either not all going to get done, or some of it will have to be done to a poor standard. There’s no point lying to yourself about that. You can’t bend time. You and thousands of other teachers are in the same position and you just have to accept it.

2) Given that you’re not going to get all of it done anyway, just pick TWO OR THREE SMALL THINGS and do those. Be unambitious. Don’t tell yourself “today I’m going to do the top 50 things on my to-do list,” because that’s a lie. You’re not going to achieve that, no matter how much you hope. And you already feel shit about that, and the whole thing is so depressing that it’s preventing you from doing anything.

Instead, aim low. Tell yourself you’re going to do a small number of things. Then do them, and feel good about having achieved your goals for the day. If that glow of success gives you the energy to do a little more, fantastic. But don’t plan for that, otherwise you’re back to square one.

Baby steps. You need to get back into a rhythm. If somebody gives you a mountain to climb when you’ve just eaten ten mince pies, you’re going to tell them to sod off. But a flight of stairs? Yeah. That’s a possibility.”

POSTSCRIPT:

I just did something which I realised I often do, and may also be good advice:

I scrolled down my to-do list until I found something I could easily do. The thing in question is pretty pointless and not at all urgent. It can easily wait til after Xmas and the world wouldn’t end if I never got round to it at all. But it’s a gateway drug. It’s not only easy, it’s vaguely enjoyable. And I know that it represents an “in”, ie once I’ve done that, I’ll be in the swing of Getting Things Done and I’ll find it easier to tackle a more worthwhile item from the list.

I know from experience that if I don’t do this, I’ll just arse around on the internet and do nothing from my to-do list. So it’s better to do something slightly pointless, but knowing I’ll find it much easier to follow it with something pointful… than to do nothing at all.

Want to learn Git / improve your Git knowledge?

Want to learn Git / improve your Git knowledge?

This list is culled from a thread where people were asking for useful resources when learning Git. A lot of useful recommendations were made, so I’m summarising them here (for my own benefit as much as anything):

I ran a git workshop for some devs earlier this year – I created a repo, a bunch of exercises and some top tips. Everything you need to find your way around should be in the readme: https://github.com/claresudbery/Git-Playground

I find it very helpful to understand what the definition of a branch is: it’s just a commit, which defines the current head of the branch …and that allows you to explain the concept of “detached head”.

I would also encourage people to dig a little into the gitconfig folder and understand what diffs and commit IDs are all about.

Criteria to Apply to Third Party Vendors

When assessing third-party products to purchase their software products:

  • Products need to be cloud native, extensible, and use open standards for integration.
  • How quickly do updates move from development to production? Do they use CI?
  • What do their processes look like?
  • What sort of extensions do they provide?
  • Do they allow you to customise a product without going off the upgrade path?
  • How will you migrate your existing data to the CRM solution?
  • Is data security guaranteed?
  • Does the solution have regulatory compliance?
  • Can you have a single central identifier for each customer, that can be used across systems?
  • How will communication happen between systems?
  • Does the vendor give good support?
  • Are their APIs fit for purpose?
  • Will they give you all the access you need?
  • Will they respond quickly to attempts to communicate / collaborate?

The Tech Lead’s New Project Checklist

These are my notes from a session on what a tech lead needs to do and know when arriving on a new project. The wisdom came from @JimBarritt at Thoughtworks – I am just the conduit.

Note that this list applies both to projects that existed before the tech lead arrived, and those where the whole team / product is new.

The first two are apparently “the two most likely causes of death or injury”:

1) Infrastructure

  • Where’s the production environment? It’s the most important one! What does it look like? When will it be ready? (Development environments are an afterthought after prod)
  • How are we going to go live? What’s the plan?
  • Load balancers
  • Firewalls
  • Certificates

2) Third parties

  • Integration!
  • If environments beyond your control are chaotic, it’s even more important to make sure your own environment is super-organised and disciplined, smooth, automated, with good scope planning, etc

3) Find the movers and shakers

  • Find all the people who can say No, and the people who hold the purse-strings/can sign off budgets, and the people who can say “Yeah, you did a good job” and get to know them
  • Eg:
    • Architects
    • The person who has control over data protection (Beware “organisational scar tissue”)
    • In the public sector, the SIRO (Senior Information Risk Officer)

4) Find any top-level documentation of your team’s work, read it and understand it

5) What’s the budget and the value proposition?

  • How well defined is it? Why are you doing the work? What’s the vision? Do people understand it?
  • Once you find this info, be really repetitive about it
  • If there are assumptions which are crucial to the whole success, keep repeating them at the start of every showcase

6) Try to have a one-to-one with each person in the team

  • Try to understand what their goals are, particularly on the project – and be transparent about your own goals. For instance if you have areas you want to move away from, find people who are keen to move INTO those areas
  • What are their main pain points and blockers?

7) Befriend a project manager and get to understand how they manage budgets

8) If there are multiple teams, find and get to know the other tech leads

9) Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead

  • There is often a tension between these three areas
  • Build relationships with these people
  • All three should be present for all decisions, otherwise it’s likely to be skewed
  • Tech leads can sometimes get a bit side-lined in these relationships

10) Backlog: make sure the scope is clearly structured

  • Use story trees and backlog hierarchies
  • People can struggle with higher levels of grouping / scale
  • You need to get into the helicopter, go up and look down on the thing you’re building

11) Code:

  • Make sure you have access to it
  • Remain connected to it
  • Get a couple of the devs to give you a guided tour
    • Can be particularly illuminating to get newer team members to do this
  • You need to be able to visualise the entire code base (overall architecture)
  • How easy is it to run it from scratch for the first time?

12) What are the pain points and blockers?

  • Project manager is good person to talk to about that

13) Cross Functional Requirements

  • Resilience & scalability
    • Is it going to fall over with the load
  • Security
    • Is someone going to break into it?
  • Automation
    • Although automation is awesome, don’t fall for the trap of thinking you have to set everything up at the start
    • Don’t necessarily prioritise automation – but do prioritise what you need to actually deliver something
    • Once you have something up and running and iterating, it’s all good – but how do you break that initial blank sheet of paper?
    • You want pipelines etc, but as a principle, maybe there are different laws of physics right at the start of a project
    • Don’t spend six weeks building a pipeline with no actual deliverable – make sure you have something iterative
    • Imagine this product that you’re building… imagine you’re doing it with no software at all. Then bring the computer into it, and ask why – what is it going to give you? Where can it give you the most value? Don’t add stuff you don’t need
    • Imagine a walking skeleton in business terms – for instance, delivering whisky by physically posting it*. Your deployment walking skeleton can be over the top – only automate something when you need it
    • It’s a subtle art though – you don’t want to end up with tons of tech debt
    • You can spend a bunch of time working out the concept without having the capability.
    • Could have a simultaneous technical alpha – looking at cross-functional requirements etc
    • Try a walking skeleton of the architecture – a “scale model”

14) As a tech lead, what things are scaring you most about this project?

  • Do a futurespective graph with time on the x axis and clouds of uncertainty. If the cloud is really close and has a lot of lightning coming out of it… pay attention to it!
  • This is partly about risk management

* Whisky idea inspired by JK Werner.