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

Hey underrepresented folks in technical roles! Performance review season is upon us. I want to take a few moments to remind you about some practical tips that can help you be evaluated more fairly in this and future seasons.

— Mekka *My Mask Protects You* Okereke (@mekkaokereke) August 9, 2018

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.

Advertisement

As a team lead …

As a team lead you need to know your team. You need to understand people. You don’t need to second guess them, you don’t need to micromanage them, but know what motivates them. Know what they need to perform at their best.

What tools do they covet? What routines matter? Do they need precision? Do they value gym time? Do they aspire to learn?

Understand their 6 month and their 5 year plan and help them achieve it. Make sure they know the team 6 month and 5 year plan and where they fit into it, and where that fits in the company plan.

Value them, and ensure they feel valued. Listen. Give them the grace to accept that which they cannot change but be sure they know you’d change it if you could.

Change what you can. Make their lives easier. Help them aspire to your job, even if they may fear the conflicts you protect them from. Keep your head whilst those about you are losing theirs.

Be the best team you can be. Discover the greatness in everyone. Play to strengths to see them through weaknesses. Move people. Change their roles. Find your gardeners and your innovators and Train them to replace you, because for certain times they will need to. Do not become vain or bitter for always there will be greater or lesser persons than yourself.

Let go. Trust them. Trust yourself. Let them do their job so you can do yours.

But lead, don’t follow. Have strong opinions, weakly held when a better way presents itself.

Let data guide you but not be your master. Don’t trust your gut.

Don’t be a stranger and make a full commitment to your team.

And make sure everyone knows the standards.

The importance of confidence

Have you ever been given a project to deliver and thought you can’t do it? That you don’t know enough, that the deadlines are too tight?

Ever felt like panicking?

Have you been on that team, and somehow still delivered, with absolute pride in what you’ve delivered, bar a few teething issues?

As a leader, to inspire your team, you need to exude confidence. Confidence in the outcomes, and in the team. You don’t deny problems or paper them over. Hiding is a sign of weakness. But the team needs confidence to deliver and they get that from you.

If you’re not confident, don’t fake it. Revise the outcomes to a scope you’re confident in. Narrow your horizon. Get answers to your doubts, and support to conquer them. When times are tough, it’s your job to set the right expectations that the team can believe in, and deliver on. It’s your job to find a clear path through the chaos. Or it’s your job to help them pick up the pieces and move on.

These are the tests of your leadership. If the team can weather the crisis, if it can keep it’s collective head whilst all about are losing theirs, then you have earned the right to be a leader.

Be confident. But be authentic.

Naughtonomy

Wherever the wind takes you

If you want a strong team of developers, give them autonomy. But what if they don’t want to take it? The ones in, or from, the big corporations who just won’t take the initiative? The ones who just want to be told what to do?

I’ve said before that those are the waterfall people. The cogs in the machine.

Have you been a developer who didn’t want to take responsibility for yourself or your work? Who doesn’t have pride in your work, and just wants the money? Do you want the opposite of autonomy?

It might not be your fault. If you live in a blame culture, you want to leave as small a footprint as possible. Head down, do as you’re told. Don’t attempt that risky refactoring or upgrade. After all, if you do it, and it breaks, it’s your bonus that gets lost, and your neck on the line for big failures. If you don’t touch it, and it breaks, maybe the previous touchee will get passed the grenade, or maybe it will just get blamed on a faceless, incomplete “process”.

Maybe your manager doesn’t want you making decisions. You’re not important enough. You don’t have the power to make them. Developer ideas don’t matter, listen to the manager, or the architect.

Or maybe you want to be motivated, to get autonomy and change things.

Show your boss this. Or get a new job.

Bootstrapping new developers

Start of a new day

When things are tough, do them often, to get more practice, as Sky Betting discuss in their recent blog post. It’s certainly something that I’ve noticed as we’ve moved to more regular releases, more regular planning and reducing feedback cycles.

One big thing I’m still learning how to do, where that doesn’t apply, is adding new developers to a team. I’ve been thinking about this after hearing The Improv Effect talk about onboarding to a company on .Net Rocks 1253 : Onboarding is Culture with Jessie Shternshus

My usual approach doesn’t apply, because good teams are stable, so onboarding is rare, which makes it harder to know how to bring new people on to the team. I always try to write a short introduction, on a wiki, to introduce the project and list the useful urls, and the getting started steps, and I ask new developers to update it with any differences they find, to keep it up to date.

Most of the team knowledge doesn’t come from there. It comes from the rest of the team. So the team needs to be built so that the onboardee collaborates with other members of the team from day one. Getting involved in code reviews, asking questions. I’m sometimes tempted to give as little information as possible to encourage asking questions, but that’s not how psychology works, and I’ve had more than a few gotcha moments where someone who’s been on the team for a while says “I didn’t know that was there” or “oh, so that’s why we do it that way”, and I have to revisit the onboarding story again, and wait for the next chance to validate it.

So, assuming your company has a good story for onboarding employees, how to you take a fresh start, or a start from another project, and build them into your team?

The tech diversity blind spot

 

Technology makes the world better. It promises to make our lives better. It will free us from work.

Except “The best minds of my generation are thinking about how to make people click ads”. And tech lives in social bubbles as well as financial ones. Apps designed for silicon Valley don’t always travel to the rest of the USA, apps for Western countries don’t always apply in the East, Facebook and Google aren’t always trusted, VR headsets that don’t work if you wear make up, facial recognition fails if you don’t have the same skin as the webcam software developer, or the photo auto-categorising application developers.

Sometimes the solution is to write technology in another bubble. Brazil, India, China, and many other places have strong home grown technology far more popular than the “global” leaders. Sometimes you expand your bubble, diversified teams, balanced teams, who are smarter than homogeneous teams anyway.

Sometimes you look outside your bubble. I get paid to write software that I will likely never use. Line of business applications, including public interfaces, for government clients. I don’t know what their business is until I ask. I don’t know how they work, or what is important to them. And sometimes I have to ask several times, and sometimes people can never understand or articulate what they do, let alone what they want, even after asking them in several ways. So what makes you uniquely qualified to understand what you do, or what problems you have, or whether those problems are universal?

If you want to know if your intuition applies to the population as a whole, make sure your stakeholders reflect that population, or accept that you are deliberately limiting your audience, because that’s what makes sense to you.

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.

Engineers, ethics and scapegoats

Uncle Bob talked about the VW software engineers on his Clean Coder Blog. Go and read it.

There’s two important issues here. One is that the official line is that the engineers acted alone and no-one else knew what they were doing, in any QA, in any road testing, in any future tweak over the many years these cars were for sale. Although I note there’s no suggestion it was an accident, or an oversight, as in other European engineering failures.

So, if we accept this was a deliberate action, and that the engineers were aware of the consequences, at least in terms of the NOx and CO2 outputs in US and EU tests respectively, and this wasn’t a misconfiguration or falsely triggered test mode, then the engineers have some professional ethical questions to answer. I don’t know the full story about the process that led to this software being developed, signed off, and released, but it’s a good time to consider what our ethics should mean.

I hope you would all enforce ethics in your code, and would challenge any questionable decision from within or outwith the team. This is our first duty as professional developers, to ensure the integrity of what we produce, to ensure it meets all legal and appropriate quality standards, and does not mislead.

Unfortunately, it can be easier said than done. Standing up once and saying, this is wrong, can be scary, even when you have documents and a team backing you up, but when time pressure or financial threats hang over a decision, it’s far easier for that fear to turn into inaction or compliance with a bad decision.

So, before you get into that position, review your code of ethics, from your company, and from your professional body (in my case, the BCS Code of Conduct). If your company doesn’t have one, make one. Defer to a professional body if that’s easier, but make sure everyone knows it, and knows that the company will support them if they refuse to do something because it breaches the code.

It’s much harder to be a scapegoat when no code was breached. Take pride in your profession.

More about code reviews

Many thanks to @peitor for engaging with the last code review post, particularly his comments there, which I recommend reading, and his tweet:

@craignicol @yochum Additional to what CodeReviews are for: team building and finding alternative solutions.

— Peter Gfader (@peitor) October 1, 2015

I want to explore a few of his thoughts a bit further, particularly around what code reviews are for.

“team building”

You need to build your reviews carefully to allow team building. As a technical lead, I always get a member of the team, or a peer (if there’s no team yet), to review my code. This can be intimidating for people who believe that there is a hierarchy of knowledge in the team, where the lead knows all, and imparts knowledge. How can such an Oracle be challenged? If I can’t be challenged, I’ve built the wrong team. No-one should release code without review, especially the technical lead, who’s likely to be doing the least coding.

In a properly functioning team however, delegation means that the lead doesn’t have to know everything. They can rely on the developer doing the work to understand the process better than anyone else on the team, and use the review as a learning process to share that knowledge. A functioning code review process not only promotes quality, but it promotes communications within the team.

“finding alternative solutions.”

This is a great use of the review-as-pairing model where the code review is started before the code is complete, allowing for a discussion of options, and the wider context, to ensure the most suitable solution is found.

Maybe you just think of this as a chat between developers, but it’s a great time to review the code and the ideas that generate that code, whilst they’re easier to change. Much easier to change a thought than a test suite.

“What tool can we leverage to make the review more automated?”

I would argue, as @michaelbolton so eloquently does when discussing automated testing with John Sonmez, that the things worth reviewing are the things you can’t automate. Click through and see his replies and the blogs he links to. It’s a gentle but powerful argument.

@michaelbolton Uh oh, someone on the internet thinks I'm wrong. 😉

— John Sonmez (@simpleprogrammr) February 7, 2015

Tools are great. I love compilers, static code checkers, I love the Roslyn examples I’ve seen, but all that comes before the code review. If it doesn’t compile, or it doesn’t meet the style guide, or the tests don’t pass, it’s not ready.

That’s not to say it can’t be reviewed. There may be questions that need reviewed and answered before all the automated stuff passes, but the sign off review requires that the change has passed the automated steps before it can be reviewed.

Also, be wary of following style guidelines. There’s a reason compilers don’t complain about these things. Unless you know why a guideline exists, don’t follow it blindly. Review your automation as much as your code.

“Review not only code in your team. What about the build process? Deployment scripts? Configuration setup?”

Definitely. This might need to involve the whole team, but everything should be open to review and reflect, and where possible, version it so you can review, share and rollback changes. Don’t trust change, but understand it and use it to help you improve.

“Does it stand on its own?”

“What do you mean by stands on its own?As in, the code under review is a complete new feature, or that it is self-consistent (code and tests match, etc.)

Does the change need a lot of explanation via voice? Or is everything there, so that a future reader can follow everything aka the Why? What?”

Does the code leave behind enough context? We all know the scenario where we’re trying to track down some obscure bug, and then we see that 18 months ago, someone used a > rather than a >= and you’re not sure why. The code review is a good chance to document those decisions. If you want to make sure everyone knows you meant “tomorrow or after” instead of “today or after”, make sure it’s explicit, so that when someone calls your code in 12 months time, they don’t get surprised.

Is there anything else I’ve missed?

I love reading your comments, so please let me know

On respect

Firstly, an apology to my regular readers on the delay to this post.  I’ve had a very busy couple of weeks personally, squeezing out the time I have available to blog. Hopefully things will be back to normal next week.

As a coda to my 3 Dear… Blog posts, I wanted to discuss respect.

• Dear developer,
• Dear customers, and users,
• Dear manager

All of these talk about respect, but I realise that respect isn’t always understood. Respect doesn’t mean to tolerate, it doesn’t mean to accept someone’s position blindly, it doesn’t mean opinion is as valid as fact.

It means that I will try to tailor my message to talk about things meaningful to you, I will be technical with developers, I will talk deadlines and finances with managers, and I will talk to users about their business, not our architecture.

I will disagree with you, but I will be open to the possibility that I am wrong, if you can show me why.

If we can’t agree on something, we must respect each other and the team enough to come to a way forward that recognises without necessarily resolving that disagreement.

I will not respect your opinion. But I will respect your right to hold it. I will respect a hypothesis based on that opinion that can be tested and reasoned about. And I will respect the result of that test, if the methodology is sound. I expect that your first hypothesis will not be your last.

I will not respect you because of the title you hold, your seniority or your ability to bulldoze dissent. I will respect you if your actions demonstrate respect, if your words respect your actions, and your attitude respects your words. Power is not worthy of respect. You will be judged by how you wield that power. I will try and wield my power responsibly.

I am open to change, but not for the sake of change.

Respect yourself and the respect for others will follow.