I'll include the TL;DR here:
TL;DR: Project in a very messy situation, I'm under tremendous pressure to deliver while all responsible parties are on vacation, my performance rating from 2.5 months ago was lowered after the fact, and a promotion I was told to be given was withdrawn. Advice? And are they even allowed to do that?
2. I'd give notice, citing the change in performance review and withdrawal of the promotion/raise as the cause. It's one thing to work in what appear to be horrific conditions, it's another to then be retroactively denied compensation.
The main X factor is when you give notice, and that's up to you: personally, I'd probably give notice immediately and see if the company counters with an offer to reinstate what you were promised. Otherwise, start looking for another job and give notice as soon as you get an offer.
This will certainly come up during your next job interview, so you don't want to burn any bridges or get too emotional about this (even though you have the right to, for sure):
- Be calm and factual when explaining why you're giving notice, to prevent poisoning the reference: your performance review was changed after the fact, and you were denied compensation and an advancement opportunity you were previously promised. In any situation, this is a reasonable and justified reason to leave a job.
- Do not give K as your reference. Give one of your other superiors.
- When explaining why you left your previous company during interviews, you don't want to throw them under the bus. Explain that you were looking to advance and grow as a developer, but those opportunities were not available at the previous company.
What you're experiencing is a great learning experience. Reflect on it and you'll come out stronger.
For future: when you're a lead you should be focus on setting boundaries, expectations, systems, plannings etc. You'll probably only code for 1/3rd of your time, if you're lucky.
Don't feel comfortable with that? Then don't apply for those positions :)
It might be worth it if they had an awesome relationship with their boss, a lot of trust built up, but it doesn't sound like that's the case. If they'd a decent relationship, and decent managers, the situation would never have reached this point in the first place. Add to that the fact that the company went back on their word...
They're either liars or stunningly incompetent. Neither's worth counting with.
I don't mean the question harshly or sarcastically. I'm suggesting you take a hard look at your motivations for staying even this long. I'm sure some of them are positive: you say the project interests you technically; maybe you have at least one or two co-workers you enjoy working with. But are there any negative motivations? Those could include martyrhood: a feeling that you somehow have to save this project, even though you almost certainly can't. Or, maybe you have some fear around interviewing, or are unsure you can find anything better. Or maybe just plain inertia.
If you thought that the project might somehow succeed and that you would ultimately get credit for that, that would be one thing. But in the extremely unlikely event that it does succeed, it's clear that K will get the credit; she's already moved to sideline you.
There's nothing here for you. Really. Find another job now.
Sadly with the direction this project is heading, with K's role in this project, and with the lack of positive change from upper management after so feedback from many parties has really taken its toll/disheartened me. I do agree I need to find another job, it's just a bit hard now during holiday seasons and where I'm located.
Definitely working on it though, thank you.
On the other hand, working for AWS is hardly any sort of panacea. Initially it'll feel good to be out of your current situation, but there's a reason why Amazon burns through so many people - and as a Seattleite, I've heard lots of bad stories. I suggest you consider other options assuming you can hold things together until hiring starts again Jan/Feb.
Ideally, you would be able to find a new workplace before suing their asses, and you would get some sort of settlement. Of course it's not a risk everyone would take, have a think about the situation. Perhaps the AWS job is still open?
I would definitely leave though. Having a person who can't code in charge of coding is a bad idea, and it can only get worse with the deadline looming. Coding is not like doing a bunch of slides, where you can suddenly cut the scope and still have something that works. (Why did I bring that up? Because if you're doing a non-coding project, you can often just chop the scope and still have something.) They've broken Brook's Law by adding people near the deadline AND they then lost those people, deservedly.
You're also being positioned for the blame, showing they simply don't know what they're doing. How are they going to deliver anything with you and an intern? The least fair thing that can happen is you and the intern produce a sub-par product, and you then get the blame. Your company loses the contract, or the bosses find some other people to do the work under a different name, and you get the boot. Sorry if I sound cynical, I just don't want you to suffer.
If I were K's boss and unaware that this was happening (which I would consider my own failure) I would very much appreciate a heads up and I would make very sure that I'd do what is best for the company. Assuming you are telling the truth there are more than enough hand-holds in your email to verify this. Specifically the time-log and a bunch of other evidence. If your story tallies and hers does not the decision is clear. If it is a toss up you will have to leave, if hers is the one that I find more credible then you'll have to leave too.
Either way, I'd appreciate the notice and I would definitely take it serious, the project is large enough to be taken that serious.
best of luck.
If you don't, do this at the exit interview.
As one of the other posters mentioned, you seem to be young. I say that not because you say anything in particular that gives it away, but that most of us old guys have gone through what you're going through many times before. Team lead is usually as much a political position as it is a technical position. Knowing how to deal with these issues and how to surf the chaos that can happen at the programmer/manager interface is a big part of the job.
I don't want to kick you while you're down, but it's important to realize that you have not succeeded in the political side of your job. It may very well be the case that you could not succeed, no matter what you did. That happens. However, you need to be quicker on the draw to either solve the problem or get out. It's way too late now (which is why the advice here is uniformly telling you to get out). In fact, understanding when not to take a team lead position is very important for your career.
When you have a failed project like this (and from your description, you can feel free to mentally label this project with a big red "failed" stamp), it is quite important to reflect upon what you could have done to save it. It's easy to say, "It was K's fault" or "Nobody listened to me", but if you were to save the project, it is entirely possible that it will require you to influence K in a certain way. Or perhaps you need to get more influence with people higher up in the project. The fact that your performance report was downgraded indicates a certain souring of the relationship with those above you. Rather than worrying about whether they can do this, you should be wondering, "Where did I screw up that relationship?"
My advice to you is to find a position with a very strong lead developer. When interviewing for a new position, make sure to seek out the lead you will be working for and choose a group where you will learn the skills that will enable you to be successful the next time you are in that role. I would advise you to avoid another lead position until you find that strong mentor (unless you are hard headed and don't mind the trial and error approach -- which is fine, but a bit taxing stress-wise ;-) ).
Good luck!
Yeah, well, the OP might have screwed it up, or K might have successfully backstabbed the OP.
Offering the back end team one's own team members is a selfless act. I'll wager it's not the only way that the OP has demonstrated a commitment to the success of the project. A healthy organization recognizes such a commitment and rewards it with increased influence at the very least (ideally, with increased compensation as well).
This is not a healthy organization, and the OP can't fix it. It's time to leave.
"those front-end devs that were 'forcefully' assigned to me didn't climb the learning curve fast enough and have wasted a lot of time getting up to speed on the backend technology, while pushing bad commits that initial backend team had to fix. You know, as I already stated and as I know from experience, and you should have listened to me, throwing more people in on a late software project only adds delay.
So, in fact, it wasn't a selfless act, front-end lacked work to do and just pushed their devs onto us to swallow our billable hours without touching theirs, that was sabotage, if not just incompetence." etc.
Note, that's not at all what I think, but if I was playing a politics game, and if I was a malicious recognized team lead with several successes in my track record, that's what (or some variation) I could tell management to get out and put the blame on OP, the young team lead which has everything to prove.
Sure, an org with clueless management unable to assess the situation may not be worth staying in, but things must be kept in perspective, and here we have only one narrative to get an idea of what really happened.
> you have not succeeded
He failed [at political part of his job]. Why soften the blow?
> Where did I screw up that relationship?
Exactly - that should be the focus.
Change what you can change and do not focus to much on things that you can not change.
> find a position with a very strong lead developer
It's good to have a strong leader, but:
1) How do you recognize a strong leader?
2) In order to become a good leader yourself you still need practicing it. Just observing leadership in action is not enough.
https://hbr.org/2015/12/how-to-spot-a-bad-boss-during-an-int...
I'm certain there are many things I could have done differently for a better outcome, and I may not be able to identify all of them, but even taking to heart a couple of these will help a lot.
Thanks again!
A team lead's role's spread across several areas: ensuring the project is set up in a healthy way to optimize quality/speed ratio, mentoring team members, and working with product managers (if applicable) to solve problems/remove obstacles which can harm the project.
From your narrative, you seem to cover first and maybe second point, but be completely off the loop on the third one. When faced with a defective team member as K seems to be in your story, you have to solve the issue. Start with talking one-to-one with the problematic element to see if things can be settled, and if not, go up the management chain without hesitation, explaining clearly why K's behavior is harmful and proposing some actions.
You say that you're 'not invited' to their meetings, and that's an issue because you mustn't rely on 'being invited', you should be the one who drives the thing and invite the others. If you don't rise up and speak for yourself, nobody will, and the blame will fall on you. A lead is not passive.
One important thing is putting each of your action in the perspective of the project. You're not 'pointing finger' at a coworker, you're stating that the project can't move on and is at great risk because of some missing parts, and you're willing to work with the responsible of those parts to have them done.
Same thing for your reviews, you're a lead, you shouldn't be given a paper to sign and vague excuses. Firmly request detailed explanations, and if not provided refuse to sign anything.
If after taking enough actions, things don't resolve as they should, start looking elsewhere for work. A company which fails to take the good advice doesn't deserve talented devs, and there is more opportunities for talented devs than talented devs to fill them up.
But on your end, don't accept tasks as lead if you're not prepared to assume the 'lead' part of them.
[edit: formatting]
I don't think there's much one can do about an co-worker at one's own level, who is successfully blaming everyone else for the project's problems, accumulating influence, and driving away competent subordinates. You just have to get out. Eventually management may figure out the real problem, but if they don't get it yet, you can't wait around for them to get a clue.
Even when transferred team members complained, before leaving, OP didn't state in the text that anything was brought up to management.
There are orgs where managers 'above' the team lead level are completely clueless about the technical side, and OP's company seems to be of this type if K's getting away with her behavior, meaning that she can bullshit her way through this if nobody on the same level rises the issue.
Still, I'd agree with getting out of this type of org anyway, but upon reading I just feel like OP didn't 'fight' properly. There are several levels of action that one can take in this situation: trying to influence the coworker's behavior, face to face discussion, documented report of what's wrong to management, asking for an assessment of project state by another experimented tech lead... And these actions have to be taken early on, quitting being the last resort.
Note that I'm bringing this up because I haven't seen these mentioned explicitly in OP's writeup, so I assume that none of these strategies have been tried, but I may be wrong.
I'm on the backend team with only two of us. I'm the sole REST developer. The UI team has three people. I sit with one UI developer to my right, one right behind me, and the UX designer kiddy-corner.
When features come up, ask five us talk about the requirements. The UI guys provide input on how they'd like the API to work. As we build, I ask them questions, they ask me questions. When I think I'm done, I push to a test server where they can hit on it. Sometimes they find I missed something or ask if I can add something.
In short, were referred to in the company as the "app team". UI + API is really one team with the same goal.
I would recommend coming up with ideas that you think would help move the project forward and present those to the management two levels up and try to get buy in from them. You might find yourself in an even better position if you can actually salvage the project rather than just leaving it.
When, not if, that project craters, K will probably throw your ass under the bus. Get out.
Looks like that's already happened.
My suggestion for you in your next job (as I think the environment has gotten so twisted where you currently are that it makes little sense for you to continue there) is stay focused on your deliverables. Don't give away developers that you lead. When others are not providing the support you need, bring it up with your manager that you have time to work on other stuff while you wait, or you can keep honing your project. Only do things you are asked to do (don't volunteer) and when questioned about why you are working on something explain it was because some superior asked you too.
The politics you're running into are wrapped up around ownership, competency, and leadership. By trying to help it sounds like you stepped on some toes (easy to do). The goal here is to have your manager doing the stepping on toes, not you. That keeps you clear of the politics and that is why you tell your manager you've got your stuff done as much as can be done and ask them what they want you to do next. Do that proactively, don't sit around because you have nothing to do, and they will give you new things to work on. And people who have a problem with what you're working on will have to blame your manager not you.
While it seems silly to have to do this, when you detect you're working with people who can't be adults about what needs to be done and who is, and is not, getting it done. You need to either leave or keep your head down. I recommend the former, life is too short to work with idiots, but if you really like your teammates or the project you're working on do the latter. Force the directives to come from your manager and you are left as the person getting things done and they are the person putting you on these projects.
Show up at 8, have a nice lunch, leave at 5 and work like a professional during that time.
You could also start more carefully by asking direct questions about whose mistake it was to tell you about promotions and bonuses before the decisions were completely finalized, and what specifically the mistake in your performance evaluation was. When in doubt, always get more information first.
I've made the mistake of thinking that HR would solve malfeasance and Bad Political Shit done to me by managers. Won't make that mistake again.
Engaging with HR is still a good idea. Ensuring a fair and reasonable process for evaluations and promotions and bonuses is very much in HR's domain. When there are problems of the sort OP talks about, HR should at least be aware of it.
Speaking as a director-level leader of a shadow IT group who has (pardon my French) been through some shit, the situation isn't as bad as it looks on the surface....
Some key points:
- yes. You've got a cluster fuck in progress; K seems to be lacking in IT mgmt skills.
- regarding reviews, raises, and promotions they can do more or less whatever they want with those and nothing counts until the ink is dry. Nor will anyone who matters give two shits about them 90 days later. None of my big $ moves ever lined up with any review (actually, most of the time it was exactly opposite).
- The more pertinent question is "will I be fired" over this? Which would be silly if the facts are as you say. You are one of the remaining few who understands how the app is supposed to work.
In the long run, you know how the system works and she does not. I've played this game before several times and wind up walking my tormentor out the door.
Suggestion: mentally write off the promotion and ignore your review, dismiss all short term noise; focus on things which drive where you will be 12M-24M out. (This is also why I have never protested a review in the past 15 years; nobody gives a shit if you survive).
Fun games to play:
1) Inform C that you don't have enough access to what is going on in K's process, due to being excluded from the team lead meetings. Point to this as a source of delays and "confusion". Do so in writing.
2) Get K to put down specs; go ask clarifying questions with appropriate next level mgmt on copy. Gently highlight gaps.
3) Ideal time to get creative in how you develop / document solutions on the front end; I would give as little detail as possible to make it harder to fire me.
4) Call a meeting of your own, that overlaps the purpose of the meeting she excluded you from. It's agenda should be something like requirements validation or solution design. Be nice but indicate you need it to accomplish your goals.
What you're setting up here is a slow boiling cauldron of incompetence charges again K and yourself as a trusted "competent" source in the app and underlying technology.
Move SLOWLY and GENTLY in laying this groundwork; soft innocent questions are best. Be like water...drip drip drip. Slowly wearing away at her credibility and building your own. Maintain emotional control and calm when she lashes out (she will).
Look for a new job, of course. This crap may be more than you want to deal with and that's ok. But there are ways of fighting back against bullies like this....
That was your biggest mistake.
In abstract theory, moving developers from frontend to backend might have sense, but in practice you moved developers from capable tech leader (you) to incapable tech leader (K).
So, in essence, your suggestion made these two developers to wasting their time and, ultimately, quitting in frustration.
At the time of your "loan 2 developers" suggestion did you know that K was a clueless developer/lead?
And no, I did not.
Keep a timestamped journal documenting what is happening daily. Keep it separate from their systems, but be careful not to include their IP in it.
My (limited) understanding is that such record-keeping can carry some weight, if things ever go to court or to some form of review -- arbitration, unemployment insurance qualification, etc. Hand-written might actually be better, because it demonstrates the amount of work that went into journaling and is additionally in your own hand. Also, there is no risk of it bleeding onto their systems nor onto the public Internet.
Second, based on your description, it is time to move on. Don't tell them this, in advance and beyond whatever "two week" or the like notice you may feel is appropriate. Just do it.
In my experience, once the company starts failing on its commitments and shifting blame onto you, the ship has sailed. Get out, before you're tossed out.
P.S. Some of your management may talk about some eventual "once things have improved" scenario. Don't believe it. Just look at their current actions.
Very likely, they are waiting for the opportune time when they have their ducks in a row, to let you go. (That includes, if they are competent for their own purposes, sufficient/overwhelming documentation to justify their eventual decision -- even if it is and including "manufactured" scenarios that guarantee resulting documentation of your "failure".)
Yes, this all sounds rather cynical. Another word for that is, "realistic."
Best of luck.
From what you say, the chance of any real fix is almost nil, as no one seems to have a grasp of the elephant that is software development and what it entails. All the delay, number of bugs filed and the new recruits leaving should have raised red flags all over.
Unless you are someone who thrives in office politics, you need to bail out right now. Software development is a mentally taxing job and its something you need a lot of mental stamina to do. Poisonous environments like these will erode your stamina and your love for your career in general. That is a perfect recipe for burnout. Unfortunately, the first time burnout happens, most of us do not know we have reached that point until much after the fact. You need to preserve your sanity and well being first as this experience can potentially affect your performance and contentment in the next job too.
Do not regret this experience. Try to accept it, learn from it and move on. This will help you filter out similar traps in the future.
After that, leave. You evidently have the ability to secure good job offers. Don't gripe about this when interviewing (it's a red flag). Just focus on moving your career forward.
https://www.reddit.com/r/cscareerquestions/comments/3y8ite/n...
Personally I will get the hell out of there: it is not worst wasting your time, energy and stress level especially considering what they are doing to your review. Working in a toxic environment is not good in the long term.
As others said this disfunction is the norm, anything better is the exception.
In reality, its usually you that is the problem. For whatever reason, the people in power don't view you as a key player. They may even be hoping you'll leave.
Situations like this are pretty much unrecoverable, so best to look for another job.
But, do think hard about where you went wrong, so that the same thing doesn't happen again.
Sadly most workplace disasters are like tsunamis, people don't realize the severity until it's too late and bridges end up getting burned.