If You Can't Veto Features, You're Not a Tech Lead

I will be a happy man the day I get out of this business.

I'm working as a subcontractor for a former employer of mine.  They installed me as the technical lead for an ongoing (and off-track) project, gave me minimal training, no specs, and instructed me to bring the project to completion on time.

We had a situation where a high-priority feature was broken by the implementation of a low-priority (and purely cosmetic!) feature.  Every person on the team (including the person who produced the offending feature) has looked at the issue and is stumped; that the one feature should break the other is totally illogical, but it's happening.

Today rolls around and the issue is still not resolved.  I have to begin file prep tomorrow for Monday's delivery.  Being the Technical Lead, I make a decision:  roll back the low-priority feature.  We can deliver it in a patch in a couple of weeks rather than endanger the entire release schedule.  We all continued our work and I informed the Project manager of what we were going to do in order to keep rolling.

The Project Manager didn't like that much, telling me that decision like that "can't be made at that level".  I was instructed to ask first and then resolve the issue per the PM's instructions next time something like this comes up.

Now let me ask you - if you are not allowed to make a decision regarding the technical feasibility of implementing a feature within the confines of the constraints you've been given (such as time and budget), are you really a Technical Lead at all?

My answer is no.

Norrick
Wednesday, March 17, 2004

given your original instructions I would do one of two things.

(1) ignore the mad PMs new instructions and just continue making decisions...just next time try a little harder to stop the PM from finding out about it.

(2) Go straight to the chappie who gave you your original instructions and ask him to make a decision there and then on who has final say in this situation. (for bonus points quit if he says the PM...but at the least make sure he understands the implications of that decision)


Either way _keep written record of every non-trivial decision you make and the reasons, record all interactions with the PM and any other managers that may be hanging around.

seriously dude, this project is going to turn to shit unless the PM knows their stuff, and Im betting they dont.  make sure you dont get caught up in it.
Keep the written record regardless of the decision on who has final say...given one scenrio the PM will be in charge and the project will go to shit, given the other the PM wil have an axe to grind, so Keep Written Records.

I mean it, keep written records, your situation is only going to get worse.

Im totally serious, keep written records....this project is going to turn to shit.

Keep Written Records

FullNameRequired
Wednesday, March 17, 2004

> next time something like this comes up.

So it sounds like you "won" this time around.

What happened to give and take?

Technical lead doesn't mean you win every time, nor does it me that your technical opinion trumps the PMs "business opinion".

Next time something like this comes up, make a deal with the manager along the lines of :"Hey George, I know that you want this low priority feature, but it may kill the deadline. I will get my team to work extra hard and get it done FOR YOU, but in return you have to make concession ~X~ FOR ME. After all, fair is fair."

Give and take.

Now before you QRT purists tell me that this is pointy-hair BS. I invite you to sit in on a Sales Trip or the all hands Sales meeting. Now those boys can negotiate. If programmers, esp. Managers of programmers, had one tenth the skill of a long-time sales huckster then many, MANY projects would ship on time.

Finally,

--
ee - TDA
Technical Devils Advocate

P.S. Now to be really sneaky, “invent” a believable problem that results in George owing you something, at none or little “cost” to your team.  Again with the morality, have you actually sat in on a real sales meeting, not necessarily in the boardroom, but the one at the strip club, where the REAL work happens… (Or maybe I have worked at too many corporations…) If I recall, even Scotty from star trek follow a similar pattern: tell them it would take x hours, do it in x/n hours, presto change, instant miracle worker… Bumps head on bulkhead…Ouch…

eclectic_echidna
Wednesday, March 17, 2004

>  instructed me to bring the project to completion on time.

Also, you are screwed. If they hired specifically to complete the project on time, and now this tiff with another manager.

Not delivering is going to make things very bad for you.

> ... keeping records of the decisions that you make...

Waste of time. What is this? Crazy world?

As though there is some higher authority making rational decision based on presented evidence. Yeah right. It will boil down to suits vs. geeks, and the geeks rarely win...(unless the geeks own&run the company)


--
ee

eclectic_echidna
Wednesday, March 17, 2004

"Yeah right. It will boil down to suits vs. geeks, and the geeks rarely win"

truth is, I _always_ win when it comes time to start shoving back.  And Im a _proud_ geek.
I win because I keep notes, I win because I can afford a very good defensive lawyer (Ive never used him for any other purpose) and I win because I can sense potential for trouble far enough ahead to start taking notes and recording things.

Im telling you, Keep Written Records.

They _do_ matter, they matter because at a time when everyelse has a foggy memory, you can have an exact one.
they matter because if you do so carefully, people who are not directly involved can see that your record matches their memory in certain places and so they become more likely to believe you in others.
They matter in a court of law, they matter in private arguments and they will matter greatly when the time comes to work out why this project fails.

If the PM has this attitude there is a _very_ good chance there is going to be big problems ahead..be prepared and Keep Written Records.

FullNameRequired
Wednesday, March 17, 2004

I feel for buddy, I really do. The problem is probably this -- you are a contractor and you are only the technical lead. I write business applications for a living and at every place I have worked, the project manager was always considered to be "the immediate boss of the techies". Some PMs give their TLs a lot of freedom to do what is necessary to get the job done and others don't.

If you don't like this particular reality of the business (lots of responsibility and no authority), then you need to try and negotiate for "decision making power" before you start working on a project. How you accomplish this is up to you (have it written into your contract, ask that this fact be announced during a project meeting or in a group email, etc.). How successful you are with this kind of tactic will depend on how badly a client needs your services.

One Programmer's Opinion
Wednesday, March 17, 2004

I disagree that you're not the tech lead if you don't have veto power in this instance. You can give advice on the technical feasibility of the feature, but ultimately, it's up to the project manager to make the call as to whether they're willing to take the schedule hit to include the feature anyway.

A good project manager in the situation you describe would say, without hesitation, yank the minor feature. But it's their call, because ultimately, the buck for hitting the schedule should stop with the project manager.

In other words, it's a political, not technical decision (albeit one that is highly influenced by technical considerations).

Sum Dum Gai
Wednesday, March 17, 2004

I am willing to walk away from this contract, and that soothes me.

That a Technical Lead can't say "given the schedule and the budget, this feature won't fit" is insane.  If the TL is not the best qualified person to make this decision, who is?

Norrick
Wednesday, March 17, 2004

"You can give advice on the technical feasibility of the feature, but ultimately, it's up to the project manager to make the call as to whether they're willing to take the schedule hit to include the feature anyway."

You don't understand.  Taking a schedule hit is not an option with this PM.  If I say we don't have enough time to include something, the first thing out of the PM's mouth is a question regarding my evening or weekend availability.

Norrick
Wednesday, March 17, 2004

How about a clarifying statement?

You were "made responsible" for a result:

>> (the client) instructed me to bring the project to completion on time.

Yet you have no real power:

>> The Project Manager didn't like that much, telling me that decision like that "can't be made at that level".  I was instructed to ask first and then resolve the issue per the PM's instructions next time something like this comes up.

You cannot accept responsibility for a result when you cannot control the factors that have a direct impact on that result.

IOW, there is no accountability without authority. No authority, no accountability.

I agree with all of the advice you've gotten so far to get everything in writing and document every decision and every objection you've lodged.

The fact is, as a contractor, you could potentially be held personally and/or professional liable for failure to deliver an agreed result. It doesn't happen very often in IC work in software development, but it DOES happen.

That's one aspect that almost no geek "gets" which they ought to, that IC work is legally distinct from employee work. Employees are generally not professionally liable for their work on IT projects. Contractors are, unless they get a specific waiver in writing from the client.

CYA. Period.

But don't get neurotic about your client's shitty process and stupid decisions. It's no reflection on you that they are idiots.

Bored Bystander
Thursday, March 18, 2004

"Taking a schedule hit is not an option with this PM.  If I say we don't have enough time to include something, the first thing out of the PM's mouth is a question regarding my evening or weekend availability."

Obviously we don't have all of the information, but it does sound like a political situation rather than a technical situation. If there is an issue where the tight time constraints restrict the expected featuresets because of unexpected issues, you communicate the issue and make it known that something will give, or the release will slip. My gut feel, knowing so little, is that the real issue is that the PM feels that they were left out of the loop on this decision, even if ultimately their hand would be forced by the bitter taste of reality, so they're just trying to piss on their territory a bit.

Dennis Forbes
Thursday, March 18, 2004

If the PM refuses to take a schedule hit, and refuses to take your technical advice on what needs to be done to stay on schedule, the problem isn't that you're not a technical lead.

The problem is that he's not a project manager.

Sum Dum Gai
Thursday, March 18, 2004

I agree and disagree.

I would disagree with the statement "If you can't veto features, you're not a tech lead".  The program manager should have the last word on the features, and the technical lead should have the last word on how long it takes to implement those features (or bug fixes). 

In the given scenario, the PM has the responsibility to decide whether to implement the feature and take the schedule hit, or veto the feature.  The PM has no authority to decide how long it will take to fix the feature bug.

My $0.02

josReader
Thursday, March 18, 2004

Norrick, this is a fundamental issue in software development, because so often the people who consider themselves to be "in charge," such as the "project manager" are not capable of fulfilling that responsibility.

You will not win unless you make it crystal clear that you are demanding authority for decisions you must make. That means firstly, telling the PM to get out of the way, and secondly having a meeting with his boss to ensure this is authorised by him too. If it's not, tell them to take responsibility for delivery.

It's time developers stopped putting up with this shit.

JM
Thursday, March 18, 2004

If there is a project manager who is responsible for running the project, he decides on schedule, time and cost related issues. Not arbitrarily of course, but based on the information he gets from his team.
The team provides the information, the project manager decides. If they don't think his decision is correct, they are free to provide additional information to clear up the confusion.
And if they don't trust or accept his judgement, they have a mutual problem, which has nothing to do with the developers responsibilities, capabilities or authority.

Now, there may be reasons why a developer is also acting as project manager, or vice versa. It is not about the person, but the role.

One may not like this division of responsibilities, but it appears to be quite common and it seams reasonable.

Erik
Thursday, March 18, 2004

In my experience, a "Technical Lead' is purely a technical role and has no authority or control over features or timelines.

A project or program manager is the one who has the ultimate authority over those things.

Unfortunately for you, it sounds like your PM is just a rubber-stamp-man and doesn't have the guts to cut features when it makes sense to do so. A good PM would work with their technical leads to make sure the features won't impact the schedule.

It sounds like you are in a situation where the PM just says "Hey, get this done by tomorrow".

I feel for ya.

Huh?
Thursday, March 18, 2004

You can always play the game of saying one thing and doing another.

Tell him the small feature is broken, but you're working on it, and then roll it back and ignore it until after the release. If someone asks about it, tell them you're still working on it and it's still broken, but you don't think it's a showstopper. If your management thinks it really is a showstopper, then  you got to bite the bullet and fix it before release.

I've seen this game played succesfully many times. You might not have the nominal power to make decisions, but you have the real power to do or not do something.

pdq
Thursday, March 18, 2004

It might be interesting to find out if someone other than the PM wants the cosmetic feature in.  Maybe a critical customer?  The CEO?  The CEO's wife?
The CEO's preschooler? 

They all can be more influential than the PM or any technical lead.  Of course, I'm not saying it's right or fair.

VP
Thursday, March 18, 2004

I have to agree completely with FullNameRequired.  Document the hell out of everything.  If you talk with the PM in the hallway, email him the moment you sit down at your desk summarizing the chat.  Find out who his boss is.  Keep copies of those email and carbon copy his boss when the PM starts giving you shit.  Keep people updated honestly on what works and what doesn't, and if they get crappy about it then include full technical details of unit testing and all that sort of thing.  They won't read it if they are not tech people, and not reading it will come back to bite them in the ass later.  Do not give them the chance to say "You never told us why it wouldn't work" - instead drown them with information.  They will eventually let you get your real job done.

The downside of this approach is that while your ass is covered, you will also piss them off totally and they will probably stab you in the back when they get the chance.  You are burning your bridges behind you with this approach.  However, since you are in a crappy position to be in anyway, those bridges probably are not ones you want to go back across anyway.  Move on with your life as soon as this job is over.

Aaron F Stanton
Saturday, March 20, 2004

Since when can a Tech Lead make a unilateral change to the requirements?  The Tech Lead is responsible for technical realization of the requirements.
What, the feature wasn't a requirement?  Well then why did you implement it?

"Taking a schedule hit is not an option with this PM. "

What, he's going to change the laws of physics?  Of course it's an option.

"If I say we don't have enough time to include something, the first thing out of the PM's mouth is a question regarding my evening or weekend availability."

So?  Answer the question.  If the answer means that there's choice must be made between schedule slip or feature removal, the PM needs to confer with product management, marketing, sales, and other relevant parties in order to make the best business decision.

jqb
Wednesday, March 24, 2004

  Recent Topics

  Fog Creek Home