How can I manage someone closely, yet still gracefully?

Question

I am working for an IT Consulting firm. My employer employs me to work for his client in a team lead position.

In my team there is a team member ("A") who reports to me. He works for a different employer. The client outsourced development of the specific interface to A's employer and A is leading the development and delivery of that interface which is used as a webUI for web service communication. The client has positioned the lead role for the entire web application. A is leading one other member who works from offshore (India).

Work was assigned to him two weeks ago, and there is no substantial progress from his team on that work. We have only one more week left to complete the piece, otherwise this piece will become a bottleneck for other teams and cause delays in delivery from my side.

When it was assigned, as he is also a lead, I gave him direction and then left him to it. In the first week, however, there was no progress. My manager alerted me about this lack of progress and already talked about delays and reasons from his side and asked me to put special focus on this lead and his team. I realize my manager doesn't trust him and feels this guy is not doing his work properly and not contributing.

In the second week, I closely observed A and his work. Below are my observations.

• He attends all business and requirements meetings but he doesn't transfer that knowledge to his team member who works offshore. There are a lot of knowledge gaps in his team about the requirements and work.
• When I ask him to make sure the component he develops suits most of the business scenarios, and do basic unit and sanity tests against those scenarios, he told me that his team doesn’t know any business scenarios. He said that the UI team or myself or somebody else should test against those business scenarios and report issues back to them, and they will fix them. The only reason we (my manager and myself) were involved in the meeting was to give him business knowledge. Hence I have taken time and translated all the business requirements into use cases his team can understand and test.
• After I reviewed the deliverables from his team (he signs off and send those deliverables to me) I found that basic review hasn't happened.
• We have Scrum meeting Every morning, every morning he used to report the inputs from service team not proper, there are issues with the service and hence has send mails to the service owners and waiting for their reply. Lately I observed that he is not reading the input documents sent by service team thoroughly. He just browse the required parts like url of the service, example request format and tries to test the service. He is not going through the document carefully and understand the each parameter required for the service. 2 out of 3 cases every question he asked, the service team replies the answer is already available in the document. Even if answered late I figured out the answer actually available in the document itself.

At the end of the second week, I started getting the same feeling that he isn't contributing much and just delegating work to his offshore team member, then sending deliverables to me. I have discussed this with my manager. My manager suggested I manage him closely.

How can I do this gracefully without giving scope for any negative feelings in the team?

Answer 1

It seems clear that your team needs a better development methodology. However, micromanagement is unlikely to get you the results you want. Smart people (which developers generally are) hate being micromanaged and are liable to fight you every step of the way.

I'd suggest borrowing a page (or two) from Scrum/agile development practices. In particular, there are at least a couple of things that seem like they would help in your situation:

1. Start running daily standup meetings with your team. Hold these relatively early (say, 9:30 am if people usually show up around 9:00), and keep them quick and on topic. Each team member gets to say 1) what they worked on/accomplished during the previous day, 2) what they will be working on today, and 3) if there are any blockers preventing them from accomplishing their tasks. This should not take more than 10-15 minutes each day, and running these meetings will let you see that progress is lagging before an entire week has elapsed. And they will give you more visibility into exactly why progress is lagging.

2. Have all stakeholders/"pigs" attend all business/requirement-related meetings. It's not sufficient appropriate to only bring the team-leader; he's not the only one with a vested interest in the project. And not just for the issues that you've highlighted, but because the more developers you bring to these discussions the more likely you are to 1) get accurate estimates on the scope of each requirement, and to 2) catch any issues or gotchas in the requirements before they become serious problems. You also, of course, solve the problem of the team lead not passing on the requirements to the team.

In general, you also seem to be dumping things on the team leader that you should be using automated tools and other processes to deal with.

For instance, why is he responsible for personally reviewing all deliverables (by which I assume you mean "source-code")? Why not have your version-control system send out an automated code-review e-mail whenever a change is submitted, to the entire team, and make the entire team responsible for code review and quality?

And why isn't there a project backlog or other construct that's accessible to all of the team members and which contains the relevant use-cases in a clear and easy-to-understand format? You're expecting the team lead to understand, remember, and communicate all of this, on top of everything else he's trying to do (and if you had a central repository for this information, you'd have an easy rebuttal to the team-lead's "what business scenarios?" remark). So you really only have yourself to blame if things start falling by the wayside. A human brain is one of the worst solutions to use for the problem of storing large amounts of information, accurately, for a long time.

And why doesn't the team have a clear definition of "done" that includes "no task is done until any related code is covered by unit/web/integration/whatever tests"?

So what I think you've got is a number of process issues, possibly being exacerbated by some poor management decisions (putting everything on the team lead, not including the entire team in meetings relevant to the project, etc.). More poor management, in the form of micromanaging the team leader, is unlikely to solve the problem. Fix the process issues instead.

Answer 2

If you are a team lead or a manager and you don't want to come across as the bad guy when necessary, then you probably out of place as team lead or manager. Let's review what's at stake: if he doesn't do his job, which is to transfer the knowledge to his subordinate in a timely way, and make sure that the tasks assigned are completed bt any means necessary, a key deadline is about to be shattered - not good for your organization, and you are going to have a high profile in the organization be the scapegoat - Not good for you.

Your manager assigned you the task of supervising your colleague, which in this case means that your colleague hands over the deliverables in a manner that is acceptable to you. It is your prerogative to reject those of his deliverables that are not in acceptable shape and to escalate the issue of his non-cooperation to your manager. I suggest that you make aggressive use of this prerogative, because any work that he fails to do is going to end up in your lap. With no time to spare.

Make clear to your colleague what he is supposed to know. If he doesn't know it, make it absolutely clear to him that what he knows or doesn't know about what he is supposed to know - that's his problem not yours. That you don't care how and when he learns it as long as he knows it, and he knows it and uses what he knows in a timely way.

Make clear to your colleague what he is supposed to do. If he is supposed to test against the business scenarios, then that's what he is supposed to do. Make it clear to him that pushing back to responsibility to you is NOT an option.

Management is a combination of loose and tight. You want to be loose about the things that don't matter that much. You want to be tight about the things that matter, and really tight about the things that really matter. What really matters is that the time window is closing fast and that your colleague delivers what he is supposed to deliver before the time window closes. I regret to say it but you have to shatter that comfortable/convenient frame of reference he is operating in and light a bonfire under his butt.

Follow-up comment by @HLGEM "Since this guy works for a different employer, I'd make sure that his boss at his employer is copied on the emails discussing performance issues"