Categories
leadership

If it hurts, stop doing it: the wrong process



If something is painful, should you do more of it? Not if it’s painful because you have the wrong tool.

Sometimes though, it doesn’t matter what the tool is, there’s something more fundamental at play. A process that exists only because one thing went slightly wrong years ago. And rather than implementing a process to correct mistakes, somebody tried to prevent them.

Just like technical debt, this process debt adds pain to every feature, every bug fix, or every release. That pain can be removed by removing the process.

It’s painful because you shouldn’t be doing it

Does your test plan or your requirements sheet still specify IE as a supported browser? If Microsoft doesn’t support it why should you?

Are you spending all your time monitoring your staff, making sure they’re working when they’re not in the office? Do you struggle getting the right reports? Do you feel resentment from your staff even though it’s in their best interest? Or have you tried trusting them?

Is every release delayed because the database team and the security team have to review all code, and they’re already overstretched? Have you asked them how to provide confidence with less manual intervention? How to minimise the impact any change could make? How to add automation for common areas? How to train the developers to fix common issues upstream before it gets to the frontline teams?

Have you ever thought about deleting a process that isn’t adding anything? About making things simpler?

`The Untapped science of less : Inquiring Minds podcast’

Advertisement
Categories
leadership timeout

If you truly want people to be creative and innovative, take them off the clock

That doesn’t mean no deadlines, but no timesheets – don’t justify every 15 minutes with a project, because the next ideas aren’t about 1 thing, they’re about connecting multiple things.

They’re about taking time to pause and thinking about the bigger picture: what problems are you seeing in multiple places? Where else would that new thing you’ve built be useful? What are multiple clients asking for?

Categories
leadership

Stop working when you’re ill

Want to stop people from working when they’re ill?

  1. Pay them.
  2. Warn them if you find they are working. The culture should expect everyone to recover before working.
  3. Encourage everyone to have an illness plan – where can anyone find what work needs to be covered, and who’s best placed to cover it.

See also: working when children or parents are ill.

Categories
development leadership

Dear technical lead

I don’t know how you got your promotion, but I hope you’re a little scared. If you’re not, there’s a good chance that your arrogance will be your downfall.

If you got the job because you want what’s best for the team and the project, then congratulations and welcome to your new challenge.

Your job is still to produce the best product you can, but your toolkit has expanded. It’s no longer just about the code you write, it’s about helping the team produce the best product. It’s about developing processes, building a framework for everyone to work in, whether technical, social, procedural, ethical, anything that’s required.

You’re not doing it alone. You need a good relationship with your PM, your product owner, whatever role your company has.

Relationships are key to your new role. One-to-many when discussing the strategy for the project to the team, and one-to-one discussions with the developers and the stakeholders. Those relationships are the key to your expanding toolkit.

Learn about your team, what are their motivators, strengths and weaknesses. Give them autonomy to work, but be aware of what choices walk the trade-off between upskilling the team and delivering the best product sooner, because upskilling the team helps you deliver vNext, so your horizon has to be beyond this sprint.

Be a mentor.

Be decisive, even if others disagree. And stand by your decision until a better one emerges.

The next project you work on is likely to be the best learning experience you’ve ever had. Enjoy the opportunity. Seek and take advice.

Listen.

You got this.

Categories
leadership

Managing across distances

As the government is starting to ease lockdown and put together timescales for allowing a return to the office, I thought it was worth revisiting some of the ideas I discussed in cross-country coding to see what applies to the upcoming hybrid world, where we know we’re capable of working remotely.

Obviously there will be done time to adjust as we inevitably feel with the mental health consequences of the anxiety of returning to the office as well as the adjustments we’ll need to add or undo to deal with family life, all the new pets and babies that have joined since the start of lockdown, and the mental space we’ve held for new hobbies, for home schooling, for the new health rules.

So take this as a waypoint on some future journey.

I’m not qualified to talk about the mental distress or whatever changes you need to accommodate in your life, but I want to think about how your employer and the technology may need to work in this brave new world.

  • Face to face matters. If you’ve seen someone out breaks down barriers to talking to them. Video beats phone, in person beats video.
  • Trusted insiders are very useful, when there’s multiple offices, or a team you need to check in with that you’re not in all the meetings for. There’s always small things that are missed when you’re just looking through the window.
  • Invest in video. It needs to be good quality. Get better broadband. Get better webcams. Get better microphones.
  • But try and be asynchronous. As soon as there’s friction to synchronous communication, collaboration plummets.
  • Reminder that in open offices, people prefer electronic communication. “The impact of the β€˜open’ workspace on human collaboration | Philosophical Transactions of the Royal Society B: Biological Sciences”
  • Set expectations. Emergent behaviours only happen through observation and feedback, and distance dampens both dramatically
Categories
development leadership

How to make mistakes

Nobody is perfect. If you tell me you’ve never made a mistake in your career, not only will I not believe you, I won’t be able to trust you.

In a safe and functioning team, we can accept our mistakes, discuss them openly, learn the lessons, improve our system, and move on.

Without that, we’re trapped not by our mistakes but by our fear of making them and our fear of the consequences when our mistakes are inevitably surfaced. And “our” mistakes quickly become “your” mistake. Not a failure of the team, not a failure of the system – the processes, the automation, the communication, and the rest – but a fault of the most vulnerable and the most exposed. “It’s always the intern.”

No one makes the intern pilot responsible for a jet plane. They start in small props and in simulators. They are supported and mentored. They are given space to practice, and to fail. Because what really makes the difference isn’t avoiding mistakes, it’s recovering from them.

Build for failure

Test-first, red-green-refactor: every new feature starts with a failing test which we then fix. Make failures part of the process, small and recoverable. Expected.

Build for backup, rollback, recovery. Test for failure continually. And recover automatically if you can.

Plan for failure

Be agile. Try new things for a day, or a week, or a year. Decide in advance what success and failure look like and monitor them. Adjust course if things aren’t working. Celebrate what you learn either way..

Move fast and bend stuff, don’t break it. Do and succeed, or do, fail and recover.

The longer a decision takes, and the more you invest in it, the harder it will be to change it, and the bigger a mistake it will become. So make it quick and don’t make it permanent.

Lead for failure

A leader needs to set a clear direction. To resolve conflicts by stating strong opinions and sticking to them. It makes conflicts easier to resolve. Until those opinions need to change. Maybe the mistake is yours, maybe it’s wrong because other things have moved on. It’s ok to change your mind, so long as you can explain it.

And then go read about why Cognitive Dissonance makes all of this so hard, by reading “Mistakes Were Made”

Categories
leadership

“He never did that to me”

Men,

If you’ve never listened to women on the internet, take the opportunity.

Sleazeballs and fascists may never show their true face to you.

When they show their true face to others, stand and bear witness, or be complicit.

All it takes is for good men to do nothing.

Sure, he’s never like that to you, but where there’s bad words from who you thought were good people, believing good intent and giving the benefit of the doubt can embed their harm in your culture. Call them out. Let them prove good intent by using the experience to learn. If they improve you will see them re-centre the most vulnerable. If not, there was not good intent, just pronouncements from privilege that isn’t prepared to accept fault.

If you want to be good, learn the penguin hustle : keep the most vulnerable in the middle, and those privileged enough to be strong rotate at the edge. So when you feel weak or vulnerable, someone else will take your place. Don’t smother them, and please listen, but the most vulnerable will always suffer a shitstorm of abuse. They need allies to call it out so they’re not drowning in it.

Trust someone on their actions towards towards those who are more vulnerable, not to you who they see as an equal, and maybe a threat. Fear may keep them in place around you, but that’s just a mask to protect who they really are.

And don’t expect others to speak up. For some, simply existing is bringing politics to work.

Categories
free speech leadership

No politics at work

No politics at work.

We’ve got these tabulating machines to send to Hitler.

Talking politics doesn’t get us paid.

There are plenty of companies withdrawing into their shells of privilege because the founders are scared of getting uncomfortable.

If you want a more uplifting picture of what happens when you talk politics at work : you save lives.

Whatever the antecedents of the recent wave of decisions to ignore people’s lives by “not talking politics”, the effects are defiantly anti-union, anti-women, anti-BLM, anti-trans and pro-christian-conservatism.

Even at companies who may have introduced these policies as a reaction against actual fascist viewpoints on their internal discussion boards (which I haven’t seen is the case, but I have heard some justify it that way), banning all politics supports the fascists.

It chills the speech of the oppressed, and gives fascists ammunition that “our free speech is under attack”.

There’s plenty of policies that allow you to talk about maternity leave and single payer healthcare without allowing blood and soul nationalism.

Companies that ban all politics are companies that have weak leadership who only want to align with the prevailing winds, in the most conservative way possible.

Companies, especially tech companies, can change the world. But too often they just reinforce the status quo.

Even companies that want to liberate us from the office, or liberate us from fossil fuels, or liberate us from Earth, still reinforce the power structures that led to the problems they claim to want to solve.

To summarise this, and other points,

“we’re uncomfortable with you having a life outside work”


Categories
development

When the old guard are not heroes

When I started programming, there were some key figures identified as the experts. They wrote the books that laid out how my code should look, how I should behave, and what the purpose of a software developer was. And there’s a new guard, also steeped in that mythos, publishing their hot takes and simple books.

I looked to my peers and seniors for guidance, and they looked to the agile manifesto, the gang of four and others. Those who packaged up existing ideas and best practices, set against a growing trend of Taylorism, and wrapped themselves in a punk ethos fighting the power, wielding keyboards like axes.

And there was value in what they were selling, small pieces that fed my hunger for “something better”.

But for all the bravado, the facade of Woody Guthrie and Bruce Springsteen they presented, deep down they were the establishment, tweaking the system slightly for their own benefit, re-engaging the bro culture of the “frontier spirit” of the early internet. Rules and processes are dictated by “the man” to restrict our freedom to innovate, and to work in the best way.

Companies formed and rose on the counter-culture ethic, buoyed by the vacuum left as union power fell, blinding us all that tech was the new utopia, and it brought a meritocracy that would bring equality.

And the gods saw agile, and it was good.

We moved fast and broke stuff, re-wrote the rules. The industry didn’t take time to consider why those rules existed, just that they were roadblocks.

So when women and people of colour, and anyone else who wasn’t a bro, stepped into the arena, they were vulnerable. Because there were still rules, just no process. And the rules aren’t made for them. And the gatekeepers, clear in their self-image that they weren’t racist, or sexist, and only discriminated on merit, could not comprehend that processes and written rules exist to limit privilege, because equality means nothing without equity.

They asked all of us, the squirrels, the rhinos, the fish, and the peacocks, to climb trees and collect nuts to demonstrate our worthiness to join their club, without regard for our skills or our backgrounds. They bully, they fight, they protect their own, because rules weigh us down, man.


  • People over process, so long as the people are the right people.
  • Working software, so long as it works for me. Anything else is externalities and not my problem.
  • Collaboration over contracts, we’re all on the same team, so forgive me as I forgive you.
  • Respond to change over following a plan, but is there a vision that informs what changes are acceptable?

Agile still has its place, but what would it look like if the manifesto and the guiding principles had been laid out by a more representative group? The antecedents, stretching right back through NASA, Bletchly Park and The Difference Engine, remain the same, and the key lessons are independent of those teachers, but what did we miss by not having others at the table?

  • What does process that protects people look like? Process that keeps people safe and secure to deliver the best solution?
  • What does software that works for everyone look like? Beyond documentation on accessibility and anti-discrimination.
  • What does proper, honest, compassionate collaboration look like? Within teams, between teams and across disciplines?
  • What does meaningful, people-centered change look like?

Software is too important to be left to the swamp that is this libertarian mess. The current ways are driving great developers out of tech, and users are not fairly represented. Some of the old guard recognise this, but many don’t, and they have plenty of followers who still believe the meritocracy myth.

There is no level playing field in tech.

Not everyone has spare time for technical exams outside work hours. Not everyone is comfortable pair programming. Not everyone can follow a spoken stand-up. Not everyone feels safe to bring their full self to work. Everyone is not treated the same. Not everyone can have alcohol and pizza. Not everyone has the experience of standing up to authority figures. Not everyone can be themselves without being judged or mocked by the cis straight white male gatekeepers, and their supporters.

There’s precious few unions and the biggest tech companies are all struggling with human rights, fair employment and treating their users fairly. And it’s not just them.

Unlike the 20th century, it’s not a battle between management and worker. Agile has cast management and worker in the same side, but some workers are far more equal than others.

People are not supported by the process. Software doesn’t work for everyone. Collaboration is limited because contracts don’t protect and promote safety. The plan for meritocracy to end discrimination isn’t working. How are you going to change it?

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.