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?

Advertisement

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?

#digitleaders 2017, Edinburgh

Last week I attended the first Digit Leaders conference at Dynamic Earth in Edinburgh. There were 3 loosely-themed sessions consisting of 3 15 minute talks and a collective Q&A panel with the 3 speakers.

I’ve mentioned before that I think it’s a great venue and it was the first conference I’ve been to with this format, which doubles down on thinking of a conference as a high level overview of a topic, and a networking event for questions. For these topics I think it went well, but it suited the second two topics more than the first, where I think all the speakers would have benefited from more time to explore how they made changes rather than the high level what they did.

I’m going to split the topics up slightly differently in this post as there’s a couple of topics that came up in several places, in talks, questions and the networking event after.

Digital Transformation

Leadership is sometimes about a steady hand and maintaining course, but sometimes it’s about taking a failing team, or culture, and turning it around.

A great example of the latter was Helen Marshall of Yodel who was brought in to lead an infrastructure transformation by an IT team with a reputation for impeding progress and without faith in their ability to execute the transformation.

She took some well worn leadership techniques : find and communicate a clear common goal; break the work into smaller chunks; move people into roles that play to their strengths, and created a team that won awards internally and externally for their ability to power the business.

Interestingly though, whilst there were goals for the project (complete this part of the migration before the Christmas rush so we can handle x% more parcels), the goals she focused on were cultural: delight the business, inspire others, won awards. And the project got a new name to keep things fresh. Westinghouse theory can be useful.

There was also an interesting take from Gordon Craig of Craneware, looking at transformation outside the digital part of the business. They sell software but​ their sales process was misfiring, partly down to long lead times that meant the feedback loop was slack.

Again, rather than focus on sales goals, he started tracking team behaviours, which can be monitored and corrected on a much shorter timescale. He didn’t go into much detail on what behaviours he monitored except to say there was daily dashboard monitoring that could be done locally in the US and at home in the UK, and that data quality in the CRM was an issue so he tied commission to having the correct data in the CRM. If it wasn’t there, no commission was paid.

He also spoke about rethinking the company as a sales company rather than a software company, aligning the rest of the business, and the strategy, to the goal of more sales, pushing the rest of the business to support that pipeline.

Cultures, sub-cultures and co-existing

There’s always been a stereotype of IT as socially awkward, 20-stone, socially awkward men who work in windowless basements. That’s less true than it was, but there’s still cultural differences between IT and other parts of the business, but one thing we can easily forget it’s that there can just as big differences between Sales culture and Marketing culture, between the US organisation and the UK organisation, or between verticals within the organisation who target different markets.

Liza Horan discussed the later in the context of Disney, a very hierarchical organisation with a culture of asking for permission, with their child organisation ESPN, which is individual driven and a culture more about do it and all for forgiveness. Which very much reminded me of the behind the scenes stories of how Pixar works and how they fit in.

Chris Rivinus had some great data quantifying this cultural difference, between departments and between countries, based on surveys and Hofstede’s law. He also spoke about how he’d used this to aid communication. In one large organisation, they needed to update their cybersecurity. This was communicated as an agreed document, and everyone git the same content, but the highlights of the message were adapted to whether the department in question was, for example, hierarchy focused (do this for your boss), financially driven (do this or here are the penalties) or various other axes.

We know, as IT, we need to tailor our message to the audience, but it was fascinating to see numbers and here more techniques about how to put that into practice.

Diversity and the skills gap

A recurring theme throughout the day was that the white male stereotype was very much the norm at the conference. 7% were women, and no numbers on other aspects of diversity.

It’s hard to blame the conference for that though as it was still far more balanced than the pure technology and architecture conferences I’ve attended.

I think on the core question of whether it’s a lack of diversity in technology or in leadership, I see marginally better balance higher up in organisations, but I don’t know why.

The big challenge, as it has been throughout STEM for a while, is how to get and keep them interested in technology throughout school and university and into work. Find the right inspiration and role models? I’m not the expert here, but I see the problem constantly.

Leadership psychology

Good leadership is full of apparent contradictions. You need to be strong to inspire others to the bigger goals, and to make the tough decisions; but you have to be vulnerable enough to ask for help when you don’t have options to make decisions on, to rely on others to tell you what the coalface is really like. You need to understand numbers and empathise with people. You need a strong unifying culture where individuals thrive.

I’m no expert on soft skills. I’m still learning. In that, I’m not alone in the technical sphere. Other teams succeed on skills that overlap more with leadership skills, so it can be harder for technical people to succeed as leaders without a willingness to learn. That’s why we need conferences like this, to help us learn.

My notes

For those of you who can read it, here’s my notes from the conference.

Reducing waste by automation

Reducing waste is one of the key concerns of agile development, and is a defining character for Kanban, where blockages are ruthlessly identified and resolved. Timeboxing provides a low-cost means of identifying waste and a framework for tackling it, but doesn’t provide many solutions on its own.

For tasks that continually cause blockages, such as the release process, or testing, automation is a good way to eliminate the repetition, and the chance of human error. Indeed, the engineers in the audience will immediately recognise the key drivers for Continuous Deployment and Continuous Integration in the examples I’ve given.

And yet, whilst we appreciate the gains it can make, how many teams set aside specific time in their schedules for “automation” as an activity alongside “refactoring”, “upgrading dependencies” and “deleting dead code (including tests)”.

Check your backlog, and if automation, in some form, isn’t there, ask yourself why those repetitive manual steps still exist in your workflow and why they have priority over the other work you have to do.

Everyone has a voice

​One of the challenges that Technical Leads face that isn’t always easy to resolve is making sure the whole team is involved in decisions. 

There is a large overlap between people who can think in code and people who are shy around other people. For some, the enthusiasm of the former can overcome the latter, but for many, especially younger members of the team, they need encouragement. 

There are a few key ways to do it. If you’ve built the right team, pairing with a patient mentor, who asks questions, is a good way to build confidence. We all hate it, but asking someone their opinion in a meeting is important too, until they get confident enough to speak up themselves, because they know they’ll be heard. So pick your meetings wisely. 

There’s also non-verbal ways to increase interaction and confidence. I’m a big fan of asynchronous code reviews, because they help people focus on the code rather than the coder. I realise there is a risk that this can lead to an atmosphere where someone being reviewed feels under attack, but in my experience, with ego-less teams, and especially with teams who understand and fight technical debt, they see reviews as a chance to improve the code and their own understanding, and make everyone’s life easier next time they look at that feature. 

Lean Coffee meetings are also good for helping encourage people to suggest ideas, as they can see what others want to talk about, so they know they have something worth dating. 

Make sure the quiet people speak up

What is an agile developer?

@joe_jag a developer who practices continuous improvement, with our without the support of am agile team.

— craignicol (@craignicol) September 29, 2015

A developer who practices continuous improvement, with or without the support of an agile team.

You care about being better. You consider code to be craft. You’re only happy when you deliver value, so you want to deliver value more often. You set yourself a high bar, and always try to raise it. You want to learn. 

You accept your mistakes and move on. 

What does an agile developer mean to you? 

For those of you coming to CodeCraftConf, I’ll see you on Friday. 

Bad change : The rock star developer and dealing with unexpected change

Have you ever worked with a developer who knows everything? The one who does a bit of tinkering in the evenings and weekends, and when the rest of the team come in, they can’t find anything in the code?

Yes, it’s a bit neater, but it’s a lot more broken, because it’s less readable, because it’s using a beta version of a library rather than the previous stable version. And one project in the solution uses different conventions to the rest.

I also tend to find the tinkered code is proof of concept with minimal testing, and little documentation. So the software diva who developed to the limit of their ability can’t tell you how it works 1 week later. They got bored and moved on. After all, there’s another Javascript framework to learn.

It’s great if you write throwaway code. If no project lasts more than a month. But that’s not the software I’ve been building. I enjoy the challenge of nurturing code that’s got a lifespan of 5, 10, 25 years or more. Not necessarily the same code, modules get rewritten, tests get added, dead code is removed, but it has to remain readable and maintainable all the time.

If you are a lead with a diva on your team, use them for research, because they will chase The Precious whenever something shiny comes into view. But when they need to get code into production, enforce your coding standards strictly. They will moan. They will sometimes throw a tantrum. If they do, you know they’re wrong, otherwise they’d have a convincing argument for doing it their way.

Standards are universal. Divas are occasionally useful idiots. Learn to spot them, and use them to your advantage without disrupting the rest of the team.

Your API sucks : testing

Finally, you’re ready to launch, you’ve integrated the API, you’ve decoded the documentation, you have passing integration tests, and FAT passed against their test server, with their test data. You go live. And everything breaks.

Strawman testing

Sometimes the test data or the API out of sync with live, and you find you’ve been testing the wrong thing. Maybe the test server is a version ahead of the live API (if they’ve ignored the advice not to version HTTP APIs).

More frustrating is when the data is plain wrong. When the returned record has { Firstname = “Lincoln”, Lastname = “Abraham” }, or an invalid postcode (did you know, The final two letters do not use the letters CIKMOV) which means the test site may require a postcode that your validator will reject.

Tests doomed to succeed

Sometimes the test data is correct, but incomplete. Imagine a postcode lookup where test addresses are all SW… which means you can’t test for:

• Flat x/y addresses
• BFPO addresses
• Irish or other EU addresses

Or imagine a payment processor test stub that always returns success – so you can’t test for declined cards, or 3DS cards, or check that you only accept debit cards.

If your API supports it, put it in your test, and make it available to users for their tests. If it’s not tested, it’s not complete.

 

Your API sucks : Error handling

Exceptional validation

So many places I’ve seen throw an exception for the first validation error they encounter:

HTTP 500 - Credit Card number invalid

When I see that, I need to make multiple calls before I can see what’s wrong. If you’re going to validate, try and validate everything beyond authentication in one shot, like this:

HTTP 400

{
    validationErrors: [
        {"CreditCardNumber" : "Must be 16 characters"}
        {"ExpiryDate" : "Must be in the future"}
        {"CCV" : "Is required"}
    ]
}

Success : ERROR

If something went wrong, make it obvious. On the web, use a 4xx or 5xx status code, instead of a 200 OK. In code, throw an exception. This isn’t C, we don’t need to rely on errno any more. If I see success, I want valid data. Parsing your error messages isn’t part of the deal. Especially if they have spelling mistakes.

Illegal characters

If I see that your API won’t let me have O’Malley as a name, or Flat 1/2 as an address, I will immediately start thinking of Bobby Tables, and I will assume you have a poor encoding excuse at your backend. If you can’t handle that, you shouldn’t be writing an API. As the security sucks said, you should not be my weakest link.

Your API sucks : hidden effects

Your API can be well structured and use the right language on the surface, but it can still be a pig if you get it wrong behind the scenes.

Data bloat

Are you sending 1/2 Gb of data for every roundtrip? XML encoding the entire object graph for a call that can only possibly change 1 field within it? Are you wondering why your network is slow?

Busy waiting

Sometimes data is big. It will take a long time to upload and process. That doesn’t have to be a problem. But don’t make me wait whilst you do it. It’s easy to find asynchronous libraries, or just throw the request in a queue and return. Let the client get on with the next thing.

Idempotence

Idempotence is a posh word for a very simple idea : looking at something shouldn’t change it. Quantum mechanics is hard because that’s not true. Your API is not there to impress Niels Bohr.

In other words, GET over HTTP doesn’t change data. Property getters on a class don’t change data. CQRS queries don’t change data. Don’t change data unless explicitly requested to do so.

Don’t get confused though. This doesn’t mean that each get will return the same result, after all tomorrow’s weather will be different to today, but I should be able to change the weather just by observing it.

Hidden prerequisites

Have you ever visited a shopping site and tried to checkout, only to be denied because you haven’t previously added a credit card to your account?

It’s very annoying having a hidden step that’s not clear. If it’s required, make it required at the point of action (definitely my preferred option), or if you can’t do that, deny access to the point of action until the prerequisites are cleared. And make it very clear why access is denied.