Team is extreme in prioritising velocity.
Posted by SawToothKernel@reddit | ExperiencedDevs | View on Reddit | 79 comments
I'm interested to hear your views on this. Whether or not there's some validity to this approach, and if you've been on a similar team and how you handled it.
I recently joined this team, and it's like no other I've been on before. The primary concern is velocity, so everything that can be perceived as slowing velocity has been stripped out.
-
There is no planning: no meetings regarding who is doing what this week/month/cycle/whatever. We have a standup every day, but it's just a status update. We align in chat, and most decisions seem to be quite ad hoc.
-
There are no reviews - or at least, we've been specifically told that we are to just rubber stamp PRs. The PR author is trusted 100%.
-
There are very few tests. The boss looks down on tests and encourages us not to write them.
-
We are encouraged just to come up with ideas, ship them, and then see what happens. If it works, it works. If it doesn't, we remove the code.
I can see benefits to this approach, but we also do ship quite a few. bugs, and the code is not in the best shape (although not yet a disaster). The UI is quite fragmented, as you might expect, but mostly works.
The main issue I have with this approach is the lack of alignment - it's hard to know what we should be working on, what others are doing, who's talking to whom about what, etc.
NB: Just to pre-empt this, I'm not looking for another job.
keel_bright@reddit
Funny thing is this is the most actually true-to-Agile thing I've ever heard
BigHambino@reddit
Do you ever actually go back and remove it? Or do you have feature flags stacking on feature flags and no one even knows what reality is anymore?
Like with all things, there is a balance. Given a toss up between velocity and quality, I’ll choose velocity for my team every time. But there’s plenty of quality to be had at the cost of velocity that is worth the trade off.
AY-VE-PEA@reddit
You are accumulating tech debt at an unprecedented rate, by the sounds of it. Unless it is an MVP/Prototype phase or pivoting to try to gain traction/users, then just sounds like a recipe for eventual disaster and it may take years to see that come to fruition.
ramrajv@reddit
OP didn't say that youre just guessing it.
DaRadioman@reddit
Didn't say they were accumulating tech debt? Yes they did!
All of those point to tech debt intentional or not. All of them together means they are taking it on rapidly.
Key-Life1874@reddit
That doesn't mean tech debt is accumulated. The best teams I worked at never had reviews and decisions were made on the fly. That's called trust.
ramrajv@reddit
I am starting to realize that this entire sub is a bunch of middling morons who have no idea about being truly productive, or AI or anything except jira ticket 100 line PRs.
anubus72@reddit
i guess I’m a middling moron because I’m not sure what you’re getting at with "jira ticket 100 line PRs"
Danedz@reddit
Yeah, if everyone is perfect, it will work fine. I never saw that personally but hey, anything is possible. Sadly, OP mentioned that there are bugs - so we can be sure that everyone is not perfect.
angrathias@reddit
Age old adage: If a software falls over in the cloud and no one is there to see it, did the tech debt really accumulate ? 🤔
unemployed_MLE@reddit
Sounds like a hackathon team.
ramrajv@reddit
And what's wrong? Sounds like OP doesn't belong, but if it works, and the bugs in prod are tolerable, and upper management is not complaining, and the rest of the team is fine with the system, what exactly is the problem here?
In the end the point is to ship, and they look like they're shipping, sustainably. Arguments about it not being sustainable are moot. You don't know that. They're not a startup so in all likelihood they are indeed sustainable. More sustainable it looks like to me than many many teams I've seen ticking all the boxes marked as missing here and they deliver utter crap.
Existential_Owl@reddit
I work in a similar environment to OP. Honestly, it hasn't been so much of a problem that it's caused me to want to leave. But there certainly are annoyances.
The two biggest ones for me have been:
1 - Since we have no PMs, no product roadmap, and no planning whatsoever behind a giant board of unsorted Jira tickets, we only ever work on whatever new feature idea our EM pulls out of his ass at the start of the sprint.
It just bothers my sensibilities as an engineer knowing that, were we to take even the most basic steps to solicit customer feedback, we'd have a clear idea of what our team should be working on each sprint.
But nope, it's ADD (Ass-Driven-Development) for us.
2 - Because we have no unit tests, no e2e tests, and barely a QA process, half of our reported bugs are due to regressions. New code goes out, and old code gets broken. Nearly every single time.
Honestly, it makes my job easier knowing exactly where and why our bugs come from, so, ironically, it's made me look far more "heroic" being able to push these spot fixes so quickly after they're found.
More people should try getting rid of all their tests. It keeps life interesting.
ramrajv@reddit
I am the guy arguing against all the people calling this place unproductive but at the same time im not against tests. The same environment with extensive tests is a pleasure to work with (especially with really good CI CD and ephemeral environments) .
Existential_Owl@reddit
I agree with both of your points.
Environments like OP's and mine can very productive, and, honestly, I feel that we get more features done without tests than we do with tests.
But, still, I think we all can agree that we'd all rather work in an environment with extensive test coverage.
And I'll happily point out that my company's customers complain all the time about how buggy our software is.
But they stick with us because it just so happens that our competitors' products are even worse (quality-wise) than ours.
I can't even imagine what sort of godforsaken engineering practices our competitors have to employ to have a worse-quality product than ours, considering what I've typed up above about our test-less, ass-driven approach to development.
Ibuprofen-Headgear@reddit
Given all that, and if they’re actually fine with it, my biggest annoyance would be having to create ceremonial prs or get ceremonial approvals. Maybe the PRs have a test gate? But it sounds like no. And even if they’re actually fine did, you could just require that and not require approvals.
But if no test gate, then why not just yolo to main? Unless there is some conflict resolution / check gate for merging, but then why require reviewers to just click approve vs not requiring approvals
ramrajv@reddit
Probably to maintain bullshit soc2 compliance rules?
Megamygdala@reddit
Yep, it'll be fine and sustainable until prod goes down and they'll start enforcing real reviews
Ibuprofen-Headgear@reddit
I mean I do that on some small or solo projects just so unit tests run on a hosted env before auto merge, but it sounds like they’re not doing that. But yeah, prob “compliance”
SawToothKernel@reddit (OP)
Feels like one.
renoirb@reddit
Stinks like one
daemonengineer@reddit
If it works, it works, until its not. Have fun if its fun for you, but make sure to exit before it crumbles.
Is it a startup?
SawToothKernel@reddit (OP)
It's not a startup, it's a small team in a 2nd tier tech company (3000+ employees)
daemonengineer@reddit
It borderline insane to have such processes for a critical long term application. I would look for reassignment ASAP.
KokeGabi@reddit
What is the teams purpose? Maintaining or upgrading preexisting “core” software or are you building MVPs constantly?
Seems like it would be a “fun” environment to be in if there’s no expectations of future maintainability. Otherwise I would be looking for an out before all that shit comes crashing down.
SawToothKernel@reddit (OP)
It's definitely a long-term application, and is in fact quite crucial to the org as a whole. I feel like the boss is treating it as a startup still finding its niche and has yet to recognise that you generally need to transition to something a little more organised.
KokeGabi@reddit
Fucking hell. What’s your managers background? What’s the relationship like with the rest of the org? Is he the only person in charge of making decisions?
You obviously know this is insane, question is whether or not you care enough to actually rock the boat and get some change, or just silently move on before shit hits the fan.
SawToothKernel@reddit (OP)
He's was a serial entrepreneur - still is, to be fair. I think the rest of the org is happy to move quickly, but I do think the shit will hit the fan at some stage.
My compensation is heavily weighted to stocks, which are doing amazingly and I'm actually quite trapped here I would say, as I won't get anything close to this elsewhere. So I have to ride it out. My inclination is to document my suggestions, but ultimately to go with the flow.
PragmaticBoredom@reddit
There’s a type of corporate climber who comes in, moves fast, and sweeps the technical debt under the rug. Then they move up and on based on their accomplishments. Someone else is left holding the bag for the project, but the glory has already been claimed by someone else.
In these situations, it’s best to avoid being the one left holding the back. Keep a look out for teams to transfer to.
SawToothKernel@reddit (OP)
Thanks, yeah team transfer is definitely an option.
KokeGabi@reddit
Golden handcuffs.
Yeah, as long as you are able to show you tried to improve processes even if it’s just in conversations, slacks, emails w ur manager. Cover your ass and hope the buck stops with him.
FinestObligations@reddit
Then your boss is a moron.
onafoggynight@reddit
We don't know that. There can absolutely be background we are not privy to, e.g. maybe he has been put in this position to explicitly move the product along faster.
What op needs to do, is figure out why the pace is what it is, and if it is aligned with what the business wants.
FinestObligations@reddit
Product doesn’t move faster by skipping on reviews, tests and planning. It’s the exact opposite.
Blankietimegn@reddit
how often is there an incident during deployment? How is it resolved?
SawToothKernel@reddit (OP)
Good question - I would definitely say there are more incidents than I'm used to. We don't measure it though, so it's hard to say exactly.
Blankietimegn@reddit
I mean I figured lol. Does your team measure uptime? It’s important because that kind of stuff is usually necessary for your SLA with the customers.
originalchronoguy@reddit
I am both type of teams. My main team is a Tiger Team/Skunkworks. And I work on a team "cleaning" up the mess of Team A.
The tiger team pushes out a lot of products that tend to be high impact, short lived by design. They are built to solve a quick problem. We also do a lot of research and POC. Which tends to be fine. Example will be building out a feature of a major product that a vendor does not have. They have a 1-2 year roadmap so we go in and fill in the holes.
Now, we produce a lot of MVPs and some MVPs actually go on to becoming products.
One of them is a now a big product. There is some tech debt. Sure, but that debt literally hired a whole department to support. Something that was rushed out in 6 months now has a team of 25-30 people working full-time to support it. Some of those people don't like the debt and I get it. But I always reply, "if it wasn't for that debt, you'd wouldn't be hired to solve these problems." Since I originally built it, I am the SME and have the most knowledge of how things work.
It is a mix bag because the new team can't innovate and they take forever to refactor things. The quality they produce is not substantially better. The original team has to go in and improve and redo what the new team does. Example is scaling and performance.
Ideally, Team A goes back and handle the tech debt. But we are constantly assigned to new things to create fast.
Careful_Ad_9077@reddit
Assuming there is never a catastrophic failure.
I was In a similar org ( well a few, but talking about this one in specific), we had hard deadlines for features as we needed to demo them to possible cliente and having the features was the difference between closing the sale or not.
So, this created two tiers of devs, the ones who understood the debt and the ones who did not. Sometimes nobody understood, and it was time to rewrite the features.
My recommendation, which seems to be above your pay grade, is to document how the software should work/works from a business logic perspective. Usually technical debt accumulates and then you start doing feature rewrites until not even that is feasible then you rewrite the whole system, usually when a new hit tech is popular so you can both do the rewrite and the tech change to ease into justifying all the extra work.
It's as if tech debt accumulates so badly that you declare bankruptcy and move to another city.
Aromatic-Ad-5155@reddit
Sounds amazing!!!!
SawToothKernel@reddit (OP)
David?
fmae1@reddit
My gut says you're working for an early stage startup. I feel you and worked in a similar environment for 2 years or 3. We basically sprinted and built a SaaS in this way. Eventually, you reach the point that you have to start adding tests and doing big, big refactors because in these months you would have accumulated an insane amount of tech debt. It is to be expected but I understand that during the race people don't want to hear about this stuff.
My personal advice: don't take your code personally. The code works and prod bugs are tolerable? Just do it, continue this way and get paid. Ship stuff and don't overthink.
If you start thinking: "I'm a smart person, I have high quality standards, I will change this into that", you'll go crazy.
Ready_Anything4661@reddit
Just start changing all the APIs without telling anyone.
MagicianWithABadPlan@reddit
There's never time to do it right, but there's always time to do it over.
irespectwomenlol@reddit
Key information missing.
SawToothKernel@reddit (OP)
This is an established company with >$1bn turnover. The customers of this particular feature are likely to be some of the biggest companies in the world. The feature could end up being critical if workflows start to get built off the data at these companies. At the moment, we have only a few big customers migrating in.
irespectwomenlol@reddit
A few elements that you described might be somewhat questionable. Though honestly, I particularly adore the idea of being given flexibility to come up with your own feature ideas.
But there might be some business context missing. Even within a giant company, there are teams that can be on the chopping block unless they deliver. Your manager might be privy to political things going on at your company that you're not aware of and trying to protect you.
I don't know what's best for you. Personally, if I thought I had a good relationship with my manager and wasn't at risk by it, I'd try and politely talk about an issue that was bothering me and get their perspective.
SawToothKernel@reddit (OP)
Thanks, that's fair enough. I have talked to the manager about this, but this is his belief about how to run a software team. In fact, he said it was "proven", so I don't think he's changing his mind.
I'm not completely against this, though, and I'm happy to ride it out to see what happens. Maybe I'll learn something new here.
IProgramSoftware@reddit
So what’s your question?
SawToothKernel@reddit (OP)
In the post:
onafoggynight@reddit
We cannot answer that. You need to figure out why there is so much emphasize on execution speed. Ask your boss or other team members how this aligns with business priorities
If this is expected and aligned (including the potential issues down the road), there is little you can do manage it - this mode basically relies on very competent people to know what they are doing, making (mostly) correct decisions repeatedly, and cutting the right corners.
_JaredVennett@reddit
Sounds like paradise to me….. as someone tired of never ending sprints. Discouraging tests I’d want to change because without them it will increase stress when deploying into production.
Gloomy_Actuary6283@reddit
It potentially can work, if this is at least coupled with some long-term planning and architecture - meetings to discuss direction/architecture can be of course executed from time to time when needed, and not tied to any fixed cycle.
That is more dangerous. Especially if some components are worked by one person only. Each component should imho ideally have at least 2 people, so knowledge is shared.
I think PRs can be trimmed - focus on architecture/design PRs. Not necessarily bug hunting, and especially not nit picking. In early stage of project bug-free may be really less important. This is what I have seen in my current (soon past) project.
That is most dangerous, I would highly discourage. Lack of tests will soon start slowing down dramatically. Its against speed.
Generally, this is what I like. Especially good for early stage projects, and I would also say for middle stages too.
That tells me most however - and in negative way. If you dont know what you do, you probably go in bad direction. Going in bad direction at high speed is not recommended. Architecture/design/direction need to be well thought first.
SawToothKernel@reddit (OP)
I agree with that generally. The main issue for me is the lack of any planning in the initial stages. There's always scope creep, and lots of changes of direction during a project.
To be honest, the rest of it I can deal with - I can at least make sure my own code is well thought-out and mostly bug free. But the lack of alignment eats away at me.
Gloomy_Actuary6283@reddit
And lack of planning is the most dangerous mistake. If this does not change, its probably going to be a failure. I would try to escalate this up in management.
Other than that, I think you can reach out to other team members. I cant imagine other devs to not agree with you in this situation. With larger front, you have bigger voice, right?
Twizzeld@reddit
How long has this team been working together? That has a big impact on how I would perceive this situation.
I worked with the same team for almost 10 years. In the second half of that time, we got so good at working together that the environment became very similar to what the OP is describing. • Planning was semi-informal. We talked about the end goal, handed out assignments, and just got to it. I knew what my co-workers would want, and they knew what to expect from me. • Reviews and PRs weren’t rubber-stamped, but they were very quick. I knew what to look for with each person. I understood their strengths and weaknesses. On top of that, everyone was great at their job, so most mistakes were trivial. • We wrote tests for critical areas and skipped the rest. Despite the claims, we never had any major bug issues.
It sounds to me like your team is experienced and works well together. It might seem like chaos on the surface right now, but give it time — it’ll make sense once you’ve been there a while.
Also, it sounds like you’re actually using an Agile philosophy: go fast, remove anything that slows you down, fail quickly, and iterate constantly.
SawToothKernel@reddit (OP)
Insightful comment.
3/4 of the team have been working together for a while - they are the core. And it's clear they have a chemistry, and it's worked.
I would describe it as "Extreme Agile".
My issue, I suppose is that the feature and team is growing, and we're now spread in several timezones, which hurts alignment. I think Extreme Agile works only if you're all on exactly the same wavelength. Maybe we'll achieve that.
Euphoric-Neon-2054@reddit
Sounds very amateurish.
MonochromeDinosaur@reddit
This sounds fun. You get paid to literally not have to do any of the usual slog.
Testing, code reviews, etc. are all good practices but they’re also a slog at the end of the day.
They’re giving you free reign to not do it and still get paid. That’s an ideal scenario, pump out code, eventually change jobs, profit.
Lopsided_Judge_5921@reddit
I like the first and last bullet point but he middle two are a joke. I'd start to push back on that as it's eventually going to backfire
SawToothKernel@reddit (OP)
For me it's the first bullet point that's the problem. I don't feel aligned with the team or the boss, so this free-form process is a struggle.
leftsaidtim@reddit
“Team is prioritizing velocity”
“We are discouraged from writing tests”
These two statements are at odds with each other.
bulbishNYC@reddit
This sounds like the non-technical boss anti pattern. The engineering boss doesn’t understand tech, dismisses it, performance is accessed by number of visible UX delivered, and nobody has any motivation to do the thankless and risky job of touching the growing pile of tech debt.
d4lv1k@reddit
No PR reviews and no tests. Are you sure you want to be with that kind of team? It seems like the boss is hell-bent on making crappy software.
NeckBeard137@reddit
Sounds like a start-up. It's up to you if you want to be there or not.
SawToothKernel@reddit (OP)
Unfortunately I'm essentially trapped here because of how lucrative it is. The stock price means that I'm essentially on about 300k, which is 3x more than I can reasonably expect elsewhere.
bonnydoe@reddit
Sounds like the big socials: just throw it online and see what happens.
I like the idea of throwing it live to see if the new feature has any use and appeal at all. Finetune later when it is liked by the users.
JaneGoodallVS@reddit
Do you guys need to get to market fast?
Tests accelerate development but I've absolutely worked with people whose code reviews are a net negative.
I'd take rubber stamps over death by a thousands nits any time.
james__jam@reddit
Sounds like a great place for fraud! 😅 may i recommend a js miner that runs on your clients’ browsers my good sir 😊
Ciff_@reddit
Needs info, is this R&D or initial startup phase the this is ideal.
Is this in any way a somewhat stable long term product it is an absolute NO - your velocity will be CATASTROPIC within the year and incident increase.
SawToothKernel@reddit (OP)
It's a long term product, about 1 year old, individual feature within a much larger application.
Ciff_@reddit
Then it is likely time for the team to transition into another phase / mindset focusing on mid to long term velocity.
However you still mention very hypothesis experimental driven development where you throw stuff at the wall to see what sticks. If this is the case, is it really somewhat stable? Or are yours till exploring what the product will become?
Who are your customers, stakeholders, business etc etc
SawToothKernel@reddit (OP)
I'm fairly new to the team, so still finding my feet here, but the boss has a lot of experience in this domain, and so lots of this is well-trodden ground. Although of course we're doing a lot with integrating AI, so there's "novel" stuff there.
Ciff_@reddit
I think if there is a decent sized growing user base it is time to focus on the mid/long term with all that entails (testing automation, tech debt management, etc). But it sounds like you need to get a better bearing first. Then you can start pointing out the paints of lack of automated regression testing, messy infrastructure, tech debt etc.
eyes-are-fading-blue@reddit
If customers are happy with buggy software, there isn’t any need for change. This approach may in the end slowdown velocity for good, though.
Helpjuice@reddit
This is the classic Facebook/Meta move fast and break things external mentality. Sounds good on paper, but not really due to the technical debt incurred and potential security, performance, and reliability issues being introduced over time.
With so many failures in professional organization this normally ends up in massive issues occurring that could and should been prevented where it is least expensive to do so which is in dev where everything is still able to be a two-way door.
zhouga@reddit
This type of model works when the team itself is great, but those types of teams generally work well in any environment. Some really thrive in this environment specifically.
SideburnsOfDoom@reddit
So poor quality and no tests "in order to move faster".
Lol, good luck with that. I personally wouldn't go near it.
Dziadzios@reddit
Sounds like a mess but fun mess.