Call for content – what do new team leads need to know on the first day?

About 5 minutes after I posted about eh existence of this blog on twitter, I’ve gotten lots of great feedback (and various little nitpickings) about the content, what I shoudl talk about and things that I might cover.

This is your chance to influence the topics this blog covers : What topics do you think are essential for new team leads to learn if they’ve never done it before?

What tips or tricks would you give them?

What topics would you make sure they learn?

What topics have you learned about leading teams that are not covered in *any* book?

Comments

[Steve Bohlen]

In my experience, most if not all of the Agile/Lean/<your-new-methodology-here> approaches boil down in their implementations to the following core ideas (NOT in order)

1. transparency and visibility of process (no secrets between anyone)
2. willingness for introspection (to enable course-correction)
3. rapid --immediate is best-- feedback on everything you do (req'ments, code, deployment, etc.)
4. reducing waste (in all its myriad forms including working on the wrong things)
5. managing a technical team isn't about technology, its about managing people who *use* technology
6. never lose sight of the BUSINESS purpose behind the software you are building

Anything you tell anyone who's getting started managing a team that supports these core values is probably going to help them. Getting lost in arguments about the 'right way to do SCRUM', the 'right way to do Kanban', etc. us pointless. Philosophies that have at their very foundation the implicit (and often explicit) premise that "context is king" and "teams should choose an approach that is effective for them rather than follow the rules of others" by their very definition will resist prescriptive guidance from outside the context in which they need to be applied.

A site like this has the potential to be very helpful to those just starting out in this area, but I think it would be most valuable as a sort of smorgasbord of choices from which visitors could be made to understand the relative pros and cons of each technique, tool, practice, etc. based on the experiecnes of others who have tried various of them in the past rather than a step-by-step "first do this, then do this, then do this..." kind of thing which is very likley to be taken out of context, applied where its inappropriate, and lead to more first-time-failures than first-time-successes.

Its my experience that software develoers are internally wired to ask "where is the sample app for this?", "where is the best-practices guidance white-paper for this?", etc. and this is *barely* appropriate where we're talking about a technology implementation -- it can be downright dangerous to offer practice guidance without extremely clear delineation as to the context for which the guidance applies.

I'd rather see a site like this present various options in a style similar to a 'patterns' listing where there is a clear statement of practice, its pros, cons, and appropriate context so that visitors could be better informed to make the choices they need to when trying to assemble a process likely to work well for their situation.

Just my two cents -- I applaud the idea behind what you're trying to do here, but I fear that absent clear context all its going to do is produce people following this guidance right into a dead-end :)

[lior]

>>What tips or tricks would you give them?
1) Admit that you dont know everything.
many new team leaders I've seen assume that they must know everything when they start out.
admitting to themselvs and to others will buy a new leader the time needed to learn
2) Pick a good management book and read it

>>What topics would you make sure they learn?
How to manage - people. Yeah i know its kind of obvious. But I think that too many just skip this.

>>What topics have you learned about leading teams that are not covered in *any* book?
The main thing is that no matter which tool/technique you know that it will not work ALL the times.
People are just too different from one another and some techniques which worked great with specific people, wont work on other (and might be a disaster to use).

[JacobM]

Here's a question: for lead developers, who are guiding a team and overseeing the architectural design, but also writing code, how should they decide which codeing tasks to take on for themselves?

[Doron]

How do I help people grow, while still meeting my business goals?

[Jane]

To some extent it depends on whether the new team lead knows the rest of the team or not, or the product/project that the team are working on. But, getting to know the team must be pretty high up there. Find out, via 1 2 1 chats, what they like doing, what they don't like doing so much, and make sure that you can play to their passions when allocating workload. Find out where the project/product currently is, and what the main headline issues are - I sat down recently with my team and got their views on their concerns, what's going well, what isn't going so well. Basically, holding a Post implementation review style meeting during the project to get a good grasp on where I was starting from.