Tools for CTO scaling engineering team: what worked and what was a waste of money
Posted by Aware-Version-23@reddit | ExperiencedDevs | View on Reddit | 91 comments
I'm genuinely curious what's actually worth spending a budget on when you're scaling from like 15 to 40 engineers, and what turned out to be total garbage. Our team doubled this year and I'm drowning in tool requests.
Here's what I mean, we spent $18k on a collaboration tool that literally nobody uses because slack does 90% of it, and wasted another $12k on a "productivity tracker" that just pissed everyone off. But we also got some wins, our ci/cd overhaul with better monitoring saved us probably 20 hours a week in firefighting.
The thing is, everyone's selling you something when you hit this scale, vendors love the "you're growing fast" pitch. I'm specifically trying to figure out code quality and review tools. We're at the point where manual reviews are creating 3+ day bottlenecks and my seniors are spending half their time just reviewing prs.
I've been testing different options, some open source stuff was too janky and enterprise tools are crazy expensive. Also looking at better testing infrastructure because our QA is basically "run it in staging and pray."
What actually moved the needle for your team? And more importantly, what did you buy that you deeply regret?
ActiveBarStool@reddit
out of touch C suite final boss
tikhonjelvis@reddit
One approach: find people who are passionate about specific things and then give them the air cover to make them happen. Having somebody who is already motivated to push something bottom-up will have a bigger impact than details of the specific tool in question.
One of my absolute favorite management anecdotes is about how Armen led Strats and Goldman Sachs, from this HN thread:
A couple of the best folks I've known in tech started their careers in Strats and had very positive things to say about the tech and culture there.
Trick-Interaction396@reddit
Focus on good people and process then worry about tools later.
zapman449@reddit
Adding: focus on radically reducing in flight tsk counts. Get groups of 3-6 people on any initiative… no smaller. Drive a thing to realistic completion before you accept another into “active” status. Don’t let anyone “lone gunman” an initiative.
Let more people focus on fewer things.
wesw02@reddit
I completely agree with this. I'm not a CTO, but I've worked as a lead and architect on many high profile projects at big cos and startups. I've always found success in putting people above process.
Hziak@reddit
Same experiences and I echo this advice. I’ve done death marches on small teams and felt better at the end than after BAU Mon-Fri at larger companies that had miles of red tape for the most basic results. The only thing that mattered as an IC for me was whether or not I believed in the product and whether or not my team was my other family. Four years since leaving one startup and I still talk with two of my Jrs every day and we meet once / month for dinner. I’ve probably gotten more work in my free time on personal projects with them done than I have at my new jobs since just because it’s such a natural feeling to work with the right people.
People > process.
And for the love of god, if you bring on a manager who tries to break up a good team or change a process that’s working, do not hesitate to can them! I’ve worked at two incredible startups that hit the 50ish person mark and decided they needed a CTO or VP of Tech with big company experience to ease the transition. In both cases, the new manager started to change things, we were told to “bear with it and trust them,” the company began to fail because the processes didn’t work, people quit, the company failed. If you have good people, trust THEM. Don’t feel like you have trust the most expensive person…
/soapbox.
Grass_fed_seti@reddit
wow, I didn’t realize that was a common pattern. At my first early stage company, they hired a new VP of eng with big company experience, who basically overhauled everything (direction, process) and pushed for massive scaling changes that didn’t match the needs of product. They eventually got canned, but it was demoralizing to work through that
MoveInteresting4334@reddit
Unfortunately, when all you know is a hammer, everything looks like a nail.
breek727@reddit
Surely if all you know is a hammer everything looks like a hammer
spline_reticulator@reddit
I'd say good people, good culture, clear vision, and well defined ownership. If you do that they'll mostly figure out the good process.
dodo1973@reddit
Replace process with culture.
oVtcovOgwUP0j5sMQx2F@reddit
not necessarily; culture can emerge from process
SansSariph@reddit
I'd frame as - process is ideally the scaffolding or guardrails used to guide outcomes when for whatever reason (inexperience, divergent priorities or backgrounds, whatever) there isn't organic cultural alignment.
When a team is operating effectively the process is invisible or natural (and more flexible). When it's forming, growing, etc process provides structure to fall back on.
Trick-Interaction396@reddit
Yes, better said than I.
nickisfractured@reddit
You need tools because of poor culture and hires, bigger question is will doubling your staff quickly actually save your time and make you faster and maintain the same quality? I’ve seen and been part of many companies who double in a year and by the end of the year they’re almost out of business because they didn’t manage the team properly out hire for quality over quantity.
jmelrose55@reddit
The most important process you can have at that size is psychological safety.
Material_Policy6327@reddit
This. Tools but with horrible process and standards means the tool most likely won’t help
lunarlarry7@reddit
Code rabbit has been really useful for our team (4 total). Not only is it nice in that it catches silly mistakes but it also provides good summaries and we tie it into slack to give a rundown of each persons changes as a daily standup (we do a real standup too)
coredweller1785@reddit
The answer is ask the people doing the work.
The answer isn't from shareholders or from external companies.
Its right inside, the engineers know best and the answer is usually more people or more time outside of meetings.
Tools, especially management reporting tools only create overhead which eats time. I include Agile in this as well when you lean too heavy into it the overhead outstrips the benefits for the developers.
Stubbby@reddit
I was at a place where we had ALL tools and everyone was able to pick the right tool for themselves.
PowerPoint became the tool of choice for most teams across the company for tasks, personnel and project management.
Another place, we only had SOME tools and we ended up with Google Slides for task, personnel and project management.
I was thinking, what if I did a Google Slides wrapper and sold it as a project management SaaS?
Powerful-Prompt4123@reddit
> our ci/cd
> manual reviews are creating 3+ day bottlenecks and my seniors are spending half their time just reviewing prs.
That's not true CI, is it?
> What actually moved the needle for your team?
Massive TDD and trust the programmer, and true CI where anyone could push to master, and anyone could revert too. Branch on releases. Cherry-pick bugfixes.
Rascal2pt0@reddit
White boards and breakout rooms if you work in an office.
Lazy-Penalty3453@reddit
I feel this so much once you cross 20–25 engineers, every vendor suddenly claims they can “fix your delivery pipeline” but half the stuff either adds noise or gets abandoned in a month.
On the PR review bottleneck specifically, we hit the same wall earlier this year. Seniors were swamped, and turnaround time was creeping past 3 days. We tried a couple of code-quality platforms too and honestly most of them either required heavy setup, produced noisy suggestions, or felt like manager dashboards nobody asked for.
The only thing that actually helped was trying an AI layer on top of our existing workflow instead of replacing tools. We tested NotchUp’s AI Copilot (they plug into Jira + GitHub + Slack). It doesn’t do auto-reviews or anything sketchy, but it did help surface stuck PRs, unassigned reviews, capacity issues, and hotspots without me nagging the team. The biggest value was that it cut down the “who can pick this up?” guessing reviewers actually got matched based on context.
Didn’t solve everything, but it noticeably reduced the random delays and senior IC overload. Worth trying if you’re drowning in review queues.
ponderingpixi17@reddit
Focus on tools that solve specific workflow bottlenecks rather than chasing trendy solutions. Let your team's pain points guide investment, as over-tooling often creates more friction than it resolves.
apartment-seeker@reddit
And you're naive enough to believe them any percentage of the time?
TBH, from your post, you sound...less experienced than might be ideal. That's ok--you just need to hire 1 or 2 really experienced people who have been there and done that, who you can trust, etc.
Take counsel from them and delegate to them, even if the ultimate decision and executive authority still rests with you.
beachguy82@reddit
I deeply regret moving my 15 person eng team to 40.
It was a mistake that deeply hurt our company. You should know that you likely won’t even get a doubling of your teams productivity. The added process needed to manage a much larger team and to coordinate their efforts is a massive time and money suck.
howdoiwritecode@reddit
Five A rated engineers move faster than fifteen B+ rated engineers.
beachguy82@reddit
100%
tdifen@reddit
Honestly you probably know most of this shit and I could go on forever. It's an exciting but difficult problem. I wouldn't hire unless you really have to, just hire when you actually need to be delivering more but understand you won't feel that delivery for a few months.
Alternative-Wafer123@reddit
Don't waste money on Architect roles Indian Who talk better than do
Spend money on Real troubleshooting skill Deep analysis Unblocker
scott2449@reddit
It's never too soon to have a few engineers who are focused on tools. Does not have to be full time when you are still small. Let them work with everyone, discover the most value add pain points, and come up with a plan to solve with minimal tech/spend/time depending on your needs. Every tool and automation that you do well will but the whole org more time to work on product and more efficiencies in the SDLC. Once you get bigger it's time for a platform engineering team.
rer1@reddit
I second this. Even if they don't actively do much, it's important to have someone in the org who's responsible for setting up and integrating tools.
Otherwise a large disparity between teams will creep up and it will be harder to align everyone later.
EngineerFeverDreams@reddit
You should absolutely not waste time on tooling too early. In most cases you should buy a tool and not build it.
rer1@reddit
Sure, but most tools require integration and guidance. If you let each dev arbitrarily set up tools own their own, you're gonna end up in a mess that will be harder to fix later.
bishopExportMine@reddit
Sorry my company moves too fast to research what tools to use. Instead we build everything in house so we can show up to standup and talk about how much we did.
dedservice@reddit
40 people seems (from my not-CTO eyes) to be enough to have somebody part-time thinking about tooling. Every dev spends a little time on getting bought tools set up. Also depends on what you're thinking of - in terms of scope - when you say "tooling".
oVtcovOgwUP0j5sMQx2F@reddit
this, just be careful to protect that dev from getting swamped in the tooling domain and get burned out
EngineerFeverDreams@reddit
Potentially 40 people could use someone helping with tooling. It's something only that org will know. I'm merely saying there is definitely a time that's too soon. If you're not delivering value, if you haven't found PMF, you're far away from needing tooling.
randomInterest92@reddit
Focus on the basics tbh. Have simple processes, check that the processes itself don't have bottlenecks. E. G. You mention only seniors doing PRs, is that really Necessary? Maybe it's even a good thing?
Make sure responsibilities are clear, obvious and evenly distributed.
Work is a flow in a river, you need to remove everything that hinders the flow first, only then you may add more water
va1en0k@reddit
With any kind of problem like this you have to ask yourself what do you think would be the normal amount of reviewing time, and why is it higher - if it is. If you have ten juniors for each senior perhaps that's just how much time it takes.
If you don't do this analysis you'll only waste money on tools, no matter how good they are
Skullclownlol@reddit
Yeah, this. Usually you do this because each hour spent helping to train colleagues as a senior means your next 1y-3y-5y will have increased productivity because you'll have 5 people continuously getting better. It's absurd to assume "time spent on X" is a problem just because there's time being spent there.
captcanuk@reddit
This is common in optimizations. You sped up a large something that used to take 3x the time so your entire cycle time reduces heavily but the percentage of the thing you didn’t optimize has grown due to the now smaller denominator. Going faster does not mean things are getting better.
The tool you need is bettering yourself as a CTO to understand what needs to change next: process change to speed up or reinforce things, tools to speed up things or attitude and rigor to understand the slow part will remain that way because it is doing an important job.
ForsakenBet2647@reddit
> just want to throw money at problems
I vouch to be one of those problems please.
ssunflow3rr@reddit
for what it's worth the code quality automation stuff can really help with the review backlog if you get one that actually integrates with your workflow. we use paragon for some QA automation and it cuts down on the obvious catches so reviews are faster
dump_scorpiogirl-7@reddit
18k on a tool nobody uses hurts to read, did you not do a trial period?
olivermos273847@reddit
what about testing infrastructure, are you looking at something like cypress or more unit test coverage or what? that staging prayer method sounds terrifying at 40 people
Aware-Version-23@reddit (OP)
yeah it's bad lol. looking at better integration test setups and maybe contract testing. cypress is fine for e2e but slow af
jl2352@reddit
If their spending three days on PR reviews, then spend three weeks digging into it and overhauling the process.
I would bet good money it’s down to a lack of testing (so lots of QA), and poor PR reviews process. Investing in both will get it down to 30 minutes.
I worked in team where one person leaving, who was from a different team, halved our PR review time. Which we then invested in additional tests. Whilst I doubt you have something that stark, I guarantee you can speed things by working more closely with your engineers to unpick what poor processes they are following.
CoffeeRory14@reddit
The collaboration tool waste is so real, everyone thinks they need notion or miro or whatever but slack + github is honestly enough for most teams.
lbrtrl@reddit
Every company I've been at has paid for a RustRover (IDE) license. That makes me a happy dev. Let your devs request tools (like IDEs) that help the do their job, bottom up, rather than top down. The good tools will show themselves and hopefully you won't have to think much about it.
karthie_a@reddit
listen to your actual engineers not the attention seeking ones. The ones who resolves incidents in firefighting in an one to one informal coffee chat and ask them to provide you with list of pain points. how do they think it can be handled. Based on the list you collected go for a summary and map it against the tools which you already have in hand. You will end up with what you have and what you need.
Cahnis@reddit
"Productivity tracker", wtf were you thinking, everyone haaates that. I left my last job within a month of them enforcing that.
MadJackAPirate@reddit
Claude-code
SnooPears2424@reddit
Get rid of “scrum” masters and “project managers”
juan_furia@reddit
The tools that worked for us were solving pain points we already had, overhaul in ci/cd, in ease of creation/destruction of local environments, standardization of tool chains, …
Simple_Horse_550@reddit
Except for Git, Jira, copilot and those dev tools, invest in testautomation. Will help onboarding people much easier and you are not dependent that much on Joe, John etc for different parts of the system since even if a new person works on it, there will be automation catching potential bugs…
Aware-Version-23@reddit (OP)
I might look into this, I'm in koreatown and always looking for better food options that aren't delivery apps
Aware-Version-23@reddit (OP)
I might look into this, I'm in koreatown and always looking for better food options that aren't delivery apps
fllr@reddit
find ways to minimize the ned for each team to talk to each other except through contracts (and camaraderie). in other words, a hyper connected graph is expensive.
trailing_zero_count@reddit
Did you ask your engineers where the friction is and what tools they think need improving?
_sw00@reddit
This. Honestly, your people are the ones best positioned to help you figure out what they need to be effective.
LR2222@reddit
Designate hands on leads to own sections of your platform. Pay them really well, empower them to make decisions but hold them accountable.
Seniors/Mids/Juniors report to a Lead. The leads should report to you. Any more vertical org structure is bloat until you get to 150 employees.
Hire more seniors/mids and way fewer juniors. Juniors are only useful when you have some scale and resources to devote to training. They are a massive time suck and net negative in terms of productivity. You basically pay them to learn what colleges fail to teach, while taking time away from your seniors and leads. Seniors should spend the vast majority of their time coding.
PRs should be small enough to review and merge quickly. Many small PRs are always better than massive ones. Instead of a PR for entire new feature like say an appointment scheduler. You should have many smaller PRs (ie CalendarComponent, appointment form, appointment service, etc).
Engineering managers are pointless. Your leads need to communicate architecturally with one another. If they don’t, hire new ones.
Ignore the SAAS products. That should be the job of your infra/dev ops team lead. They should already know what is need. They should filter and pitch you on them.
Your focus should be on managing the strategy with other senior leadership, managing the team leads, ensuring delivery and guiding the architecture to be scalable as you grow.
“Wikis and kanban are where team collaboration goes to die”. My mentor told me that once and I will never forget it. Every company wastes countless hours building out notion or confluence pages that nobody besides new joiners ever reads.
lupercalpainting@reddit
Why? For a service I'm a SME on I can review a pretty heavy feature in an hour, maybe 2 tops. I can think of a few reasons why it'd take multiple days:
the PR is low quality and I have to go back and forth with the author a few times that could be in total a few days to get it merged
I don't have context on the feature (or on the service)
it's something very large and dangerous (it did once take me the better part of a week to review an overhaul of our auth system).
Each of these have different root causes and potentially different solutions. Maybe the PR authors are just submitting slop, maybe they're not reviewing their own stuff, maybe context isn't shared, maybe the codebase is too large for any one person to be an expert in it, maybe the implementation should have been rescoped or more upfront work should have went into planning.
AusCro@reddit
Worked as an eng at a few places like this. Best combo for them was unfortunately just locking into Microsoft Teams and Azure usage, and Atlassian. Automate everything on Azure Devops when you can, track tasks there if it's possible otherwise use Jira. Store all knowledge on Confluence. Bitbucket in the bin
thatdudelarry@reddit
Worked: communication and developing tools in-house, when needed. If we couldn't build it we searched the team for an SME on an existing tool. If that didn't exist we re-evaluated our needs because we were wasting too much time.
Waste of money: meetings to review tools, researching a bunch of tools that nobody knows how to use, licenses for layers of corporate waste miraging as productivity.
Scaling isn't the time to be introducing new shit. Scaling happens when shit is stable.
ZukowskiHardware@reddit
The best way to make your team faster is to invest in a dedicated platform team. Anything that you can measure that takes devs time, make that faster and easier, and you get speed. For example, how long does it take a new dev to open their laptop and be able to work. How long are your builds, how long is your CI. Make the platform team make that better.
double-click@reddit
Can you test independently of an integrated environment?
Can you deploy apps/services independently than those they depend on or interface with?
If so, you’re already ready for 40.
The_0bserver@reddit
Having a proper platform engineering team to take a stab at how to improve processes across the board would really help.
chipstastegood@reddit
Another thing that worked for us at that size - we put in a mandatory fix bugs first then features. We put in automated log and crash monitoring to surface runtine errors. And Slack automation to calculate MTBF. Quality went up in a couple months and stayed high
chipstastegood@reddit
CodeClimate was well worth the money for me when we hit that size. It gave me great visibility into team performance and SDLC process bottlenecks
j-e-s-u-s-1@reddit
That 18K on collaboration tool, care to share name of the tool in DM?
Beneficial_Stand2230@reddit
Jira. Small PRs. Mandatory unit tests. GitHub actions that run a linter and unit tests.
saposapot@reddit
Whatever pain or tools the team suggests.
Spare_Message_3607@reddit
What about you talk to your engineers instead of redditors. Hire a tools engineer whose sole job is to find or build tools for the other engineers: CLIs that improve annoying testing setup or CI, monitoring dashboards, integrate Code Analysis tools; bring in QAs, more people means more points of failure. Team management? have a conversation with your team leaders/seniors and have them suggest a tool and why.
greasytacoshits@reddit
we're at like 25 engineers right now and hitting the same review bottleneck problem, how did you evaluate the different code review tools? Did you run any pilots or just pick one and commit? also curious if you're doing any automated QA alongside the review stuff because those seem related
Aware-Version-23@reddit (OP)
ran 2 week pilots with 3 different tools on a subset of repos. polarity had the best signal to noise ratio for us. for QA we're still mostly manual but looking at contract test frameworks next quarter
matthra@reddit
One of the things that helped us with seniors reviewing PRs was having Claude (though I imagine any AI would work) do preliminary review of pull requests. You still have a senior review the PR, but Claude is good at finding red flags, and can make reviews much faster. It's a pretty easy GitHub action to setup.
I'm a data engineer, and a tool that has really helped us with quality is a good data diff tool. We use data fold, and that way we always know the downstream effects of any change are. It was so effective that we were able to shrink our QA team.
Management likes jellyfish, but I haven't really interacted with it much. Like most seniors on here I have strong opinions on how to rate engineers but that's probably out of the scope of the question.
Another tool recommendations is a meeting AI note taker, it makes it safer and easier to miss a meeting because you can just review the notes. Any engineer salary you can save on meeting is generally money we'll spent.
Anyway good luck with scaling up and good on you for asking engineers what works!
blendermassacre@reddit
Are you scaling other positions to match? Product, UX, QA and managers? If not, spend money on that instead.
AwesomeOverwhelming@reddit
Sonarqube. Automated testing for pull requests, code coverage requirements on changed/new code. Start the requirement low and build it up.
EngineerFeverDreams@reddit
What are they spending time reviewing? I'll bet if you look at their reviews, a lot of it can be solved with a linter and some rules.
If there's days on days of problems that people are debating via PRs, there's no amount of tools that will fix the communication and collaboration issue you have.
Let me know what they're spending time discussing and I'll dive deeper.
Diolex@reddit
This. Automate as much as possible on code reviews. Automate running tests, code coverage, linting, and security scanning. Have it block merging a PR and make the engineering culture force engineers to only post healthy PRs.
alien3d@reddit
The last company i work . Nobody write any description bugs in jira except me . All put title and point and 0 Link to commit number.
Euphoric-Usual-5169@reddit
No tool can compensate for bad management. Focus on good processes and management.
Mundane-Mechanic-547@reddit
Hi former CTO of a small team. We mostly just used Jira. Once we got acquired they threw all sorts of "process" at us which killed productivity. 4 different tools for tracking stuff, etc. No actual people, of course not. But yeah Jira did 99% of what we needed. We got 1 enterprise tool for like 15k that did a really cool API dashboard, and the rest was real small scale stuff. Quickbooks integration, gusto for payroll, etc. I find the cheap per seat per month models are fantastic. Nearly all the Zoho things are good. Is Netsuite or Salesforce better? Maybe but that requires such a large lift as to never be worth it at our scale.
sexytortuga@reddit
Atlassian (who owns Jira) has a new RovoDev tool that ca n accelerate code reviews.
jakesboy2@reddit
Suggestion for pairing/screen sharing tools, Tuple is really good. I’m actually hesitant to leave my job because I don’t want to have to pair without it lol
Tacos314@reddit
Can you clarify what specifically you’re looking to scale? The questions you’re asking are fairly foundational, and in most cases standard SDLC and DevOps practices will scale effectively to teams of hundreds of developers.
From what you’ve described, it may be more useful to first focus on establishing or refining core CI/CD pipelines and SDLC processes. Bringing someone in to help design and implement those fundamentals could give you a solid base to grow from.
1QSj5voYVM8N@reddit
Biggest accelerator is better engineers. Spend money on fewer, better people.
Try and platformtize somewhat as you grow, not allowing all teams to reinvent the wheel from scratch, but have standards for telemetry, logging etc, deployment, support tools, that minimize the rework teams do.
Have design processes, and standard definitions of done, and what level of tests you want, what your testing strategy is so everybody knows what the quality bar is. A good reviewing culture is essential, but it is clear you need to broaden your pool of reviewers and the nr of people you trust to approve reviews.
more tools to understand your code base and what people are really working on only become important when you are above 100 or so engineers and management visibility decreases.
engineered_academic@reddit
What I have seen improve the needle:
Proper CI/CD process optimization. A smaller dev shop running CI will generally not scale once you reach 50,100, 200 devs. All that extra cost will add up. Especially if your pipelines are not context aware. Having automated links to runbooks so people know where to find info for an error or incident and are able to contribute is important
A proper vulnerabilty management strategy. This includes supply chain security. Small regular cadence is better than a big push every year/two years.
Proper penetration tests. SAST/DAST tooling is useful but I have seen too many false signals. Paying for an actual yearly test is worth it.
lordnacho666@reddit
Start with the boring, standard solutions. Everyone is using grafana? Start with that and change when you find there's a hole it doesn't cover. Boring stuff tends to be well tested and also extended in all the ways people would naturally have thought of.
Start with things that are free, to see if people bother using them.
Get business side to negotiate a good exit clause if you're thinking of spending money.
t-tekin@reddit
What are you trying to solve? What problems do you see with your org? What opportunity space do you see?
Without those it is very hard to tell.
But in general, every team and company is different. Let your team tell you what gaps they see and what kind of tooling they need. Not some reddit strangers.