development leadership

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

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 ).

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.

development leadership

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?



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.

code development programming

Event Horizon : When sharpening the code means missing bug zero.

A great programmer sees software as a craft, honing a perfect solution from a sea of binary logic. Good software is beautiful outside and in, and even on a large scale is simple enough that there are no obvious bugs. They produce software that is precise and clean down to the last detail, continually improving quality. 

But it’s easy to fall into the trap where quality beats everything. The software cannot ship until every bug is fixed, every scenario is covered, even the heat death of the universe. And the software still hasn’t left your machine.

Until your code is in front of your users it’s an untested hypothesis about what they want and what they can use. And hypotheses, no matter how precise, have a habit of not surviving contact with reality.

Test early, test often 

So start with a smaller hypothesis. Remember that for most of what we do, Newton’s laws of motion are good enough, and simple enough. Unless you’re building something that depends on very precise timings and/or very high speeds, you don’t need to handle relativity.

So ship it.

Build it. Test it. Ship it.

Prove your hypothesis meets the real world, and use it. Define your MVP. Cut it to the bone. And ship it.

Make sure you’re building the right thing: ship it.

Bug Zero 

Every project has a bug zero: no-one can use something that doesn’t exist, and isn’t live.

Fix that bug first, because every other bug depends on it. Either the bug is important enough for them to complain and tell you want they want. Or it’s never used, so remove the functionality.



Fear of failure, and risk-takers

We all make mistakes. We should learn from them, whether it’s because we didn’t know enough, or because we’re taking a risk. People are afraid of mistakes. We’re afraid of being found out. We need to fight imposter syndrome, and tell the world we are not phonies. So we don’t want to fail, we don’t to make mistakes, so we avoid taking risks.

But what if, when we ask Is it OK to fail? we start asking instead, “is it OK to learn?” or “Is it OK to to take risks?” If you feel like an imposter, that you’re out of your depth, you have 2 options:

  1. Decide you need to learn. I’m currently in charge of a team that’s moving to a more devops culture, and I don’t know enough to know if we’re doing it right. So I’m reading, and testing, and building out my knowledge, so that I can make some mistakes and learn from them, to help me understand the mistakes bigger teams made so I can learn from them too.
  2. Decide you don’t need to learn. Trust your team, or a 3rd party to deal with it for you. Learn how to detect bullshit, and let them deal with the detail.

I loved reading Risk taking and imposter syndrome at Google where Google talk about battling imposter syndrome head-on. When you are surrounded by the brightest and best, you are always going to struggle with confidence. So ask everyone what risks they are taking, and what they’re learning. What do you know today that you didn’t at the last stand-up?

When you are adding value, no-one will think you’re an imposter. And hopefully, neither will you, but when you do, know you’re not alone.

Go learn.



development programming

Your API sucks : notice period

Based on a true story, although as one of the clients in question, I can’t guarantee the validity of the conversation. Any similarity to any developer alive or dead is purely coincidental.

“Dave, we need to make a change to our API.”

“Is it a zero-day security issue?”

“Nah, but it’s pretty important.”

“Will it break existing clients?”

“Yeah, probably, we used to recommend 128-bit keys, and we need to jump to 512-bit keys.”

“Do you think we should tell our users?”

“Yeah, probably. Want to let marketing know?”

“Shall we tell them it’s important?”

“Nah, they’ll figure it out.”

2 weeks pass

“Hey, support  have started getting a lot of calls about clients who cannot connect to our API, any idea why?”


“Did we make a change and not tell our users?”


“Do you think we should tell them?”

“Do we have to?”

Remember, even if you do give a positive notice period, your clients will need lead time to update their code.


The importance of language: company culture 

There’s language you use in a team that defines the project. The language that a company uses defines every project. Get it right and the company makes people happy. Get it wrong and your staff, and your customers, will start asking what’s wrong, and you might not be able to tell them.

Don’t be creative

Software development is just a matter of sitting in front of a keyboard and typing. Thinking isn’t software development. Designing isn’t software development. Talking isn’t software development. Even if it’s talking to a duck. Therefore, in order not to disturb those who are working, get away from your desk and go be creative somewhere else, you anti-social malcontent.

Or maybe lateral thinking and problem solving are exactly what you’re paying software developers to do. Just because you don’t understand the beauty of what’s being produced, doesn’t mean the beauty isn’t there. I understand developers need quiet time, but most developers (and any developer I’d want to work with) need to be social. Sometimes you talk through a problem, sometimes you debate alternatives, and sometimes you chat over a coffee to take your mind off the problem for long enough to be able to find the solution.

Just one little thing 

Software development is easy. Sure, there’s hard problems, but that’s what those other guys in Microsoft, and Google, and Apple do, not us. So those requirements we asked for an hour ago, should be done by now, right? After all, it was just one change to our database to support transgender employees.

OK, so I didn’t realise we didn’t have Mx as a title, but that’s just one other little change, right? No, I don’t know what a boolean is, or what that’s got to do with the gender column, but you can just add one more value, can’t you? I don’t know whether all the historical records need to be changed, I’m not a developer, can you just add support for transgender or not?

Just is a very dangerous word.

Right first time

We’re a company that our users can trust. We don’t make mistakes. We do it right, first time, every time. And anyone who doesn’t can go work for someone else. Losers.

Or, we’re a company that doesn’t take risks. We’re scared to fail and we don’t know how to recover from failures. If we make one mistake, our house of cards will fall and our users will leave. We don’t innovate, we can’t adapt. And if we fail, we’ll blame someone else. We’ll brag about our self importance to cover up our tiny exposure, and we’ll come down like a ton of bricks on anyone who questions us.

Don’t be that company. Sometimes things fail. Expect failures, expect things to go wrong. Figure out how to recover. A customer who has a complaint dealt with quickly is often a happier customer, and a better ambassador, than a customer who hasn’t, or can’t complain. Don’t make mistakes for the sake of it, but take risks, be interesting, and learn to right yourself when you capsize.

development lifehacks

Take your laptop home

The modern workplace demands flexibility. Sometimes to accommodate work, because international companies need to work to international timezones. Sometimes to accommodate life. Don’t discount good staff because they have childcare duties, or other demands on their non-work time. 9 to 5 isn’t the only way, so long as people do the work and are involved in the right conversations.

As a worker though, that flexibility in hours means that sometimes you need to work after bedtime, or you need to learn about a new technology in an evening or weekend event. You don’t stop thinking when you leave the office, but you can stop taking every call.
The modern workplace is noisy. It’s full of distractions. Go home and disconnect so you can have the peace you need to get in the zone. But put it in your calendar, in advance, so no one is surprised.
But only take what you need. Prepare your equipment and your space. Make it productive.
development leadership lifehacks

Don’t take your laptop home

To fit a good work life balance, your work should stay at work. My previous job supplied me with a laptop and rules, when working at certain desks, that I had to take my laptop home “for security”, and it became second nature to carry a heavy bag with heavy laptop, heavy notebook, and several printouts, because I’d need them.

It made sense for the job. I was on client sites a lot, and didn’t know when I’d have a network connection, so I had to take what I thought I’d need with me. And I’d check email on my personal phone because 3g/4g is far more available than WiFi.
I told myself it was OK because I was using webmail so I didn’t get notifications on my phone. But then I got phone calls on my mobile. At night. On holiday. Boundaries crumbled, and yet my bosses had it worse. They’d give me battle stories of weekend working and lack of sleep, as if poor planning at a company level was something to be proud of.
Let’s be clear. A culture of antisocial hours is a failing culture. A culture that bleeds onto personal devices when I pick up the cost is a failing culture. A culture where people brag about it is a failing culture. A culture that asks for a hackathon to work on things no-one can get a budget to fix is a failing culture.
I’ve heard horror stories of companies set up for one or more of the above. It happened to me occasionally on the odd project, and when I was leading, I made it my responsibility to identify and fix the root causes. Failing once is a good opportunity to learn. Twice is a warning. If you fail the same way 3 times in a row, it’s a dysfunction you should stop everything to correct.
I don’t have a laptop bag in my new job. I have a place to leave it overnight. I don’t need papers to visit clients. It’s lightweight, and technology has moved on so WiFi is available. Taking a laptop home is an exception, not an expectation.
To those who need their laptop out of the office:
  • Travel light. Small notebooks are better, tearaway pages are better still.
  • Don’t bring your own device. If a company needs you to access work outside the office, they will pay you to do so. Or at least give you reasonable compensation. They’ll have a sane home-working policy, or a laptop-installed communication channel. If you can’t use Unified communications, or at least VOIP, things should change.
  • Treat long hours as a bug. Fix it. If the company can’t fix it, the culture is wrong.
  • Antisocial hours may be required, but they must be compensated for in whatever reward suits the worker best. And planned ahead whenever possible.
development leadership

Dealing with stressful relations

happy sliced bread
“…until everybody does what they’re always going to have to do from the very beginning — sit down and talk!”

Sometimes, there are customers, and users, that frustrate us. They tell us we’re idiots because we built what they asked for (not what they needed), or because they changed their minds. Sometimes they change the hardware, without telling us, into the DMZ, and then get us to figure out why the intranet site no longer works with single sign-on. Sometimes they ask us to draw red triangles with a blue pen.

Most discussions with the customer are straightforward, and you each understand the others strengths, but when things like this happen, especially when there’s a lack of honesty, or a common understanding, it’s easy to quickly reach an impasse and finding yourself getting angry.

I used to work in a call centre for an ISP, where much of the stress was already in play before the customer phoned. I had to learn to deal with people calmly, even when they were clearly upset at not getting the internet service they’d requested. My induction trainer said he took it as a personal challenge to have a customer like that smiling by the end of the call. We had limited tools at our disposal. We had engineers we could call, and we had certain discretionary payments that could be made to compensate for lack of service (although I note that my mobile provider pays these automatically, which is a far better customer experience).

Recently, in the news, there was a story about a wedding venue whose manager was annoyed by a particular bride and decided to challenge her on a forum about it, despite the bride not mentioning the venue, therefore dragging herself into a mess, especially once the other brides in the forum got involved, and she started posting contract details publicly.

It was not a good way to deal with customers.

I have seen it before. It’s an attitude I see when an incumbent supplier loses a renewal to a rival company, and tries to frustrate them, to make it look like the new team are incompetent, without grasping why they lost the contract in the first place. I see it with certain managers who have trouble relinquishing control. I’ve seen it with the customer who said “if you could only write bug free code, we wouldn’t need to test”. I can see where their thinking is coming from, but each example breaks down the trust between the customer and the supplier, and causes barriers to go up, which inevitably make deadlines trickier to meet, increase procedural safeguards, and kill any hope of agility.

I’m not always a people person, but I understand the importance of trust in maintaining these relationships. If you find yourself getting frustrated, don’t take it out on the customer, however much you may feel they deserve it. The customer isn’t always right, but they always deserve respect, if you want the relationship to last.

  • Take time to reflect, and calm down.
  • Sound out the conversation you want to have with an understanding colleague, or a rubber duck, so you can get to the meat of what you want to resolve.
  • If you need to sit down and negotiate a peace, set some groundrules.
  • Always challenge yourself to make the other person happy.
  • Be honest.

And it’s not just your customers, I’ve had to deal with big disagreements in the team as well. Sometimes you need to shepherd the team, and sometimes you need to manage them. Just don’t become part of the problem.