How do I succeed as a lead developer?

Question

I have become the lead developer in a particular project, but I'm having difficulty focusing on the big picture and making sure all pieces of the project are covered.

What should I keep in mind when managing this project? How can I make sure everything gets handled the way it should?

Answer 1

I've seen this trip up other developers as they make the transition to senior or lead. Here are a few suggestions I've made to others.

• Understand what the goal of the project is.

Often it isn't about all the features that have been pushed into the project. It's about a core set of functionality that is addressing a business need. Always keep this in mind because that is your primary goal.

• Breakdown what needs to get done into tasks. Understand the dependencies between them.

Breaking a project down should be pretty straightforward. Break it down as early in the project as you can. If you have to gloss over parts, understand that they pose a risk until you understand what has to be done.

• Understand what the open questions or ambiguities of the project are.

You won't be able to resolve all the ambiguities initially (although you should try). Make sure your manager and the project stakeholders understand what they are and what risks they pose to the project.

• Business hates surprise.

Make sure everyone knows (ideally on a daily basis, but weekly works) what the status of the project is. And by status I mean what has been done, what is left to do, open questions, problems, etc. Anything that can impact the completion of the project should be reported.

• Everyday, go over the big picture.

You should go over the big picture every day for an hour. Ask yourself the questions. What's been completed? What's left to do? What are the open questions? What's the goal? You should be able to give someone a detailed status of the project whenever they ask.

Answer 2

The first piece of advice I'll give you is to accept that managing the team is more critical than doing your own programming tasks. That means when you have 3 juniors who need help, it is your job to help not to whine about how it is taking you away from the developing. As a lead, you often become the roadblock to progress if you are too focused on your own development tasks first.

Additionally you need to learn to delegate. It is hard to give tasks to someone when you can do that easily in an hour and you know they will flounder for a day. However, they will never progress unless they get the tasks and you will be working overtime while your team is playing games.

Further, never just fix someone else's code. Tell them what is wrong (and why) and make them fix it. Or you will get in a cycle where you have to fix everything because they are not getting any better. If they can't fix it, then consider if they should stay on the team. Don't let weak team members stay because you are fixing everything they do.

As lead, you get to be the bad guy and give them the unpleasant news (both up and down the chain). That goes with the job as well. That means you have to do the poor performance appraisal; you have to tell them that the deadline was moved up or the requirements have changed; you need to push the lazy guy who isn't making progress; and you have to tell your superiors when the deadline is not going to be met and why and what you are doing about it. Being lead is not about being liked, but about being effective. Your job is to get software out the door, not make friends. Communication is key and avoiding the bad news ends up making the situation worse. A client is far more likely to handle being told it will be three more weeks a month before the launch than they will when the launch date passes and then you tell them you need three more weeks. Managing by wishful thinking (sure we can just pull some all-nighters and get it done) is the surest road to failure that I know of.

Answer 3

Here's my informal checklist. It's very informal... I don't do everything everyday, but if I haven't hit all these things weekly I get a little worried, and if I haven't hit them monthly, I should panic. And the mileage varies entirely based on company/team culture, personal style, and type of project.

• Talk to team individually - does everyone on your team - have useful work to do? know what the overall goal of the product and current release are? do they know how you make money and what the major thrust of your business is? do they know how their current work fits with all of that?

• Talk to team collectively - get them all together with major news, get groups together to make sure communication is happening with and without you. As a small team, this is probably group strategy sessions. As the team gets bigger, it will become the case that you have to guide them through the major points, and it will inevitably become a you talking at them scenario. That's not wrong - there are times when it's very important that everyone hears you saying the public information to everyone. So everyone knows that you're giving the information universally. But the "you - to - everyone" meeting is very different from the group strategy meeting where you are more of a guide.

• Sample the team's work - try to get a bit of a survey of everyone's work. Read their code, run their functions, try their test cases. Don't aim at 100% of everyone's work, try to sample a little bit from everyone. Give them feedback, but also file away areas of strengths and weakness across the team.

• Check in with your management early and often - this isn't brown nosing, this is keeping in the loop. If you don't know what your management needs and what your management is thinking then how can your team possibly meet the expectations? You need to have a really good repore with your boss and you need to be on his team, the way your people are on your team. Being able to communicate effectively with the boss on trivial stuff raises the confidence that you'll be able to get help and clear understanding when the crisis hits. It's also a good reality check for where your big picture blinders are.

• Review team resources periodically - people will screech when a previously available resource becomes unavailable, but review for unknown points of pain. Where are your chokepoints? Are there new tools that would be useful to have? Most teams have a guy I think of as the Tool Hunter who is always up to speed on the latest and greatest gadgets. Balance out conversations between Tool Hunter and GuyWhoHatesEverythingNew to find the next point for evolution. Tools include everything - SW, HW, physical space, learning resources.

• Know and keep in touch with support teams. Every company is different, but know the people in charge of your quality control, document writing, legal, facilities, finance, and any other supporting groups unique to your business. They are the best big picture triggers I can think of, because they see the world entirely different from you.

• Know your competition - spend at least some time each week figuring out how someone would solve the problems your product solves if they weren't using your product. It may not be a single company, but what does that other solution offer that you don't?

• Review cost and schedule - How likely is it that your team will mean their current deadline? How about the next deadline? What's the burn rate of your costs? What big upcoming purchases haven't you paid for yet? What's left of your budget? The details vary with how you do financial tracking, but even in a very informal company, you should have some idea of both how many days/weeks/months of budget you have left and what your deadline is for the current product. Somewhere, somehow someone had better be planning "how many people do we need to do this job?" and "can we afford to pay them next month/quarter/year?". You need to know those numbers and have input on the next steps. You need a crystal clear plan for next week that you could explain right now if someone walked in and asked. You need a pretty good plan for next month, that will only change in 2-3 places when reality hits. You need a sketchy plan for the quarter and a general off the top of your head gist for the year. Past that, even in huge project, the numbers are just numbers. Listen to them, but realize that no one signed in blood.

That's my off the top of my head list. I generally add to it as I get smacked upside the head by a "surprise" (picture me sayintty sensitive to an area I missed and then I manage to fold it into the check list.g "surprise" with a forced grin and gritted teeth).

Also - be prepared for the Dread Context Switch. If you are just starting in management, it's likely you have a small team and someone up in management thought it would be fine for you to spend some time managing a team and some time doing individual contributor stuff. This can be done, but the context switch between the two is rough. Plan for it. Block off time to switch (like before and after lunch) and know your less practiced skill set and realize that you'll need to drag yourself there the first few times - so book off time to do something "big picture related" and figure that you'll need at least two hours to really get anywhere.

The context switch works in both directions - management to hands on work and vice versa. But when you go from your point of strength and practice to your place of discomfort and less practice then you feel the pain more and the impetus to retreat is strong. Know its there and fight it and realize that thrashing around in the big picture makes you better at taking it all in. Give yourself time to thrash.

Answer 4

Read this book: Herding Cats: A Primer for Programmers Who Lead Programmers

_{Some time ago I gifted this book for my boss and he liked it. When I was reading it, it seemed that he knows what he is talking about. And this is so. The author tells about his own experience. Is not a collection of manager's "simple truths" - these are the words of former programmer. And it should be understood that it was HIS experience, but yours might be different. So, on some things you should look critically. "Manager can no longer be a programmer - it is important".}

Answer 5

When I took over the technical leadership of a small company recently on a product I didn't develop, what I found very helpful in managing things was to document in plain english the workings of the product—features i documented in cucumber, and for internals I wrote up explanations of the object model and flow through various controllers. What I found in doing that was that A) the product was a bit of a mess :) And B) I learned much more quickly how the app worked, so I could have an intelligent conversation about what problems were there and what needed refactoring, or what it would take to implement a given feature.

Pictures also help—i don't mess with products like Visio, I just use crayons and blank paper (really, I do—I work from home and often alongside my 2 year old) but whatever works for you is what you should use.