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.

  • 1
    If the customer representative showed it off as if this is what they want, then yes you are being unreasonable. You need to make the case (if there is one) that what they did is going to prevent them from getting what they actually want in the future (if indeed it will). If you can show it in money terms (i.e. if they do it your way, it will save them x gazillion dollars), you'll be a hero. Jun 13, 2011 at 20:11
  • 1
    @Robert - I'd agree with that with one caveat...I think I should be involved before it was shown off. I think I should have had the opportunity to say, "No, lets not do this this way and here's why." If I'm overruled, no matter how wrong everyone else is, then that's the way it is. I recognize that and live with it. My problem is not getting the opportunity while supposedly being the "leader". Would you still consider that unreasonable? Jun 13, 2011 at 20:21
  • 8
    I don't think you're perceived as being the leader, based on your description of the situation. You will have to become the "leader by example," the go-to guy whose suggestions are considered seriously because you make good ones. This would be true even if you were granted specific authority. Jun 13, 2011 at 20:24
  • @Crazy - no it is not unreasonable, that's what a leader is for. Jun 14, 2011 at 6:19
  • 1
    Remember that respect is earned and cannot be enforced. They will follow you eventually, if you do it right.
    – Falcon
    Jun 14, 2011 at 9:55

10 Answers 10


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.

  • I've tried to implement code reviews and pre-design. Neither worked out because of a variety of reasons, including some of those I was lamenting above. I've also had a hard time figuring out a way that didn't slow us down. Another part of the problem was that people didn't seem very willing to critique code. I've also tried having multiple people come up with ideas/designs for hard parts of our project. Unfortunately mine was always the one we used so I think that could have been discouraging. Both are things I think we need to be doing (and unit testing too, yeah), but have had trouble. Jun 13, 2011 at 21:14
  • Any suggestions? How can we do code reviews without taking up a bunch of time? How can I get the other members of the team to VALUE it (and unit tests too)? That seems to be the big problem. It seems like it's just me assigning a bunch of busy work that just slows everyone down when I really believe we'd be better off. One big problem for me here is never having been mentored into this position, I just had to take it on (small, niche company hiring people straight out of college). Been at it a long time now but learned by research, trial, and failure instead of working under one better. Jun 13, 2011 at 21:17
  • 2
    --Something else that worries me is "I always think I'm right".-- I see all your points and agree with them. Was a poor choice of expression mixed with some self-deprecating humor. I try to keep my hair from pointing up. Jun 13, 2011 at 21:19
  • There are a few tools that you can use to help speed up code reviews. Web-based tools seem to work well - you can find a list of OS projects here: ostatic.com/blog/open-source-code-review-tools. Of course, the biggest component to having reviews be successful is accountability. Reviewers must be accountable for their reviews. Jun 13, 2011 at 21:36
  • 1
    Really, it boils down to making sure that your team takes pride in what they do and what they output. Knowing that their name is attached to a review and that they've okayed what's going in the change should lead them to do their job well (or at least as well as they can). If they're not, then perhaps some mentoring is in order (again, in private).. Find out why they don't care about what they're reviewing and stress the importance of the reviews (lower bug count, code quality, etc). Jun 13, 2011 at 22:06

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.

  • I suppose it's possible but I really doubt it. We just hired a manager and when I applied for the same position I was taken aside by the CEO. Pretty clear they don't see that position as playing to my strengths :P I can be abrasive. After watching the new guy I have to agree with some of the assessment. His political maneuvering and diplomacy to get shit done is something I certainly have a lot to learn about. Jun 13, 2011 at 21:29
  • "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." Yes, very much so. I've always taken the attitude of stretching my authority as far as I can and seeing what happens. Get smacked down? Well, I found where the limits are. Doing this though - you have to be right more often than wrong. Unfortunately, the other side of a lead / manger position is that some people are just plain REALLY HARD to deal with, and when they are not amenable to any reason at all life gets very difficult. Jun 14, 2011 at 6:23

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.


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.

  • Well, it was open ended in the fact that it didn't say NOT to do what was done. All that the story that was being worked on said was to get the values into the report in the document's units. Someone else, somewhere decided that they needed more than that, which I might agree with somewhere down the road...what bothers me is the hack, I would have liked to have said, "I really don't think you should do it that way." Jun 13, 2011 at 20:19
  • @Crazy Eddie: you can also approach it in a forward thinking way. Create a bug indicating that the functionality needs to be removed/replaced with whatever it should be, and assign to the dev who wrote it in the first place. Then it's just business as usual fixing a bug. Jun 13, 2011 at 20:22

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.

  • +1: This called "The Smoking Gun file". Print that stuff out and keep it at home. Jun 14, 2011 at 6:25

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.


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.

  • I always allow for someone to prove me wrong or convince me that I am. I do tend to think I'm right until that's done though :P Jun 13, 2011 at 20:18

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.


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).


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.

  • blindsided you? Grief, what kind of sweat-shop org do you work in that you have to ask your manager for every little detail and agree every little bit of work? If it wasn't for his manager, I can easily see his entire team wanting to quit.
    – gbjbaanb
    Jun 14, 2011 at 8:39
  • @gbjbaanb, design issues are not little details, they affect more than just the immediate. Design is his responsiblity not theirs. They knowingly exceeeded their authority (and from the description it wasn't the first time) and deserve to be smacked down hard for it.
    – HLGEM
    Jun 14, 2011 at 13:17
  • 1
    @gbjbaanb - that would suck for my employer pretty hard because I've also decided it's time to move on. I have it in me to be a good leader, and I know a lot (which is why I ended up in that position), but getting tossed into it without having any mentor has been a disaster and constant frustration for me. Jun 14, 2011 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.