3 ms·
1. Give direction with appropriate detail. Be prepared to give very detailed direction to junior people. I sometimes ever go as far as putting lines of code rig
by edw519 12y ago
1. Give direction with appropriate detail. Be prepared to give very detailed direction to junior people. I sometimes ever go as far as putting lines of code right into the technical specs. Most technical leads hate to do this. They say, "I might as well write it myself." That's because they look at it as an expense. I consider it as an investment because people learn from it. This should make things run much smoother. Important: the level of detail should decrease over time. In fact, your junior person should start pushing back: "I don't need that much detail anymore!" If this doesn't happen, then they're not learning fast enough. This is not normal.
2. You must have your finger on the pulse of everything going on all the time. Not every little detail, but you must know where each project is, plus or minus 10%. Don't let yourself lose track of anything; that's when problems start.
3. Reviews must be daily, not weekly. You don't need status meetings, emails, or project updates, just one minute reviews. 3 day old problems are 2 days too old.
4. Peer review everything your people do until you're absolutely certain you can let someone else do it. And even then, continue to peer review something they do every week. You are responsible for their work; peer review is one of the best ways to stay one top of it, insure quality, and teach. And always be brutally honest with peer review, never bashful. Tell them what's not good enough, what you want, and why. It may be uncomfortable at first, but it will save everyone headaches later.
5. Read "The One Minute Manager". Then do it.
6. Be nice, have fun, and get shit done.
- hyperpape 12y agoRegarding 1, I'll link to a comment downthread (https://news.ycombinator.com/item?id=9009056 https://news.ycombinator.com/item?id=9009056): you're in tricky territory if you're giving direction that detailed. Giving a level of guidance that's appropriate is good. Treating a junior dev as incapable of working except as a puppet is soul-crushing.
- jkaunisv1 12y agoI think the part about backing off the level of detail is important. I've learned a lot about breaking down a large goal into smaller tasks by having it done for me a couple times. Even the first time I was laughing at how specific some tasks were, but it gave me a model to work from when I planned the next one myself.
- edw519 12y agoThanks for the interesting feedback, hyperpape. I agree that this is tricky, or "delicate" as I prefer to call it. What you cite is a classic example of academia vs. the real world. I am currently responsible for 19 offshore programmers of varying skill levels and work habits and this is exactly how I've been handling their assignments for 5 years. I have gotten better results this way than any other technical lead I know. At first, they love the extra detail. Then over time, they push back. And without exception, they all want to be in my group. Grandparent was my own heavy experience getting great results with issues similar to OP's. I know there are academic studies for just about everything, but remember, it's my ass on the line if the work doesn't get done, not the professors.