Get uncomfortable

This blog is about technical topics and being a technical lead. Understanding architecture is part of it, but if you don’t reflect on understanding people then you will never be a leader. I don’t have all the answers but it starts with accepting you can learn from others, and some of what they share will not fit with your current world view. Be ready to tear down and rebuild some foundations if you’re a technical person willing to become a leader. In the spirit of learning I’ve included the original tweets at the bottom for context so you can see the rest of the conversation.

Data needs the right questions

I trust science, so data beats anecdotes, but once I started to listen to people’s stories, I realized the people collecting the data weren’t asking important questions. “How many women applied for this job?” “How many targets of violent crime are gay?” “Are black men targeted by stop and search?” Some of these questions now have better answers, but there’s still a lot of questions that don’t even occur to people to ask.

I learned a lot from my wife in that respect – the importance of qualitative research to make sure you’re asking the right questions. But qualitative is “soft science” so isn’t as well respected, despite being fundamental to getting it right. Sound familiar?

And then you have to ask why the data isn’t collected? Is it a blind spot, or do people earnestly not want to know because then they’d have to face up to uncomfortable truths that their image of themselves does not match how others see them? Our egos are fragile, which is why I have to work hard and compassionately with new developers to understand ego-less code and collective ownership. Vulnerability is hard, especially for men in tech, and that manifests itself in many defensive micro-agressions.

I’m not going to talk about toxic masculinity here, but please go watch The Mask You Live In to hear a US perspective on how “manning up” is creating a toxic environment.

Code needs the right questions

Yeah, code is for solving the problems you know about, but how do you solve the problems you don’t know about?

If someone calls you a snowflake, or an sjw, just for asking a question, there’s a very important reason they don’t want you to ask that question : they’re scared of the answer.

Let’s be clear, science and data matter, otherwise the opinion of some white guy who can’t keep his job at Google is worth as much as someone who has collected, reviewed and summarised all the data. But we all need to be sure that the right data is collected and the right questions are asked.

To be honest, I started down this path because I saw my friends were hurting, and they helped me understand homophobia, and then I started seeing where everyone else was disadvantaged. Having a friend to guide you is the best way to open your eyes.

Why should you change? Because “we’ve always done it this way” is the worst justification for anything. Because if you find out something is broken, it should make you uncomfortable. And if you think nothing is broken then you shouldn’t be writing software and fixing problems.

Make space

This isn’t about feelings, or political correctness or any of that. This is about you doing your job, understanding the domain that the technology you create sits within. It’s about bringing your full self to work, and making sure everyone else on the team has that opportunity too. And if they don’t want to talk about what they did at the weekend, that’s their choice too.

If you can’t make space to accept that other points of view are valid, that technology mediates access and knowledge, and your code will directly impact someone’s ability to access that, you should not be in this industry. Make space for someone who gives a shit about the users, and the wider community affected by every decision you make in every line of code you write and review, and every interaction associated with that code.

Is it exhausting? It can be. Especially at first. But you know what’s really exhausting? Fighting… technology…

Every

Step

…

Of

…

The

….

…

…

Way.

Don’t accept the status quo

Don’t be the developer that makes their colleagues rage quit. Or makes the users curse their every day stuck because you didn’t ask the right questions.

Did you test your facial recognition on black faces?

Can blind people order pizza on your website?

Is every woman on your team made of regular polygons and has regular periods?

Question everything. The truth is out there if you care to look. Other people should not be alien to you.

---

I just talked about @jsconfeu. The value of the mixed methods (quantitative and qualitative) research approach to collecting and evaluating data to guide business decisions. It takes both to ensure that products and services meet customers and client needs #causeascene https://t.co/Zgxl2Hjmss

— Kim Crayton 🏢 💻🎙#causeascene (@KimCrayton1) June 5, 2018

Learned a lot from my wife in that respect – the importance of qualitative research to make sure you're asking the right questions. But qualitative is "soft science" so isn't as well respected, despite being fundamental to getting it right. Sound familiar?

— craignicol (@craignicol) June 5, 2018

I trust science, so data > anecdotes, but once I started to listen to people's stories, I realized the people collecting the data weren't asking important questions. "How many women applied?" "How many targets of violent crime are gay?" "Are black men targeted by stop and search?

— craignicol (@craignicol) June 5, 2018

Yeah, code is for solving the problems you know about, but how do you solve the problems you don't know about?

— craignicol (@craignicol) June 5, 2018

If someone calls you a snowflake, or an sjw, just for asking a question, there's a very important reason they don't want you to ask that question : they're scared of the answer.

— craignicol (@craignicol) June 5, 2018

Let's be clear, science and data matter, otherwise the opinion of some white guy who can't keep his job at Google is worth as much as someone who can raise a massive crowd. But we all need to be sure that the right data is collected and the right questions are asked.

— craignicol (@craignicol) June 5, 2018

To be honest, I started down this path because I saw my friends were hurting, and they helped me understand homophobia, and then I started seeing where everyone else was disadvantaged. Having a friend to guide you is the best way to open your eyes.

— craignicol (@craignicol) June 5, 2018

Advertisement

Inclusion is not a zero sum game

Look around your office. How many people look like you? How does that compare to the people you saw on your commute, or in the supermarket? How does that compare to your users? Do you even know?

Are you making space?

How many people are struggling with mental illness? How many have accessibility challenges? How many are white, straight, cis-gender, able bodied men?

Is there a mismatch? And if so, what are you doing to change it? Are your job adverts inclusive and on inclusive sites? (hint: look at the StackOverflow developer survey before posting your job there) Do you have a network outside work that you can tap into to find new candidates?

Are you creating a safe space for everyone? Are company events open to new parents, to non-drinkers, to vegans, to women? Do people have to out themselves to attend a family day, or to avoid travel to a certain customer site? Do you support staff who need to transition? Staff who need quiet spaces? Staff who are fasting, or need non-Christian holidays?

Can your staff find somewhere to learn to sign? Or to write simplified for language learners, for those who have struggled to attain or retain language?

Which three of these questions are the most important to achieve for you this year? And how will you do it?

If you need somewhere to start, have a look at Inclusive 101 from the Microsoft Inclusive Design Toolkit, and ask yourself if that’s you, or pick an episode from the Cause a Scene podcast and listen, especially if it makes you uncomfortable.

CodeCraftConf 2018 : Successfully Growing A Team

Thanks to everyone who came to my CodeCraftConf session today, and to the organisers for all their hard work. Here’s the questions I asked, and I’ll follow up with my thoughts from the discussion.

Successfully Growing A Team

1. When is it time to grow your team?
2. How do you deal with resistance from existing team members?
3. Is it more important to find a culture fit or build a diverse team?
4. What is your biggest worry with your current team size, or with growing your current team?
5. How frequently can you add new people to your team?
6. How long does it take to integrate someone new?
7. What practices do you use to ensure sustainable growth?
8. How do you know when a team is too big?
9. How do you split a team that’s grown too big?
10. How do you grow a team when the existing members are already overworked?
11. How long is your recruitment pipeline in terms of short-term planning (getting people in the door) and long-term planning (having the right team in place for next year or 5 years?
12. How do you recruit outside your specialty?

CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.

---

As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

1. How do you keep track of your team and the company goals?
2. How does your team manage risk to and changes to those goals?
   • Pre-mortem
   • Chaos monkey
   • Agile “threw away risk register and other important documents”
3. What makes a great team?
   • People
   • Feel comfortable
   • Trust
   • Communication
   • Balance
   • Good Leader
   • Sustainable development
   • Transparency
   • Healthy Debate
   • Growth and change
   • Common Goals
   • Motivation tailored to each person
   • Rules
     • Raise concerns
     • Feedback should be timely and structured
     • Coding standards
     • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
4. What would you change about your current team?
   • Management
     • Decisions made outside the team, not taking input from the team
     • Coaching developers to talk to management
     • Wrong person promoted to lead
   • Too many rules
     • “Because we’ve always done that”
     • Needs the context of why that rule exists
   • Clear roles
   • Respect for decisions the team has made
   • No secret tasks
   • Co-located, or remote, not mixed.
   • No “them and us”
     • Manager vs developer
     • Techie vs non-techie
5. What makes you feel unsafe in a team?
   • Lack of:
     • Support
     • Communication
     • Respect
     • Goals
   • Secret genius / hero developer who does their own thing
   • Decisions made without buy-in
   • Teams without source control
   • No tests
   • Secrets
   • Success at the expense of others
   • Developers are not “resources”
     • And managers are not “overhead”
   • Fear
   • Stagnation
6. How well would your current team survive a conflict?
   • To survive, have Strong Opinions, Weakly Held
   • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
   • Avoid imbalance in workloads that lead to loading stress onto key individuals
7. Should teams change when projects change?
   • Teams should be mixed to avoid stagnation, but not completely break them up
   • Good teams can inspire others
   • Every good team cares about the product they produce
8. How does the culture of a team change as it grows?
   • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
   • Lines of communication fail, especially as distance increases.
   • Old vs new – “I prefered the company when it was smaller”
   • T-shaped individuals are better collaborators
   • Tribe structures can help by allowing multiple communication lines
9. What kinds of diversity should we seek in the teams we work in?
   • Diverse teams build diverse products
10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

CodeCraft – Architecting Teams

Thanks to everyone who came to the CodeCraft guided conversation yesterday. If you want to reconsider any of the questions yourself, you’ll find them below.

---

As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

1. How do you keep track of your team and the company goals?
2. How does your team manage risk to and changes to those goals?
3. What makes a great team?
4. What would you change about your current team?
5. What makes you feel unsafe in a team?
6. How well would your current team survive a conflict?
7. Should teams change when projects change?
8. How does the culture of a team change as it grows?
9. What kinds of diversity should we seek in the teams we work in?
10. Should we recruit to enforce the current culture or diversify it?
11. What one thing can a leader do to make a team great?
12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

Flightplan : How to run a meeting

Usually, you don’t need a meeting to make a decision. If you can do it with a quick discussion and a single follow-up email to confirm, do it.

Kick-off, stand-up and retrospective meetings are important to:

• introduce team members to each other;
• plan work and review progress; and
• set tasks for improvement.

Avoid other meetings if you can, but a well planned meeting is preferable to a long, winding email trail.

Cut your meeting time by 90%

The only goal for a meeting is “to decide and commit.” No other objective is worth meeting for.

The Acid Test

• Pick a red marker and search your agenda for terms such as “discuss,” “update,” “review,” and other non-decisive verbs. Cross them out and see what is left.
• Then put any remaining item through the following three-question test:
  • What will we do differently if we succeed in this meeting?
  • Why do we need to meet to accomplish this?
  • How will this help us further the goal of the team?

I bet that 90% of your meeting time goes away.

General tips

• In my experience, people who have met in person are far more likely to talk to each other – kick-off meetings should always be in one room (no phones, no VC, plenty of tea and biscuits) unless you have a very good reason not to.
• As short as possible, but no shorter
  • If you’re chairing the meeting, don’t be afraid of telling people to shut up, or to defer the discussion until after the meeting.
  • Book some contingency time. For a 30 minute meeting, plan for 25 minutes, for a 60 minute meeting, plan for 50, so there’s time to summarise and re-schedule for further discussion if necessary.
  • If you get through the agenda early, finish the meeting early. Respect everyone’s time.
• Have an agenda
  • And stick to it.
• Assign tasks
  • There’s a risk everyone will see a task as somebody else’s problem. If it turns out someone can’t do a task for whatever reason, it can always be re-assigned.
  • Don’t expect people to volunteer.
  • If there’s no tasks to be assigned, there’s no point having a meeting.
• Provide feedback at a specified future date
  • This is a lot more important than I expected – especially with retrospectives
  • Where the actions aren’t immediate, keep the actions visible and explicitly tick them off at the next meeting
  • If there is no next meeting, because there’s no further decisions, schedule an action to feedback results to the attendees
  • Record actions and feedback where everyone (including potentially other projects) can refer back to them so they can see when and why decisions were made.

Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

The importance of confidence

Have you ever been given a project to deliver and thought you can’t do it? That you don’t know enough, that the deadlines are too tight?

Ever felt like panicking?

Have you been on that team, and somehow still delivered, with absolute pride in what you’ve delivered, bar a few teething issues?

As a leader, to inspire your team, you need to exude confidence. Confidence in the outcomes, and in the team. You don’t deny problems or paper them over. Hiding is a sign of weakness. But the team needs confidence to deliver and they get that from you.

If you’re not confident, don’t fake it. Revise the outcomes to a scope you’re confident in. Narrow your horizon. Get answers to your doubts, and support to conquer them. When times are tough, it’s your job to set the right expectations that the team can believe in, and deliver on. It’s your job to find a clear path through the chaos. Or it’s your job to help them pick up the pieces and move on.

These are the tests of your leadership. If the team can weather the crisis, if it can keep it’s collective head whilst all about are losing theirs, then you have earned the right to be a leader.

Be confident. But be authentic.

Give yourself time to think

I’ve spoken before about how a quick time out to grab a coffee can help you get to the bottom of a problem, but sometimes you need longer. You need time to switch off and think. 

I feel guilty about just sitting and thinking, despite trying mindfulness techniques, so for me, my best thinking comes when my body is busy but my mind is free. Sometimes in the shower (and apologies to my wife for those days when I take an extra 10 minutes to think through something), sometimes swimming, sometimes mowing the lawn.

Take time to get bored. Boredom is not boring. Boredom gives you ideas.

Read these…

• in praise of boredom – Why boredom is anything but boring : Nature News & Comment 
• How being bored out of your mind make you more creative 

Action is good, thinking then acting is better. Make time to think.