Be Productive and Stop Using XML

Why managing a software team can be more effective than "regular" management

Over on the team leadership mailing list, Yves claimed:

"Is leading a software team different then leading another team? No 
it's not. Can it help to know about writing software? 
yes if you can also let go of control. 
(which you would have o do if you did not know software) "

I disagree.

Managing a software team is different than managing a non software team, in that software by definition is a soft thing - it rotates, mutates and changes form, and with proper automation, we can break down many time "barriers" which are not possible to break in the real world.

I touched a little bit on this in a previous post, where I said that in software, you can achieve immediate satisfaction, vs. life, where immediate satisfaction is wanted but is many times un-achievable.

The hidden skill: Automation

In software, you can teach and demand that a team break down many such "fake" barriers to be more productive, wheas in real life, there are things that as a manager you might accept as final truth ("mail always needs to be opened manually").

As a software lead, you have many more options to come in and change the flow of things by changing how the underlying team's infrastructure works (automated builds, deployments, tests etc..)

What other things are different in managing software teams?

Manifesto for Continuous Improvement

thanks for the picture, Andrew.

the difference between the picture above and continuous improvement?

The answer to "Are you Happy" is always "No".

Growing developers: Ask for solutions instead of giving them

This post is part of the "Growing Developers" guidance.

One of the best things you can do for the developers on your team is to stop giving them the solutions to problems they are facing, and instead ask them to find the solution on their own.

I'm talking of course about problems that are under their control, not things which require you to make it happen.

A few examples:

• If a developer comes to you asking about what a specific API of the application infrastructure might look like - don't follow your initial feeling. Don't give them your idea of what a good API for that part of the app might look like. 

Instead, ask them to come up with 3 different possible designs, and show them to you. Give them a time frame for coming up with the designs. They can use a peer or the whole team to help get the design of the API right, or they can do it alone. It's their choice. 

When they come to you with the API you might be pleasently surprised by what they have. If you don't like what they came up with, you can explain why you don't like their solutions, and ask why they came up with that solution in the first place.

This would be a great place to ask them what values they were thinking of when they designed the API (maybe none!). This might be a good time to gather the team and ask them to come up with guidelines for an API (short? single point of entry? no singletons?) and then ask the person who came up with the initial problem to go back to the drawing board and come up with another three solutions for the API, and choose the one that best fits the design guidelines the team has chosen.

All this process may take a bit of time at first (instead of 10 minutes of you giving them an API, they might spend half a day working on it if they've never had guidelines before). But this is time well spent. 

What do you get from this?

• The team is honing its skills - they become better at what they do
• The team comes up with shared knowledge about how things might looks in specific scenarios
• The team can now come up with its own solutions to a specific set of problems, using very simple guidelines
• You will be less of a bottleneck next time such a problem occurs

It's important to not only ask for one solution, but to ask for multiple soutions. At the very least, the team is open minded and not dead set on a specific choice from the get go. But there is an added benefit to multiple solutions:

Multiple solutions allow the company to "select' the solution that best fits the current status of the company in the marketplace. For example, one API design could be beautiful, but would take far too long to implement, when you have urgent things to do and get ready for a version.

Another API might be great for the short term but very risky in technical terms as it relies on a third party product that the company maybe disconnecting its ties with next month.

In short, not only are you growing your team and giving them tools to solve their own problems, you are also making the company more adaptable to changes (in the small, but that's something!).

What if they can't decide?

If your team can't come up with a good solution of can't agree on the best one you can help them in several ways: 

• Give them a time-box: "in 15 minutes you should choose one of these and that's it"
• Ask them if they want to add another "value" to decide against to make deciding easier
• Give them hints as to what they may have forgotten to discuss
• Make the choice for them (not recommended)

What if they don't know enough to decide?

You can ask them to learn the subject matter before deciding. it might legthen the decision but you will lower the technical risk of using something you don't understand.

It could also be sign that they are way our of their comfort zone (a team of infrastructure doing UI for the first time for example) - you can ask them to do a small "spike" - a simple proof of concept for a couple of ways to achieve the solution for a problem. should not take more than a day or two.

After the spike they will know more.

This whole idea is just adding lots of time to our schedule!

Like it or not - learning takes time. Things slow down a bit at first. You need to be confident in yourself and your team that you will all be better for this.

This scares you? good. Means you're our of your comfort zone as well! That's not a bad place to be - this is the place where you actually learn something. treat it as an experiment - see what happens.

5 ways to grow great developers instead of desperately looking for them

One of the most common phrases you hear from managers about lack of agile adoption in their team is 

We don't have that kind of 'super' developer here. We just have ordinary day folks - they can't handle it. And We can't seem to find anyone who can fit what we look for.

The real key to being a great leader is that if you do your job right, than you'll make your developers better and better  - you will grow them until they become the developers you wish you had. 

Grow your developers into their full potential and you won't have to seek anyone from the outside

I'm not saying it's easy.

As a team lead, helping people grow was one of the toughest things I've had to do. It got me waaay out of my comfort zone, and i had to do things I'd never imagined doing, but that means that I also  grew personally as a lead while growing other people.

Today I feel more confident than ever that given a team I can start my way to making the team a better team, instead of always looking to the outside.

How do you grow people?

 Here are the the headlines (i'll blog about each seperately)

1. Give them "Homework" about things that will make them better
2. Take them (and yourself) out of their comfort zone
3. Ask them to come up with multiple solutions to problems
4. If you're not happy with someone's current state, be assertive about not accepting it and ask them to commit to be better (management by integrity)
5. Implement code reviews and teach them to do them on their own

Of course, to get all these things going there are several simple conditions that have to be met first:

• You should be spending enough time with your team, at least 50%
• You should have full control of the dev team territory
• You should be fully committed to doing this - this is hard work and will add more tasks to your day