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

Categories
development

Naughtonomy

wp-1450118461565.jpg
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.

Categories
development

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?

Categories
development

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.

 

 

Categories
code development programming

31st January – Developer’s Hangout : The Next Generation

EDIT : Had to correct the link. Sorry folks.

31st January – Developer’s Hangout : The Next Generation

In this month’s hangout, following the last fascinating discussion about recruitment, I want to look further back, into schools and universities and see what people think about the way programming is taught, and how to get the next generation as excited about software development as we are.

Let’s step further back. We’ve discussed recruitment last month, so this month, let’s talk about education. What should we, as people who live and breathe software development, do to encourage the next generation?

Is it up to schools, or is there something else we should be doing? Volunteering at the Maker’s Fayre? Or is everything just peachy the way things are, with programming an ever more expensive hobby, ever more divorced from using a real machine?

Is the Raspberry Pi a good move for teaching, bringing back the BBC Micro and the 8-bit days or is it irrelevant in the modern world of touchscreens and consumer technology?