Consultants who work as CTO, Engineering managers or leads in some way, how do you deal with dysfunctional teams when you join a new client company?
Posted by SweBot@reddit | ExperiencedDevs | View on Reddit | 54 comments
A common pattern I see when I join a new dev team is often relaxed change management (git, CI/CD), lousy jira tickets, bad communications, buggy deliveries, and "I know it best" mentality.
How do you assess what to do, and implementation of changes to improve over all processes? And accountability, how do you get people to care about end to end quality?
Potential-Papaya-501@reddit
As someone that has tried what you are doing, you may have a very difficult time getting anyone to listen to you. It may have to come from the boss.
datacloudthings@reddit
I'm pretty much ready to say that bad engineering practices are ALWAYS part of the problem.
You tell stakeholders you have to slow down now to speed up later, and you tell engineers they're going to stop shipping so many bugs to prod.
bluelexicon@reddit
Youre asking a lot of different questions at once, the only simple answer is you need to shift the teams culture
Adorable_Tip_6323@reddit
Been there done that, have scars on scars from doing it.
The first thing I always do is take inventory of skills. I have yet to see a place that has a properly managed inventory of skills that brought me in to manage. I do this under the guise of "just observing" and "don't fix what isn't broken"
Next, I start rectifying the skills inventory. Sometimes you can reskill someone fast enough, sometimes you have only front-end devs, sometimes you get a menagerie of crazy. You need to get the skills inventory to a functioning state. This is often where you'll find your first yelling match, typically with the older "gentleman" that has to be let go for one too many of those comments.
Now you can start work on the relatively superficial things. Things like engineers are not allowed to clear their own tickets, instead now everyone has to be reviewed. Detail qualification for tickets. Actually using version control. And rolling up your sleeves and getting down in the muck to get everyone out.
Those are the basic phases I drag them through. Like I said, I haven't had one yet that had a well groomed skills inventory that needed to helicopter in a tyrant to fix things. Oh, and I've learned how to be loud enough to shake windows in the office.
TurrisFortisMihiDeus@reddit
How does one get these fractional or consultant-cto gigs?
TurrisFortisMihiDeus@reddit
List all the issues you're seeing. Put them in a column. Next column is impact. Make it as data and evidence based as much as possible. For example executives will react better to "this issue makes us lose 20k every month" over "this issue has a morale impact". Not saying you shouldn't list the softer, difficult to quantify, items, but prioritize showing the impact of issues using metrics your sponsors will care about and be more amenable to fixing. Next column, executive priority. Leave this blank. Next column, your recommendations. Next column, eta for resolution if this was prioritized and if you had x resources and a,b,c tools etc. Next column, comments and risks/issues/caveats.
Categorize this list by theme. Senior People like to focus on things that make money, save money, or reduce risk. And then other themes.
Kick off a call with your initial list. And then iterate. Ensure you have buy in from the engineering teams. Engineering teams usually know where all the problems lie and also potentially how to fix them. The more you get buy in from them early on, the easier it gets to move forward.
Of course I am assuming you genuinely want to improve things and make an impact and not just milk the system as a consultant.
Let us know how it goes. Rooting for you.
casualfinderbot@reddit
If someone is hiring a consultant into a leadership position, it has to already be a dumpster fire
SweBot@reddit (OP)
Yeah, but how to put out the fires? đ
joydeepdg@reddit
Depends on the fire.
Some problems are political, some are structural, some are culture problems, and the easiest ones are code problems. The higher you go, the tougher the problems become, and you need a range of skills to tackle them. Unfortunately a lot of problems have no clear solutionâŚand it takes a fair bit of skill and experience to understand which problems can be solved at all.
I am sorry for being so vague, but having done a fair bit of âproblem solvingâ in my past few jobs, I sometimes question myself if most problems are really worth solving at all? Especially when the people who benefit the most from solving them (investors, board, ceo) donât really want to solve them.
ColossusAI@reddit
You donât, you run.
Abangranga@reddit
Fight dumpster fire with MBA dumpster fire
ivereddithaveyou@reddit
Sounds like your job buddy. Each fire has its own fuel, spark and oxygen supply.
jonbennallick@reddit
I award your common sense that wayyyy too many companies lack.
I say this as a consultantâŚ
AnythingNeat2320@reddit
There's a book named "The Phoenix Project" , this can give good insights to your problem !!
SagansCandle@reddit
One thing you learn when you get into technical leadership is that there are very few "technical" problems to solve. They're pretty much all "people" problems.
It's a different skillset, and while technical expertise is necessary, it's generally not the skillset you're exercising on the day-to-day.
If things are broken, there's usually a reason. Maybe someone thinks it's the right way, maybe it's a budget problem, or a time problem, but you're not going to fix the problem by bringing all the technical answers to the table. It almost never works that way.
Ttbt80@reddit
Make the releases not buggy.Â
CalmTheMcFarm@reddit
trite and unhelpful.
SweBot@reddit (OP)
Very much appreciated, thanks!
chrisza4@reddit
I am in that situation.
First, focus on improving.
You should not think of technical excellence and good engineering as binary but more of a steps.
Itâs is not dumpster fire team vs. ideal team.
It is kindergarten, elementary school , high school, university, grad, junior, senior, etc. team level.
So if you land into kindergarten team, your aim is not to make them professional, your aim should be improve them to elementary level or high school level.
Now you need to accept the idea that what you will do here even with your best effort would not even bring them to basic graduate team level. Thatâs life.
You canât teach a baby to do a calculus without teaching them a basic math first.
And that is the hardest part mentally.
Many people proud of themselves that they can build the best engineering team given right ingredient. They talk and write article about how awesome the team is.
You would cannot be that person.
You will be the one who brings the best out of bad ingredients. You would be proud of the progress you made, even thought the end result is still mediocre team. The point is you managed to transform them from dumpster fire team to a mediocre team.
That is what you will do. That what you will be proud of.
After you deal with your mental and mindset. The next thing is to focus on one thing at a time.
Remember, no matter how bad things are it already works for them. This means the worst case scenario, if you literally not doing anything then it will be just âthing work as it isâ.
Bad change control? It works, with a lot of issues.
Bad tickets? It works, with a lot of effort.
That means you can improve some of the area and leave another area as it is, because it is already works.
You can focus on ticket writing and reduce miscommunication. And leave bad testing out for now.
And then you said to your client, based on this change here is how much we improved. Justify it in terms of business value.
Thatâs all.
I myself currently focus on automated testing and while the requirement specification is still pretty bad, I managed to reduce number of issues given clean requirement and client appreciate the improvement.
Is the testing practice I managed to push through comparable to FAANG or just simply good software company? No. Not at all.
But is it 100 times better than what the team used to do? Yes.
ââ
About people, do you have authority?
If not, then you should communicate to your client that in order to improve the team, you need to have people with xyz skill. Otherwise improvement is impossible.
I even wrote them a job description.
If there is someone who reluctant to change and you canât talk them out report to your client and get a support.
Your client usually donât want to waste money on you as a consultant CTO and being blocked by basically developer.
They might asked you to try collaborating more. You did that for few weeks, try few things, show them that with 4-5 different approach to people here it is not working.
The hard part here is you need to come up with 4-5 different to engage with people. Good cops, bad cops, stoically logical, very empathetical, etc.
and we usually have our âdefault mode to engage with peopleâ that is hard to let go.
But you need to let go just to prove the point.
YMMV but this is general advice I can give with current context you give.
alien3d@reddit
Let said , most don't enter jira .. no documentation .. and some even only have interface not even Code. Don't be cheapskate if wanted to create a software.
metaphorm@reddit
> lousy jira tickets
this is the inevitable conclusion of JIRA.
"once a metric becomes a target, it loses its value as a metric" - Goodhart's Law
I sincerely think one of the best things a consultant can do is to deprecate JIRA and switch all the teams to a project tracking system that makes sense for their needs (which is likely to vary from team to team), and most importantly, to dispense with the non-sense "Agile" rituals that lead directly to project management tickets becoming worthless and out of touch with reality.
Effective_Roof2026@reddit
Transformation engineering. You don't do it with one person, usually CTO is brought in specifically to do it and brings a team with them. 3rd company doing it with the same CTO and VPs now. It has a high rate of failure as it requires complete C level and board agreement to do a transition.
A beard is useful. SOC2 or FedRamp are great for this, SOC2 can mean anything you want it to mean and FedRamp is prescriptive enough for places more resistant.
Absent those I usually do something NIST still like SSDF for CI/CD. The end state is usually the easy part as the big boxes always look the same, it's the transition that's hard. CI/CD transition is always don't transition, just start again as its always easier to build something new than to peel the onion.
Process stuff is not hugely difficult, you just need the right breed of Kafka to run the program. Usually starting in CM and then spiraling out is the easiest as you can make nearly everything CM. If you have competent CISO support this becomes exceptionally easy as you are not selling anything, you are doing security requirements that will be bound in to the terms of employment.
Engineering culture is the hardest part of this. Getting people to do commits/branching/reviews in a sensible way is extremely difficult if there is an established bad culture. Forcing people to trunk & kanban as a reset is usually the only way forward but is always unpopular with the engineers and tanks velocity for a while until people figure out how to build in small pieces effectively. Right now, I am experimenting with LLM to replace one PR review (formally within team) and mandatory 2nd review from a human not on the same team randomly selected based on geo. I am also toying with the idea of a social graph based on slack and commit history from GH to help select the 2nd reviewer so I can find someone the author has interacted with the least socially but has similar enough engineering skills to provide useful reviews.
Usually the easiest way to sell to engineers is prototype the end state and don't talk about the pain period in the middle at all. If you show a working preview environment and code space where when they create a branch they get a virgin VS code environment with their settings & extensions with an isolated preview environment just for that branch they usually forget they like the way they work currently and want it now now now.
Other stuff you can help with automation. Like CI/CD, if you are deploying services to k8 most services can use template Dockerfile's/Helm charts with shared github workflows so there isn't any work to do here at all, you create a repo from a lang specific github template and its already setup for everything and you just deposit code in to the new repo.
SweBot@reddit (OP)
Amazing, great suggestions!
IGotSkills@reddit
Yeah I just had someone come onto our team. They thought they were helping but they just brought culture cargo big company garbage by insulting what we had(that worked really well by the fucking way).
Make sure what you are doing is actually an improvement before you go and do it. If you just walk in and assume you know best, believe me, you are the worst. And it's your fault.
ivoryavoidance@reddit
How to become a consultant CTO?
LCD-Segment-01@reddit
Just be a consultant Director/VP for a few years to prove yourself.
theavatare@reddit
Normally reduce the number of things they are doing.
Explain the new state that you want (this requires a lot of legwork).
Change one thing a time to allow people to absorb the change(depending on how critical the changes are the rolling out cadence).
Build support for weeding out the people that could not keep up.
Evaluate after a period time to rinse and repeat till you get to where you want.
spaaackle@reddit
This is great, and Iâm not a consultant. Appreciate you!
theavatare@reddit
Any time. I'm here wasting my 20 years of experience at this point.
spaaackle@reddit
Doesnât seem wasteful to me, appreciate you being out here helping the rest of us out. đ
theavatare@reddit
I donât meant on the reply. Just the rest of the time around it.
Mundane-Mechanic-547@reddit
Yeah. I will add, build processes, scrap what doesn't work. If devs are doing 20% meetings that's the edge of okay. Beyond is too much. The process needs to solve the pain point. For ex if prod release is a shit show then adapting a rigid deployment model will help.
terrorTrain@reddit
First ask if they want recommendations based on what I see
If not, keep calm and get my job done. Not my circus, not my monkeys.
If so, tell them, try to help them migrate to something manageable. Usually doesn't work as they run out of organizational willpower for change
thecoachpunk@reddit
As a Interim CTO I had a similar client, what I did was:
- Having 1:1 Interviews about workflow, process and what they (employee/leading Staff) admire as best in the company
- Mapped the problem in clusters and presented this to the board
- Decision by the board to go deeper into analyses - after that mapped a clear roadmap with deliverables;
- Pinpointed and motivated people for the change project
- Started the project with a kickoff workshop, where everyone was presented (digital/physical) symbolic hand of (we used a key) for start of the project
- Board started the kickoff and handed over the key to me, to signal the importance of the projekt
We have been always transparent and hard on the topic, but empathetic to the people, bi-weekly report to the board in charge for the project.
The project took over a year - and we kicked off a change that was not reversable anymore. On a side note, I usually get booked when shit hits the fan, so I know exactly that everyone will blame me, if things for wrong. BUT that is something I can deal with and can communicate strongly.
SweBot@reddit (OP)
Nice, thanks!
Ihavenocluelad@reddit
Seems to me like you are literally asking how to do your job? On what qualifications have you been hired
SweBot@reddit (OP)
So you've never bounced ideas with a peer?
UntrustedProcess@reddit
I'd love to ask the reverse. Is anywhere not a dumpster fire?
ivereddithaveyou@reddit
Nowhere that's asking for consultants at this level...
AxBxCeqX@reddit
Grass is never greener. Just a different shade of brown.
ivereddithaveyou@reddit
Sometimes it's dead too
AxBxCeqX@reddit
Haha, stealing it. âGrass is never greener, itâs always a different shade of brown. Make sure itâs not dead in the interviewsâ
riplikash@reddit
Are there places that aren't a dumpster fire? Yes, though it takes a lot of hard work, and it's rare to be just hired into one (they generally have low turnover and do a lot of reference based hiring).
But for consultants coming in at this level? You only hire an expensive consulting manager when you have a dumpster fire and you've finally realized you have NO IDEA how to solve it.
Consulting managers are INCREDIBLY expensive.
theavatare@reddit
I worked in one place that had their shit together. I only been in this field for 20 years.
Extension-Entry329@reddit
Short answer: nope.
LogicRaven_@reddit
Consultant or FTE, no one hires a CTO or EM if things are not on fire. So this is business as usual.
Start with the busines stakeholders - what are their concern? Stability, time to market, costs, a certain new feature or else?
Chart the state of the kingdom: what is the product and key services, high level architecture, key data and process flows for the product, dev process, team ways of working, prioritization and changes, responsibilities, support processes, etc.
Create a signature win: pick something that is not very complex to change and will create visible improvement for one of the top concerns. Plan, get buy in, deliver.
Use the newly acquired credits to repeat the process with a more complex item.
One thing at a time. Make the change stick. Measure the improvement, if possible. Share the results.
Why should they care? Answers vary across companies, from public kudos to stability based bonuses. Likely need a combo of incentives and culture change.
SweBot@reddit (OP)
Great reply!
SweBot@reddit (OP)
Great reply!
TheRealKidkudi@reddit
Always start by collecting information and asking pointed questions. You never know what youâre walking into, but asking questions pertaining to the best practices you want to see or expect gives you a lot of insight into the current state of affairs - and when youâre new, they donât ruffle feathers the same way since itâs perceived as the new guy getting himself onboarded.
After some time building report/credibility with the team, you can start asking questions like âwhy arenât we doing [x]?â These can pretty easily transition into you volunteering to come up with some docs on how it should be done.
Then, you can communicate these plans and get everyone to buy in by explaining why theyâre helpful or how youâve seen them work successfully in the past.
Very important is to lead by example e.g. consistently following your own guidance and respectfully reminding people when it hasnât been followed.
Itâs also important to not be afraid to break any âunspoken rulesâ in the process. Iâve found that a lot of these bad habits come from some inertia of 1) learned helplessness/laziness and/or 2) some fear of office politics such as saying the wrong thing or being branded as ânot a team playerâ by not following the status quo. If you approach it from a perspective of reasoned intent to improve, people generally find it hard to push back if thereâs not a legitimate reason to do so.
SweBot@reddit (OP)
Love your comment!
darkhorsehance@reddit
Figure out why they are dysfunctional and go from there.
No_Flounder_1155@reddit
Biggest problem with these roles is not necessarily the responsibility of fixing things up, but understanding whether you actually have the authority to do so.
iBN3qk@reddit
I failed spectacularly. Dev mentor/team productivity consultant turned director of engineering.Â
Client had a portfolio of low budget clients and more in debt than I was aware of. I thought it was a satisfaction/motivation problem, but it turns out they are just low budget/quality devs.Â
I should have pushed harder on financial analysis. But if I had, I would have noped out of there.Â
One thing thatâs helped financially is raising rates and cutting the lowest tier clients. But that gives devs less time unless clients are willing to pay more. The only option to cut costs further is to outsource work to cheaper countries.Â
Company owes me about 6 months back pay stretching over a year now. Iâm about to take a dev contract and ask to cut my time/salary to 25%. Iâll focus on strategy and mentoring and maybe the lower cost will help them with repayment.
I feel like this company is an injured animal on the side of the road. You can drive by, call the humane society, try to nurse it back to health, or put it out of its misery. Whatever you do, donât allow it to cripple your finances, or else youâll lose your ability to help others.Â
Iâve had to adjust my whole philosophy on helping others. Put on your own oxygen mask first.
binarypie@reddit
Figure out how to fix it. That could be process or it could be restructuring the team. Never a fun conversation in either way. "War Time" leaders are unique in their ability to ignore bullshit legacy and feelings. Not everyone can do that.