How do you establish authority as a technical lead when managing resistant senior employees?
Posted by RNNDOM@reddit | ExperiencedDevs | View on Reddit | 91 comments
I've been brought in to modernize and upskill a team of 4 developers (including myself) who've been with the company for 10+ years. While they have significant tenure, they lack formal IT training and modern development practices (git, CI/CD, Scrum). A key part of my mandate is ensuring the team follows the product roadmap - historically, they've worked on whatever they pleased without accountability, resulting in consistently missed deadlines.
Management wants improvement but replacing team members isn't an option due to labor laws and company culture. While one team member is supportive of the changes, two others are actively resistant. Recently, they excluded me from a critical incident that took them 2 days to diagnose unsuccessfully (which I diagnosed in 5 minutes when I finally found out).
hooahest@reddit
If they purposefully hid a product incident from you for several days, you have a bigger issue than them just 'resisting'. Your team has huge trust issues.
tcpWalker@reddit
Excluding OP from an incident is a big distance from hiding it. For that, the trick is to build a good RCA culture and get buy-in through understanding the benefits of sharing such issues. Production issues get handled a certain way, that way includes overcommunication in an incident channel, etc...
In terms of projects, about 50-75% of the time the team knows better than management what needs to be done if the team is good, and good management listens but adds maybe 20-60% company priorities and helps prioritize team ideas and makes sure the team doesn't overcommit. Maybe this team is promising too much; someone needs to help them cut the work they're promising to deliver in half and make more of it be the company priorities.
The best teams I've seen hardly ever have a team meeting, so you certainly don't need scrum or the like to do a great job. But sometimes it helps.
Constant-Listen834@reddit
Yea normally what “brought in to modernize and upskill a team” means is actually “hired into a terrible team that is miserable to work at” in corporate speak
gomihako_@reddit
OP might have already fucked up with his "mandate". In this situation, just come in and observe. Don't change everything within the first week and rock the boat. Observe, diagnose, gain trust. Then suggest small incremental change, but give them the credit.
dangdang3000@reddit
This guy leads
Capable_Hamster_4597@reddit
That's not a trust issue, it's unprofessional and malicious.
IGotSkills@reddit
You aren't in their shoes.
SpiderHack@reddit
And you are?
klavijaturista@reddit
You don’t. They are senior and have strong opinions, just like you. That holds true even if they respect you on a technical level. You are either GIVEN authority or not. Also, a big mistake would be considering yourself superior to them. Hopefully, you all get along eventually.
PS: scrum sucks, continuous delivery is not absolutely necessary and git is not the only scm.
Funny-Thanks7667@reddit
Fire the whole lot. Replace them and clean house. Start with the worst one. Sometimes the only way to cure a rotten tree is to chop it down
JasonBobsleigh@reddit
Purposefully hiding an incident is a severe breach of employee obligations and can be a legal cause of employment termination, even in EU countries.
GeneralBacteria@reddit
excluding is not the same thing as purposely hiding.
JasonBobsleigh@reddit
lol, wtf are talking about. This is exactly hiding. There was an incident and they took purposeful steps to keep their supervisor in the dark. People literally get disciplinary terminations for stuff like that.
GeneralBacteria@reddit
where does it say anything about purposeful steps?
JasonBobsleigh@reddit
“They excluded me from a critical incident”. They took action (excluded) to withhold critical information that endangered the employers business (critical issue). I’m not going to argue with you any further.
Maxion@reddit
For sure it would be cause for a written warning.
casualfinderbot@reddit
Just saying, while scrum might be something people do it’s not really a hard skill and isn’t necessary. CI/CD and git are pretty crucial though
PurepointDog@reddit
CI/CD can be done without. Not well, but local unit tests exist.
How does a dev work without git though?!
ZunoJ@reddit
Maybe they use mercurial
ThatSituation9908@reddit
You forgot the CD part. Without CD, you end up testing in prod.
ComfortableJacket429@reddit
I’ve seen employed devs email source files around
sonobanana33@reddit
The horror! They should be emailing patches! Not whole files!
Careful_Ad_9077@reddit
hopefully just a different version control system. I don't like the alternative.
donjulioanejo@reddit
MyPrivateStaticVoid_java_v2.final(2) - Copy.java
reboog711@reddit
Aye, there are a handful of alternate version control systems out there. But, Git seems to be get the most use these days.
Constant-Listen834@reddit
Running local unit tests and then deploying is insanity lmao
theDarkAngle@reddit
Scrum is almost always suboptimal if not downright detrimental. Most programmers these days hate scrum.
IGotSkills@reddit
And for good reason. At best it erodes culture
theDarkAngle@reddit
I believe it sometimes might be good if:
1. The project really fits. (hint, a single product with multiple ongoing goals and flexible timelines is a good fit. A mature product without clear goals but constant small scale change requests from disparate users or stakeholders is a terrible fit, and should probably be simple Kanban). 2. The team is allowed full control over the open parameters of the methodology (e.g. six week sprints are just as valid as two week sprints, ceremonies included only as needed, etc) 3. It's done with competence and good faith. (E.g., estimates are treated as estimates rather than commitments, product owner is actually a product owner and not a glorified supervisor, PO knows when to cancel the sprint, the daily scrum is not a status meeting and managers don't attend, etc).
But it's somewhat rare that even two of those things are true, let alone all three.
ThatSituation9908@reddit
Could you explain more if daily scrum isn't a status meeting, then what is it? Just whoever has blockers speak up?
kneeonball@reddit
This feels a bit pessimistic, as Scrum works really well when it fits and the organization enables it rather than getting in the way. I've seen it work really well in small pockets of an organization that didn't have to answer to higher ups on deadlines all the time.
Most of the times executives don't even create a culture where it's remotely possible to do well. It's like they want the team to enter an F1 race and be competitive but then only allow the team to have a 10 year old base model Toyota Prius.
PangolinZestyclose30@reddit
One thing which is missing in this type of discussions is - what's the alternative which is better than Scrum?
Most programmers hate any kind of process which pushes them to do things they don't like to do (but which might still be necessary).
TBH I hate physical exercise like jogging. But I still recognize it is something I need to do. I believe it's similar with some processes like daily standups and retros. You can argue about each specific thing, but just the fact devs hate processes does not say much about them being important in the larger picture.
donjulioanejo@reddit
Eh. Depends on how and what you do with it.
Strict adherence to ceremonies when you don't know why (AKA cargo culting) - worse than useless and likely actively detrimental. You're just wasting your time this way.
Using them to plan and prioritize work? Helpful, especially if you treat your sprint as a guideline rather than as holy writ.
For example, telling a different team when they need your team to do something that "you're working on it sometime next month" isn't helpful. Telling them "hey, we have X, Y, and Z as high priority this sprint, but we can do your request W next sprint" gives them a rough guideline to plan stuff around.
This way you're also politely telling them that no, you won't drop everything you're doing for their medium priority thing, but you will also get there eventually.
Source: middle manager.
Antares987@reddit
When I was teenager in the 90s, I worked at a cheesesteak place in the mall's food court. I was promoted to the shift lead...at 15, managing a bunch of high school dropouts who did not give a shit. I wasn't related to the business by family or anything else, and I had no power to force my will on anyone. The pay was shit. People didn't care if they were fired. My first shift doing this was an absolute disaster as one of the workers tried me. It resulted in me doing a bunch of yelling and it took us hours to close and get home.
I regrouped. The next shift I led, which was a day shift, I show up, unlock the store, and immediately start doing the most unpleasant prep work that nobody wants to do -- running 50lbs of onions through the Hobart slicer. Chopping onions fucking sucked. Full waterworks of eyes and nose watering. People would see this and nobody complained about washing potatoes or doing dishes. And they would often volunteer to do the least pleasant jobs because they saw I was willing to work to make their job easier.
The same principles apply today in business, and I feel that service industry experience teaches certain skills and empathy that many people in corporate environments lack.
FistBus2786@reddit
This is how you earn authority, by gaining the trust of co-workers. Nobody wants a person "asserting their technical authority".
donjulioanejo@reddit
Yep this is what I do. If you get brought in to upskill a team...
Instead of telling them what to get with the program and use git, here are some possible ways you can get them to see the light:
Of course, this assumes they are still engineers and aren't going to play politics (like tell senior management a bunch of bullshit, like for example you causing an incident in the first place).
iamiamwhoami@reddit
Servant leadership style is a good way to build trust. Show the team you're willing to get your hands dirty and are there to help them. That will help build both trust and reliance on you as a leader. Once that's accomplished you can start transitioning to other leadership styles if necessary (e.g. do more delegation, mentorship, putting your foot down if necessary).
EarthquakeBass@reddit
Yeah man. Whenever I have a bad day in the trenches I remind myself what bussing tables or busting your ass prepping for a chef or hauling big ass equipment around is like. Pretty rich to think I made $8 an hour at one point getting my body and spirits banged on constantly and now I sit in an office chair.
secretBuffetHero@reddit
I like this onion slicing story from 30 years ago. it's highly relevant. Did you go into leadership?
Antares987@reddit
I'm not sure if this is sarcasm or if you're asking what the attitude led to in the 30 years that followed.
I have one rule: Do not reward bad behavior.
secretBuffetHero@reddit
it's not sarcasm. I'm genuinely interested.
cuntsalt@reddit
Also worked food service, with similar stories, they make for good analogies.
For example, the manager who did the opposite of what you did, and chose to stand around yelling "go faster" at the 16 year old disabled dishwash kid on an anomalously busy night when the dishwasher had also broken down. Not a manager who'd ever get a lick
kitatsune@reddit
Not an experienced dev but I have experience in food service. I did the same thing when I was leading afternoon/night shifts. I asked my coworkers which chore they would like to do, and I stuck myself with the 'leftovers' they were reluctant to do. The work got done quicker and we closed on time :D.
I applied to same methodology towards a ML competition project group I led during college. I made myself do the "ugly" work so my other team members wouldn't be unmotivated to do their work. It worked in the end eventually, me and my team got first place!
LogicRaven_@reddit
The phrasing might imply that you are trying to use your non-existent authority to force these people to change. This would be high risk for you.
Your environment made it clear that you don't have any sticks, so you need to find carrots. Why should these people change anything?
Motivation: could vary from extrinsic (praise, bonus) to intrinsic (purpose, mastery, autonomy, being proud of their work). You might need a combination.
Trust: how could you earn their trust, what can you do for them.
You might also need to work with your stakeholders on incentives and how to establish accountability.
dobesv@reddit
Are Scrum and "following the roadmap" and deadlines coming from above considered "modern" development? I would look into that a bit more, or maybe "modern" means from the "modern era"... The years between 1500 and 1945.
I would expect in a modern process the team itself sets it's own priorities, process, and maybe a roadmap.
If you can clarify the business problems that the company is trying to solve with this effort you can ask people if they have any ideas how to address them. And I don't mean problems like missing deadlines or not using scrum, I mean lost sales, unhappy customers, etc. . And try to listen honestly instead of listening for an excuse to stick with your original plan.
teapeeheehee@reddit
BRING THE HAMMER DOWN
tonjohn@reddit
SpiderHack@reddit
To add onto this, explain why it might be hard to grasp tight now. But long term you want to make all their jobs easier and less hassle filled, but first there is some growing pains...
Good example is not accepting large PRs that do bug, feature, and kotlin conversion all at once.
Explain that you as a reviewer can never do all 3 at once, and that if they push through 3 smaller PRs you can actually make more meaningful reviews at once, and make it so their PR velocity actually improves total throughput.
Things like this show that you are trying to solve their problems, but need their help in the process.
suspicious_williams@reddit
This list is so good.
I think OP is saying “authority” but what they really want is leadership. You can become a leader without authority, just keep doing #1 in the list above.
sonobanana33@reddit
lol no. That just means you work and they slack :D
theDarkAngle@reddit
I'm glad someone said #3. I hate that fucking term. It's like they don't want to call it "training" or "continuing education" because then it might seem like something where employers should pay employees their full rate while they complete it.
cerealShill@reddit
To be fair, learning the nuance of persuasion and power politik is something you learn over a career, not from strangers on the internet.
Leopatto@reddit
Beatings shall continue until morale improves.
Hiding purposefully a major incident by employees to an employee is a cause to let go of these people even within Poland, where we have one of the strongest labour laws.
fortunatefaileur@reddit
impress and convince them instead of demanding they respect this small amount of authority management gifted you
b1e@reddit
This is it. Full stop.
OP is already coming into this with completely the wrong attitude.
SSJxDEADPOOLx@reddit
This is the way. Well said.
Metabolical@reddit
I don't think the phrase, "assert my technical authority," will serve you well here. You want to refer to the team as "we" not "you" and avoid being in a me vs them frame of mind.
General Stuff:
Set clear expectations - "We have been tasked with modernizing our development practices, and achieving an explicit roadmap of product capabilities. Success will be measured by our ability to regularly deliver items from that roadmap, and doing so will require quality goals that are best handled by those best practices. "
Set achievable timelines for adopting the best practices. Don't try to do everything at once. Start with important things like git. Given your incident anecdote, holding blameless retrospectives and teaching them that you are concerned with preventing recurrence and not blaming.
Make sure they know their performance and rewards are dependent on adhering to the plan (assuming that's true). Most of the world has performance based bonuses. They should know your recommendations will reflect how hard they work to achieve the objectives. Ignoring the objectives or failing in general might result in a poor performance assessment and a recommendation of 0% bonus.
Specific Stuff:
You need to have separate crucial conversations (I recommend the book by this name) with the two rebels. You want to listen more than talk. Find out why they excluded you. What are their concerns? How can you help ensure their concerns are explicitly addressed by the changes you plan to implement? What do they know about how it's been that you don't that causes the skepticism.
People often talk about how a manager's job is to remove obstacles from the team. This is true, and what that means is everything that makes their job harder but they aren't in the position to change is up to you to try and improve. That's your task list. You want to relate the problems their facing to the prioritization of the modern practices most likely to improve those situations.
peargod@reddit
This. Also, I'd reframe the story above as it took US 2 days and 5 minutes to address the produciton issue. When they see you treat failures as owned by the entire team, they'll feel a lot safer and put more trust in you.
devoutsalsa@reddit
assert(Domninance())
HackVT@reddit
Do they report to you on the org chart ? Do you have 1:1s? I would start employing managerial tasks to your day to day so that you are doing and not just trying to assert as a supervisor versus a leader.
EarthquakeBass@reddit
Well, you can’t use the stick, so try the carrot. Get them interested in new practices. It’s a slow game - you need to “incept” the ideas because if you swing your dick around, they’ll knee-jerk reject you. Which is clearly happening since they hid a major incident instead of asking for help. That’s on them, but from your attitude, sounds like you didn’t help either.
Find their angles. Maybe one guy’s obsessed with TDD - send him articles about gitops for TDD. That kind of thing. Cultivate the direction you want like a gardener. The more they see themselves in it, the better. Means letting some stuff go for the greater good.
You might consider having a heart to heart and apologizing if you got off on the wrong foot. Just explain you want what’s best for the team and ask for their honest feedback and cooperation moving forward. From their perspective you’re probably the annoying brash newbie who thinks he’s gonna come in and change everything or make them work harder than they want to.
dodo1973@reddit
Focus less on your authority. Focus more on helping the team to find consensus on mission and values. From that groundwork everything else will flow.
E.g. them hiding that an incident happened can be used to start a conversation about how the daily work could change to actively prevent such incidents in the future.
Revise how you see your own role: Is taking the "lead" about tactical decision making and enforcement or about building and shaping the team culture?
teerre@reddit
I think lead by example or even "bring snacks" are great advices, but this has a limit. You can't discuss with someone who's being malicious about it. Doing random things instead of actively contributing to work is just malpractice, there's no labor law in the world that will protected that.
Guilty_Serve@reddit
You spend most of your time listening to them. You make friends. You make people feel heard. You operate slowly. You give them examples on how things are helpful. You keep going.
donnager__@reddit
well I'm not going to defend introducing scrum (insert your favorite rant about it here)
as for the rest of what you wrote, this sounds like a C team and I would try to bail yesterday if at all possible
thatdevilyouknow@reddit
Jump in, manage source control, and make sure it’s known that source control is the measure of success. If it doesn’t happen there it doesn’t happen period. If they haven’t checked anything in ask them why and remind them to check in their code. You will also still need to be there for them and advocate for them. Being tech lead is not about complete control because they will tank the whole thing if they feel like it. It’s more about bargaining for the best outcome and sometimes doing things you don’t want to do but what the team wants to do. Don’t add on a bunch of tasks and meetings until things have settled down or it will be seen as a punishment. Things will balance themselves out but that takes time not just effort.
No_Technician7058@reddit
ok then theres nothing you can really do to make them change. enjoy your new role eating shit
IGotSkills@reddit
Fuck scrum, fuck scrum, fuck scrum, fuck scrum, fuck scrum, fuck scrum.
In case you didn't hear me, FUCK SCRUM.
PothosEchoNiner@reddit
You’ve got a tough case there. I would recommend establishing a weekly hour meeting with an open agenda for engineering problem solving. Don’t invite the manager unless they are a hands-on contributor. Most developers appreciate having a regular devs-only venue for discussing problems, solutions, code quality, etc. Have a rotation for who is running it so it’s not like you’re just making them listen to you. Encourage everyone to put topics on the agenda, things that are bothering them or things they want the team to consider. Every time put one or two issues that you consider important like the ones that you mentioned. Try to persuade the team to come to a consensus so you can have team decisions instead of tech-lead-says-so. That should help with the modernization.
The issue about them refusing to do high priority work is more of a manager thing than a tech lead thing. But maybe you can try to help. Give them the benefit of the doubt, make the goals clear and ask the team for ideas on how to meet the goals. Your proposal there is “we should all spend more time on high priority tickets” and if they can’t agree with that then your manager will have to step in with “do the damn job or we will start our long and ineffective termination process”
imti283@reddit
If you have a cybersecurity team try to hide behind them for a few of these enforcements. This may win you few small battle which can help changing their perspective.
Its hard to work with people who don't want to change. I find hiding behind a greater authority to push forward your agenda works sometimes.
freekayZekey@reddit
already lost me. you may have seniority, but you may not know as much as you think you do. if people are pushing back, ask why and have a conversation. arbitrary mandates is a bad way to go. throw up suggestions, ask the team, then see what happens there. sometimes, “best practices” are practices that don’t fit with every team or product
thatVisitingHasher@reddit
Expose everything. State what you need to accomplish. Then show everyone in public meetings that the other persons worked on something else. Repeat each week.
secretBuffetHero@reddit
you have a little bit of a problem here, with no ability to hold these guys accountable. a lot of good answers to this post, but I'll try to add a different take.
Why do you think they resist git and CI/CD? As a dev, you should be able to put into a sales pitch why git and CI CD are good. Don't just assume everyone agrees. You will have to sell it. But this is the job of leadership (you). If they actively resist, well, that's kind of a tough one. Do they have any desires to do more than the minimum? You have to go at that angle, really.
also, is there any reward for anyone for upskilling?
Old_Bug_6773@reddit
Agreed. Channel Don Draper. Mad Men is a good resource in these situations.
BertRenolds@reddit
What were the details of the incident?
For security related ones we need to keep it need to know until it's gone through legal, security, etc.
roger_ducky@reddit
Have a more frank conversation with the resistant ones first. Goes something like “Look, I don’t like change any more than you do. (Pacing their mood) but management wanted us to be more “modern” (still matching…) So, let’s make the most of it. What things about how we do things right now slows you down? (Leading them towards you) Be honest. I have a few tricks. Let’s see what we can do.”
Praise them publicly for anything they did that improved efficiency or productivity based on your guidance. Also praise them for locating pain points and letting you work on it with them.
Think that’ll eventually get them to come around.
nickisfractured@reddit
Watch Simon sinek circle of trust videos, learn about googles project Aristotle, learn about trust and psychological safety, you can’t rule by authority here, you’re going to have to earn their trust and make them feel safe to learn and fail with you to support them.
Going in and trying to force them is literally never going to work even if you have the best of intentions. Sometimes people can’t be saved but that’s very rare honestly.
icesurfer10@reddit
Are you also their line manager? If not, then I think you need to move away from terms like "establish authority" and "up skill". You're only going to rub these people up the wrong way.
With you coming in, there's a good chance that they're either threatened, or aware that you're there to change things. For people who have been at a company for 10 plus years, where things haven't changed much, many are resistant.
I think you need to start by showing what you're good at and leading by example. People are more receptive to ideas if you're also a doer, rather than a teller.
One thing I've done in my current workplace is to assign a "feature lead" to each feature that comes through the door. Giving them more ownership and accountability for the planning, design and delivery of a feature. I will generally review/help with the designs and ensure things are kept on track, and blockers are raised immediately.
Honestly, it sounds more like a process problem than anything else. You need those responsible for the ways of working to clearly define them, and id somewhat expect you to help put those together with your differing experience. It's going to be very difficult for you if you don't actually have the power to change things, some people can be really stubborn and set in your ways.
Most in my experience however are more willing to have a trial period for changes if they feel empowered to push back or change them if they're not working.
SagansCandle@reddit
Your main tools as a lead are going to be your ability to prioritize work, establish processes, and set expectations. Authority is a tool you should only yield when necessary because dropping the authority hammer always damages relationships, which in a best-case scenario is two steps forward, one step back.
Careful_Ad_9077@reddit
I once got a great lesson from a Dilbert strip.
In that one wally proposes a chagne in the process, he is immediately shutdown by another engineer; she asks him if the change involves him doing less work and someone else doing more work.
So, when telling them about all the new extra work they will need to do to adopt the new process, emphasize the other work they will stop doing with the new process.
qlkzy@reddit
In broad terms, there are three kinds of sources of authority:
There are some other names and definitions for these, but those three general categories show up all over the place in management literature.
Be brutally honest with yourself about how much of each of these kinds of authority you have with each person. It is very easy to overestimate. If you try and exert authority beyond what you actually have, you are liable to permanently damage your relationship.
Positional authority is the easiest to use, and the one you should rely on least, particularly with people who are used to a lot of independence and autonomy. From the sounds of it, you may be relying on it too heavily. I would only use positional authority in a few contexts:
By that last one, I mean things like leading standups and (fairly) chairing meetings — opportunities to cast yourself in the role of a helpful authority figure.
Most of the rest should generally come from the other, softer sources of authority, and those you just need to earn the hard way — it is rare to he able to speedrun respect.
In one previous job, the biggest factor in establishing my authority was this: someone in my team had their PTO allowance screwed up. I spent two weeks working late, digging into employment laws and company policy on top of the rest of my work, and going back and forth with HR in unending email chains. My team member got their PTO, and the team learned that I was willing to go to the mat for them. After that, if the team knew something was genuinely a priority for me, I never had to push them. (I did of course work to earn their trust and respect in lots of other ways, and I kept fighting their corner).
Look up "servant leadership", and consider the framing that (at least in some sense), you work for your team.
If your team is in a really bad place, look up "situational leadership", and perhaps watch the film "Twelve O'clock High". But be very careful before going to extremes with this kind of software/knowledge work.
No_Radish9565@reddit
This is going to be a miserable job. You are being put in a position where you are expected to enact change but you can’t fire anyone — responsibility without authority.
I’ve been on teams where I was responsible for teaching experienced industry professionals how to do elementary tasks like use basic Git commands. It was absolutely soul-sucking and I never want to do it again. I like mentoring folks who are mostly self-sufficient but inexperienced, but I loathe trying to babysit adults as they struggle to learn how to use
git commit.Good luck. Do you have any other career prospects?
DualActiveBridgeLLC@reddit
PhDs and subject matter experts are some of the most difficult people to work with when trying to use proper software development practices. They love doing the fun shit but asking them to commit incrementally or do code reviews is such a slog.
Had an SME who after 1 year of driving good practices finally said 'this git stuff is pretty easy, I'm surprised XYZ doesn't do it more'. I was both pleased he finally got it, but also gobsmacked at the lack of self awareness.
DualActiveBridgeLLC@reddit
This is not a technical authority issue, almost nothing in managing a team really comes down to technical authority. Dysfunction like this can come from many areas, but hiding issues from you sounds like a personal conflict.
I would start by going over the business strategy, then how the teams goals fit into the strategy, and then the metrics of how you judge success. You said deadlines are the primary metric. You need to connect the modernization effort to why you are missing deadlines. You are not modernizing for the hell of it, it is for a purpose. If they do not agree that modernization is necessary or that the goals or metrics are bullshit....then you have to solve that issue.
Also they are professionally making themselves very vulnerable by not knowing git, CI/CD, and Scrum
kirkegaarr@reddit
Pizza party!
zagajaw@reddit
Face it straight on and communicate what is being asked of the team (and you). Crucially present yourself as their support person and a buffer between management and the day-to-day. Then workshop a plan of action together (all the while knowing where I you want to end up).
Wide-Pop6050@reddit
Okay so this team is a mess. I don't agree with the majority of the responses you've gotten, but I do agree that you can't sound like a MBA textbook.
Every time someone comes here and says "assert my authority" they're going down the wrong path. You have to effectively manage.
Who was these peoples manager before? It sounds like they're basically used to doing whatever they want, and ultimately may need to be fired. Hiding something this big for 2 days is grounds for firing or a demotion - which may be more doable.
You're going to have to talk the long route there. A lot of talking to them about what they're currently doing, "praising" their past work but suggesting improvements, etc - and then sticking to your guns.
ninetofivedev@reddit
Uh. The answer to your title: No.
Would I address having shit hidden from me? Yes.
CanIhazCooKIenOw@reddit
How is there a production incident and the team is not aware of it? I would start there.
Like anyone that needs help, they need to recognize there's a problem. Start by setting up team ceremonies to both improve team work and knowledge sharing but also retros to understand changes that can be made to improve expected outcomes.
zaitsman@reddit
If you are unable to replace people due to labor laws and it has been 10+ years for these guys, forget it. I would explain to whoever set you to this task that this is not practical.
In a normal operating environment you’d focus on setting clear, achievable and business-aligned goals and then reprimand non-delivery. You also need to focus on coaching and dancing around each muppet’s special quirks, some like to be left alone, some like constant praises, this is individual
magmaticly@reddit
Publicly praise people who do well.
Bring snacks.