De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Advertisement

Sense and Respond by Jeff Gothelf and Josh Seiden

Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously by Jeff Gothelf

My rating: 5 of 5 stars

Having read Lean UX, I was expecting a good book on how organisations could deliver projects. This book is about much more than that. The authors are coming from a point of frustration where agile delivery and Lean UX projects have failed to reach their potential because the organisations surrounding them were not supportive, so this book is about how to reshape an entire organisation to meet the challenged of the modern world, with lots of positive and negative examples, which is refreshing to see in this type of book. If you’ve ever had a strategy meeting, or ever found your project success limited by your organisation, go read this book.

Easily the best book about dysfunctional organisations and organisational change I’ve read since Peopleware.

View all my reviews

Buy on Amazon UK :

How do you know when it’s time to move job?

Around 18 months ago, I decided I needed a new job. It took almost 8 months to find my current job, and I swayed between wanting to leave and wanting to stay. In the end I discovered that I was finding excuses to stay because I’d been there long enough, and made enough friends, to be scared of leaving. But the company I left was a very different company to the one I joined.

If you’re starting the new year after some time off, starting to fear going back, or having doubts about your job, have a think about these things, and see where you stand. Then decide if you want to stick or shift.

Some of these are things I’ve felt, others are ones that came up from multiple people in recruitment interviews I’ve done over the last few years.

• You don’t see yourself here in 5 years
• You have more direction than your company
• You’ve lost sight of, or respect for, the company values
• You do all your learning, and all your best work, out of the office
• The idea of doing the same thing next year fill you with dread. But it’s exactly what you expect
• You’re ready for the next step, but you can’t see where that step is.
• Your team, or your company, is shrinking, and no plans for growth are forthcoming.

What’s made you switch jobs?

Handling disagreements as a team

Following my code review post, I added some more thoughts regarding code reviews, but there was one comment that I wanted to come back to later:

“Social aspect: How do we handle disagreements? As a team.” – peitor

There are a number of aspects to successfully dealing with disagreements, some of which are about mitigation and avoiding the problem in advance, and others about how you deal with the problem once the disagreement has started to grow, after all, it’s hard to avoid the vim vs emacs, “that’s not RESTful”, brace placement, or other developer arguments.

Collective Ownership

The first key to avoiding unnecessary disagreements is to leave your ego at the door, because teams full of egos will fight each other to be seen. As Peopleware: Productive Projects and Teams so elegantly describes, any situation that asks developers to compete against each other, whether under performance review,or by dividing functional teams geographically, will inevitably lead to conflict and a blame culture. If you are all on the same team, with the same goal, it’s in everyone’s interest to resolve disagreements before they become conflicts.

Constructive Criticism

One of my colleagues has been writing a series on becoming a technical lead, it’s all worth a read, but his latest post, about constructive criticism, is particularly relevant to this discussion.

Constructive Criticism is a reality of doing code reviews, it’s arguably the whole point of doing them, but make sure that you are able to articulate clearly what you expected in a friendly manner, a Blame Culture is bad.

This doesn’t just apply to code reviews, but that’s an important example of where code is judged. Firstly, constructive criticism should be about the behaviour or the outcome, rather than the person (although even at that level, it’s wise to avoid abusive language if you want to avoid alienating your team, just ask Linux Torvalds), and secondly it should offer practical, achievable improvements, so that the person receiving them can use them as an opportunity to improve.

Lone Wolf

There are 2 main categories for individuals who have a detrimental effect on the team. One is the black hole who needs additional support or encouragement and sucks time away from the rest of the team, and any work they produce is marginal. They might be just a poor team player, or a square peg in a round hole (maybe they’d be great in another job on the team or in the company), but they breed resentment in the rest of the team having to compensate.

As a leader, you either need to find a way to help the person to improve and fit into the role they are doing, via mentoring, training or other means; or you need to find a role they are better suited to, by looking at other tasks that need doing.

If you can’t do either of these things, you will need to make the tough decision to get that person off your team so that the rest of the team become more productive and do not degenerate into dysfunction.

Rockstar

The other key individual threat to team coherence is the rockstar developer. The one who plays by their own rules, and always knows best. Unlike the black hole, they get the job done, but they often do so at the expense of the team.

Key traits of Rockstar code is code that doesn’t fit the rest of the team, code that is too clever for its own good, and therefore much harder to test and debug.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

• Brian Kernighan

Just like the black hole, the rockstar developer causes addition work for the rest of the team, but often leaves behind code that the rest of the team don’t understand in order to be able to refactor it. This resentment can be seen by the rockstar developer as jealousy, as their non-stick ego prevents them from taking responsibility for dysfunctions in the team, and it is clear, particularly to those outside the team, that the individual is achieving results (indeed, the rockstar often makes it very clear).

A rockstar does have many of the qualities needed to be a good developer, so long as they can be convinced to simplify and work with the team rather than steamrolling past. Unlike black holes, they are probably doing the right tasks, but need help to understand their impact on the rest of the team and any problems that result from their code, as they may have trouble accepting it.

Duelling banjos

Sometimes, there are individuals that work well with the rest of the team but not each other. Sometimes this can be caused by jealousy or resentment, particularly if one was recently promoted or given extra responsibility when they were previously equal, or one of them is more likely to have their ideas accepted by the team.

The slighted individual in this scenario needs support from the other individual and the rest of the team to accept the situation, and build resilience so they can move on, and, where appropriate, a clear explanation for why the differential occurs.

Hopefully these disagreements are on the ideas rather than the individuals, because when things get personal, it gets a lot harder for people to back away from a disagreement. However, the technology world is notorious for bug fights over little things.

Which text editor do you use? (whichever one you like, so long as you can set the format to the project coding standards)

Where do you put the opening braces? (for Javascript, always use K&R style, on the same line, for everything else, whatever the project says)

If you’re fighting over something that doesn’t really matter, ask yourself why, and if you can just agree to disagree, and accept that you’re not going to convert everyone to Dvorak.

If you see others on your team fighting, look out for Logical Fallacies that can drag the argument down into personal attacks, or unproductive sniping rather than a stimulating argument on improving the code. Be prepared to step in and separate the individuals. Give them a chance to cool down and reset, or space to think, talk and reflect.

Red eyed monster

The tired, stressed team are far more likely to argue and those arguments are more likely to get personal. Don’t overwork. Find your work-life balance.

You

You are a member of the team. Exhibit the behaviour you want to see.

Work-life balance : No interruptions, only peace

My favourite discussion from the Technical Lead discussion was defining a successful technical lead, to which one of the first answers was that no-one will need you. If you are good at what you do, you can optimise yourself out of a job, or at least free yourself up to go on holiday once in a while, without anyone needing to interrupt you. Get better at getting away. This is something close to my heart, having had 3 breaks in a row interrupted due to having to make decisions for a team late on various Saturdays.

If you want the same, first you need to get in the proper holiday mindset – where you do not get any work email on your phone. If work really want you to read email on your phone, they’ll pay for it.

Once you have the mindset though, there’s a number of things you need to do to make it happen, so you can avoid webmail and phonecalls and properly relax. Thinking about your break is also a good way to build a resilient team, and a resilient project. Here’s a few things that have worked for me.

Don’t build software, build teams.

Start with the team. You won’t always have a choice of the team, but if you want to defer your job to the team, at least temporarily, you will need people in the team that you can trust, and that the rest of the team will respect, so that they can keep a steady hand. And make sure you debrief them before you go.

Don’t speak, write.

Talking is great for working through problems and sharing knowledge. But people will forget. So write it down, and then talk it through. That way there’s something to refer to in 6 months time, when they, and you, have forgotten what you did and you need to work it out again from first principles.

Automation trumps documentation.

But if you can write it in code, do. People get bored reading documentation, skipping the sections they think they know. Computers don’t know how. And run the automation regularly, so you know it’s up to date. Deploy often from scripts, not documents. Every document runs the risk of papercuts.

Delegate everything, to everyone.

In other words, don’t be the only person on the team who knows how to do something, and don’t let anyone else on the team be that person either.

Own the code, but don’t be the code.

If you practice ego-less programming anyway, this should be easy, but ego-less programming takes a lot of deliberate practice. Be proud of the code you write, but not so proud that you can’t leave it alone for a week or two. If you have build the right team, you know the code will be in as good a condition without you as it would if you were there, bar a nudge or two you can easily resolve when you get back.

Relax.

Walk off. Don’t look back. If you keep checking in, you’ll send the message that you don’t trust your team, and you run the risk of micromanaging, which means your team will lose some autonomy and be less effective, which then creates a vicious cycle that you will need to get more involved. If you run the project as if you’re not needed, except in an emergency, it will run more smoothly, and you will be able to relax.

Plan.

From day 1, plan for knowledge transfer, plan for delegation, and plan for everyone’s holidays, and family emergencies, and paternity leave, and for the loss of team members to other projects and companies, plan for a team that will change over time, in the short term and the long term. It’s not a matter of treating people as replaceable parts (see the last point, and trusting your team), but it is a matter of responding to change, and building flexibility in from day 1. I don’t always get it right, but the more successful I am, the better the team works, and the more I can relax.

Trust your team.

Trust them, and let them trust you. And please, please, please, don’t phone them whilst they’re away. Lead by example.

Paperless and warning free

Do you have a licence

As a quick follow up to my post on the new process for endorsements following the demise of the paper counterpart driving licence.

First, a clarification, the change in the DVLA is for the paper counterpart to the photo id licence, not the paper licence that existed before the photo id licences. Many people will have been switched to photo id by moving house though, so it’s only the hardcore who won’t be included.

I got confirmation from the car hire firm 24 hours in advance that I needed to print out my endorsements sheet, by which point I no longer had access to a working printer, so I was glad I’d tried it beforehand. The guy at the desk noted that it was a new scheme, and also mentioned that if I hadn’t printed it out, they would need to call a DVLA verification phone number which is very busy when it’s not shut. So still a number of teething problems to sort out.

Do if you are hiring a car, get yourself over to dvla in advance (any time within 21 days) and get your endorsement sheet printed. It might just save you from long queues and grumpy car hire staff.

Developer cognitive load

Anything a developer does that doesn’t add business value is wasted cognitive load. That’s why we use abstractions.

I know my developers are smart enough to handle memory management if they needed to, but developers just as smart in the past were less productive and introduced buffer overflow bugs because they had to think about that as well as the business problem they were trying to solve.

I want my team to fix one novel problem a day, rather than 10 papercuts that have already been fixed and get in the way of business logic.

When I see a developer make a mistake, I always need to ask myself if that mistake is a papercut that other developers will suffer from, and if there’s a way to fix it before the next developer encounters it. Code that makes my team more productive is always useful code.

Agile papercuts

I’ve worked on a few projects and I’ve tried many ways to run them. The agile manifesto is a great starting point, and should be in your bookmarks for quick reference. But when you put it into practice, your first thought is the mistakes you made last time, the lessons you learned, so you can do better this time.

So you look at where things failed, and you add a process around it, maybe one of your own, making taking inspiration from others.

For example, you had a big problem with release management in your last project, and git flow is a process for release management, so you try it on for size.

But the planning decisions about when to deliver features, and how the support and feature releases work together are not changed, because it was a release management problem, not a planning problem. So you add more process.

STOP

Let’s assume you don’t have time for root cause analysis of everything that caused you pain last time. Just assume everything is causing some pain, but for some things the benefit outweighs the cost.

How do you spot what causes more pain than benefit?

Does your process support the people, or sideline them? Is the documentation useful or mothballed as soon as it is delivered? In other words, are you valuing the things on the right more than the things on the left?

As developers, it is a long battle to get over your ego, and the sunk code fallacy, and learn not to be precious about the code you’ve written because the product you’re delivering can always be improved, and if your code is no longer fit for that product, it should be removed. Celebrate the code you no longer have to maintain.

As tech leads, we can be just as precious of our procedures and our practices, but they can be even more painful that the code. They’re harder to refactor, to measure, to test, because people are less predictable than code, but we need to be willing to identify waste, and identify the pain points so that we can address them, and remove practices if necessary. Measure where you can, but don’t be afraid to be as ruthless with your process as you are with your code. Anything that didn’t add value is weighing you down, and even those small papercuts that sung every time are worth removing.

Whatever you think Agile Is, even if you think Agile Is Dead, don’t forget your process is as much a part of the delivery as the code you produce. Own it. Trim it.