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
leadership Uncategorized

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.

Categories
development leadership

Bootstrapping new developers

Dawn behind the trees
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?