Leading a team, am I being overbearing?

Question

I'm in what seems to me a very strange position. I'm "team lead" in role for a particular project, Sr. Software Engineer in job title. On my team I have 4 developers, one of whom serves a similar role on another project but now mine has been given priority so he's working on mine. I also have 2 testers, one of whom is a Manager. Another member of the team is the "Customer Representative" who is a part of a completely unrelated department. I also have a Manager who is directly above me and I believe also above the Manager of Test that's part of my team...not so sure about that though.

I've tried to get clarification on why my role is exactly several times. It's been hard for me to figure out where my authority begins and ends, if I even have any. The answer I'm currently working with is that I am "technical lead" of the team. This seems to mean that my authority is over technical decisions regarding architecture, design, and process/coding standards as they pertain to the product code itself.

Today something came up and the results of code I delegated to one of the members of my team where shown to the rest of the company in our Scrum show-it-all-off meeting. The customer representative person does the showing off. Something was shown off today that I really disagreed with and nobody had ever even asked me if I wanted to have a say in what happened. In short, in order to provide the ability of a user to display a value in a report in the following manners ("doc" units, design units, rounded, not rounded) they provided access fields for each permutation. Thus we have the value in rounded doc units, rounded design units, unrounded doc units, unrounded design units. Each record that the user will be wishing to work with has many such values and each one is permuted in this manner.

I really hate this.

The people we showed this to want to make sure that the API we use for reports is the same as the way we do things like export data to Excel. Unfortunately, now we're gaining this momentum in a direction that I think is really, really bad.

I did get a little upset at the next meeting and I asked the two people who'd done this, "Why wasn't I involved in this decision??" It's an issue that keeps coming up and I have a hard time it seems to just get people on the team I'm supposed to be leading to ask me if I want to be involved. Sometimes I do not and I think whatever they come up with will be fine. Other times I do. Unless people ask me though it's hard to even know that something is going on that needs my input and they don't give me that opportunity.

Unfortunately, my authority doesn't extend to telling people, "Next time you go off and do something like this on your own without even talking to me, you're going to be disciplined." That's a "PR" issue that is one area that's quite clearly not in my scope of authority. That's fine with me actually since I don't want to have to deal with that kind of crap if someone else is willing.

Today though, my manager, in front of everyone (which I guess is partly my fault too for bringing it up like that) told me that I can't be involved in every decision and need to delegate.

I of course think I'm right....I always do. I don't say things I think are BS. I think I should have been approached about this issue and asked if I had a better idea. My direction for this would have actually been to just decide on ONE value to provide for now, since this was actually the very beginning stages of a new feature, and discuss options for providing further access in the future if so desired. I never would have approved of or recommended the current implementation and I really don't think it should have seen the light of day.

The question is, am I the one being unreasonable?

---

Well, the two of us talked about it and agreed that we both "dropped the ball" and we seem to be on the same page. Monday mornings... We're going to try to make sure my role is clear in the team and that yeah, I get to decide when there's a design or task change that needs to happen; I get proposed to and either agree or decide I need to look deeper. Then there are some other bits I can try to work on to make sure they know that they can come to me.

Answer 1

Sounds like you need to monitor source commits. Perforce has this ability natively, Git has it through hooks, others I'm sure have their own methods. You don't have to nitpick every commit, but at least having notification and diff'ing them will give you a brief glimpse into everything that's going into your project.

As for your manager saying that you need to delegate, I'm not so sure that I'd agree - with a team of four developers, you should be able to handle it. Any more, I might be siding with him (or her). Of course, even in tasks that are delegated, you should be asking for status updates or walk-throughs on design changes, etc.

Nothing negative should ever be brought up in meetings - sounds like both you and your manager dropped the ball on this one. The absolute worst thing that you could ever do to a peer is embarrass them. As a lead (as with your manager), you need to be approachable and trustworthy. Belittling someone will lead to resentment, which will taint your ability to lead your team (as well as lead to disgruntled employees).

I hate hearing the word "discipline" from anyone in a lead role. Disciplining (at least in this context) is negative and not productive. Working with someone (personally and not in a meeting setting), finding out why they did something and provide alternatives if you don't agree with their proposed solutions is what should be done. Sometimes, you'll find that the person you're working with is right and your gut instinct is wrong. Why? They've spent more time on that specific problem than you have.

Something else that worries me is "I always think I'm right". IMO, that's the worst possible attitude from any lead. You should obviously be confident in your abilities, but realize that if you're not neck deep in a specific problem, then more times than not, your suggestions are coming out of your rear (no matter how much experience you have) and may not be the best. If someone who is concentrating on a specific problem provides an alternative, then it's your job (well, as well as theirs, depending on their own experience level) to prove why yours is better, not to just say "I'm the lead and I always think I'm right", which is what your sentence leads me to believe.

To wrap it up

Yes, you're being unreasonable on some points, but others no. As a lead, I'd expect that if there are feature or architectural changes that they're at least passed by you.

However, it's also your job to ensure overall system and code quality, which you need to do on your own. Does your company employ code reviews? Do you have your programmers design what they're working on prior to getting into the code? If not, you might want to start looking at employing these kind of quality control mechanisms.

Answer 2

You might be being checked out for management, and if so you're failing (which may not be a bad thing; plenty of us are good developers and would be bad managers, and I'd much rather program than manage programmers).

Managers frequently don't have the authority for everything they're expected to do. Getting things done anyway is one sign of a good manager. You need to find ways to get people to do things without doing any sort of disciplinary action. (Note: disparaging people in public isn't it. Praise in public, criticize in private, and show some interest in your subordinates as people.)

Managers also have to delegate, even when it hurts. You're likely to spend more time dealing with this issue than you would have spent writing it yourself, and that's fine. Once you've dealt with it, the people who did that should have learned something, and they're less likely to do things the wrong way in the future.

The right way to deal with something like this is in private, first asking the developers why they did the display that way. Not in a meeting, and not by assuming up front that you're right and they're wrong (even if you're right and they're wrong). Give them a chance to explain. That doesn't mean you have to go with their decision; you, after all, are the technical lead. It does mean you need to give them reasons to do it your way, and you should address any fundamental problems that show during that private meeting.

Also, managers have the responsibility for what comes out of their people. You should try not to be blindsided by anything they do, particularly in front of a customer. This may involve keeping track of code check-ins or having quick mini-conferences with your developers (although you need to be careful of that, you don't want to interrupt them when they're in the zone). Possibly you should talk to all the developers the afternoon before the meeting with the customer rep.

Answer 3

Don't take it personally

It's a team effort. Your the technical lead, not the only guy on the project. You should focus on having the team learn from mistakes or changing the process.

Lead and learn

Part of any leadership position, including a technical lead, is to understand that you do the best you can with the people you have. The more the team works together, the more they will know when to bring things up and when not to. Just make sure you don't fall into the trap of dictating to your team. Review what went wrong and what went well on a weekly basis. Communicate with your team if you want them to do things differently. Punitive measure should always be a last resort and they usually mean you either need to fire someone, or you have failed in your role.

Review before Customer Presentation

If your the lead of a project why hadn't you reviewed the feature and implementation before it was presented?

If it's wrong fix it

Explain clearly why something is wrong and change it. It's more expensive, but if it's actually wrong then fix it. If it's not wrong, just different from how you wanted things done, then again; understand your not the only one working on the project.

Answer 4

Was there any spec documenting what is supposed to be implemented? Given a too open ended requirement, devs will often fill in the blanks (or require micromanagement) with whatever they think is appropriate.

So you end up going to your manager with "So instead of working on what's in the spec, they decided to do [feature] instead. Now we're behind, because of a feature that wasn't approved in the first place."

Then you can start to work on scrubbing out the feature once the devs have been re-assigned.

edit> And no, I don't think you're being overbearing. Their work ends up being your ass.

Answer 5

I find myself often in the same position and raising it in meetings and discussions do not seem to get anywhere. Sometimes as a last resort before I resign myself to going with the decision made (albiet not mine), I send an email out to the relevant parties stating this in black and white with my reasons why.

Then I would archive that email so I ensure I have it for future reference in case needed further down the line when a manager or customer asks why something was done that way, or why a change is costing so much to fix.

Answer 6

I think you were wrong to bring it up the way you did, as you acknowledged. You aren't wrong to say you should have some input on design at this level but I'm not sure how you expect to implement that is reasonable. People aren't going to run a design by you if they consider it to be straightforward; since they can be just as easily be wrong about it being straightforward as they can about the design itself you will not find people volunteering to show you all their wrong designs. At this point I'm mostly curious about your working habits and communications patterns but really no matter how all that is done sometimes you will just be blindsided by these things. Short of diligently reviewing every commit I'm not sure how you proof against this.

Answer 7

I too often feel like this emotionally:

 I of course think I'm right....I always do. 

but I do have the sense intellectually to know I am occasionally wrong. I also know when to pick a fight - you can't argue about everything, and sometimes an unexpected agreement on your part can work wonders.

Answer 8

What is a true leader?

Is someone that can fire a subordinate, any subordinate. (but not needing to hire a new one)

Sometimes, most people are "tagged" as a leader of some project but, without the power of fire someone then it is more a "guidance"/"teacher" than a true leader.

But again, it can happens that you can be a leader of team but not leading your current project. The worst case is when the customer is leading the project. At this point, if the project fail (and it will fail) then, it is not your responsibility.

And the worst case is when exist two leader of project.

As a military, chains of command is everything (not so radical as "die for a project" but close enough). For this matter, your manager broken your status, lowered the moral of "your" people and didn't help at all.

Answer 9

Yes, your boss is right - you can't be involved in every decision. In fact its impossible to catch everything like this unless you do it all yourself. I think that's where you're coming from - you feel you cannot have a good handle on the entire project unless you're involved in every little detail, yet you cannot be involved in every little detail without overwhelming you (which will totally demoralize the team and probably burn you out).

The answer is not to get worried about things that go wrong - they always do - instead to worry about fixing them afterwards, in a constructive manner.

If you keep on track with communication, you can not only delegate, but you can let your senior people go off and do what they know is needed without always holding them back with reviews, discussions and misguided attempts to control them. Trust them to do the right thing, and be there to 'chat' about what's going on so you can be kept in the loop (and stick your nose in when you feel its really needed).

Answer 10

You have several problems. First your manager sided with your team and told you to delegate more. This shows a lack of confidence in your ability to lead the team. It in fact shows that while you have the title of tech lead, you are, in fact, not the tech lead becasue you have no authority. You need to sit down with your manager and have a heart to heart about this. No one can succeed in a technical lead position without the support of his manager and without authority to change design decisions made by the team without his consent. You don't have the authority to do your job. Your boss needs to understand that you are in a no-win position and that he must give you his public support for it to get better. Responsibility without authority is the worst possible situation to find youself in.

Next, your team blindsided you. You need to talk this out with them. You should be having the design discussion with them before they do any development and long before they do any public presentation. It's ok to delegate some of the design (although you, not them, get to decide what you think should be delegated), but not OK for them to proceed without informing you. They have lost your trust by blindsiding you, now they have to learn better behavior. You need to check with them frequently to ensure they aren't blindsiding you again and if they do, you should be doing some sort of formal reporting of the problem to HR. Leads aren't leads to be popular, when developers deliberately go around them after being told not to, then they deserve consequences. It doesn't matter if they like you or not but clearly at the moment they don't respect you. They need to have consquences for their inappropriate behavior or it will just get worse. However, you can't fix this part of the problem until you fix the management support problem.

Next you blew up publicly, you need to apologize publicly. This will help you build your reputation back.

Then you need to take each of the people aside privately and tell them the consequences for their continued bad behavior (once you have gotten your manager to agree to allow you to give them consequences). Public praise and support, private criticism should be your rule. You also may need to check in with them more frequently outside of teh group nmeetings so they can't blindside you.

Now frankly since both those above and below you clearly think you are someone who can be ignored and not kept informed, you need to do some serious soul searching yourself about what is causing them to disrespect you. You also need to decide if you wouldn't be happier not being a tech lead or if you should move on to a place where your will have authority to go with the responsibility. If you decide you want to stay inthe isposition, you are going to have to ask people to level with you as to why they treat you so poorly. That will be painful and you probably won't want to hear the answer, but you need to know why you are perceived the way they clearly perceive you.