I'm thinking (with a strong preference for leading from behind) that my team's members will inspire the project with their own predispositions and inclinations if I give them the space this requires; I lay out the requirements, promote good methods and processes, and then let the workers do "their work" while I do "mine". I have in mind the worker who is trying to implement something but has been MicroManagedIntoAutomaticity, a type of DoubleBind that can easily enough be justified. Within the container of proven methods, let the people doing the work do the work. ''I'm making reference to day-to-day hour-by-hour basis here, not the occasional intervention, ''viz''.: if the foreman spends his day head down pounding nails, who's supervising?'' -- BenTremblay (with thanks to the WikiGnome''''''s) ---- ''I think there's two kinds of leader. TeamLeadersDoDo - but leaders directing more than one function shouldn't do.'' I'll quibble that: team leaders ''lead''; team '''members''' ''do''. But yes, of course, there is a continuum here, from the leader who spends most of her time hammer-and-tongs to him who occasionally refactors a bit here or there (by way of example or to avoid some imminent snarl) ... a matter of granularity. -- BenTremblay ---- I think I need more context. I'm more accustomed to a LeadByDoing model. -- GarryHamilton ''"He who hesitates is lost" | "Act in haste, regret in leisure"'' We would profit most by drilling through to the concrete base of these pity sayings; I would surely hope to deserve having my methods emulated by team members, but many (number) of the activities I clear is outside their job description. Likewise, it's only because they do what they do (quantity) that I have the time to do that many things. -- BenTremblay ''An example: I run a team that defines technology standards for the rest of the organisation. I have in the team security experts, Intel server experts, Solaris experts, Networking experts, storage experts etc. They evaluate technology, determine how we should use it, assess risks and so on. I can't do any of that as well as they can. I can say something about '''how''' that is to be done, from the point of view of project management standards, requirements definition, explaining how to trade off technology best practice against the needs of the business etc. So, I don't do (what they do), but I do lead. I do do what I say they should do when it comes to practices we share (like reporting, defining requirements, meeting commitments, project planning etc).'' Ahh, and here we have that uncomfortable disconnect between "leading" and "managing" -- leadership, in its truest sense, is an on-the-ground thing, while management is more of a directive "above the action" position. ''I'm intimating that there's another dynamic mode. (Evidence perhaps that I've avoided getting into management?) If I could, I would glance at individual SitRep''''''s every 15 minutes, have a good look every hour, and read them through at least twice a day (cyber version of ManagementByWalkingAround?) I should only have to dip my oar in the water rarely, either because we need a mid-course adjustment or because we're bearing down on a rock. -- BenTremblay'' I think that might (just) work for managing a project, for a while, but it misses all the fuzzy stuff about developing the team, spotting individuals who could do with a bit of coaching and support etc. It's all a bit one way, too - you need to be an exemplar: the team won't get to see you doing all the best practices you'd like them to be doing. Interventions have many reasons, and correcting project progress is only one of them. [also references AgilityTest] To be sure, management must embody some leadership qualities, but the broader the context becomes, the more difficult it becomes to lead rather than manage. [A neat use of the distinction; has the distinction itself been established clearly ''ala'' PhenomValence DistinctionClearNot?] To lead, one must almost certainly "do" to provide example, while, once the spectrum broadens sufficiently, it becomes almost impossible to "do" in any relevant way, and one must now manage. [I'd point to the BriefEntity series as exemplary of WhatLeadersDo in apparent contradiction to LeadersDontDo (apparent because the LeadersDoDone is a finite rather than ongoing entity; that leader has done, and so might not be doing now, while we are doing ... even if we aren't leading but rather following what the lead has done. *sigh*'' see BriefIntro, BriefComments, and BriefTutorial; these not only exemplify "brief" but also "describe page" ... just hit "like" and you'll see PageDescription in all its glory. Now '''''that's''''''' a fine example of leading by having done. :-) -- BenTremblay ] I'm sure this sounds like semantic gnit picking, but I think it holds water despite being a somewhat off-the-cuff analysis. Comments are welcome. -- GarryHamilton ''I'm not sure how far up your post extends, garry. h_b'' I think use of the term "leader" here is problematic. I strongly agree that ''managers'' shouldn't try to do their subordinates' jobs, but I think anyone who wants to be a ''leader'' has to be seen as a participant. The most effective leaders I've worked with generally had no formal management roles, and gained their leadership positions by being superb performers and assistants. -- KrisJohnson ''Leading, supervising, managing. Here are some uses of the words from my StarcraftGame: I can't '''lead''' my zealots into an attack, because I'm not there. I'm above, watching and giving some very specific commands - attack this, move there, run away from that. I can give a general command, such as "romp through that area and kill everything you can find until you're dead or they are", but since the little blighters don't ever learn, it is sometimes very important to MicroManage them. When I have the upper hand, or things are otherwise quiet, I can merely supervise. I ignore the units until I hear, "we're being attacked!" or I see some enemy units on the map.'' ''Sometimes I put hallucinated units at the front of my formation. They are cheap to create, and they'll be the first to catch a faceful of siege tank fire. They may be at the front, but they aren't leading.'' ---- Funny, I misread ''LeadByDoing'' as ''LearnByDoing''. Then, seeing the edit following hot on the heels of LeadersDontDo I came to the conclusion that the editor meant to say that LeadersDontLearn. This might follow, if the leader spends his time leading and not doing... ''That's the likely consequence of becoming disconnected from the work. But is it binary, i.e. either I do the work or I'm oblivious to it? I can't imagine actually leading effectively while being on Cloud 9.'' -- BenTremblay ---- See also: DevelopmentTeamModels, ManagersDontCode