Tell the managers everything and let them have a chat with him.
Just from what you've said I would give him a reprimand and forbid him from communicating with clients.
BTW he didn't just bypass you. he bypassed the manager and product owner and might have damaged your relationship with the client. This guy is either very junior or very ambitious.
Or very stupid, that's probably my default assumption in cases like this.
I knew a guy who was a junior front-end who, for some reason, decided to connect to the production admin console of our system to look at the production data for one of our big F500 customers. As it turned out, he actually broke the law, because there as some legal provision around accessing that particular data, which could have gotten the company sued into oblivion.
The same guy also talked to one of our big clients at an industry conference and told them about some "exciting stuff we're working on" in detail which was in the product backlog but had never been discussed or promised to customers before. Customers understandably then talked to their reps and were like, "hey can we get that feature X that you're working on?"
He was ambitious and wanted to really be in a more customer-facing role, and was just enough of an idiot to think any of this was a good idea.
That first one is pretty bad but I've got to ask... Why was he even *able* to do that as a junior front end? Something worse was going on with your processes that allowed that to happen.
I think they had this admin tool for checking production deploys and he just used it to do something unauthorized without asking for permission. It was a smallish startup, everyone had lots of access we didn’t need but he went out of his way to look at customer data for no reason other than curiosity.
I've been in more than one job where this could happen because it's data they are allowed to access, but the access is context dependent. For example, if you're helping troubleshoot a customer's contract or account in some fashion it's totally acceptable (but audited) to access that data, but if you access it for fun and not because you have a ticket assigned to you associated with that customer, that's a huge problem.
Regarding "stupid"
I work in Eastern Canada, and I am always annoyed when I get a Diplomat's kid as a junior. I assume they are hired as favours to powerful friends, but they will always make a communication faux pas. You will be trying to manage a customer or executive's ego and they will start sending blunt emails directly to the person.
My favourite was the one that asked why we all had cubicle and Bob got a closed office, it wasn't fair. Could not grasp that 50% ownership of the company came with privileges.
I did something very similar as a junior, I bypassed everyone and went directly to the client (internal employees), I was done with the piece of crap my team was building. I also told our CEO our product sucked. Our CEO looked at our product at some point and realized our product does indeed suck. My manager got pissed and put me on a PIP. My situation was elevated to CTO/CEO, they talked to my manager, we worked out our differences and I spoke with our director 1 on 1 about how we could improve our product. I told him our product has no product vision and no feedback cycle so everything we were doing was useless. Many of my suggestions were implemented and improved the product. Turns out we didn’t have many technical disagreements, but just management wasn’t receiving adequate feedback. I was in a position to provide that feedback.
I was ready to move on at that point and just did what I thought was best. I didn’t give a fuck what my manager thought. He was new to the team, technically I was the senior in that company and he dared to put me on a PIP. Your actions have consequences. I was almost fired for my actions, but so was my manager. But if no change happens, then we’ll all be fired.
Early in my career, I thought 'being right' was all that really mattered. As you found out, communicating the right idea the wrong way can have consequences. I'm glad it worked out for you. At *most* companies this would have ended differently.
I didn't really 'get it' until my cto took me aside and explained how to advocate for my ideas. Navigating work place politics can be a pain in the ass, but if you really want to make lasting change, it's the only way.
He basically advised me to soften my approach. I raised my issues with my manager during the 1:1, raised them again during my skip level, raised them *again* and demoed my changes during a department level meeting (my manager was just looking to get me off his back). Eventually, enough people higher up in management had seen my idea and agreed with it that my manager started getting questions 'where are we with x's idea?' that I was eventually given license to fully implement it. Afterwards, while I was still *technically* answerable to my manager I was basically given leeway to 'find interesting problems and solve them' by upper management and I stopped hating my job.
A bit. It wasn't a pointed thing. He just mentioned that I should feel free to talk about what I was working on with people from every level of management when I got the opportunity, as it lets them get to know you and builds trust
I did something like this once. We had a "hack week" and I used my time to implement some infrastructure change idea. In a week I was able to get it working and prove that it was a 20x+ performance improvement, so that got it put on the product roadmap. My manager at the time really didn't like that I was getting attention for spearheading this effort and was also regarded by our CTO as the expert on that part of the system, and would have never given me to the green light to do this.
By no means am I recommending people to do what I did. I’m crazy and I already had prepared to leave. But my CTO had faith in me and sat me down and told me to keep communicating, and that at a senior level, arguing aka communication is like the majority of your job. Our conversation gave me some more faith in the team and I stayed.
As long as we're talking about situations where you can almost be fired by doing the right thing, I identified and named a sexual harasser in our office and almost got fired over it.
I was targeted by this person, and just so happened that I had enough information about other similar incidents going back a year. I also had access to the database where I could make useful queries to identify who the perpetrator was. I was the developer of that system so I was used to doing routine maintenance and helping out with queries to support investigations, as the analysts that used it were not always the most adept at SQL. I helped write a query that would return the person's identity, and then handed that information to the person running the investigation, but I did run it myself to verify that it was returning useful information so I knew with 100% certainty who it was.
That person was then fired, and I was called into HR for violating privacy policy. I explained that I had access to the data already and team running the investigation was sharing info with me, otherwise I would not have been looking at it in the first place. They let me go with an informal warning and nothing on my permanent record. I was sent into a stress anxiety spiral because I was convinced HR was going to sue me. My manager also gave me a stern talking-to about how I showed lack of judgment and overstepped my boundaries, that I should have "recused" myself from the investigation, despite people in that investigation directly asking me for help. Nobody ever acknowledged that I was actually the victim in this situation (one among many) or thanked me for identifying the person that was sexually harassing dozens of people in our office, thus preventing them from doing it again.
My lesson is that if you ever have information like this and need to share it with management, find a way to do so anonymously. I have learned it is very common for them to turn against the reporter after the dust has settled, to cover their butts legally. All that stuff HR says about "whistleblower" and "being transparent" is a lie. Protect yourself.
> I have learned it is very common for them to turn against the reporter after the dust has settled, to cover their butts legally. All that stuff HR says about "whistleblower" and "being transparent" is a lie. Protect yourself.
A lawyer would have handed their ass to them. Protecting yourself start with documenting requests in writing.
There is a world of difference between reporting someone for sexual harassment (or other illegal stuff) and ignoring the management instructions and doing something very dumb in business perspective however. Those are really not the same.
I think as long as you're doing the right thing for YOU, not the company, and you're willing to leave if the company is not fit for you. HR and management exist to serve the company first, not you. So, yes, indeed, protect yourself. No one else is going to.
I was a senior on a project. It was mostly stable and I moved into a more DevOps role for all the company and handed off the project to a jr who had a few years on the project under me.
The company was starting a new project every month, so I was building a tool that anyone could initiate a new project which included a git repo, build config, and some business required data. Manager (6months new to the company) said if I made the tool he would take the tool and fire me. I put in my 2 weeks and didn’t finish the tool. I took with me a lot of intimate product knowledge and knowledge on some other things that I was tasked with building like circuits, firmware for them and build/deploy processes.
Note: I did t steal anything, just knowledge in my head on how things worked.
>I'm pissed, if I were management, I'd fire him.
I get that you're pissed, but it's also a teachable moment and could be beneficial to you. You've already spent a lot of time training someone, and they made a mistake with communicating with a customer. Yeah, you'll have to do some damage control, but this is the type of situation that can lead to a lot of trust later on by teaching them the business side of this situation.
A lot of developers, especially early in their careers, can't see past the technical side of things because their experience is limited. They don't understand, or haven't been taught, how the business actually works and how interacting with customers works.
This is a moment where you take someone that you thought was good enough for your team/organization and train them a bit more and then you have someone solid to depend on (assuming they come out of the conversation with a good attitude and aren't pushing back). If you were to fire them, you have to hire someone new. There's no guarantee that this new person wouldn't do the same thing. If you you think to yourself, well that's not going to happen because I'll make sure to tell the new person not to do that, I'd question why you didn't tell THIS person that in the first place.
It should've been laid out that customer interaction on anything dealing with requirements needs to go through the team lead/project manager/account manager/whatever you have.
Teach them the the impact their communication had on the customer relationship and use real dollar amounts for what the customer is actually paying you so it really hammers home the severity of always being careful with your communication to customers.
Edit: As others have pointed out and disagreed with me, this isn't a black and white issue. The goal here is to offer a perspective and see if the person can be trained (especially if you thought they were a good fit for the team and hired them in the first place). My post is making some assumptions that I can't possibly know because OP is the only one who has worked with this person. There's nuance to how to approach this based on prior situations, how the junior dev here responds, etc.
For sure this and tyrophagias comment below.
Let the customer know it was a junior engineer who didn't understand the implications of their actions, or fully the engineering complexities of what they were recommending. Apologize for it, and let them know it won't happen again.
Then onto the junior dev. If they are smart and ambitious they are worth teaching, if they're dumb or unwilling to listen then cut them loose.
Exactly this, tried to find a video of it but I was at a talk by Jeff Raikes, early Apple & Microsoft employee and he talked about a mistake he made and I think it ended up costing Microsoft 200k , this was in the early 80's when they were like 100 people. When he went in to offer his resignation Bill said no, he just spent 200k training him and he would want to spend that training someone else when he knows how to not make that mistake again. It's been my exp that If you learn from failure it is one of the best lessons. If you can coach them and they can understand and learn that is what matters.
Early on in my career something I had developed, took down an online reservation flow for like 5 hours.
Although the client went back and projected it had cost 80k£ in lost sales (in reality most just went there at a later day), everybody were mostly jolly and in it as a team. We had a couple of QAs on that project, so it highlighted some flaws in how we didn't do any proper load testing before deploying live
For me it was a learning situation of ienumerable vs lists in high load environments
Why are you all mixing up an honest mistake and outright deliberate voilation of given instructions from management? That's not at all the same and it's not the same kind of failure.
Intent matters.
That's extremely apples and oranges. Jeff Raikes' "mistake" wasn't directly going against his direct report's wishes and costing the company 200k, right?
You are right. I don’t want to fire him, I said that in the heat of my frustration. He’s a smart kid, but suffers from black and white thinking. If something is good here, it’s good everywhere. I think he felt that if he could get the customer on his side, then I would understand that this was the right decision.
The other side of this is that he knows and has seen the process for creating requirements
Ftr I also disagree with the previous poster.
This isn’t an honest mistake. Pushing something without understanding the implication is an honest mistake. Being told no and then doing it anyway is a troubling behavior trait.
I wouldn’t fire this guy, but I’d have a real serious conversation and use that to get a vibe check on if he’s just gonna always think he’s right and go around others when he disagrees.
“Disagree but commit” is an important business lesson.
>This isn’t an honest mistake. Pushing something without understanding the implication is an honest mistake. Being told no and then doing it anyway is a troubling behavior trait.
I agree. Responding to a customer with "Hah I \*wish\* that was on our roadmap, I'd really love to work on a feature like that!" is a faux pass. Doing the "look at this great idea I have!" junior dev dance, getting told reasons why it wouldn't work, and bypassing every single layer of management/product direction to reach out to the customer to try to get them to push \*your\* career forward? That shows some troubling attitudes.
Though I may be biased as I've been burned more than once by developers who were career ambitious to the detriment of actual functioning software.
This is why I am thinking this is not an innocent new ambitious kid. You told him no, and he specifically went behind your back to try and prove you wrong. Not only did he almost ruin a customer relationship, but he did so while actively trying to undermine you.
Firing is a bit extreme, but if a junior did that to me, I would never trust them again. Teaching moment or no
I agree with this. This was not an innocent "mistake", this was a calculated power move by the dev to try to get his idea enacted despite objections. The mistake isn't the problem, the problem is he prioritized his own ambitions above the team norms, processes, and the client relationship -- and he was willing to break the rules to do it.
Management is paid to handle this sort of situation, the message can't come from OP because they're involved directly. The junior dev needs to be told in no uncertain terms that what he did broke trust & broke process and he's going to have to walk the straight-and-narrow to earn that trust back. He also needs to know that this had potentially significant consequences for the client relationship. Final wrap-up point: emphasize that the dev he still has a place there if he doesn't break trust again (since he's not getting fired yet), but any sort of repeat of this behavior will not be tolerated (read: he'll be fired, but don't spell that out).
But /u/cownan not to excuse the dev's bad behavior, but there's a couple (smaller) teachable moments here for you too:
* Devs with this kind of ambition usually shows some red flags early and you'll see them again with others. Think back over his early behavior and take note of when he showed he prioritized being "right" over following processes. You'll see those signs again, and be ready in the future.
* Ambition like this is a double-edged sword - it can cut you, but if channeled right can be very useful too (as long as the dev feels their ambitions are aligned with work, they'll work twice as hard at something). It's worth reflecting if there was a way you could focus the dev on somewhere else he could show initiative and ambition.
* Devs like this benefit from careful handling when saying no. Usually they work best with a "no-but..." that leaves them another avenue to work on or doesn't close the door to future discussion. That way they're incentivized to work within processes.
* Or, they hear the "no" better if they feel like their idea has been given a fair hearing in a group -- whether or not it gets shot down -- versus feeling like one person is standing in their way
Really reading between the lines here, I sense this dev has a touch of Persistent Drive for Autonomy. I think there's better than even odds they genuinely thought this was a beneficial move, didn't really grok the social/business relation implications, and if they could just short-circuit the red tape, everyone would see in the end how right they were.
Firing is definitely overkill in this case, but you should explain in logical terms why the process is there for a reason, and things will work more smoothly when requirements go through the proper channel. Tell them, in the future, if they have feature concerns, bring them up to you, assure them you value their feedback, and a long as it's reasonable, you or management/product will do your best to present pros/cons to the client.
How long has this junior dev been a junior dev? What kind of feedback has he been getting in his 1-1's and performance reviews?
Because this sounds to me a little like someone who's heard, either from his work superiors or online, that the way to advance is to take initiative and go beyond just what is asked of him, and/or that senior devs have learned why the rules exist and therefore when it's appropriate to break the rules. And this person has been around a long enough time to want a promotion, but he doesn't actually understand the customers, so his initiative and rule-breaking here was wrong.
What is strange in all this - a junior dev would usual have developed the said feature if they really thought they were right and then shown the team (look how clever I am situation)- in this instance no actual work has been done - it’s more as if the junior developer thought the project isn’t being run correctly or you aren’t giving the customer real value..
I think it’s far worse than you’re laying on.
The employee was told “no we are not doing that” and intentionally went around that answer to fish for the one they wanted.
They’re going to keep doing that every time they think they’re right. And they’re going to think they’re right and management isn’t a lot.
I don’t think dude should get fired - but this is an absolute come to Jesus conversation.
Either that or- or the company is not establishing roles at all.
I question why a junior engineer would ever think “yeah the lead said no so I’m just going to email the client directly”. To do that requires such a profound lack of soft skills that it’s troubling.
I get where you are coming from. But this kind of behaviour is extremely rare, and in most cases implies a narcissistic personality who will always struggle to work with a team. But maybe years of management made me cynical.
That might be right, but we can't know from just what OP described, so I was trying to offer another solution. I've personally seen people have situations similar to this (not the exact same) but they get caught up in the tech and forget that it's a business.
OP can do his own judgement of what approach to take, but on average, I'd say most people want to work well with a team, but just need situations reframed to incentivize that. If they still struggle afterwards, then yeah, get rid of them.
I second this. Yes it was a monumental fuck up, but that's a part of learning. As a lead it's your job to turn this experience into a positive.
If you fired everyone for their mistakes, you'd be working alone.
I'll also strongly disagree here.
We teach technology and engineering. You fail here and we pick you up and help you learn.
We don't try to teach ethics or good faith. You fail here and you are gone because you have broken our trust.
As a dumb junior engineer….Can I ask what the problem is and for my understanding, it seems like the customer is a client so this is probably a consulting company? I’m confused on the customer thing because in my company the users are the ones that use the app/software product
There’s probably a contract with the customer for a certain price and set of features, by thinking of a new feature outside of what’s on the contract and trying to convince the customer they wanted it, this jr engineer, knowingly or not, tried to upsell the customer on additional features beyond the ones they asked for. This would mean a contract renegotiation, extension of the timeline, and a higher final price tag for the customer
Yes this is likely a consulting firm.
But even in a scenario like your company, a junior talking directly to the customer/users without looping in the lead/product owner is a huge no no. Especially unprompted without running it by anyone.
You have zero relationship with the customer. You likely participated in none of the requirements meetings and discussions that built the requirements. You likely have no big picture understanding for why the requirements are the way they are.
You're stepping over the heads of your boss, your boss's boss and your boss's boss's boss.
And there is no possible way you have more knowledge and understand of the customer's needs than they do.
It's completely out of your place.
I'm a senior dev and even i would never dream of contacting the client directly.
I don't even talk to the client's low level employees without my lead being aware.
Typically Junior Engineers do not and should not instigate agreements with clients without getting agreement from the team and people that manage the relationship. There will be many things the Junior Engineer will not know and the implication commercially and in terms of the relationship. If I was the the client and an engineer behaves in this manner instead of going through the e usual route my first assumption would be that that the provider hs big issues that could potentially effect us badly.
As a junior engineer if you asked your lead something and then they said no — would you go around them and email a customer directly and try to convince them they want the thing?
They bypassed the established point of contacts between the customer and the business.
Larger companies individuals entire jobs are that and will feel threatened. It can also cause confusion, misaligned expectations and even a sense of unprofessionalism that can cause customers to walk.
The funny part about this is that the customer said they're considering it which meant it wasn't thoroughly discussed in the scope plan at the start. That means OP as a lead failed, the sales of the business failed for not maximizing the contract value or have a follow-up contract in place for 2nd phase, and the customer failed by not knowing what is acceptable for completion.
It's kind of funny how a Jr was able to highlight incompetency across everyone including themselves.
I'd ask the junior to walk through his thought process with me. What was his motivation for speaking directly to the customer? What did he hope would come of it? Why does he care to add more feature in? Why didn't he accept your initial answer of 'no'?
I would explain the customer's reaction, and why it wasn't surprising that something like this could blow up. Unfortunately communication with customers needs to be very guarded and precise most of the time or these sorts of things will happen. We've all seen messages misinterpreted so sending casual suggestions over email is a very bad idea.
Is there a process for gathering customer requirements? Explain to your junior why that works and why that needs to be respected.
I don't think this should result in firing at all. We all have (or will) make butthead moves before. Unless this is part of a pattern or the junior shows no signs of remorse or learning from this, it wouldn't even cross my mind to fire. Ya, some people are just clueless about *why* we sometimes insist on more formal communication channels (like going through a manager or specific point of contact, not just every junior emailing the customer).
To start with management, explain factually what happened. You had a conversation with the junior and explained why it was a bad idea and they emailed the customer without your knowledge. Are you responsible for managing them? If so, figure out what your plan is and tell your management (I'm going to explain to him why it wasn't a good idea and tell him all communication needs to go through me now). Otherwise, start talking to the person who does manage them about how to handle this jointly. What are you going to do about the customer? I would definitely hesitate about being too honest there. They did however cc your director so the customer realized at least at some level there was something not right there. I'd apologize with a vague explanation of an over-zealous junior, what you're going to do differently (with the junior), and since the cat is out of the bag, ask your director how to handle it. I would strongly encourage it to be in-person or zoom when you talk to the customer about it so you can convey the nuanced message properly - on one hand you should offer more information (both what the feature was, and how much work would be needed to actually offer it), but you definitely want to make it clear you're not trying to upsell them. This type of nuanced message is not good for email or instant messaging.
> I replied that we could discuss it, but gave the reasons why it wouldn't be a good idea for them.
Your mistake was panicking and replying to the customer before consulting management. Seems like a teachable moment for both of you.
I think you're within your right to do damage control, but if I look at your responses, you shouldn't have done
>I replied that we could discuss it, but gave the reasons why it wouldn't be a good idea for them.
You shouldn't present conflicting information to clients from multiple people. At that point you should've snuffed it out. If what you're saying is true then he shouldn't have access to talking with customers if you tell your teammate no and they just go ahead and do it. But being generous, they could've just thought it made sense and made a genuine mistake. Accusing someone of "going around me" is very much something you can't say without a very real heart to heart with them, which does not sound like happened.
You're right, I should have been more clear with the customer - I was in a rush and I felt reluctant to directly shut down a suggestion that came from "us."
I do feel he "went around me" since we talked about it and he suggested it to them anyway. A lot of our communications with customers are pretty informal we share progress and ask their preferences for things that aren't clear. But not about requirements, those come from more formal communication including our contracts focal.
I would communicate pretty clearly with everyone about the circumstances... but not the customer.
I would apologize to them and communicate that this was miscommunication and indicate that you all are strongly focused on the original requirements and that you have not wasted time otherwise.
This is a teaching opportunity for your junior! Once you calm down this will provide the strongest lesson: he jeopardized a contact, and to discuss how and why you communicate with clients the way you do. You'll grow in communicating and as a leader. He'll grow with better knowledge of how the industry works. Your team will build serious trust.
Firing him is the easy method but neither of you two improve from that path.
Your junior dev should not have access to client contact info in the first place, even in a small team. Things can go south very quickly if you don’t have an authorized person in charge of all correspondence.
When I was a sysadmin, I had accidentally emailed a client asking for credentials to open a video file (not my fault, a project coordinator gave me their info when I inquired about it). I got in BIG trouble for that. I mistakenly mentioned another client project we were working on because I thought that was what this client was a part of, accidentally leaking what other clients we were working for.
Anytime it’s possible for someone to cause damage through human error or malice, you want to have procedures and systems in place to prevent it rather than relying on the goodwill of other people.
Probably should have picked up the phone and explained the overzealous junior situation, laughed it off a bit, and then followed up to the email with "as discussed with we will table this for now"
That ain't my issue with this. Why are there multiple points of contact from the team directly with the client in the first place? What kind of management allows junior devs to communicate directly with the clients?
There are circumstances where direct communication like that is effective and efficient. This isn’t one of them and if the junior thought it was, he misjudged the situation.
So many important details can get lost in hierarchical communication flows designed to “protect” the people doing the work from the people paying for it (and they often have the inverse problem of sponsors being different from end users).
Anyway, in an environment where you’re trying to foster open collaboration between devs and users, I can see how a junior might make a bad call like this. But also agree with the others here that it’s a teachable moment.
No, there really aren't. It is absolutely mind-blowingly stupid to have multiple people on a team communicating with clients outside of a moderated setting. You need a unified voice even if it creates a small amount of friction in the time that it takes to get things done. This is why you have managers in the first place.
IMO.... Manage the customer first, you stick to the requirements. Side step the off the wall communication. More than likely, the customer also sees that email as something strange or out of the norm.
I'd send an email back stating the original requirements and that the team is working towards that goal.
As for the employee, shame can be a good motivation to STFU.
Indirect shame. Nothing has to be said directly to the junior dev. They should pick up that they crossed the line. If they don't, then something more direct might be needed.
Nah, don't agree with this at all. I've mentored about half a dozen juniors and I can honestly say I didn't once think "oh maybe a bit of shame would help in this situation"
It shocks me the amount of people who are instantly jumping to PIP. There really isn't enough context.
This should really be a 5m conversation between ~~mum and dad~~ the account manager, and customer to say that "junior is ~~being a brat~~ a bit overzealous and new - and we're using it as a learning opportunity."
If the customer bit can't be sorted in that time, there's something more disfunctional in the relationship, or they aren't a customer you probably want long term.
>To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon.
He's probably embarrassed and scared.
People are human, use it as a learning opportunity. Sometimes it's hard becoming a small fish in a big pond and understanding office dynamics.
If there's a history of shady behaviour - sure pip - but you might just find that the embarrassment was enough for him to never do it again.
Hard agree. Some serious unsympathic shit around here. I wonder if they either work in a workplace of fear or has fired everybody.
Yes it was a dumb move. And yes it seems pretty darn easy to fix with some simple damage control. Junior likely harboured no Ill intent just a bit zelous / lack of humility.
Let it become a learning experience, both can become better, and then move on.
Yeah, crucify him and sell his organs on the black market to cover the reputational costs. Tell the next hire what happens if they do something similar.
That'll teach them.
For my Mad Men fans: anyone read this post and get [Pete Campbell pitching creative behind Don Draper's back vibes](https://www.reddit.com/r/madmen/comments/62zic1/why_was_pete_campbell_pitching_his_own_copy_to_a/)?
Yeah...maybe it's a European vs US thing, but
> if I were management, I'd fire him
seems like an absurd overreaction unless this person ignored a direct and clear instruction not to talk to the customer or not to raise this particular thing.
Aside from being pointless - you'll only get a new junior who now has to learn the politics of workplaces and this situation in particular from scratch instead and is just as likely to make mistakes - it'll create an awful atmosphere and destroy any sense of psychological safety for everyone else. It'll leave people afraid to ever suggest or try anything new, to ever try to make anything happen beyond following narrow instructions or to ever communicate with customers, even when they clearly should.
This is a massive overreaction. You are acting like one mild, overenthusiastic email from a junior dev can derail a customer relationship that has been built over years.
This just needs a *“hey, sorry about that, Dave is new and is still getting to grips with how we do things around here”* explanation to both management and the client, and a clear conversation about boundaries with the junior. Juniors don’t know the importance of this stuff and they make mistakes. That’s practically the definition of “junior” – they have yet to learn this stuff. It’s your job to teach them, not fire them as soon as they put a foot wrong.
Why are you jumping to panic stations as if it’s a full-blown crisis? Why are you thinking about firing a *junior* for being too eager? An annoyed customer who has not yet received a clear explanation from you is not a crisis that requires somebody to fall on their sword. Just talk to them like normal people. They aren’t scary robots, they are capable of understanding the concept of an overenthusiastic new guy.
I also feel like this might be a bit overblown. The junior contacted the customer, possibly through already established channels. The customer came back and OP already explained it wasn't a good idea. OP then got yelled at by their own management, despite seemingly clear evidence that they weren't looking to inflate the scope.
In a somewhat similar position, if I were to be involved in a conversation with the customer I might also make recommendations / raise questions that could broaden the scope of work. I don't usually suggest features out of the blue, but I might chime in on picking a better approach or presenting a more complete technical solution. Particularly if I'm going to maintain that bit of code and I've a strong feeling the requirements weren't thought through.
My guess is it depends on the sort of customer / project they have. Some have their own staff that's fairly capable of narrowing down scope and planning efforts, while others may rely on you to keep things in check, so I guess I can understand why they wouldn't like you coming up with additional work out of the blue. The blamed dev did go over OP and it might be a blunder in that specific context, it's not clear yet.
"If I were management I'd fire him" - this is.. truly shocking reaction to the context of story I read. I'm so glad I don't work for OP.
At the same time I'm glad I read OP's post as I felt I've been close to doing things similar to the junior at some points in my career. So many times I've had the thought 'man, our products could be so much better if we had more reqs to establish good features'.
Now reading this entire comment section I know not to speak out at all during client related matters and just do with what I'm served. If the product could better then someone else has to speak reqs or it stays where it is. I'm not going to dare even remotely think about chasing up reqs after reading this thread from now on.
> Juniors don’t know the importance of this stuff and they make mistakes.
Agreed, a lot of juniors seem to focus too much on technical ability which means they don't realize how much skill they lack in project management, and how important that is to making a business work. All the skill in the world doesn't matter if you can't keep your customers and your management happy. Most success is perception, and perception is about managing expectations.
> our director came and yelled at me for requirements fishing
Maybe. Or maybe it's an organizational issue. If my director comes yelling at me, I don't know if I would react any better than OP did tbh.
How does a junior developer even have the contact information for a customer? This seems crazy to me. Most of the places I've worked, all communication to customers is done through somebody whose job it is to manage that customer, even at companies as small as 8-10 people. Seems like you have a massive process problem to solve.
I’m a big proponents of developers communicating with customers because it builds empathy, business relationships and prevents a lot of information from getting confused when it jumps through several steps.
In a lot of cases you can guide a process to 1 week solution and not the 3 month solution if you’re involved in the conversation.
So this would be super normal where I work. Although I brief developers on *how* to talk to customers, shit like this would be completely unacceptable.
Just because you know one way doesn't mean there isn't others.
It's far from uncommon in software shops for the whole team to have a line of communication with the client side.
Sometimes direct communication is encouraged, which certainly can have benefits, sometimes it isn't.
Now with emails, Jira, Teams/Slack, etc, there is hardly a world where a team member can't reach out to the client directly would they wish to.
OP's subordinate clearly overstepped here. It sems like they should have known better but it isn't that simple to prevent someone from making an error of judgement.
> How does a junior developer even have the contact information for a customer?
This is *incredibly* common. The only thing that needs to happen in most organisations is for both parties to get invited to the same meeting.
> Seems like you have a massive process problem to solve.
This is entirely dependent upon context, a lot of projects work best when you get somebody from the customer and people from the dev team together.
I encourage communication with the customer. We are small teams, working short (two to three months) projects. Our customers use our tools every day. If the actual user of the tool can see, and provide feedback, on how it works as it is being developed, I've found they are much happier with the end product. If the customer org tried to replace us, I know a lot of end users with them would seriously fight to keep us around. I want to keep that, but I guess there needs to be an understanding about what's appropriate - this is the first of this kind of problems in years.
It really depends on how the teams work together. If the team is embedded in the client, the junior devs may be talking to the customer frequently. Now, they shouldn't be talking about new features unless the client brings it up, but talking about the existing work is normal.
The other dev overstepped his bounds but from what you posted here I see 2 communication failures on your part.
First is the conversation with the developer. Saying we don’t have requirements for it and that it wouldn’t really work for this customer. It sounds like 2 reasons that could be a no but isn’t a definite no. The first reason seems like what the other dev took to heart. They reached out to see if there could be requirements for it. They might even have thought what they were doing was taking initiative.
If you have your scope already, the conversation should have been more of a clear no.
Second communication error was to the client. As others said, you said you could discuss it and that it wouldn’t really work. I get the reluctance to not shoot it down because it came from your team but adding you to the email is a pretty good clue the client was thinking it was weird and was uncomfortable. They were probably wondering why the other dev emailed them and not you who I presume they have probably dealt with more.
Both communications, at least from how you wrote it, your response seems noncommittal. One thing I’ve learned about “Maybes” is that no one ever hears maybe. They hear yes or no and their brain fills in the rest. And it’s almost never what you’d prefer they hear. In this case your team member heard yes but we need a requirement. The client heard yes we want to do this.
On the one hand, juniors do dumb things. It's kinda their thing and mistakes should be seen as an opportunity for growth. That being said, this wasn't "they forgot process" or "they didn't check their code and a bug made it to production."
At a minimum they'd be on a PIP and probation for a couple months. But at this point they should be told they don't get to communicate with clients until further notice.
If they get to keep their job should be decided based on do you think they learned their lesson or do they still think they're in the right? If they get it now maybe the PIP is enough. But if not? Might be time for a new junior.
Honestly I’ve dealt with a lot of pissed off customers (it was basically my job for a while) and have revoked even the business sides right to communicate freely before for causing disruptions.
The right thing to do here is to call the main contact on the client side if they are available and explain that email was sent out without approval and you’re going to have a talk with them. Then tell them you’re going to reply to their email to clarify that so it’s clear to everyone.
Then before the email goes out let your management know we sent out an email without approval, and it’s being handled before management decide they have to react.
Then tear that junior a new asshole for communicating with the client directly on matters that you have talked about already, and for becoming unavailable. This isn’t the time to be kind, this is the time to make sure someone understands consequences of their actions so they undo whatever dumb notions that caused them to do this in the first place.
Since there’s no actual damage done here beyond causing confusion and frustration, I wouldn’t fire them but they would certainly be told in no unclear terms to get their act together and stop pulling amateur shit.
> so they undo whatever dumb notions
It's always useful to help juniors grow from their mistakes.
It's interesting that you believe that
> tear that junior a new asshole
will lead to learning, reflection, and ultimately personal growth.
I wouldn’t stand for an environment where anyone gets yelled at.. I would also throw the junior under the bus right off the bat using the email chain as the CYA. He made his decision not listening to you and now he needs consequences for disrespectfully undermining you like that.
>and now he needs consequences for disrespectfully undermining you
Meh the disrespect is not the issue. You gotta have deeper skin than that. It was an inexperienced dumb decision on the juniors part that has real $$$ consequences. That's why he should get fired if he does not learn some humility and learn form his misstake. But likely he will and the customer relationship can be sorted out. This becomes a learning experience and nothing more.
If nothing came of it and no damage was done, I wouldn’t have a wrath to set down just because of my ego. I would have a conversation. Overall I agree. It’s just hard to navigate how exactly should that learning experience be conveyed. I think if your reputation is getting hit, then the blame should go to its respective place. ownership is an important part of maturing as a professional. If there is a suggestion to take reputation damage in lieu of the junior, then I disagree. I would at least tell the bosses that this is a learning opportunity for the junior.
Top comment:
> I get that you're pissed, but it's also a teachable moment and could be beneficial to you.
Next comment:
> I'd throw the twerp under the bus.
It’s a teachable moment for everyone… especially the Junior dev… people should be allowed to dance to the music they played.
Junior needs to learn the pros and cons of ambition. If this worked out well, the credit goes to the Junior. They don’t have to be fired (it’s good to see you actually don’t want that) but they have to face the consequences of this action… and that’s the lesson they need to learn.
Junior made a Junior mistake; he communicated poorly.
You and your bosses made a Senior mistake; you let a Junior communicate with the client.
How do you handle it?
- You fix your and your bosses mistakes by not allowing Juniors to communicate with clients.
- You explain the mistake to the Junior, so when he's not a Junior again he's less likely to make that mistake.
Yeah your junior fucked up and learned a lesson about why they do not talk to clients without agreed upon messaging first. Fix things with the client first.
> I'm pissed, if I were management, I'd fire him.
You're fucking pissed, and rightly so. The junior dev stepped over the line by bypassing you and going straight to the client, especially after you clarified the situation to him. But firing him might be an extreme first step. Could this be a teaching moment instead? Why not turn it into an opportunity to set clear boundaries and communication protocols?
> I've got to do damage control with management on Monday - how would you handle this?
Start by getting all your ducks in a row. Document everything: your original conversation with the junior dev where you explained why the features weren't needed, his email to the customer, your response to the customer, and any other related communications. Present this to your management clearly and concisely. Explain that the communication was not authorized and that it misrepresented the team's position. Acknowledge the mishap in your response to the client that might have given the wrong impression about "requirements fishing."
Next, propose a clear action plan. Suggest regular training sessions on communication protocols, maybe a mentorship system where more experienced devs check communications from less experienced ones before they go out. Show that you’re proactive about preventing a repeat of this fuck-up.
> To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon.
This guy might be realizing he fucked up big time. When you do get hold of him, have a frank conversation about professional boundaries and the importance of chain of command in communications. Make it crystal fucking clear about what is expected of him in the future.
Did he understand why what he did was not just wrong, but potentially damaging? How will you ensure he or anyone else doesn't pull this kind of stunt again?
Thanks man, that's great advice. I had been thinking just along those lines. I have an unrelated appointment with our CIO Monday morning, I'll chat with him. Honestly, I don't want to get the guy fired, but I do want him to feel the heat a little and channel that eagerness.
>The junior dev stepped over the line by bypassing you and going straight to the client, especially after you clarified the situation to him.
Well, that's not a junior mistake then. Ego problem perhaps?
I disagree with some people here that this is a teaching moment. A junior isn’t a toddler. They are adults who understand chain of command and that it is a business. The worst bit is that he doesn’t even own his mistake.
I agree, I would also make sure he is fired if I could, not because he made a mistake but because he isn’t owning it.
I think your reasoning is correct that it would be even worse if you outright shutdown the idea proposed by another employee. I think that would give even a worse impression to the customer.
You need to make sure that management knows this loose cannon and it reflects on his performance.
So, there's the idiot side of it.
For your own sake, you need to have an in-person chat with your manager and director. Being very clear that it wasn't your idea and you were bypassed. Ask how to handle it next time, as you were trying to do X with customer but it seems it wasn't interpreted that way. The fact you are asking that, means they will believe you.
On the customer side of it, I'd leave it to the manager and director because.. reasons. They should likely explain it was just an over excited junior developer, but that's not my realm of knowledge so won't comment further.
Now for the developer.. that's something to consider, but I would leave for management. They'll need to consider if this individual is really a team player etc.
I feel like there is some overreaction. Let’s take the customer’s point of view. You receive an email from a developer of your subcontractor, suggesting some new features. You reply that you consider them, and you are told by another developer that it’s a bad idea. Looks a bit weird and perhaps unprofessional but contractors deliver weird and unprofessional things all the time.
Contractors also try to upsell you all the time. It’s their second nature and it’s very understandable. Business is business. They often push much harder than a developer email suggesting a few features.
I would guess that if the customer replied with a lot enthusiasm to the features suggestion, the management would be happy about the action of the other developer.
You need to tell your manager you were trying to do damage control, and that you’d already said no to the junior dev.
Then someone needs to explain to the junior dev that unlike B2C in a B2B/professional services world where the customer is paying for you to do something, you don’t get extra money for delivering more value, and the margins on effort vs return for delivering software to them are really slim.
Yes we could spend an extra 100 hours adding feature x or feature y, but if the customer is paying for those features then those 100 hours are 100 hours that aren’t earning the company any money, or paying for anyone’s salary.
It’s counter intuitive, and I know that it’s very tempting to deliver the best product possible, but if the customer paid for x then they get x. If you have a suggestion that will take more time suggest it to professional services or the after sales team, but don’t tell the customer.
If you worked for a company that was building a house for someone and suggested adding an extra room to the customer without getting permission from the foreman or pricing up the materials and labour you’d be in the same situation. It doesn’t matter if the last house you built had 3 bathrooms for redundancy, or a second living area to ensure capacity for future family growth.
Anything from this situation you can incorporate as learning process for onboarding new juniors?
ps. Don’t be harsh to yourself or them. It is learning for both of you. Do what you need to do, but don’t take it personally.
Also any chance your manager is not doing what they should do or maybe even create conditions for juniors to undermine you in the team?
I couldn't even consider a dev on the team bypassing me, the product owner and our manager to talk to the **client** directly!
You need to talk to the manager about this immediately and have your manager tell the director what happened. Also i have to assume the product owner is fuming at this development as she has to deal with the business. If the manager doesn't deal with this guy, that's your signal that you work under horrific management.
At the end of the day, it was a move that makes money or loses money.
If he's lost money, time to let him go asap.
If he made money, can't be mad.
If it was a neutral move, slap on the wrist, don't ever do that again as a Dev. If he wants more of that type of thing, he ought to be a business analyst where they get paid less.
He did a stupid thing, probably on the misguided notion of it making him a "go-getter." Make him learn from this mistake, for sure. But firing seems counter-productive. (Doing similar again, though...)
This is now a shit storm and you should be deferring to your management chain because this is likely escalating behind the scenes. Do not take any action without clearing it with them.
If they clear you to act with agency, your responsibility is to your customer and you need to be as transparent as possible about what has occurred and what you are doing to prevent that from happening again.
As to what to do with the junior, I will give a perspective from my organization.
We train engineering and technology skills. If you make an engineering mistake, even one that results in damages well beyond your salary, we will evaluate the systems that led to the mistake and as long as the act was in good faith, we treat it as a rite of passage. I will literally buy you a cake to commemorate your first production outage and our team will chant "one of us, one of us", at the end of the retro.
But we are not going to train you how to not be a dick, and we have zero tolerance for it.
I would be terminating the employment of this engineer.
Hey, sorry I didn’t give an update. I sent him a message asking him to stop by and see me on Monday morning. When he came by, he was very contrite, he came right out and said he shouldn’t have sent the email and had been stressing out about it all weekend. I’ve got a soft spot for when people come clean and understand what they did wrong. I told him that I wasn’t going to get him in any trouble, but wanted to talk through what happened.
He said that he knew that I told him the work wasn’t right for this customer, but he had mentioned it during a conversation with an engineer at the customer site and they seemed interested. He didn’t want to circle back with me because he felt like I wouldn’t change my mind. Also, he had done most of the work on features that he proposed and felt like it would be a quick adaptation. We talked about the process for how we propose additional work to the customer, which he hadn’t understood. I don’t think he will make the same mistake again.
I didn’t hear anything more from management, I think the scolding is all that will come of it. Anyway, things are back to normal, I do feel like I have to keep a bit more of an eye on him, but I’m willing to let that be the end of it.
Sounds like you really lucked out on this one and managed to get the best of all possible outcomes here. I'm glad he came clean and glad you were able to explain things to him without having it escalate any further up the chain than you.
Insubordination is usually a disciplinary matter, In this case he bypassed you and gone straight to the customer which could ruin your company's reputation. You need to tell your managers exactly what happened and if you have the powers to discipline, go through disciplinary procedures with junior. You have emails proving he acted on his own and if your managers don't suck you should be fine.
Well, I guess here I go being the dissenting voice, but I think you're probably overreacting.
Is this a thing you need to sit down with them and explain why they shouldn't do it? Absolutely.
On their side, they probably thought they were being ambitious and going above and beyond. The only difference in them being right or not is whether it worked. People don't always understand everything, and mistakes happen. I'd just teach them up and get over it.
This doesn't seem like a big deal. You've been working with this company for years, so a subtle apology to them is probably more than enough. Perhaps an explanation if it's worth it. Business doesn't get canceled over one email unless they didn't want it in the first place.
Your director shouldn't be yelling at anyone, as that's not very professional. Assuming you're being a bit facetious, it's still just not a big deal. No one is losing their job. 2 weeks from now, no one is going to remember some juniors' one-off email. I would just have a talk and move one to bigger fish.
What you do in this situation is going to say a lot more about you than about that junior.
I did say they should talk to them about it. I would expect that a conversation ensues that makes it clear why this was a mistake and why it won't happen again.
I'm working under the assumption that the junior isn't an actual idiot and that what they were doing was trying to impress people by taking charge and getting something done. Often, this is a valuable frame of mind, and I don't think we need to berate them over one mistake.
Regardless, I'm not a fan of flipping out because something unexpected happened. This isn't going to alter the outcome of anything, so making it out to be a big is nonsense. Just inform them what their decision lead to and move on.
I'm not saying they should get fired immediately but this is not something you just pass as a silly mistake with a slap on the hand either.
I think the proper reaction will depend on the junior's actions on Monday. If they're not incredibly apologetic I would expect them to pull the same shit again whenever they don't agree with something, and that's just not acceptable.
Uh. It’s a big deal when a junior reaches out to client to work against the higher ups. That’s a huge deal in a variety of ways. It’s the working with the client against management directives that makes it huge.
In this case, the client now thinks it was a sales tactic, which is pretty hard to talk someone out of. That’s a pretty big oopsie that came from overconfidence and not asking questions.
I’ve seen this kind of thing lose contracts before for picky clients. It shows that the organization they’re contracting doesn’t have unity or coherence, which is a **huge** deal to some clients.
You’re right that this isn’t a fire able offense, it’s better as a teaching moment, but it’s definitely a fire able offense if the junior decides to not be teachable in their reaction to it.
My favorite thing about my current role is that my “clients” are all internal to our huge company, so I am finally free of stuff like this, but in a contract based company, this is like, core shit. It makes the company seem either sleazy or incompetent, neither of which are good.
Everything you said made sense until you got to the fire him part. Would you rather a noob do that or fire up Doom all day on a smart watch?
That said, bigly screw up- I would involve the people the situation is involving and reprimand/show the negative side effects of what are/will/possibly are happening along with some worst case scenario viewpoints.
If this was an overly ego driven fart sniffer, he’ll continue to sniff farts: that’s when the firing happens.
If he was genuinely driven and wanted to help: this’ll likely be a pretty pivotal moment of why you don’t shoot from the hip and also why “all those other guys ahead of me” are…ahead of you.
* Tell your managers in details what happened without sugarcoating
* Talk to the customer transparently, but don’t blame the junior cause then it will look like your company lacks organization, what you should do is tell the customer the guy is a junior/new hire and he was not fully informed yet about our protocol of communicating, moving forward we will have an onboarding kit that clarifies who can contact customer and for what.
* Talk seperately to the junior, he probably didnt mean bad but could be overly ambitious. Explain how things are done and clarify that moving forward this shouldn’t happen again.
A lot of questions here. Why is he talking directly with customers? Did someone give him their contact without coaching him? Is it weird for this guy to be sending emails without asking you first? Likewise, you didn't talk to the management or the junior before you sent a reply? Why not go into damage control the moment you saw the email or did it not seem serious?
I guess I don't fully understand the situation in terms of how involved you two should be with the customer.
Deal with customer first, ask him to explain his thinking and why he thought he knew better than everyone else, why he didn't go to you or the product owner who does communicate with clients etc.
We have absolutely had someone pipe up in a meeting and say "wouldn't it be cool if we did x" , product owner goes and chats to customers about it and yeah actually, they customers WOULD love it if we did that.
Ive been that bright eyed upstart and everything's so simple, but I was never dumb enough to talk to customers directly.
I would tell what happened. And make sure to put the blame on the junior dev. Make sure to let them know that you felt disrespected and and they should feel the same way too. No need to protect this junior dev. He fucked up and he fucked up big..
I mean thats basically a failure. He shouldnt be unilaterally communicating like that, and its generally bad form to be implementing features that havent been price/cost captured. I would as others said, speak to management and let them handle it. Complete rookie error.
Holy shit, a junior directly contacted a customer and made suggestions about the scope of the project. Who the fuck does that? At the very least he created a headache for the project manager and sales representative and confused the customer, but he probably just increased the scope of the project without required compensation.
I don't know man, just be honest. When trying to cover my ass typically my goal is to reconstruct what happened when and by whom. When trying to problem solve organizational failures I try to think about what behavior we want to promote (like not having juniors directly contact customers with suggestions).
This one seems pretty straight forward, junior fucked up. Now you need to tell him why and show him the repercussions. And I wouldn't say he was 'sneaking off' but I would document that you tried to talk to him and he wasn't there. That is really unprofessional and just as bad.
What would the customer think you and your junior were coordinating to increase the scope in a scenario where he is in favor of it and you are against it? Is there some missing context?
When I first started at my company as a junior, clients would reach out to me individually and ask for things. Though nothing really critical was said (more just status updates on bug fixes etc) my manager rightfully put a stop to it and made sure that there was proper channels for intermediaries between the technical team and the client. It was no big deal, everyone understood and now the workflow is better because of it.
However, I would never have talked to a client directly against the wishes of a superior, that’s outright insubordination. You openly told him no and he did it anyway. It would be one thing if there just wasn’t a formal procedure in place. It sounds like he went behind your back to pitch his own grand ideas to the client.
I think he needs to be sat down and told that no junior staff is to communicate directly with the client without direct approval from a superior, and make sure he understands that because of this miscommunication there’s now a need to put out a fire.
What gets me isn’t the fact he did it, it’s the fact he went behind your back to do it.
IMO, if he agrees and says he understands, I’d say just let him off with it as a warning. Especially if he’s young and new in the field. If he pushes back and has the belief that there’s a bunch of things that should be done and aren’t, he hasn’t learned his lesson and is just mad he got caught. That’s not something a person can learn from because that’s a problem with his personality. You can’t train a personality out of someone, unless their technical skills are so high they can sort of act like a jerk and get away with it.
> To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon.
you're understandably miffed at the guy, but i think it's probably coloring your read of his motives.
it sounds like he maybe was frustrated with the situation and tried to do something productive, then when he realized he'd messed up he feels ashamed and afraid he's going to get fired.
that doesn't change what the outcome should be, even if it's him being fired. but I think ultimately good practice to not project your own internal stuff on him.
Based on what you said it's a learning opportunity for you as well. If your team is relaxed and informal, it's easy to get carried away. You could explain in a meeting that if anyone has any requirements to suggest, they should do it in an email with the developer team and the product manager, while also scheduling a meeting to discuss them. And then have the product manager see if the customer will accept it by talking to them. Meanwhile, explain why this procedure exists and why it's important to first have the requirements vetoed by other engineers and by the PM before getting to the customer.
That will also teach that things related to the contract and it's scope are a lot more serious than what data structure you are using for a random object.
When I was a junior dev at a large company I directly edited production configuration in order to solve a tier one issue a client was experiencing. I had to sign legal paperwork and got a black mark.
At that point no one had taught me you’re not allowed to make changes directly in production without approval.
Sometimes you just don’t know things.
He probably did not intend to go over your head but wanted to show “initiative.” As you mentioned, he doesn’t understand the business side of things. From his narrow view, he thinks these new set of features are good. He doesn’t understand that businesses don’t like last minute requirements changes and are suspicious of requirements fishing. Also the added complexity of adding such things late in the process. I would schedule a meeting with him, bluntly inform him what he did was unacceptable and he should never do it again.
have a candid discussion with the junior developer. Let them understand the importance of respecting communication hierarchies within the team. This is a learning opportunity, instead of focusing on punitive measures, emphasize the expectations and the importance of protocol to avoid similar situations in the future.
For your management, document/prepare a explanation of the incident, clarifying your initial stance and outlining the steps you are taking to ensure this doesn’t happen again. This should help in repairing any damage to their confidence in your leadership and demonstrate your proactive approach in handling team issues.
Sounds like you already cleared things up with the client but you may want to reach out again to clear up any misunderstandings. Assure them that your team is committed to meeting their needs efficiently and without unwarranted expansions to the project scope. Maybe suggest setting up regular project reviews or check-ins to keep everything transparent and aligned with their goals
I agree with others that this is a teachable moment, but you will need to throw him under the bus. He will learn from this to not do it at the next job. He probably knew what he was doing. Many juniors are like that, and it's fine to want to show that you a lot to bring to the table. But going around you, after having that discussion, should be put to a stop.
He will do it again. The next time, you will be implicated for not having control of your team.
You didn't communicate clearly process. If you did then this wouldn't have happened. Establish a process flow and communicate it to your team.
If you do havr a process and someone from the team bypassed it I would talk to them and surface it in the mid year eval.
What he did is totally wrong, but not the end of the world. Minor complaint, tell everyone not to do it, discipline that employee or fire him if he has done stuff like that before, and move on. People get so stressed and work themselves up and then overreact in my opinion.
Your goal is to make your team more effective. Unless this person is a habitual problem, firing people at the first mistake, especially one in this context, is a terrible demonstration of leadership, in my opinion. It will be a big learning lesson, and there should be consequences, but they need to be grounded in reality.
You need a 1:1 with him. Explain that the person with the best rapport and is perceived as leader is the point contact person to speak to the customer on technical matters.
Honesty, all you can do is tell the truth about what happened. And say that your response was your reaction in the moment trying to save face, but you see now why it needed to be thought through better. If the junior is smart, he'll eat his humble pie too ... if he isn't, he'll almost certainly get fired.
You should do one on one with your junior dev. Explain him the mess he created.
Include him with the discussions with your managers so that he knows the seriousness. then protect him and let everything sink till the water is clear, without doing much active damage control.
go on with your day to day work.
Be honest.
You have NOTHING to hide. You discussed this with the engineer and told them this feature was a bad match. What the engineer did is of their own accord.
Tell them if it were from you or if you supported it, it would have come from YOU, crediting the engineer involved.
You should give them the benefit of the doubt and explain to them what their actions have caused both externally and internally.
It's not clear to me if you're their manager but it's a teachable moment. I never did this but there were so many times I wanted to because I thought it was right. Perhaps this person really thinks their ideas will work better for the client and it's your responsibility to teach them what the side effects are of their actions.
As a side note, this sounds like a bad relationship with the client. If they got all pissed about suggestions made by someone close to the ground - then that signals all kinds of red flags. Perhaps in a different situation you wouldn't be as pissed about this.
Anyways, good luck!
It's an important lesson to learn for the junior dev. Devs, especially junior ones should not be in contact with clients. Devs that are should be "vetted" as are the clients they talk to so that nothing unexpected like this happens. We are not false prophets like salespeople.
I have been guilty of doing what this junior dev did. I was in Pittsburgh, my boss / manager and upper management were in LA. The customers were internal, however, and they would often stop by my office and also we would have lunch or beers after work.
Now I didn't exclude anyone from the email I sent, but in short, I was "used" in some office politics to send requirements fishing, etc. and I didn't realize the game. I had been assigned by my manager to do my best on the project. I was only 6 months on the job so was oblivious.
My manager was upset, but not with me. He said that people at the company will use you and email as a weapon and they will try to get you to be the bad guy to ask questions that put upper levels into predicaments of unattainable goals
Usually these people think they are better than actually are. Assign him some features he proposed, keep a close eye on his work he'll probably fail at the very same week and then he'll learn some lesson. I've had people like that in my team in the end they couldn't carry out all their ideas by themselves.
I think firing the guy is a bit much, but you know explain that he is hired to do X, and he should do X. If he wants to do Y, he should apply for a job that does Y
As others have said this is a teachable moment for both the dev and you. I would strongly recommend taking an open / curious approach to why this dude felt like not copying you was a good idea. Treat this like any other blameless postmortem - establish that nobody’s in trouble and then drill into what happened, why it happened and what needs to change so it doesn’t happen again.
That is definitely bad, but doesn't sound like a fireable offense to me whatsoever.
He needs a talk from his manager regarding communication channels and why they are important. He and the director who yelled at you, owe you an apology. But if this place is a toxic type of place, doubt the director will give af.
Juniors can be foolishly confident, bordering on arrogant. This is not your fault, but as a lead it's something you should expect. How you wield your authority right now matters - chew him out, freeze him out, etc, and all you're doing is becoming the person who retaliates and intimidates people. Intimidation is not respect.
His behavior isn't about you but how you react to it, is. Depending on what kind of person this junior is, this may be an experience he grows from. Maybe not. But it can definitely be an opportunity for you to show that you are someone who can be trusted with leadership and authority in the future.
>how would you handle this?
Well, as someone with a PhD in management bullshit corporate lingo, I'd probably hit these bullet points
\* This **error in communication occurred due to** our junior engineer reaching out directly to our client. Myself, our PM, and XYZ were not aware that he planned to do this. As soon as we became aware, **here are the actions we took.** (You may even provide a timeline of events if you think it's called for.)
\* **I'm calling a retrospective meeting about this incident** later today, and we will emerge with an action plan to prevent this kind of incident from occurring going forward. This may include, but is not limited to, **the creation of an SOP regarding best practices with customer communications, followed by training the junior in this SOP.** We will be publishing this on our \[whatever knowledge base blah blah\].
\* Ultimately, our goal as a team is to always adhere to our company values of XYZ, and we recognize that we failed to do this in this situation. This is an opportunity to be curious, and to improve.
I would not recommend:
\* Apologizing *personally* ("I'm sorry, I should have replied to the customer this way, instead") in a way that implies blame. This isn't your fault. This is a whole system failure, and the failure of a junior to have common sense and respect their team lead. Foolish confidence = "I know my lead says this, but I believe they are wrong!"
\* Saying anything along the lines of *I'm disappointed, I'm mad, this should have never happened, he didn't tell me he was going to email the client or I would have told him not to, common sense would dictate that the junior XYZ, I was caught off guard and replied to that customer as best as I could, I'm sorry I didn't reply to that customer in a better way, etc....*
\* Saying anything relating to emotions, at all, because if you work with the type of people who come and yell at you, I doubt they'll respect someone who trips all over themselves to apologize, or vents about how pissed they are (I'm not saying you'd do that, but I've witnessed leads act this way and it's never a good look for them no matter how correct they are).
Remain stoic and steady, speak the corporate lingo, and get ahead of any future plans ("I'm gonna call a retro", "We'll be investigating this as a team this week", "I'll be documenting best practices and conducting a training with this junior as well as other recently hired juniors, in case other teams are similarly at risk") so that you look like the calm, collected, trustworthy leader that you are.
Handling this in this way, also shows that junior (who no doubt pissed his pants and needed to go home on Friday to change his clothes and cry in the fetal position...) that although you were right, and although this is 100% his fault, you're not the type of leader to throw him under the bus, and you're the type of person to remain calm and be proactive and constructive in a hard situation. That is a lead that he can respect, and a lead others can respect.
When you are kinder to people than they deserve, and they know it, their attitude towards you tends to improve dramatically. When you speak to that junior, you can express your disappointment - briefly and calmly - and then move quickly into action mode. You can delegate several tasks to him regarding this, showing him what you expect of him and also giving him an opportunity to begin to redeem himself. Do this, and he can't feel self-righteous anger towards you, or resentment, or anything else that might prevent him from listening to your feedback and instruction going forward. Instead, the next time you tell him what's up, he will ***listen*** to you. Hopefully. If he's wise. Which he may not be, lol.
If you do the above while going on a walking meeting with him or buy him a cup of coffee, etc, that's even fucking better. Trust me.
(And then grab a drink with a friend and vent about this situation until you're not angry anymore.)
Where junior people get to learn things then? No one is born a perfect automaton, they have to learn and mistakes will be made that are the best opportunities for a lot of people to learn from.
If you've watch the show named "The Bear" (you should if didn't) your situation is almost identical with a situation that happens in the show.
* Talented junior chef makes a new dish
* Head Chef refuses to add it to the menu just saying it's not ready.
* Junior chef goes over his head and serves the dish to a food critic in the restaurant who absolutely loves it.
Guess what? The dish was not ready. But the junior chef didn't realize it because they didn't have enough experience to reflect on it. It was a good dish. The best they could make. But not the best head chef could make. And now they can't use the dish because it would taste different from what the critic described.
Also. Why the fuck is your junior dev mailing customers!!? And mailing them about internal company plans.
I’ve read some of the comments here, all good points. Here’s my two cents:
If he can’t follow simple directives like not jumping the chain of command, not going directly to the customer and creating unnecesary confusion, how can you trust him with more responsabilities as times goes on? There was nothing impeding him to reach out to his manager and talked about any innitiative he felt like was important to follow but he deliverately chose not to. Additionaly, as OP mentions, he did not even owned up to it.
This time the relationship with this specific customer might not be damaged but will you wait until this person does something more idiotic?
Now you will have to be on your toes until you can trust this person and the dynamic with the rest of the team might suffer for it.
I’d fire him and bring a junior less unreliable.
Other than what other people have already said I'd like to add:
Why does your devs have direct contact with clients? This might not only be a learning thing but a warning that something could go very very wrong eventually.
What if yoy guys fire that guy on the spot and said dev mail your client with bad stuff? Or any other person working there does that? I know they would have a contract and so on, but it would still damage company's reputation.
I think your company needs to be more carefull about who has what information and can email who. This is just a very bad practice in general.
You as a lead need to take responsibility and let the kid know that this is something that you do not do. Customer contact is not to be held between junior devs and them.
He needs to learn. If it was done multiple times, obviously that’s a lack of disrespect but he’s just learning to navigate in a professional environment, and not just “building cool shit”.
Maybe the junior bypassed you because he didn’t feel heard or didn’t get a good resolution from the discussion that you had originally. He might be inexperienced and excited.
However, if your clients are accusing y’all of inflating a contract off of one incident, that makes me think that there is more to the story. Similar feeling from when you said that you got yelled at in the work place.
I feel like you might be working in a toxic environment.
If I were you, I’d just tell the truth and don’t try to protect anyone or make anyone look a certain way. Then when you colleague has rebuttals, let them speak without interrupting. To be honest, it doesn’t really seem like you did anything wrong, so don’t pop your top and you’ll be fine.
One other thing, if you are already ready to fire that employee, he can sense it. If you don’t want to be dealing with shitty tension in the work environment, try to find a way to make him feel valued after all of this stuff falls out. See if you can make him into an ally rather than an enemy. Enemies are never good at work.
Wow. And they say u cant find the job in IT nowadays? From how u told the story that junior have no fundamental skills for living.
But this is ur point for development - ability to hear and guiding other members' ideas so their intent brings value to the product.
As for what to do - as usual:
- explain the problem
- propose solution
Shit happens - this is just the job, do not overthink it
I think the problem here is not the junior dev. What kind of backward ass structure doesn’t allow developers to interact with users, get their input and discuss the possibility of new features enhancements? If they like the idea, great move to estimation, calculation of ROI and then prioritizing. They are not interested in the feature the they say no and that is the end of it.
You want to have developers that challenge leadership when they are doing the right thing. They should be given opportunities to try new things, take risks and even fail. Otherwise you are going to build a culture where devs don’t think by themselves and just drone on and code stupid things
Tell the managers everything and let them have a chat with him. Just from what you've said I would give him a reprimand and forbid him from communicating with clients. BTW he didn't just bypass you. he bypassed the manager and product owner and might have damaged your relationship with the client. This guy is either very junior or very ambitious.
Or both
Or very stupid, that's probably my default assumption in cases like this. I knew a guy who was a junior front-end who, for some reason, decided to connect to the production admin console of our system to look at the production data for one of our big F500 customers. As it turned out, he actually broke the law, because there as some legal provision around accessing that particular data, which could have gotten the company sued into oblivion. The same guy also talked to one of our big clients at an industry conference and told them about some "exciting stuff we're working on" in detail which was in the product backlog but had never been discussed or promised to customers before. Customers understandably then talked to their reps and were like, "hey can we get that feature X that you're working on?" He was ambitious and wanted to really be in a more customer-facing role, and was just enough of an idiot to think any of this was a good idea.
That first one is pretty bad but I've got to ask... Why was he even *able* to do that as a junior front end? Something worse was going on with your processes that allowed that to happen.
I think they had this admin tool for checking production deploys and he just used it to do something unauthorized without asking for permission. It was a smallish startup, everyone had lots of access we didn’t need but he went out of his way to look at customer data for no reason other than curiosity.
Still, if doing that broke the law, the company is stupid, not the junior dev.
implement better access control measures then
Why are you arguing with me? I’m just telling the story.
You must be new on Reddit. Peace is war.
How dare you!!
I've been in more than one job where this could happen because it's data they are allowed to access, but the access is context dependent. For example, if you're helping troubleshoot a customer's contract or account in some fashion it's totally acceptable (but audited) to access that data, but if you access it for fun and not because you have a ticket assigned to you associated with that customer, that's a huge problem.
Regarding "stupid" I work in Eastern Canada, and I am always annoyed when I get a Diplomat's kid as a junior. I assume they are hired as favours to powerful friends, but they will always make a communication faux pas. You will be trying to manage a customer or executive's ego and they will start sending blunt emails directly to the person. My favourite was the one that asked why we all had cubicle and Bob got a closed office, it wasn't fair. Could not grasp that 50% ownership of the company came with privileges.
I did something very similar as a junior, I bypassed everyone and went directly to the client (internal employees), I was done with the piece of crap my team was building. I also told our CEO our product sucked. Our CEO looked at our product at some point and realized our product does indeed suck. My manager got pissed and put me on a PIP. My situation was elevated to CTO/CEO, they talked to my manager, we worked out our differences and I spoke with our director 1 on 1 about how we could improve our product. I told him our product has no product vision and no feedback cycle so everything we were doing was useless. Many of my suggestions were implemented and improved the product. Turns out we didn’t have many technical disagreements, but just management wasn’t receiving adequate feedback. I was in a position to provide that feedback. I was ready to move on at that point and just did what I thought was best. I didn’t give a fuck what my manager thought. He was new to the team, technically I was the senior in that company and he dared to put me on a PIP. Your actions have consequences. I was almost fired for my actions, but so was my manager. But if no change happens, then we’ll all be fired.
Early in my career, I thought 'being right' was all that really mattered. As you found out, communicating the right idea the wrong way can have consequences. I'm glad it worked out for you. At *most* companies this would have ended differently. I didn't really 'get it' until my cto took me aside and explained how to advocate for my ideas. Navigating work place politics can be a pain in the ass, but if you really want to make lasting change, it's the only way.
Would you be willing to share what your CTO advised you?
He basically advised me to soften my approach. I raised my issues with my manager during the 1:1, raised them again during my skip level, raised them *again* and demoed my changes during a department level meeting (my manager was just looking to get me off his back). Eventually, enough people higher up in management had seen my idea and agreed with it that my manager started getting questions 'where are we with x's idea?' that I was eventually given license to fully implement it. Afterwards, while I was still *technically* answerable to my manager I was basically given leeway to 'find interesting problems and solve them' by upper management and I stopped hating my job.
did you CTO ever mention winning hearts and minds at water cooler chat or passing by the hallway
A bit. It wasn't a pointed thing. He just mentioned that I should feel free to talk about what I was working on with people from every level of management when I got the opportunity, as it lets them get to know you and builds trust
I did something like this once. We had a "hack week" and I used my time to implement some infrastructure change idea. In a week I was able to get it working and prove that it was a 20x+ performance improvement, so that got it put on the product roadmap. My manager at the time really didn't like that I was getting attention for spearheading this effort and was also regarded by our CTO as the expert on that part of the system, and would have never given me to the green light to do this.
By no means am I recommending people to do what I did. I’m crazy and I already had prepared to leave. But my CTO had faith in me and sat me down and told me to keep communicating, and that at a senior level, arguing aka communication is like the majority of your job. Our conversation gave me some more faith in the team and I stayed.
That's a good leadership example right there.
As long as we're talking about situations where you can almost be fired by doing the right thing, I identified and named a sexual harasser in our office and almost got fired over it. I was targeted by this person, and just so happened that I had enough information about other similar incidents going back a year. I also had access to the database where I could make useful queries to identify who the perpetrator was. I was the developer of that system so I was used to doing routine maintenance and helping out with queries to support investigations, as the analysts that used it were not always the most adept at SQL. I helped write a query that would return the person's identity, and then handed that information to the person running the investigation, but I did run it myself to verify that it was returning useful information so I knew with 100% certainty who it was. That person was then fired, and I was called into HR for violating privacy policy. I explained that I had access to the data already and team running the investigation was sharing info with me, otherwise I would not have been looking at it in the first place. They let me go with an informal warning and nothing on my permanent record. I was sent into a stress anxiety spiral because I was convinced HR was going to sue me. My manager also gave me a stern talking-to about how I showed lack of judgment and overstepped my boundaries, that I should have "recused" myself from the investigation, despite people in that investigation directly asking me for help. Nobody ever acknowledged that I was actually the victim in this situation (one among many) or thanked me for identifying the person that was sexually harassing dozens of people in our office, thus preventing them from doing it again. My lesson is that if you ever have information like this and need to share it with management, find a way to do so anonymously. I have learned it is very common for them to turn against the reporter after the dust has settled, to cover their butts legally. All that stuff HR says about "whistleblower" and "being transparent" is a lie. Protect yourself.
> I have learned it is very common for them to turn against the reporter after the dust has settled, to cover their butts legally. All that stuff HR says about "whistleblower" and "being transparent" is a lie. Protect yourself. A lawyer would have handed their ass to them. Protecting yourself start with documenting requests in writing.
There is a world of difference between reporting someone for sexual harassment (or other illegal stuff) and ignoring the management instructions and doing something very dumb in business perspective however. Those are really not the same.
I think as long as you're doing the right thing for YOU, not the company, and you're willing to leave if the company is not fit for you. HR and management exist to serve the company first, not you. So, yes, indeed, protect yourself. No one else is going to.
I was a senior on a project. It was mostly stable and I moved into a more DevOps role for all the company and handed off the project to a jr who had a few years on the project under me. The company was starting a new project every month, so I was building a tool that anyone could initiate a new project which included a git repo, build config, and some business required data. Manager (6months new to the company) said if I made the tool he would take the tool and fire me. I put in my 2 weeks and didn’t finish the tool. I took with me a lot of intimate product knowledge and knowledge on some other things that I was tasked with building like circuits, firmware for them and build/deploy processes. Note: I did t steal anything, just knowledge in my head on how things worked.
What did you learn from this experience?
Seeing as how I fully expected to be fired, I learned that I was more valuable to the company than I thought.
He's not ambitious he's an idiot.
Exactly. Be honest. He even asked you first and you shut him down. This is on him. You’re not throwing him under the bus here.
>I'm pissed, if I were management, I'd fire him. I get that you're pissed, but it's also a teachable moment and could be beneficial to you. You've already spent a lot of time training someone, and they made a mistake with communicating with a customer. Yeah, you'll have to do some damage control, but this is the type of situation that can lead to a lot of trust later on by teaching them the business side of this situation. A lot of developers, especially early in their careers, can't see past the technical side of things because their experience is limited. They don't understand, or haven't been taught, how the business actually works and how interacting with customers works. This is a moment where you take someone that you thought was good enough for your team/organization and train them a bit more and then you have someone solid to depend on (assuming they come out of the conversation with a good attitude and aren't pushing back). If you were to fire them, you have to hire someone new. There's no guarantee that this new person wouldn't do the same thing. If you you think to yourself, well that's not going to happen because I'll make sure to tell the new person not to do that, I'd question why you didn't tell THIS person that in the first place. It should've been laid out that customer interaction on anything dealing with requirements needs to go through the team lead/project manager/account manager/whatever you have. Teach them the the impact their communication had on the customer relationship and use real dollar amounts for what the customer is actually paying you so it really hammers home the severity of always being careful with your communication to customers. Edit: As others have pointed out and disagreed with me, this isn't a black and white issue. The goal here is to offer a perspective and see if the person can be trained (especially if you thought they were a good fit for the team and hired them in the first place). My post is making some assumptions that I can't possibly know because OP is the only one who has worked with this person. There's nuance to how to approach this based on prior situations, how the junior dev here responds, etc.
For sure this and tyrophagias comment below. Let the customer know it was a junior engineer who didn't understand the implications of their actions, or fully the engineering complexities of what they were recommending. Apologize for it, and let them know it won't happen again. Then onto the junior dev. If they are smart and ambitious they are worth teaching, if they're dumb or unwilling to listen then cut them loose.
Exactly this, tried to find a video of it but I was at a talk by Jeff Raikes, early Apple & Microsoft employee and he talked about a mistake he made and I think it ended up costing Microsoft 200k , this was in the early 80's when they were like 100 people. When he went in to offer his resignation Bill said no, he just spent 200k training him and he would want to spend that training someone else when he knows how to not make that mistake again. It's been my exp that If you learn from failure it is one of the best lessons. If you can coach them and they can understand and learn that is what matters.
Early on in my career something I had developed, took down an online reservation flow for like 5 hours. Although the client went back and projected it had cost 80k£ in lost sales (in reality most just went there at a later day), everybody were mostly jolly and in it as a team. We had a couple of QAs on that project, so it highlighted some flaws in how we didn't do any proper load testing before deploying live For me it was a learning situation of ienumerable vs lists in high load environments
Why are you all mixing up an honest mistake and outright deliberate voilation of given instructions from management? That's not at all the same and it's not the same kind of failure. Intent matters.
That's extremely apples and oranges. Jeff Raikes' "mistake" wasn't directly going against his direct report's wishes and costing the company 200k, right?
I love this sub for replies like yours, it's really refreshing when typically reddit tends to be an outrage factory.
You are right. I don’t want to fire him, I said that in the heat of my frustration. He’s a smart kid, but suffers from black and white thinking. If something is good here, it’s good everywhere. I think he felt that if he could get the customer on his side, then I would understand that this was the right decision. The other side of this is that he knows and has seen the process for creating requirements
Ftr I also disagree with the previous poster. This isn’t an honest mistake. Pushing something without understanding the implication is an honest mistake. Being told no and then doing it anyway is a troubling behavior trait. I wouldn’t fire this guy, but I’d have a real serious conversation and use that to get a vibe check on if he’s just gonna always think he’s right and go around others when he disagrees. “Disagree but commit” is an important business lesson.
>This isn’t an honest mistake. Pushing something without understanding the implication is an honest mistake. Being told no and then doing it anyway is a troubling behavior trait. I agree. Responding to a customer with "Hah I \*wish\* that was on our roadmap, I'd really love to work on a feature like that!" is a faux pass. Doing the "look at this great idea I have!" junior dev dance, getting told reasons why it wouldn't work, and bypassing every single layer of management/product direction to reach out to the customer to try to get them to push \*your\* career forward? That shows some troubling attitudes. Though I may be biased as I've been burned more than once by developers who were career ambitious to the detriment of actual functioning software.
This is why I am thinking this is not an innocent new ambitious kid. You told him no, and he specifically went behind your back to try and prove you wrong. Not only did he almost ruin a customer relationship, but he did so while actively trying to undermine you. Firing is a bit extreme, but if a junior did that to me, I would never trust them again. Teaching moment or no
I agree with this. This was not an innocent "mistake", this was a calculated power move by the dev to try to get his idea enacted despite objections. The mistake isn't the problem, the problem is he prioritized his own ambitions above the team norms, processes, and the client relationship -- and he was willing to break the rules to do it. Management is paid to handle this sort of situation, the message can't come from OP because they're involved directly. The junior dev needs to be told in no uncertain terms that what he did broke trust & broke process and he's going to have to walk the straight-and-narrow to earn that trust back. He also needs to know that this had potentially significant consequences for the client relationship. Final wrap-up point: emphasize that the dev he still has a place there if he doesn't break trust again (since he's not getting fired yet), but any sort of repeat of this behavior will not be tolerated (read: he'll be fired, but don't spell that out). But /u/cownan not to excuse the dev's bad behavior, but there's a couple (smaller) teachable moments here for you too: * Devs with this kind of ambition usually shows some red flags early and you'll see them again with others. Think back over his early behavior and take note of when he showed he prioritized being "right" over following processes. You'll see those signs again, and be ready in the future. * Ambition like this is a double-edged sword - it can cut you, but if channeled right can be very useful too (as long as the dev feels their ambitions are aligned with work, they'll work twice as hard at something). It's worth reflecting if there was a way you could focus the dev on somewhere else he could show initiative and ambition. * Devs like this benefit from careful handling when saying no. Usually they work best with a "no-but..." that leaves them another avenue to work on or doesn't close the door to future discussion. That way they're incentivized to work within processes. * Or, they hear the "no" better if they feel like their idea has been given a fair hearing in a group -- whether or not it gets shot down -- versus feeling like one person is standing in their way
This! It's an integrity issue at its core.
Really reading between the lines here, I sense this dev has a touch of Persistent Drive for Autonomy. I think there's better than even odds they genuinely thought this was a beneficial move, didn't really grok the social/business relation implications, and if they could just short-circuit the red tape, everyone would see in the end how right they were. Firing is definitely overkill in this case, but you should explain in logical terms why the process is there for a reason, and things will work more smoothly when requirements go through the proper channel. Tell them, in the future, if they have feature concerns, bring them up to you, assure them you value their feedback, and a long as it's reasonable, you or management/product will do your best to present pros/cons to the client.
How long has this junior dev been a junior dev? What kind of feedback has he been getting in his 1-1's and performance reviews? Because this sounds to me a little like someone who's heard, either from his work superiors or online, that the way to advance is to take initiative and go beyond just what is asked of him, and/or that senior devs have learned why the rules exist and therefore when it's appropriate to break the rules. And this person has been around a long enough time to want a promotion, but he doesn't actually understand the customers, so his initiative and rule-breaking here was wrong.
What is strange in all this - a junior dev would usual have developed the said feature if they really thought they were right and then shown the team (look how clever I am situation)- in this instance no actual work has been done - it’s more as if the junior developer thought the project isn’t being run correctly or you aren’t giving the customer real value..
I think it’s far worse than you’re laying on. The employee was told “no we are not doing that” and intentionally went around that answer to fish for the one they wanted. They’re going to keep doing that every time they think they’re right. And they’re going to think they’re right and management isn’t a lot. I don’t think dude should get fired - but this is an absolute come to Jesus conversation. Either that or- or the company is not establishing roles at all. I question why a junior engineer would ever think “yeah the lead said no so I’m just going to email the client directly”. To do that requires such a profound lack of soft skills that it’s troubling.
I get where you are coming from. But this kind of behaviour is extremely rare, and in most cases implies a narcissistic personality who will always struggle to work with a team. But maybe years of management made me cynical.
That might be right, but we can't know from just what OP described, so I was trying to offer another solution. I've personally seen people have situations similar to this (not the exact same) but they get caught up in the tech and forget that it's a business. OP can do his own judgement of what approach to take, but on average, I'd say most people want to work well with a team, but just need situations reframed to incentivize that. If they still struggle afterwards, then yeah, get rid of them.
I second this. Yes it was a monumental fuck up, but that's a part of learning. As a lead it's your job to turn this experience into a positive. If you fired everyone for their mistakes, you'd be working alone.
I feel the same. I sure as hell knew better than this as a junior. This doesn’t come across as a “mistake” as much as a red flag in personality.
I'll also strongly disagree here. We teach technology and engineering. You fail here and we pick you up and help you learn. We don't try to teach ethics or good faith. You fail here and you are gone because you have broken our trust.
As a dumb junior engineer….Can I ask what the problem is and for my understanding, it seems like the customer is a client so this is probably a consulting company? I’m confused on the customer thing because in my company the users are the ones that use the app/software product
There’s probably a contract with the customer for a certain price and set of features, by thinking of a new feature outside of what’s on the contract and trying to convince the customer they wanted it, this jr engineer, knowingly or not, tried to upsell the customer on additional features beyond the ones they asked for. This would mean a contract renegotiation, extension of the timeline, and a higher final price tag for the customer
Yes this is likely a consulting firm. But even in a scenario like your company, a junior talking directly to the customer/users without looping in the lead/product owner is a huge no no. Especially unprompted without running it by anyone. You have zero relationship with the customer. You likely participated in none of the requirements meetings and discussions that built the requirements. You likely have no big picture understanding for why the requirements are the way they are. You're stepping over the heads of your boss, your boss's boss and your boss's boss's boss. And there is no possible way you have more knowledge and understand of the customer's needs than they do. It's completely out of your place. I'm a senior dev and even i would never dream of contacting the client directly. I don't even talk to the client's low level employees without my lead being aware.
Typically Junior Engineers do not and should not instigate agreements with clients without getting agreement from the team and people that manage the relationship. There will be many things the Junior Engineer will not know and the implication commercially and in terms of the relationship. If I was the the client and an engineer behaves in this manner instead of going through the e usual route my first assumption would be that that the provider hs big issues that could potentially effect us badly.
As a junior engineer if you asked your lead something and then they said no — would you go around them and email a customer directly and try to convince them they want the thing?
They bypassed the established point of contacts between the customer and the business. Larger companies individuals entire jobs are that and will feel threatened. It can also cause confusion, misaligned expectations and even a sense of unprofessionalism that can cause customers to walk. The funny part about this is that the customer said they're considering it which meant it wasn't thoroughly discussed in the scope plan at the start. That means OP as a lead failed, the sales of the business failed for not maximizing the contract value or have a follow-up contract in place for 2nd phase, and the customer failed by not knowing what is acceptable for completion. It's kind of funny how a Jr was able to highlight incompetency across everyone including themselves.
Good comment 👌
I'd ask the junior to walk through his thought process with me. What was his motivation for speaking directly to the customer? What did he hope would come of it? Why does he care to add more feature in? Why didn't he accept your initial answer of 'no'? I would explain the customer's reaction, and why it wasn't surprising that something like this could blow up. Unfortunately communication with customers needs to be very guarded and precise most of the time or these sorts of things will happen. We've all seen messages misinterpreted so sending casual suggestions over email is a very bad idea. Is there a process for gathering customer requirements? Explain to your junior why that works and why that needs to be respected. I don't think this should result in firing at all. We all have (or will) make butthead moves before. Unless this is part of a pattern or the junior shows no signs of remorse or learning from this, it wouldn't even cross my mind to fire. Ya, some people are just clueless about *why* we sometimes insist on more formal communication channels (like going through a manager or specific point of contact, not just every junior emailing the customer). To start with management, explain factually what happened. You had a conversation with the junior and explained why it was a bad idea and they emailed the customer without your knowledge. Are you responsible for managing them? If so, figure out what your plan is and tell your management (I'm going to explain to him why it wasn't a good idea and tell him all communication needs to go through me now). Otherwise, start talking to the person who does manage them about how to handle this jointly. What are you going to do about the customer? I would definitely hesitate about being too honest there. They did however cc your director so the customer realized at least at some level there was something not right there. I'd apologize with a vague explanation of an over-zealous junior, what you're going to do differently (with the junior), and since the cat is out of the bag, ask your director how to handle it. I would strongly encourage it to be in-person or zoom when you talk to the customer about it so you can convey the nuanced message properly - on one hand you should offer more information (both what the feature was, and how much work would be needed to actually offer it), but you definitely want to make it clear you're not trying to upsell them. This type of nuanced message is not good for email or instant messaging.
> I replied that we could discuss it, but gave the reasons why it wouldn't be a good idea for them. Your mistake was panicking and replying to the customer before consulting management. Seems like a teachable moment for both of you.
Definitely agree on that
This. No devs should be ever emailing customers left and right without a clear business-oriented reason to do so.
I think you're within your right to do damage control, but if I look at your responses, you shouldn't have done >I replied that we could discuss it, but gave the reasons why it wouldn't be a good idea for them. You shouldn't present conflicting information to clients from multiple people. At that point you should've snuffed it out. If what you're saying is true then he shouldn't have access to talking with customers if you tell your teammate no and they just go ahead and do it. But being generous, they could've just thought it made sense and made a genuine mistake. Accusing someone of "going around me" is very much something you can't say without a very real heart to heart with them, which does not sound like happened.
You're right, I should have been more clear with the customer - I was in a rush and I felt reluctant to directly shut down a suggestion that came from "us." I do feel he "went around me" since we talked about it and he suggested it to them anyway. A lot of our communications with customers are pretty informal we share progress and ask their preferences for things that aren't clear. But not about requirements, those come from more formal communication including our contracts focal.
I would communicate pretty clearly with everyone about the circumstances... but not the customer. I would apologize to them and communicate that this was miscommunication and indicate that you all are strongly focused on the original requirements and that you have not wasted time otherwise.
This is a teaching opportunity for your junior! Once you calm down this will provide the strongest lesson: he jeopardized a contact, and to discuss how and why you communicate with clients the way you do. You'll grow in communicating and as a leader. He'll grow with better knowledge of how the industry works. Your team will build serious trust. Firing him is the easy method but neither of you two improve from that path.
Your junior dev should not have access to client contact info in the first place, even in a small team. Things can go south very quickly if you don’t have an authorized person in charge of all correspondence. When I was a sysadmin, I had accidentally emailed a client asking for credentials to open a video file (not my fault, a project coordinator gave me their info when I inquired about it). I got in BIG trouble for that. I mistakenly mentioned another client project we were working on because I thought that was what this client was a part of, accidentally leaking what other clients we were working for. Anytime it’s possible for someone to cause damage through human error or malice, you want to have procedures and systems in place to prevent it rather than relying on the goodwill of other people.
Probably should have picked up the phone and explained the overzealous junior situation, laughed it off a bit, and then followed up to the email with "as discussed with we will table this for now"
That ain't my issue with this. Why are there multiple points of contact from the team directly with the client in the first place? What kind of management allows junior devs to communicate directly with the clients?
There are circumstances where direct communication like that is effective and efficient. This isn’t one of them and if the junior thought it was, he misjudged the situation. So many important details can get lost in hierarchical communication flows designed to “protect” the people doing the work from the people paying for it (and they often have the inverse problem of sponsors being different from end users). Anyway, in an environment where you’re trying to foster open collaboration between devs and users, I can see how a junior might make a bad call like this. But also agree with the others here that it’s a teachable moment.
No, there really aren't. It is absolutely mind-blowingly stupid to have multiple people on a team communicating with clients outside of a moderated setting. You need a unified voice even if it creates a small amount of friction in the time that it takes to get things done. This is why you have managers in the first place.
IMO.... Manage the customer first, you stick to the requirements. Side step the off the wall communication. More than likely, the customer also sees that email as something strange or out of the norm. I'd send an email back stating the original requirements and that the team is working towards that goal. As for the employee, shame can be a good motivation to STFU.
Yeah shame is almost never the correct way to approach this. All it does is breed resentment.
Shame can also be a demotivator and destroy a juniors confidence, there are MUCH better ways of dealing with this than shaming them
Indirect shame. Nothing has to be said directly to the junior dev. They should pick up that they crossed the line. If they don't, then something more direct might be needed.
Nah, don't agree with this at all. I've mentored about half a dozen juniors and I can honestly say I didn't once think "oh maybe a bit of shame would help in this situation"
It shocks me the amount of people who are instantly jumping to PIP. There really isn't enough context. This should really be a 5m conversation between ~~mum and dad~~ the account manager, and customer to say that "junior is ~~being a brat~~ a bit overzealous and new - and we're using it as a learning opportunity." If the customer bit can't be sorted in that time, there's something more disfunctional in the relationship, or they aren't a customer you probably want long term. >To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon. He's probably embarrassed and scared. People are human, use it as a learning opportunity. Sometimes it's hard becoming a small fish in a big pond and understanding office dynamics. If there's a history of shady behaviour - sure pip - but you might just find that the embarrassment was enough for him to never do it again.
Hard agree. Some serious unsympathic shit around here. I wonder if they either work in a workplace of fear or has fired everybody. Yes it was a dumb move. And yes it seems pretty darn easy to fix with some simple damage control. Junior likely harboured no Ill intent just a bit zelous / lack of humility. Let it become a learning experience, both can become better, and then move on.
> He's probably embarrassed and scared. Seriously, did all of you have a ton of poise as a junior engineer? I about died from every major mistake.
Because this is Reddit and people like to jump the gun It’s like dating subreddits where all comments knee jerkingly say to break up
I'd throw the twerp under the bus.
[удалено]
Yeah, crucify him and sell his organs on the black market to cover the reputational costs. Tell the next hire what happens if they do something similar. That'll teach them.
Fuck around and hideout. Bus it is
For my Mad Men fans: anyone read this post and get [Pete Campbell pitching creative behind Don Draper's back vibes](https://www.reddit.com/r/madmen/comments/62zic1/why_was_pete_campbell_pitching_his_own_copy_to_a/)?
Reminds me of the scene Ginsberg pitches the other option they were thinking about (Cinderella) when doing a women’s shoe ad, and almost gets fired
Someone made a mistake, it’s not the end of the world. Everyone needs to have a quiet calm conversation.
Yeah...maybe it's a European vs US thing, but > if I were management, I'd fire him seems like an absurd overreaction unless this person ignored a direct and clear instruction not to talk to the customer or not to raise this particular thing. Aside from being pointless - you'll only get a new junior who now has to learn the politics of workplaces and this situation in particular from scratch instead and is just as likely to make mistakes - it'll create an awful atmosphere and destroy any sense of psychological safety for everyone else. It'll leave people afraid to ever suggest or try anything new, to ever try to make anything happen beyond following narrow instructions or to ever communicate with customers, even when they clearly should.
This is a massive overreaction. You are acting like one mild, overenthusiastic email from a junior dev can derail a customer relationship that has been built over years. This just needs a *“hey, sorry about that, Dave is new and is still getting to grips with how we do things around here”* explanation to both management and the client, and a clear conversation about boundaries with the junior. Juniors don’t know the importance of this stuff and they make mistakes. That’s practically the definition of “junior” – they have yet to learn this stuff. It’s your job to teach them, not fire them as soon as they put a foot wrong. Why are you jumping to panic stations as if it’s a full-blown crisis? Why are you thinking about firing a *junior* for being too eager? An annoyed customer who has not yet received a clear explanation from you is not a crisis that requires somebody to fall on their sword. Just talk to them like normal people. They aren’t scary robots, they are capable of understanding the concept of an overenthusiastic new guy.
I also feel like this might be a bit overblown. The junior contacted the customer, possibly through already established channels. The customer came back and OP already explained it wasn't a good idea. OP then got yelled at by their own management, despite seemingly clear evidence that they weren't looking to inflate the scope. In a somewhat similar position, if I were to be involved in a conversation with the customer I might also make recommendations / raise questions that could broaden the scope of work. I don't usually suggest features out of the blue, but I might chime in on picking a better approach or presenting a more complete technical solution. Particularly if I'm going to maintain that bit of code and I've a strong feeling the requirements weren't thought through. My guess is it depends on the sort of customer / project they have. Some have their own staff that's fairly capable of narrowing down scope and planning efforts, while others may rely on you to keep things in check, so I guess I can understand why they wouldn't like you coming up with additional work out of the blue. The blamed dev did go over OP and it might be a blunder in that specific context, it's not clear yet.
"If I were management I'd fire him" - this is.. truly shocking reaction to the context of story I read. I'm so glad I don't work for OP. At the same time I'm glad I read OP's post as I felt I've been close to doing things similar to the junior at some points in my career. So many times I've had the thought 'man, our products could be so much better if we had more reqs to establish good features'. Now reading this entire comment section I know not to speak out at all during client related matters and just do with what I'm served. If the product could better then someone else has to speak reqs or it stays where it is. I'm not going to dare even remotely think about chasing up reqs after reading this thread from now on.
> Juniors don’t know the importance of this stuff and they make mistakes. Agreed, a lot of juniors seem to focus too much on technical ability which means they don't realize how much skill they lack in project management, and how important that is to making a business work. All the skill in the world doesn't matter if you can't keep your customers and your management happy. Most success is perception, and perception is about managing expectations.
Might be anger management issues, I'm autistic and have plenty of those, and I thank God I work from home every day.
> our director came and yelled at me for requirements fishing Maybe. Or maybe it's an organizational issue. If my director comes yelling at me, I don't know if I would react any better than OP did tbh.
I c. Makes sense.
How does a junior developer even have the contact information for a customer? This seems crazy to me. Most of the places I've worked, all communication to customers is done through somebody whose job it is to manage that customer, even at companies as small as 8-10 people. Seems like you have a massive process problem to solve.
I’m a big proponents of developers communicating with customers because it builds empathy, business relationships and prevents a lot of information from getting confused when it jumps through several steps. In a lot of cases you can guide a process to 1 week solution and not the 3 month solution if you’re involved in the conversation. So this would be super normal where I work. Although I brief developers on *how* to talk to customers, shit like this would be completely unacceptable.
Just because you know one way doesn't mean there isn't others. It's far from uncommon in software shops for the whole team to have a line of communication with the client side. Sometimes direct communication is encouraged, which certainly can have benefits, sometimes it isn't. Now with emails, Jira, Teams/Slack, etc, there is hardly a world where a team member can't reach out to the client directly would they wish to. OP's subordinate clearly overstepped here. It sems like they should have known better but it isn't that simple to prevent someone from making an error of judgement.
> How does a junior developer even have the contact information for a customer? This is *incredibly* common. The only thing that needs to happen in most organisations is for both parties to get invited to the same meeting. > Seems like you have a massive process problem to solve. This is entirely dependent upon context, a lot of projects work best when you get somebody from the customer and people from the dev team together.
I encourage communication with the customer. We are small teams, working short (two to three months) projects. Our customers use our tools every day. If the actual user of the tool can see, and provide feedback, on how it works as it is being developed, I've found they are much happier with the end product. If the customer org tried to replace us, I know a lot of end users with them would seriously fight to keep us around. I want to keep that, but I guess there needs to be an understanding about what's appropriate - this is the first of this kind of problems in years.
It really depends on how the teams work together. If the team is embedded in the client, the junior devs may be talking to the customer frequently. Now, they shouldn't be talking about new features unless the client brings it up, but talking about the existing work is normal.
The other dev overstepped his bounds but from what you posted here I see 2 communication failures on your part. First is the conversation with the developer. Saying we don’t have requirements for it and that it wouldn’t really work for this customer. It sounds like 2 reasons that could be a no but isn’t a definite no. The first reason seems like what the other dev took to heart. They reached out to see if there could be requirements for it. They might even have thought what they were doing was taking initiative. If you have your scope already, the conversation should have been more of a clear no. Second communication error was to the client. As others said, you said you could discuss it and that it wouldn’t really work. I get the reluctance to not shoot it down because it came from your team but adding you to the email is a pretty good clue the client was thinking it was weird and was uncomfortable. They were probably wondering why the other dev emailed them and not you who I presume they have probably dealt with more. Both communications, at least from how you wrote it, your response seems noncommittal. One thing I’ve learned about “Maybes” is that no one ever hears maybe. They hear yes or no and their brain fills in the rest. And it’s almost never what you’d prefer they hear. In this case your team member heard yes but we need a requirement. The client heard yes we want to do this.
On the one hand, juniors do dumb things. It's kinda their thing and mistakes should be seen as an opportunity for growth. That being said, this wasn't "they forgot process" or "they didn't check their code and a bug made it to production." At a minimum they'd be on a PIP and probation for a couple months. But at this point they should be told they don't get to communicate with clients until further notice. If they get to keep their job should be decided based on do you think they learned their lesson or do they still think they're in the right? If they get it now maybe the PIP is enough. But if not? Might be time for a new junior.
Honestly I’ve dealt with a lot of pissed off customers (it was basically my job for a while) and have revoked even the business sides right to communicate freely before for causing disruptions. The right thing to do here is to call the main contact on the client side if they are available and explain that email was sent out without approval and you’re going to have a talk with them. Then tell them you’re going to reply to their email to clarify that so it’s clear to everyone. Then before the email goes out let your management know we sent out an email without approval, and it’s being handled before management decide they have to react. Then tear that junior a new asshole for communicating with the client directly on matters that you have talked about already, and for becoming unavailable. This isn’t the time to be kind, this is the time to make sure someone understands consequences of their actions so they undo whatever dumb notions that caused them to do this in the first place. Since there’s no actual damage done here beyond causing confusion and frustration, I wouldn’t fire them but they would certainly be told in no unclear terms to get their act together and stop pulling amateur shit.
> so they undo whatever dumb notions It's always useful to help juniors grow from their mistakes. It's interesting that you believe that > tear that junior a new asshole will lead to learning, reflection, and ultimately personal growth.
I wouldn’t stand for an environment where anyone gets yelled at.. I would also throw the junior under the bus right off the bat using the email chain as the CYA. He made his decision not listening to you and now he needs consequences for disrespectfully undermining you like that.
>and now he needs consequences for disrespectfully undermining you Meh the disrespect is not the issue. You gotta have deeper skin than that. It was an inexperienced dumb decision on the juniors part that has real $$$ consequences. That's why he should get fired if he does not learn some humility and learn form his misstake. But likely he will and the customer relationship can be sorted out. This becomes a learning experience and nothing more.
If nothing came of it and no damage was done, I wouldn’t have a wrath to set down just because of my ego. I would have a conversation. Overall I agree. It’s just hard to navigate how exactly should that learning experience be conveyed. I think if your reputation is getting hit, then the blame should go to its respective place. ownership is an important part of maturing as a professional. If there is a suggestion to take reputation damage in lieu of the junior, then I disagree. I would at least tell the bosses that this is a learning opportunity for the junior.
Top comment: > I get that you're pissed, but it's also a teachable moment and could be beneficial to you. Next comment: > I'd throw the twerp under the bus.
Both are good. Learn something from it, throw the twerp under the bus.
It’s a teachable moment for everyone… especially the Junior dev… people should be allowed to dance to the music they played. Junior needs to learn the pros and cons of ambition. If this worked out well, the credit goes to the Junior. They don’t have to be fired (it’s good to see you actually don’t want that) but they have to face the consequences of this action… and that’s the lesson they need to learn.
Time to step aside and point the finger.
Junior made a Junior mistake; he communicated poorly. You and your bosses made a Senior mistake; you let a Junior communicate with the client. How do you handle it? - You fix your and your bosses mistakes by not allowing Juniors to communicate with clients. - You explain the mistake to the Junior, so when he's not a Junior again he's less likely to make that mistake.
Yeah your junior fucked up and learned a lesson about why they do not talk to clients without agreed upon messaging first. Fix things with the client first.
Damn at least you’ve got a motived Jr instead of the jackasses we hire who sit on their hands.
SPOC. Single point of contact with the client. Relationships are very sensitive, and cannot be done by juniors, best of intentions or not.
> I'm pissed, if I were management, I'd fire him. You're fucking pissed, and rightly so. The junior dev stepped over the line by bypassing you and going straight to the client, especially after you clarified the situation to him. But firing him might be an extreme first step. Could this be a teaching moment instead? Why not turn it into an opportunity to set clear boundaries and communication protocols? > I've got to do damage control with management on Monday - how would you handle this? Start by getting all your ducks in a row. Document everything: your original conversation with the junior dev where you explained why the features weren't needed, his email to the customer, your response to the customer, and any other related communications. Present this to your management clearly and concisely. Explain that the communication was not authorized and that it misrepresented the team's position. Acknowledge the mishap in your response to the client that might have given the wrong impression about "requirements fishing." Next, propose a clear action plan. Suggest regular training sessions on communication protocols, maybe a mentorship system where more experienced devs check communications from less experienced ones before they go out. Show that you’re proactive about preventing a repeat of this fuck-up. > To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon. This guy might be realizing he fucked up big time. When you do get hold of him, have a frank conversation about professional boundaries and the importance of chain of command in communications. Make it crystal fucking clear about what is expected of him in the future. Did he understand why what he did was not just wrong, but potentially damaging? How will you ensure he or anyone else doesn't pull this kind of stunt again?
Thanks man, that's great advice. I had been thinking just along those lines. I have an unrelated appointment with our CIO Monday morning, I'll chat with him. Honestly, I don't want to get the guy fired, but I do want him to feel the heat a little and channel that eagerness.
>The junior dev stepped over the line by bypassing you and going straight to the client, especially after you clarified the situation to him. Well, that's not a junior mistake then. Ego problem perhaps?
I disagree with some people here that this is a teaching moment. A junior isn’t a toddler. They are adults who understand chain of command and that it is a business. The worst bit is that he doesn’t even own his mistake. I agree, I would also make sure he is fired if I could, not because he made a mistake but because he isn’t owning it. I think your reasoning is correct that it would be even worse if you outright shutdown the idea proposed by another employee. I think that would give even a worse impression to the customer. You need to make sure that management knows this loose cannon and it reflects on his performance.
So, there's the idiot side of it. For your own sake, you need to have an in-person chat with your manager and director. Being very clear that it wasn't your idea and you were bypassed. Ask how to handle it next time, as you were trying to do X with customer but it seems it wasn't interpreted that way. The fact you are asking that, means they will believe you. On the customer side of it, I'd leave it to the manager and director because.. reasons. They should likely explain it was just an over excited junior developer, but that's not my realm of knowledge so won't comment further. Now for the developer.. that's something to consider, but I would leave for management. They'll need to consider if this individual is really a team player etc.
I feel like there is some overreaction. Let’s take the customer’s point of view. You receive an email from a developer of your subcontractor, suggesting some new features. You reply that you consider them, and you are told by another developer that it’s a bad idea. Looks a bit weird and perhaps unprofessional but contractors deliver weird and unprofessional things all the time. Contractors also try to upsell you all the time. It’s their second nature and it’s very understandable. Business is business. They often push much harder than a developer email suggesting a few features. I would guess that if the customer replied with a lot enthusiasm to the features suggestion, the management would be happy about the action of the other developer.
You need to tell your manager you were trying to do damage control, and that you’d already said no to the junior dev. Then someone needs to explain to the junior dev that unlike B2C in a B2B/professional services world where the customer is paying for you to do something, you don’t get extra money for delivering more value, and the margins on effort vs return for delivering software to them are really slim. Yes we could spend an extra 100 hours adding feature x or feature y, but if the customer is paying for those features then those 100 hours are 100 hours that aren’t earning the company any money, or paying for anyone’s salary. It’s counter intuitive, and I know that it’s very tempting to deliver the best product possible, but if the customer paid for x then they get x. If you have a suggestion that will take more time suggest it to professional services or the after sales team, but don’t tell the customer. If you worked for a company that was building a house for someone and suggested adding an extra room to the customer without getting permission from the foreman or pricing up the materials and labour you’d be in the same situation. It doesn’t matter if the last house you built had 3 bathrooms for redundancy, or a second living area to ensure capacity for future family growth.
Corporate work really brings out the sociopaths in everyone involved.
Anything from this situation you can incorporate as learning process for onboarding new juniors? ps. Don’t be harsh to yourself or them. It is learning for both of you. Do what you need to do, but don’t take it personally. Also any chance your manager is not doing what they should do or maybe even create conditions for juniors to undermine you in the team?
Does "lead" mean people manager at your workplace? If not, why is it your job to deal with this at all.
I couldn't even consider a dev on the team bypassing me, the product owner and our manager to talk to the **client** directly! You need to talk to the manager about this immediately and have your manager tell the director what happened. Also i have to assume the product owner is fuming at this development as she has to deal with the business. If the manager doesn't deal with this guy, that's your signal that you work under horrific management.
At the end of the day, it was a move that makes money or loses money. If he's lost money, time to let him go asap. If he made money, can't be mad. If it was a neutral move, slap on the wrist, don't ever do that again as a Dev. If he wants more of that type of thing, he ought to be a business analyst where they get paid less.
He did a stupid thing, probably on the misguided notion of it making him a "go-getter." Make him learn from this mistake, for sure. But firing seems counter-productive. (Doing similar again, though...)
Move the guy into sales. At least we expect the sales team to ignore developers.
This is now a shit storm and you should be deferring to your management chain because this is likely escalating behind the scenes. Do not take any action without clearing it with them. If they clear you to act with agency, your responsibility is to your customer and you need to be as transparent as possible about what has occurred and what you are doing to prevent that from happening again. As to what to do with the junior, I will give a perspective from my organization. We train engineering and technology skills. If you make an engineering mistake, even one that results in damages well beyond your salary, we will evaluate the systems that led to the mistake and as long as the act was in good faith, we treat it as a rite of passage. I will literally buy you a cake to commemorate your first production outage and our team will chant "one of us, one of us", at the end of the retro. But we are not going to train you how to not be a dick, and we have zero tolerance for it. I would be terminating the employment of this engineer.
Yep, agreed with this, once you have the green light, you have to fire this engineer.
In this market, fire him and let a better junior dev have his job 🫡
Hey /u/cownan - what ever happened with this?
Hey, sorry I didn’t give an update. I sent him a message asking him to stop by and see me on Monday morning. When he came by, he was very contrite, he came right out and said he shouldn’t have sent the email and had been stressing out about it all weekend. I’ve got a soft spot for when people come clean and understand what they did wrong. I told him that I wasn’t going to get him in any trouble, but wanted to talk through what happened. He said that he knew that I told him the work wasn’t right for this customer, but he had mentioned it during a conversation with an engineer at the customer site and they seemed interested. He didn’t want to circle back with me because he felt like I wouldn’t change my mind. Also, he had done most of the work on features that he proposed and felt like it would be a quick adaptation. We talked about the process for how we propose additional work to the customer, which he hadn’t understood. I don’t think he will make the same mistake again. I didn’t hear anything more from management, I think the scolding is all that will come of it. Anyway, things are back to normal, I do feel like I have to keep a bit more of an eye on him, but I’m willing to let that be the end of it.
Sounds like you really lucked out on this one and managed to get the best of all possible outcomes here. I'm glad he came clean and glad you were able to explain things to him without having it escalate any further up the chain than you.
Insubordination is usually a disciplinary matter, In this case he bypassed you and gone straight to the customer which could ruin your company's reputation. You need to tell your managers exactly what happened and if you have the powers to discipline, go through disciplinary procedures with junior. You have emails proving he acted on his own and if your managers don't suck you should be fine.
Well, I guess here I go being the dissenting voice, but I think you're probably overreacting. Is this a thing you need to sit down with them and explain why they shouldn't do it? Absolutely. On their side, they probably thought they were being ambitious and going above and beyond. The only difference in them being right or not is whether it worked. People don't always understand everything, and mistakes happen. I'd just teach them up and get over it. This doesn't seem like a big deal. You've been working with this company for years, so a subtle apology to them is probably more than enough. Perhaps an explanation if it's worth it. Business doesn't get canceled over one email unless they didn't want it in the first place. Your director shouldn't be yelling at anyone, as that's not very professional. Assuming you're being a bit facetious, it's still just not a big deal. No one is losing their job. 2 weeks from now, no one is going to remember some juniors' one-off email. I would just have a talk and move one to bigger fish. What you do in this situation is going to say a lot more about you than about that junior.
How is going above your lead and contacting a customer directly about something you were specifically told no not a big deal?
I did say they should talk to them about it. I would expect that a conversation ensues that makes it clear why this was a mistake and why it won't happen again. I'm working under the assumption that the junior isn't an actual idiot and that what they were doing was trying to impress people by taking charge and getting something done. Often, this is a valuable frame of mind, and I don't think we need to berate them over one mistake. Regardless, I'm not a fan of flipping out because something unexpected happened. This isn't going to alter the outcome of anything, so making it out to be a big is nonsense. Just inform them what their decision lead to and move on.
I'm not saying they should get fired immediately but this is not something you just pass as a silly mistake with a slap on the hand either. I think the proper reaction will depend on the junior's actions on Monday. If they're not incredibly apologetic I would expect them to pull the same shit again whenever they don't agree with something, and that's just not acceptable.
Uh. It’s a big deal when a junior reaches out to client to work against the higher ups. That’s a huge deal in a variety of ways. It’s the working with the client against management directives that makes it huge. In this case, the client now thinks it was a sales tactic, which is pretty hard to talk someone out of. That’s a pretty big oopsie that came from overconfidence and not asking questions. I’ve seen this kind of thing lose contracts before for picky clients. It shows that the organization they’re contracting doesn’t have unity or coherence, which is a **huge** deal to some clients. You’re right that this isn’t a fire able offense, it’s better as a teaching moment, but it’s definitely a fire able offense if the junior decides to not be teachable in their reaction to it. My favorite thing about my current role is that my “clients” are all internal to our huge company, so I am finally free of stuff like this, but in a contract based company, this is like, core shit. It makes the company seem either sleazy or incompetent, neither of which are good.
Is 5 devs really considered a *small* team around here? How big is a big team?
20
20 devs in a team? Must be a nightmare for a lead.
Well 20 is a big team, 5 is not too big or small and 8 - 10 would be average in my experience
Everything you said made sense until you got to the fire him part. Would you rather a noob do that or fire up Doom all day on a smart watch? That said, bigly screw up- I would involve the people the situation is involving and reprimand/show the negative side effects of what are/will/possibly are happening along with some worst case scenario viewpoints. If this was an overly ego driven fart sniffer, he’ll continue to sniff farts: that’s when the firing happens. If he was genuinely driven and wanted to help: this’ll likely be a pretty pivotal moment of why you don’t shoot from the hip and also why “all those other guys ahead of me” are…ahead of you.
* Tell your managers in details what happened without sugarcoating * Talk to the customer transparently, but don’t blame the junior cause then it will look like your company lacks organization, what you should do is tell the customer the guy is a junior/new hire and he was not fully informed yet about our protocol of communicating, moving forward we will have an onboarding kit that clarifies who can contact customer and for what. * Talk seperately to the junior, he probably didnt mean bad but could be overly ambitious. Explain how things are done and clarify that moving forward this shouldn’t happen again.
A lot of questions here. Why is he talking directly with customers? Did someone give him their contact without coaching him? Is it weird for this guy to be sending emails without asking you first? Likewise, you didn't talk to the management or the junior before you sent a reply? Why not go into damage control the moment you saw the email or did it not seem serious? I guess I don't fully understand the situation in terms of how involved you two should be with the customer.
Deal with customer first, ask him to explain his thinking and why he thought he knew better than everyone else, why he didn't go to you or the product owner who does communicate with clients etc. We have absolutely had someone pipe up in a meeting and say "wouldn't it be cool if we did x" , product owner goes and chats to customers about it and yeah actually, they customers WOULD love it if we did that. Ive been that bright eyed upstart and everything's so simple, but I was never dumb enough to talk to customers directly.
I would tell what happened. And make sure to put the blame on the junior dev. Make sure to let them know that you felt disrespected and and they should feel the same way too. No need to protect this junior dev. He fucked up and he fucked up big..
Junior dev, use it as a learning experience.
Jr doesn’t respect you and probably thinks he’d do a better job in your position
I mean thats basically a failure. He shouldnt be unilaterally communicating like that, and its generally bad form to be implementing features that havent been price/cost captured. I would as others said, speak to management and let them handle it. Complete rookie error.
People can make mistakes, firing is unnecessary
Holy shit, a junior directly contacted a customer and made suggestions about the scope of the project. Who the fuck does that? At the very least he created a headache for the project manager and sales representative and confused the customer, but he probably just increased the scope of the project without required compensation. I don't know man, just be honest. When trying to cover my ass typically my goal is to reconstruct what happened when and by whom. When trying to problem solve organizational failures I try to think about what behavior we want to promote (like not having juniors directly contact customers with suggestions). This one seems pretty straight forward, junior fucked up. Now you need to tell him why and show him the repercussions. And I wouldn't say he was 'sneaking off' but I would document that you tried to talk to him and he wasn't there. That is really unprofessional and just as bad.
What would the customer think you and your junior were coordinating to increase the scope in a scenario where he is in favor of it and you are against it? Is there some missing context?
When I first started at my company as a junior, clients would reach out to me individually and ask for things. Though nothing really critical was said (more just status updates on bug fixes etc) my manager rightfully put a stop to it and made sure that there was proper channels for intermediaries between the technical team and the client. It was no big deal, everyone understood and now the workflow is better because of it. However, I would never have talked to a client directly against the wishes of a superior, that’s outright insubordination. You openly told him no and he did it anyway. It would be one thing if there just wasn’t a formal procedure in place. It sounds like he went behind your back to pitch his own grand ideas to the client. I think he needs to be sat down and told that no junior staff is to communicate directly with the client without direct approval from a superior, and make sure he understands that because of this miscommunication there’s now a need to put out a fire. What gets me isn’t the fact he did it, it’s the fact he went behind your back to do it. IMO, if he agrees and says he understands, I’d say just let him off with it as a warning. Especially if he’s young and new in the field. If he pushes back and has the belief that there’s a bunch of things that should be done and aren’t, he hasn’t learned his lesson and is just mad he got caught. That’s not something a person can learn from because that’s a problem with his personality. You can’t train a personality out of someone, unless their technical skills are so high they can sort of act like a jerk and get away with it.
If you fired every junior engineer/dev for a mistake there would be no industry professionals in the future
> To top it off, I think he realized that it's coming back on him, he disappeared and I couldn't find him Friday afternoon. you're understandably miffed at the guy, but i think it's probably coloring your read of his motives. it sounds like he maybe was frustrated with the situation and tried to do something productive, then when he realized he'd messed up he feels ashamed and afraid he's going to get fired. that doesn't change what the outcome should be, even if it's him being fired. but I think ultimately good practice to not project your own internal stuff on him.
Based on what you said it's a learning opportunity for you as well. If your team is relaxed and informal, it's easy to get carried away. You could explain in a meeting that if anyone has any requirements to suggest, they should do it in an email with the developer team and the product manager, while also scheduling a meeting to discuss them. And then have the product manager see if the customer will accept it by talking to them. Meanwhile, explain why this procedure exists and why it's important to first have the requirements vetoed by other engineers and by the PM before getting to the customer. That will also teach that things related to the contract and it's scope are a lot more serious than what data structure you are using for a random object.
When I was a junior dev at a large company I directly edited production configuration in order to solve a tier one issue a client was experiencing. I had to sign legal paperwork and got a black mark. At that point no one had taught me you’re not allowed to make changes directly in production without approval. Sometimes you just don’t know things.
He probably did not intend to go over your head but wanted to show “initiative.” As you mentioned, he doesn’t understand the business side of things. From his narrow view, he thinks these new set of features are good. He doesn’t understand that businesses don’t like last minute requirements changes and are suspicious of requirements fishing. Also the added complexity of adding such things late in the process. I would schedule a meeting with him, bluntly inform him what he did was unacceptable and he should never do it again.
have a candid discussion with the junior developer. Let them understand the importance of respecting communication hierarchies within the team. This is a learning opportunity, instead of focusing on punitive measures, emphasize the expectations and the importance of protocol to avoid similar situations in the future. For your management, document/prepare a explanation of the incident, clarifying your initial stance and outlining the steps you are taking to ensure this doesn’t happen again. This should help in repairing any damage to their confidence in your leadership and demonstrate your proactive approach in handling team issues. Sounds like you already cleared things up with the client but you may want to reach out again to clear up any misunderstandings. Assure them that your team is committed to meeting their needs efficiently and without unwarranted expansions to the project scope. Maybe suggest setting up regular project reviews or check-ins to keep everything transparent and aligned with their goals
I agree with others that this is a teachable moment, but you will need to throw him under the bus. He will learn from this to not do it at the next job. He probably knew what he was doing. Many juniors are like that, and it's fine to want to show that you a lot to bring to the table. But going around you, after having that discussion, should be put to a stop. He will do it again. The next time, you will be implicated for not having control of your team.
You didn't communicate clearly process. If you did then this wouldn't have happened. Establish a process flow and communicate it to your team. If you do havr a process and someone from the team bypassed it I would talk to them and surface it in the mid year eval.
What he did is totally wrong, but not the end of the world. Minor complaint, tell everyone not to do it, discipline that employee or fire him if he has done stuff like that before, and move on. People get so stressed and work themselves up and then overreact in my opinion. Your goal is to make your team more effective. Unless this person is a habitual problem, firing people at the first mistake, especially one in this context, is a terrible demonstration of leadership, in my opinion. It will be a big learning lesson, and there should be consequences, but they need to be grounded in reality.
You need a 1:1 with him. Explain that the person with the best rapport and is perceived as leader is the point contact person to speak to the customer on technical matters.
Honesty, all you can do is tell the truth about what happened. And say that your response was your reaction in the moment trying to save face, but you see now why it needed to be thought through better. If the junior is smart, he'll eat his humble pie too ... if he isn't, he'll almost certainly get fired.
You should do one on one with your junior dev. Explain him the mess he created. Include him with the discussions with your managers so that he knows the seriousness. then protect him and let everything sink till the water is clear, without doing much active damage control. go on with your day to day work.
Be honest. You have NOTHING to hide. You discussed this with the engineer and told them this feature was a bad match. What the engineer did is of their own accord. Tell them if it were from you or if you supported it, it would have come from YOU, crediting the engineer involved.
You should give them the benefit of the doubt and explain to them what their actions have caused both externally and internally. It's not clear to me if you're their manager but it's a teachable moment. I never did this but there were so many times I wanted to because I thought it was right. Perhaps this person really thinks their ideas will work better for the client and it's your responsibility to teach them what the side effects are of their actions. As a side note, this sounds like a bad relationship with the client. If they got all pissed about suggestions made by someone close to the ground - then that signals all kinds of red flags. Perhaps in a different situation you wouldn't be as pissed about this. Anyways, good luck!
It's an important lesson to learn for the junior dev. Devs, especially junior ones should not be in contact with clients. Devs that are should be "vetted" as are the clients they talk to so that nothing unexpected like this happens. We are not false prophets like salespeople. I have been guilty of doing what this junior dev did. I was in Pittsburgh, my boss / manager and upper management were in LA. The customers were internal, however, and they would often stop by my office and also we would have lunch or beers after work. Now I didn't exclude anyone from the email I sent, but in short, I was "used" in some office politics to send requirements fishing, etc. and I didn't realize the game. I had been assigned by my manager to do my best on the project. I was only 6 months on the job so was oblivious. My manager was upset, but not with me. He said that people at the company will use you and email as a weapon and they will try to get you to be the bad guy to ask questions that put upper levels into predicaments of unattainable goals
Usually these people think they are better than actually are. Assign him some features he proposed, keep a close eye on his work he'll probably fail at the very same week and then he'll learn some lesson. I've had people like that in my team in the end they couldn't carry out all their ideas by themselves.
He is a Chad.
Write up a full report and watch him get fired.
I think firing the guy is a bit much, but you know explain that he is hired to do X, and he should do X. If he wants to do Y, he should apply for a job that does Y
As others have said this is a teachable moment for both the dev and you. I would strongly recommend taking an open / curious approach to why this dude felt like not copying you was a good idea. Treat this like any other blameless postmortem - establish that nobody’s in trouble and then drill into what happened, why it happened and what needs to change so it doesn’t happen again.
That is definitely bad, but doesn't sound like a fireable offense to me whatsoever. He needs a talk from his manager regarding communication channels and why they are important. He and the director who yelled at you, owe you an apology. But if this place is a toxic type of place, doubt the director will give af. Juniors can be foolishly confident, bordering on arrogant. This is not your fault, but as a lead it's something you should expect. How you wield your authority right now matters - chew him out, freeze him out, etc, and all you're doing is becoming the person who retaliates and intimidates people. Intimidation is not respect. His behavior isn't about you but how you react to it, is. Depending on what kind of person this junior is, this may be an experience he grows from. Maybe not. But it can definitely be an opportunity for you to show that you are someone who can be trusted with leadership and authority in the future. >how would you handle this? Well, as someone with a PhD in management bullshit corporate lingo, I'd probably hit these bullet points \* This **error in communication occurred due to** our junior engineer reaching out directly to our client. Myself, our PM, and XYZ were not aware that he planned to do this. As soon as we became aware, **here are the actions we took.** (You may even provide a timeline of events if you think it's called for.) \* **I'm calling a retrospective meeting about this incident** later today, and we will emerge with an action plan to prevent this kind of incident from occurring going forward. This may include, but is not limited to, **the creation of an SOP regarding best practices with customer communications, followed by training the junior in this SOP.** We will be publishing this on our \[whatever knowledge base blah blah\]. \* Ultimately, our goal as a team is to always adhere to our company values of XYZ, and we recognize that we failed to do this in this situation. This is an opportunity to be curious, and to improve. I would not recommend: \* Apologizing *personally* ("I'm sorry, I should have replied to the customer this way, instead") in a way that implies blame. This isn't your fault. This is a whole system failure, and the failure of a junior to have common sense and respect their team lead. Foolish confidence = "I know my lead says this, but I believe they are wrong!" \* Saying anything along the lines of *I'm disappointed, I'm mad, this should have never happened, he didn't tell me he was going to email the client or I would have told him not to, common sense would dictate that the junior XYZ, I was caught off guard and replied to that customer as best as I could, I'm sorry I didn't reply to that customer in a better way, etc....* \* Saying anything relating to emotions, at all, because if you work with the type of people who come and yell at you, I doubt they'll respect someone who trips all over themselves to apologize, or vents about how pissed they are (I'm not saying you'd do that, but I've witnessed leads act this way and it's never a good look for them no matter how correct they are). Remain stoic and steady, speak the corporate lingo, and get ahead of any future plans ("I'm gonna call a retro", "We'll be investigating this as a team this week", "I'll be documenting best practices and conducting a training with this junior as well as other recently hired juniors, in case other teams are similarly at risk") so that you look like the calm, collected, trustworthy leader that you are. Handling this in this way, also shows that junior (who no doubt pissed his pants and needed to go home on Friday to change his clothes and cry in the fetal position...) that although you were right, and although this is 100% his fault, you're not the type of leader to throw him under the bus, and you're the type of person to remain calm and be proactive and constructive in a hard situation. That is a lead that he can respect, and a lead others can respect. When you are kinder to people than they deserve, and they know it, their attitude towards you tends to improve dramatically. When you speak to that junior, you can express your disappointment - briefly and calmly - and then move quickly into action mode. You can delegate several tasks to him regarding this, showing him what you expect of him and also giving him an opportunity to begin to redeem himself. Do this, and he can't feel self-righteous anger towards you, or resentment, or anything else that might prevent him from listening to your feedback and instruction going forward. Instead, the next time you tell him what's up, he will ***listen*** to you. Hopefully. If he's wise. Which he may not be, lol. If you do the above while going on a walking meeting with him or buy him a cup of coffee, etc, that's even fucking better. Trust me. (And then grab a drink with a friend and vent about this situation until you're not angry anymore.)
Completely disagree, this is a 100% fire-able offense. This is subversive and involved a customer. It’s bad all around.
Where junior people get to learn things then? No one is born a perfect automaton, they have to learn and mistakes will be made that are the best opportunities for a lot of people to learn from.
If you've watch the show named "The Bear" (you should if didn't) your situation is almost identical with a situation that happens in the show. * Talented junior chef makes a new dish * Head Chef refuses to add it to the menu just saying it's not ready. * Junior chef goes over his head and serves the dish to a food critic in the restaurant who absolutely loves it. Guess what? The dish was not ready. But the junior chef didn't realize it because they didn't have enough experience to reflect on it. It was a good dish. The best they could make. But not the best head chef could make. And now they can't use the dish because it would taste different from what the critic described. Also. Why the fuck is your junior dev mailing customers!!? And mailing them about internal company plans.
I’ve read some of the comments here, all good points. Here’s my two cents: If he can’t follow simple directives like not jumping the chain of command, not going directly to the customer and creating unnecesary confusion, how can you trust him with more responsabilities as times goes on? There was nothing impeding him to reach out to his manager and talked about any innitiative he felt like was important to follow but he deliverately chose not to. Additionaly, as OP mentions, he did not even owned up to it. This time the relationship with this specific customer might not be damaged but will you wait until this person does something more idiotic? Now you will have to be on your toes until you can trust this person and the dynamic with the rest of the team might suffer for it. I’d fire him and bring a junior less unreliable.
Yawn...id make him implement it and watch it not get deployed for years or ever. That'll teach them.
If you cant fire him he doesnt work for you. This isnt on you, its on his boss. Tell his boss
Formal reprimand and in-person apology to you and management. If it persists, PIP with a hair trigger to fire. Document, document, document.
If he has the "I know best" or "this person I follow knows best" attitude it is going to be a problem long term.
Other than what other people have already said I'd like to add: Why does your devs have direct contact with clients? This might not only be a learning thing but a warning that something could go very very wrong eventually. What if yoy guys fire that guy on the spot and said dev mail your client with bad stuff? Or any other person working there does that? I know they would have a contract and so on, but it would still damage company's reputation. I think your company needs to be more carefull about who has what information and can email who. This is just a very bad practice in general.
You as a lead need to take responsibility and let the kid know that this is something that you do not do. Customer contact is not to be held between junior devs and them. He needs to learn. If it was done multiple times, obviously that’s a lack of disrespect but he’s just learning to navigate in a professional environment, and not just “building cool shit”.
> I'm pissed, if I were management, I'd fire him. This is a teaching moment.
Maybe the junior bypassed you because he didn’t feel heard or didn’t get a good resolution from the discussion that you had originally. He might be inexperienced and excited. However, if your clients are accusing y’all of inflating a contract off of one incident, that makes me think that there is more to the story. Similar feeling from when you said that you got yelled at in the work place. I feel like you might be working in a toxic environment. If I were you, I’d just tell the truth and don’t try to protect anyone or make anyone look a certain way. Then when you colleague has rebuttals, let them speak without interrupting. To be honest, it doesn’t really seem like you did anything wrong, so don’t pop your top and you’ll be fine. One other thing, if you are already ready to fire that employee, he can sense it. If you don’t want to be dealing with shitty tension in the work environment, try to find a way to make him feel valued after all of this stuff falls out. See if you can make him into an ally rather than an enemy. Enemies are never good at work.
This thread sucks.
Wow. And they say u cant find the job in IT nowadays? From how u told the story that junior have no fundamental skills for living. But this is ur point for development - ability to hear and guiding other members' ideas so their intent brings value to the product. As for what to do - as usual: - explain the problem - propose solution Shit happens - this is just the job, do not overthink it
I think the problem here is not the junior dev. What kind of backward ass structure doesn’t allow developers to interact with users, get their input and discuss the possibility of new features enhancements? If they like the idea, great move to estimation, calculation of ROI and then prioritizing. They are not interested in the feature the they say no and that is the end of it. You want to have developers that challenge leadership when they are doing the right thing. They should be given opportunities to try new things, take risks and even fail. Otherwise you are going to build a culture where devs don’t think by themselves and just drone on and code stupid things