When I was doing management in software companies, I found Management By Wandering Around (MBWA) [1] to be useful.
Being an unstructured activity (but still planned, in the sense that you knew that you were going to do it now and then during the day or week), you tended to get more out of it in terms of information about progress, status, issues, and being able to help team members, technically or otherwise.
It was supposed to have originated, or at least been used early on, at Hewlett-Packard (and also earlier by Abraham Lincoln :) see [1]).
Although I worked for a while in a company that was a joint venture with HP, I did not learn about MBWA there, but later on, in another company where I was doing management. Read about it in a management book, thought it was a good idea, and tried it out; turned out that it was useful.
Not to detract from your experience, but this sounds a lot like micro-management.
You should not have to check up on the status of ongoing projects; you assigned those projects to someone with clear deadlines, etc. etc. If you don't trust that person to be able to finish it: why did you assign it to him? If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?
Thanks for your comment, I am open to discussion or disagreement, although I may or not agree with the specific points raised - on a case to case basis.
>Not to detract from your experience, but this sounds a lot like micro-management.
In this case, I disagree that it is micro-management, although I do think that if overdone, it can degenerate into that. It is a matter of degree and also of how it is done.
See my replies and quotes of excerpts of your comment below.
>in the sense that you knew that you were going to do it now and then during the day or week).
So the emphasis is on "now and then" (and "now and then during the day or week" did not mean "multiple times during the day with the same person", at least as I used to do it).
Once a day with a few people (not every member of the team per day, e.g. in the case I am talking about, I had a team of 10, and might have had the one-on-ones with say one to three of them per day, and not every day either), and that would be enough, unless there were some serious issues, in which case more management or help or guidance is definitely needed, or the manager is not doing his/her job.
Also, it was not like I was grilling them on goals and deliverables each time I talked to them - it was more like sitting down next to them and asking "how is it going?" and only if they mentioned any issue or problem, would I delve into it and see if I could help. Sometimes they would themselves tell me that they had an issue and ask for advice/help. It was not an antagonistic relationship. In fact the chief accountant of the company, who sat in a section next to us (this was a company with cubicles, ha ha) once said to me (presumably he could overhear us talk since he sat near us) that "you have a good team". I took that as a compliment.
Actually I also used to informally (as in, not a formal code review, although we had those too) look at the code they were working on currently, and sometimes would spot issues (could be small ones like redundant computations like checking the length of a string being looped over, in the for loop itself, instead of before it (aka code hoisting - see Writing Efficient Programs by Jon Bentley).
It was technical and project management, BTW, not MBA-type management. (Project management might have a different connotation in Indian companies from some Western ones, in case you don't know that. In Indian companies it tends to be a blend of both technical and project management (as US people understand the latter term). (I've worked in/with both Indian and US startups and large companies (all 4 combos), that is how I know this.)
Also, in this particular team, they were all freshers, just out of company training after being recruited, so more management was needed. [1] But I think MBWA can be helpful even with more experienced people who report to you - maybe at a lesser frequency.
Multiple issues with your comments below:
>You should not have to check up on the status of ongoing projects;
Sorry, wrong, IMO. A manager's job is to manage (though not micro-manage; hell, even micro-management may be appropriate in certain situations, depending on the skill and experience level of the managed people, and a host of other factors.
Please don't generalize. And checking on status is a normal part of management duties.
Repeating:
>>You should not have to check up on the status of ongoing projects;
That is so far off the mark that I am almost at a loss for words (but not quite :) If an employee cannot handle the fact that the status of their work has to be checked on, then they are violating the contract that they voluntarily signed up for when they joined the company (except for free-wheeling companies where they may be no such agreement), because in most employment agreements, it is a standard clause that the employee has to follow the instructions of their managers (obviously, only regarding work, not anything else, and within reasonable limits, but status reporting and checking is very much a part of reasonable limits).
As I've heard it said, a project or a company is not a democracy. Just check out real democracies if you want to get an idea of what chaos can happen if you run a project or a company as such, ha ha. That does not mean that it has to be a command-and-control situation and everything is to be decided top-down either - that often does not work too. It just means that there can be a reasonable amount of discussion about how to do things, what to do, etc., between the team members and the manager, but ultimately the manager's decision has to be final (mostly - and any enlightened manager who does not have ego issues should/will accept the suggestions of team members if they are better than what he/she thought of). Of course there can be incompetent or evil managers, for that the remedy is to go report the issues to higher levels or other options (including legal), as needed and makes sense.
And:
>>You should not have to check up
The manager carries the responsibility for the results of his subordinates, so he definitely can and needs to check up. I am not sure, but based on your comments, you might be coming from the background of some small US startups, where everything is on the fly, free-wheeling, "cowboy coder"-style, etc, or might not even have worked much in real companies. I don't mean to denigrate that approach in total, but in many cases, it does not work. I have been on both sides of the fence, for non-trivial periods of time, both working for/with small and large (so-called "enterprise") traditional companies, as well as small free-wheeling US- and Indian-based startups, at different times in my career, including switching from one type to the other and then back again, so have seen both (or rather multiple) sides of the picture, and have come to realize that there are pros and cons to all those approaches.
In fact I have even worked in traditional (aka non-startup companies) of both the free-wheeling / "cowboy" as well as the more formal / process-driven kind.
>you assigned those projects to someone with clear deadlines, etc. etc.
Who said the deadlines were clear? Were you involved in that particular project, so that you know?
>If you don't trust that person to be able to finish it: why did you assign it to him?
Even this statement shows you talking about stuff you do not know about. Who told you that I assigned it to him? Can it not be the case that I was given a team to work on for the project, and had no say in the choice of people? Does that seem impossible to you? Do you always get to select your team members, if you are or have been a manager? (Then you might not be much aware of business realities, which are not always (or even mostly) aligned with what people involved would like things to be like.) That was the case here, in fact - I did not get to choose the team. Stop making so many unfounded assumptions.
>If you do trust that person to be able to do what you asked: why are you bothering him about the status of the project?
See reply to above point (too). Sorry, I'll have to call that a very idealistic and impractical notion. In business, to quote a saying: It's not the things that are expected that get done, but the things that are inspected.
[1] There is more that I can say, including some shockers, but this comment is getting long, so I will just give a hint or two:
The company used software engineering practices (it was not a startup, BTW), and required software engineers to use checklists for different phases of the s/w dev life cycle.
I have seen (example of shockers) team members do things like dutifully place a printed copy of the checklist for, say, program spec creation or unit testing, on the desk at the side of their PC, and then proceed to happily ignore it while doing the actual work!
Another and worse example: a dev on my team (actually saw this on his screen) wrote an if statement to check for an error after some operation, and then happily printed a message that there was an error, and went on to write the code for a following operation (after the if statement and error message printing) that depended on there being no error. IOW, print the error message, but then go on as if no error happened!
I rated him the lowest of the team during appraisals, because that error of his was avoidable by sheer common sense; you do not even need to understand anything about programming to avoid it. I mean, it's like saying: I see a deep ditch in front of me, I yell out a warning about it, then proceed to fall into it!
Of course this was an outlier, but you may be surprised about how often such kinds of blunders can happen, even at somewhat higher levels in companies.
Being an unstructured activity (but still planned, in the sense that you knew that you were going to do it now and then during the day or week), you tended to get more out of it in terms of information about progress, status, issues, and being able to help team members, technically or otherwise.
[1] https://en.wikipedia.org/wiki/Management_by_wandering_around
It was supposed to have originated, or at least been used early on, at Hewlett-Packard (and also earlier by Abraham Lincoln :) see [1]).
Although I worked for a while in a company that was a joint venture with HP, I did not learn about MBWA there, but later on, in another company where I was doing management. Read about it in a management book, thought it was a good idea, and tried it out; turned out that it was useful.