Should you grow even a short-term consultant in your team?

What if you have a short-term consultant on your team? What if you're the team lead for 

just this project, and there will be a new team lead in the next project?

Should you work on growing people even in those situations?

My answer is an unequivocal yes. (unless we're in chaos mode).

People who come across my path , even for a short time, will get the same

amount of respect, expectations and challenge from me, as if they were there forever.

I will try to always leave people who I've led, better off than they were, in terms 

of new skills and challenges.

It is in my personal integrity to do so. If you conduct yourself this way,

you'll find that people will want to work more with you, and will remember you 

even years later, no matter how short the project was.

You never know when you're going to meet those people again, and 

you may find hidden treasures are laying down in your future path, just because 

a few years back, you did the "right thing" with people who didn't expect you to.

Show a personal example that even in the short term, you do not give up 

on quality (of people, of leadership). 

Elastic Leadership course in Amsterdam - July

Join me this July for two days of elastic team leadership workshop. Learn new skills, get out of your comfort zone, and learn to lead better.

We can tackle all the hard questions together.

I'm also looking for a venue to host the course in - so if your company is willing, you can get a couple of free tickets! Ping me.

On time, with quality - why is this mostly failing?

Everyone in the software industry seems to be talking about the quality mantra lately. Agile, XP and kanban brought this issue to full front, but I see many team leads failing with the quality part.

Many of us keep chasing quality and never achieving it, because we don't know how to make time. We don't have any time to learn/teach the team and practice true quality code (unit testing, tdd, acceptance and automation to start with) because we're in chaos and we are addicted to it.

Our lack of time makes our decision to focus on "getting things out the door" more frequent, and so we have more quality issues and even less time, because we just have more and more fires to put out.

To break this pattern, true leadership from us, the team leaders at the bottom, is needed. It's about taking a risk and breaking the cycle. It's about making time to learn.

Want to ship on time with quality? remove some of the commitments you have, make time to learn, practices, and build quality into the code you're writing. You can't get better at what you do if you don't have time to get better. and You don't have time because you keep chasing your tails.

So you have to break away and make time by removing some existing commitments. That's scary, but it's your job, remember? Here's your manifesto again.

Middle Management or puppet management?

Most team leaders I've seen in lead roles usually feel quite helpless. Someone put them in their position, and no one taught them how to do their jobs. So they are mostly developers who are just trying to keep the status-quo.

They either don't want to, or not sure how to lead the team, and what's their role in the team. 

They don't feel like leaders, and they mostly act as puppets for upper management for setting (sometimes) impossible goals and chasing them.

If you're that team leader, you should realize that your job is to lead people to do the right things, and to do the right things the way you believe is right(for everyone involved). That's your job. That's why they pay you more.

Management, done right, is a very tough job. That's why you get paid more.

But maybe no one ever told you this. I'm telling you this now. Your job is to make your own decisions, and find your own voice. and to lead.

Your job is to build value, and knowledge in the company. Your job is to grow your team to become the best bloody team they could be.

This is your manifesto.

Scared? Great. Means you're about to start learning new skills, and get out of your comfort zone.

If you're looking for a QA to automate your tests, you've started to fail

If you are looking for someone to join the QA team to automate tests, the failure is in the way the system is built. Your *developers* should be proficient (or start learning how to) in automating the tests, creating automated tests, and overall  be able to automate the hell out of everything.

Having a separate QA department is a fail in that, there is an explicitly delegation of all those "things QA folks do" to that other department, so that devs can focus on the other things.

at the very least start with each team having a QA in the team, that is part of the team. then spread the knowledge of the QA dude to the rest of the team. 

By looking for someone to do all that "other work" is keeping the system in fail state. instead of starting to grow your devs to be able to become better, and do that work so it's part of their work. *it is*.

Steps I'd take(assuming the team is in the learning phase):

1. Start getting each dev/team into automation thinking mode
2. Having small goals to automate more and more things, as we write them
3. doing code reviews with an "automation" theme
4. Having "automation week" a the team level