Categories
development leadership

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.


Categories
development leadership

Unsuccessful Teams

Are you making space?

Game Outcomes

In a previous post, I looked at how to create successful teams, and looked at the Game Outcomes project as a useful formulation.

Some of these points are about avoiding negatives and that’s what I want to focus on here.

The most important indicators for success from the Game Outcomes project are:

  1. Great game development teams have a clear, shared vision of the game design and the development plan and an infectious enthusiasm for that vision.
  2. Great game development teams carefully manage the risks to the design vision and the development plan.
  3. Members of great game development teams buy into the decisions that are made.
  4. Great game development teams avoid crunch (overtime).
  5. Great gamedev teams build an environment where it’s safe to take a risk and stick your neck out to say what needs to be said.
  6. Great gamedev teams do everything they can to minimize turnover and avoid changing the team composition except for growing it when needed. This includes avoiding disruptive re-organizations as much as possible.
  7. Great gamedev teams resolve interpersonal conflicts swiftly and professionally.
  8. Great gamedev teams have a clearly-defined mission statement and/or set of values, which they genuinely buy into and believe in. This matters FAR more than you might think.
  9. Great gamedev teams keep the feedback loop going strong. No one should go too long without receiving feedback on their work.
  10. Great gamedev teams celebrate novel ideas, even if they don’t achieve their intended result. All team members need the freedom to fail, especially creative ones.

Confounding factors

Overtime and crunch

Deadlines are good, to a point. It helps focus. With a clear goal and a timebox it’s much easier to discard sandbags and maintain motivation. Many personal productivity schemes rely on setting yourself deadlines.

When those deadlines are too restrictive however the product will suffer. Teams will work late and produce lower quality work. They will cut corners. If time is fixed then either scope or quality or both need to be cut.

Unplanned or persistent overtime is a critical bug and needs to be prioritized as such. There’s no such thing as completely bug-free, but you should always be aiming for zero.

Mono-cultures and silos

Cross-functional teams make better decisions faster. That’s a lesson I learned the hard way. The consumer of the API should sit in the same room as the producer. Even better, at the same desk, or in the same chair.

It’s not just technology silos that cause problems. If your team is a straight cis able-bodied English-speaking white male silo, or functionally equivalent to one, then it will fail at every interface with someone outside that group. Widening your team doesn’t stop those failures, but if you manage the team properly, the failures are fixed within the team (with the goal of fixing them before the code is written) rather than experienced by consumers.

Diverse teams are also more creative.

Inter-personal conflict

Teams don’t shy away from conflict. Open discussion, even a heated one, clears the air rather than letting micro-vexations and micro-aggressions become the norm and harm the team, one papercut at a time.

Successful teams solve disagreements in the open. People first, then process after, to remind everyone of decisions made.

Punishment driven development

Feedback is great. Tracking progress is useful. But please be sure you are tracking the right thing.

I can’t say this any better than Louise Elliot, who talks about all the ways measuring the wrong thing can seriously affect a team. Video is below, but you can also listen to her talking about Punishment Driven Development on the .Net Rocks podcast, if that’s more your style.

Are you unsuccessful?

What dysfunctions have you seen in your teams now or in the past? How have you fixed them, or how will you?

Categories
development google leadership

Successful teams

Successful teams deliver successful projects. As a lead, how do you build a successful team?

There are many factors to build a successful team, but the foundation of them all is safety. Can problems be discussed openly? Does everyone trust everyone else? And once you have that, the team can build. Build diversity, build towards a common goal, and build something that matters.

Successful Google team

Google defines successful teams according to its research at https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/

Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
Dependability: Can we count on each other to do high quality work on time?
Structure & clarity: Are goals, roles, and execution plans on our team clear?
Meaning of work: Are we working on something that is personally important for each of us?
Impact of work: Do we fundamentally believe that the work we’re doing matters?

I accept, given multiple ongoing accusations against them about defending toxic managers and culture, that Google may not be living these values. However, these are clear statements that are supported by other studies such as The Game Outcomes project.

Penguins at Edinburgh Zoo

So how do we build a team like that?

Number one thing, and the only way I’ve found success, is to empower the team and everyone within it to make changes. Without that ownership, nothing matters.

Once you have that, you as the leader have to own the rest. Delegate where you need to, but own your team’s safety, support, direction, purpose and motivation.

Safety

Are you free to take risks and try something new?

Not everything you do will be a success, so do you celebrate knowledge and learning as a goal? Yes, that cost us time and money, but we learned not to do that again

Are team members supported? When someone mansplains your tech lead, do you correct them, and ensure her voice is heard? When a deaf developer joins the team, do you ask whether they prefer lip reading or sign, and help the team adapt appropriately? Do you recognise colour? Do you use preferred pronouns?

When mistakes are made, do you find someone to blame or do you all accept responsibility to address it? If the production database can be deleted by the graduate on their first day, and there are no backups, that is never their fault.

Creating Psychological Safety in the Workplace https://hbr.org/ideacast/2019/01/creating-psychological-safety-in-the-workplace

High Quality

Do you always have an high standard?

Everyone has their code reviewed, especially the lead. Is every line of code, and every process open to review and improvement? Great that you’re agile, but if you really value people over process, write the process down, and follow it. It doesn’t mean no process, it means that process serves the people, not the other way around. It means you change it when it no longer supports the people or the product.

What are your quality standards for code, for user experience, for security, and most importantly for behaviour? How are they enforced? And are they always enforced on time, every time?

Have policies. Do not have a daily fight over tabs vs spaces.

Direction

Ask everyone on your team what the team is building. If you get more than one answer, that’s a bug.

Ask everyone which part everyone else on the team plays towards that. Does that match how they see their role? Are there any gaps in responsibility?

Ask everyone what their priority is and why. Is anyone blocked? Ask them what their next priority is and if they have everything they need to fulfil it. If not, do they know where to get it?

Purpose

Is everyone bringing their whole self to work? Do office politics make them wary? Are they in a marginalized group and they have to bring representation as well as talent, and they are having to do both jobs at once?

At the office, is this the number one thing for them to be doing? Are your developers feeling stuck in support or BA? Are they frustrated that they aren’t allowed to refactor a gnarly piece of code that’s very open to be improved because “it works, don’t touch it”.

Does everyone on the team feel empowered to speak up and to fix things where they interfere with the goal of the team?

Motivation

Ask everyone why the team is building what they’re building, and why their part is important.

How will this change the user’s day? How will it affect the company? What’s the net improvement?

The Game Outcomes formulation

If you don’t like the Google formulation, try the game outcomes one. There’s plenty that applies to non-game projects. There’s a few negatives to avoid, and I’ll revisit them in a later post.

The most important indicators for success from the Game Outcomes project are:

  1. Great game development teams have a clear, shared vision of the game design and the development plan and an infectious enthusiasm for that vision.
  2. Great game development teams carefully manage the risks to the design vision and the development plan.
  3. Members of great game development teams buy into the decisions that are made.
  4. Great game development teams avoid crunch (overtime).
  5. Great gamedev teams build an environment where it’s safe to take a risk and stick your neck out to say what needs to be said.
  6. Great gamedev teams do everything they can to minimize turnover and avoid changing the team composition except for growing it when needed. This includes avoiding disruptive re-organizations as much as possible.
  7. Great gamedev teams resolve interpersonal conflicts swiftly and professionally.
  8. Great gamedev teams have a clearly-defined mission statement and/or set of values, which they genuinely buy into and believe in. This matters FAR more than you might think.
  9. Great gamedev teams keep the feedback loop going strong. No one should go too long without receiving feedback on their work.
  10. Great gamedev teams celebrate novel ideas, even if they don’t achieve their intended result. All team members need the freedom to fail, especially creative ones.

How do you keep your team on the right path?

We all want to work on successful projects, and there’s been a couple of times in my career I’ve been lucky enough to work in a team where everyone is delivering 10x. 10x developers don’t work in isolation, they work on teams where all the above needs are met, and they thrive off each other.

It’s great to have that dream team, but start by thinking about how to make your team reliably successful, and you’ll be doing better than most software teams.

Categories
development leadership

Leadership by example

Are you a manager or a leader?

What behaviour are you modelling for your team? Do you send many emails out of hours? Do you multitask in meetings? Do you project frustration and disagreement with C-suite?

Do your team copy you?

If you send emails that late, an expectation will be set that everyone needs to check, unless you are clear why. Tell them you have to leave a hour early to do the school run every day, so you do your emails after bedtime for everyone to pick up in the morning. Even better, write at night but don’t send until the morning. There are plenty of tools to schedule that for you.

If you’re not focussed on a meeting, how can you expect your team to be. If you don’t need to be there, don’t be. If you trust your team and you won’t add value, step back. If you can change the meeting so it’s not boring, do that. When you’re in the meeting, be present, even if it’s just too watch the body language, and engage with that, use that feedback.

Are your team frustrated by decisions and often blaming others? Is that because you do it too? You’re not going to agree to every decision, but if you were on the room when it was made, or it’s your job to disseminate it, be at peace with the decision. If you can’t live with it, there’s other channels, up to and including leaving, but on your team decisions should be respected. They can be debated, reviewed and changed when circumstances change, but if decisions can’t be respected collectively, you don’t have a team.

Are you being the leading the team in the way you want them to work?

Categories
code development leadership

Tribe of Mentors – 11 questions

I’ve been listening to the Tribe of Mentors podcast by Timothy Ferris and in the related book, he talks about the 11 questions he sent out to get people to respond. He’s got a great discussion about how he refined the questions, and why he chose those questions in that order, and I’d recommend checking out the book and the podcast. I thought it would be interesting for me to answer them. If I’m going to write a blog, I should give you some insight into who I am.

The questions he asks all his interviewees are:

What is the book (or books) you’ve given most as a gift, and why? Or what are one to three books that have greatly influenced your life?

What purchase of $100 or less has most positively impacted your life in the last six months (or in recent memory)?

To give me a significantly more productive commute:

  • I have a small notebook that I can carry in my pocket, from my local supermarket;
  • A cheap bluetooth earphone for listening to podcasts, which is good for voice, but not great for music;
  • Pocket casts for managing my podcasts. I also set it up to auto-play whenever I turn by earphone on.

How has a failure, or apparent failure, set you up for later success? Do you have a “favorite failure” of yours?

Deleting a database

If you could have a gigantic billboard anywhere with anything on it — metaphorically speaking, getting a message out to millions or billions — what would it say and why? It could be a few words or a paragraph. (If helpful, it can be someone else’s quote: Are there any quotes you think of often or live your life by?)

“Do not compare yourself to others for you may become vain or bitter. There will always be greater and lesser persons than yourself.”

Desiderata, Max Ehrmann

What is one of the best or most worthwhile investments you’ve ever made? (Could be an investment of money, time, energy, etc.)

My PhD. I learned discipline, I took the opportunity to learn lots of new technologies, and to sit in on some random lectures.

What is an unusual habit or an absurd thing that you love?

I love weird films and music, such as Trout Mask Replica, Eraserhead. Things that I don’t choose all the time, but reset my expectations about what art can be. It’s always good to get a refresh to help my problem-solving and avoid getting stuck in a rut.

In the last five years, what new belief, behavior, or habit has most improved your life?

Regular blogging. It has helped me to crystallise my thoughts; share ideas with others, and my future self; and led to some great conversations.

What advice would you give to a smart, driven college student about to enter the “real world”? What advice should they ignore?

It’s OK if it takes you a few years to find the right job for you. It’s ok to have a few jobs on your CV if you have a reason to move. Treat them as a chance to find out who you are, and don’t let golden handcuffs make that decision. Bank the cheque in case you need a parachute.

Don’t work on your free time to get a job. Do what you enjoy. Climb hills. Practice the guitar. Volunteer at the hospice. Spend time with friends and family. Jobs that require you to learn on your own time are jobs that don’t respect you.

What are bad recommendations you hear in your profession or area of expertise?

April Wensel covers this better than me. I felt an unease about things, but April Wensel managed to capture it much better than I could. Don’t be a hero. Be a team player. Don’t follow these toxic tips.

In the last five years, what have you become better at saying no to (distractions, invitations, etc.)? What new realizations and/or approaches helped? Any other tips?

I became a dad during this period, and time has become far more precious as a result. Family comes first. So less TV in the evenings, more time with my daughter, more together time with my wife. Less news, less shouting at the TV. If it’s not something that I’m passionate about, or will help my family, me or my friends, I can’t justify the time.

When you feel overwhelmed or unfocused, or have lost your focus temporarily, what do you do? (If helpful: What questions do you ask yourself?)

Go back to my task list. What’s the best thing to do now that my future self will thank me for?

Categories
development leadership

CodeCraftConf follow-up : notes on growing a team

Whilst I have a few thoughts I’m still processing after the whirlwind of fantastic insights I got from CodeCraftConf, I wanted to capture some of the highlights from some of the answers to my questions on Growing a Team.

Many thanks to everyone who came to the session. Lots of thoughts coming out of the conference.

When is it time to grow your team?

  • You never grow a team, you create a new one.
  • There’s always too much work, you should grow when you have capacity, so you don’t put new starts off

How do you deal with resistance from existing team members?

  • Communicate clearly and address concerns (e.g, time to mentor)
  • Involve team early
  • Do you have a choice who joins?

Is it more important to find a culture fit or build a diverse team?

  • Do candidates know what they’re signing up for?
  • Introvert vs extrovert (see also hiring practice)
  • Interviews should be structured to filter out arseholes – do they have empathy (or have they been taught to suppress it)
  • Every new hire should bring the level up
  • Don’t just hire for technical skill
  • Diversify your interview pool

What is your biggest worry with your current team size, or with growing your current team?

  • Are you doing Health Checks? Survey staff regularly
  • Make sure the bigger team, outside your daily work, understand the culture – it only feeds from top down
  • Fear of churn
  • Loss of culture
  • Try to understand
  • Make the culture explicit

What practices do you use to ensure sustainable growth?

  • Pair a lot, reflect (e.g. retro)
  • face-to-face regularly, even if it’s video
  • Values workshop – does everyone share them?
  • Social convenor to ensure cohesion
  • Slack channel dedicated to positive feedback on living the values
  • Office/company changes should have their own backlog with an open grooming process so priorities are explicit

How long does it take to integrate someone new?

  • Be careful about language
  • Train everyone in personal skills
  • Listen even when you disagree
  • lack of ego
  • Culture changes people
  • What personalities do you want?
Power corrupts
Categories
development leadership

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?
Categories
development leadership

Sometimes the greatest challenge of leadership is making your boss understand what you do all day

Everyone loves a maverick. The one who bends the rules, who gets the job done. Who leaves fireworks in his wake (it’s always a man) and doesn’t mind breaking a few chickens to make an omelette. The people who rescue the projects in a tailspin, who shout loud and carry a big stick.

What happens to the projects without fireworks? The sysadmins that don’t have to explain why they got breached? The project managers who don’t have to explain why they went over budget? The developers who aren’t in the office past midnight fixing bugs? The people who aren’t visible because they fix the problems before they become visible?

I grew up watching Formula 1 with my dad, in the era of Senna and Mansell. Senna was fiery, pushed the car to the limits, exciting to watch. Mansell was controlled, steady, hitting the right line, and easing the car in as if it was on rails. Senna looked like the hardest worker, but Mansell broke his run of world championships.

If you’re competent, if you get the job done, then people believe that your job must be easy. It’s not easy to beat a triple world champion. Sometimes you need to anchor your achievements in advance, so people understand the challenge in hindsight, especially if you are marginalized in the workforce such that your achievements are minimised.

The Difficulty Anchor

It’s even harder once you move into any management role, success is due to your team (and be damn proud of that success), but failure falls squarely on your shoulders. If you don’t have a strong sense of your own self worth, it can hollow you out, and leave you with nothing but a thick skin.

Take on extra responsibilities, be the consistency for the team when the powers above you are a maelstrom of confusion and musical chairs. And nothing happens.

Remove obstacles and no-one sees them.

Anchor your team’s success. Quiet, dependable successes make everyone on the team happy : no drama, no overtime. But it can be hard to show the work behind the scenes that makes it look so smooth.

It’s not just a dev problem, a good sys admin is invisible, designers struggle to prove their worth (How to Prove Your Design’s Value – Hack Design
https://hackdesign.org/lessons/57-how-to-prove-your-design-s-value?utm_source=newsletter&utm_medium=email&utm_campaign=howtoproveyourdesignsvalue ).

Market yourself. I know you hate sales and marketing, you’re happy to leave it to others, but you need to give yourself the confidence to be proud of your achievements and make sure people understand what you did. Share it with your boss and your peers (you’ll need some recognition when it comes to your appraisal). Promoting yourself is not someone else’s job. Practice it. Embrace it. Be proud.

Categories
development leadership

I’d rather be proved wrong than miss the chance to improve

One of my favourite books is Nightfall by Isaac Asimov and Robert Silverberg. The setup for the sorry is an old astronomy professor who has won his planet’s equivalent of the Nobel Prize for proving that the six suns in his solar system would never set on his planet at the same time. And night couldn’t fall.

And then his students did some calculations and realized he was wrong, and for a time every few thousand years there would be night.

They didn’t want to tell him thinking it would ruin his life’s work and leave him feeling dejected and worthless.

He got angry with them because he didn’t want to miss the chance to learn something new, and the thrill of discovery had the opposite effect to what the students expected and renewed his enthusiasm in the subject.

Renewed enthusiasm

I’m not a Nobel winner by a long shot, but the professor’s attitude embodies the way I want to work. Doing the same thing and thinking there’s nothing left to learn would demotivate me.

I love mentoring because I love learning.

When I build a team, I want people who aren’t afraid to tell me I’m wrong, when I am, because that’s what makes the team stronger. I know not everyone is confident at this at first but if I can find people who are confident in their opinions, my job is to nurture that.

If I’m not being challenged, I’m not learning. I know my experience has helped me get where I am, but I need to know where me and my team are going.

Tasks for you

If you are a leader or a mentor, embrace the opportunity to learn that you get from being wrong. Be vulnerable, sometimes, so that everyone knows it’s ok to be wrong, if you acknowledge it and make amends. Keep learning.

If you’re not, embrace your mistakes. (Link – my mistake) Next time you find yourself in that position, you’ll call it experience. Learn by doing as well as by reading. The most interesting challenges you’ll face won’t have a manual. Keep learning.

Don’t let your career go dark.

Categories
development leadership

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?