Why Tech Teams need Clear Team Values

OK, so a conversation with Garbados/Diana on Gnu-Masto-Social-Don tied in with some deep-founded thoughts and has started a little fire somewhere inside me. She was talking about the “PTSD” effect on developers, through bad bosses and/or bad effects – the latter isn’t something I’ve been so close to, but makes me wonder how I’d react if, for instance, a library I’d contributed to had been used in warfare.

Sadly, bad bosses are more commonplace, though. Sometimes “bad” can mean “evil”, as in acting against others’ interests. Other times it can simply mean “misunderstanding” or “unlistening”, which can happen for more and less excusable reasons. Not all managers want to be managers. Real life gets in the way. And, importantly, TECH IS REALLY HARD TO UNDERSTAND. Realistically, if you haven’t worked 10+ years on a variety of tech projects, then you’re probably still getting your head round just what “tech” and its myriad systems actually means.

Tech is hard because systems are hard. And tech brings together all the systems – code, infrastructure, hardware, changes, as well as people and business value.

I’m at the point of my life where I feel like I’ve got a small grip on this. And the question I have right now is – how can we open up “tech” in terms of a wider audience understanding its challenges, nuances, effects and needs? How can we help “bad bosses” to navigate through the – let’s face it – infinitely confusing landscape of technology in a way that benefits both the people working in tech, as much as the organisation they work for?

I’m old enough to know that work has a huge emotional impact on our lives – that for many, our job is probably the most likely thing to influence whether we’re satisfied with life, or hating it. As my kids grow up, I can’t seriously look them in the eye and tell them that work is great, that if you just follow your passion, jobs will be brilliant. Because it’s more than that – it’s about finding a space that encourages a two-way relationship, a mutual symbiosis between worker and organisation. They cannot exist without each other.

As a Tech Director for a few years, one thing I’m annoyed I’ve never quite found time for is to have more time on team values. It strikes me that this is the one thing, the single discussion, that unites the people involved in “the craft”. if you hire passionate people (or if you can enthuse them to become passionate) then individual values soon emerge quickly. Not all of these will be shared across all the team, and balancing these is one of the broader jobs of the Tech Lead. But if things are important to the team – and, if done right, to the team as a whole – then perhaps these things need to be written up, shouted out, scrawled on walls, printed on banners.

Because understanding tech is hard, and if the team doesn’t do it, then nobody else will care.

This discussion, and the courage to do this – this is what we should be doing as part of our teams, a reignition of collectivism and strength in the team. Values, not (necessarily just) hours or pay, are what drives us, and what we should be taking an individual stand on. Values should be baked into the discussion from the moment we talk to a prospective new employer, or new employee – the up-front expectation that we take our art seriously, that we believe what we do has value to others, and that any compromise cannot be taken lightly.

And that’s just a start.

Nobody Likes Code Reviews

Judgemental Pigeon Disapproves

Typical tech team conversation:

“The work is nearly done, just a few tidies but it basically works.”

“Has it been properly tested?”

“Not yet, but the basics work.”

“And any changes that come out of a code review, I assume.”

“True, but hopefully not many.”

“So still a fair bit to do then.”

“Yeah, a bit more.”

We’ve been running code reviews for a few years in a fairly tiny team with a mix of experience. For context, we don’t generally have strong specialisms, and do a fair bit of picking-it-up-as-we-go. Over the time, I’ve noticed two fundamentals:

  1. Nobody likes code reviews
  2. The right attitude to code reviews goes a long way, both for individuals and for the business

Part One: Nobody likes code reviews

You’ve just spent days using nothing except your brain and fingers to craft a solution (elegant or otherwise) to the latest user need – brilliant! The problem to hand is solved, everyone will love you, blah blah blah. Onwards and upwards.

Except – Code Review.

(If you’re not familiar with the term, then a Code Review is basically a chance to run what you’ve done past someone else. This. Is intended to catch bugs, raise questions about the work, point out improvements (including style, documentation, formatting, etc), and learn from each other. The actual benefit will depend on who’s reviewing who – it can be beneficial for a junior member of staff to review a senior member’s work, and vice versa, but the dynamic will obviously change.)

The word itself is horrible; “review” sounds so judgmental. Like your work is going to be scored out of 10 by some gravy-train critic with an axe to grind. The code works, doesn’t it? Why does it need anything further? This isn’t school any more.

There are two main reasons to be “afraid” of having your code reviewed:

  1. Explaining things to others is hard and boring.

  2. Being “wrong” is difficult.

This gets at a fundamental “double-think” that helps in code reviews – and, indeed, in life. On the one hand, how can we be proud of our work so that we can take interest and responsibility for it, while simultaneously being humble enough to accept critique?

Part Two: The right attitude goes a long way

In order to not hate code reviews – and to become stronger as a result of doing them – we must therefore develop a key set of skills as a programmer being reviewed:

  • Respect for the person reviewing, whether they’re more senior, junior, or an equal peer – without this, we cannot be open to suggestions from them. (And vice versa, it is essential to respect the person whose work is being reviewed. This mutual respect is the key part of the “contract” underlying reviewing each other’s work.)

  • Patience to explain something (often to someone who may otherwise have no idea about context)

  • Clear communicationstorytelling about what you’ve done (and not done), and (more importantly) why you’ve done or not done it

  • An inquisitiveness that opens us up to collaboration, to help explore feedback and suggestions arising from review.

By focusing on these as key skills to develop, a team can learn more quickly from each other. Individuals can improve their own skills faster, as well as learn more about working with other people generally – an essential, yet subtle side-effect of code reviews is learning how other people think. By being open to alternative thought processes, we can expand our own, and bring wider experience to problems in the future.

As Tech Lead (or a senior developer), what can I do to encourage these properties in the team?

The main, most essential thing is to simply lead by example. It’s good to become part of the process by reviewing code (as may be expected, depending on the team size) and adhering to the values above. But also it’s important to write code and be reviewed – this demonstrates what you believe to be good practice. Plus everybody has something to learn off others – often a junior member of staff reviewing your code will ask you basic questions that get you to think about your basic assumptions.

Secondly, and this is something I’d like to bring in more, it’s valuable to be very clear about the aims and values of the code review process up front. Inform new staff about why code review is important, and remind people every now and then.

It’s very powerful to be able to say that a team can learn from itself rather than rely on books and courses, or that a developer’s job entails learning and teaching, above and beyond simply pushing out lines of code and UML diagrams. Learning and teaching is something a good team does all the time, as a matter of course.

I haven’t touched on more detail here, such as what the main attributes look like, or what to look out for to see if a team really are developing as a unit – maybe I’ll follow up with these in a later blog post, if there’s interest.