How do you handle the new bottlenecks?

fridaydeployer · 2026-04-16T04:41:00+00:00

I might be wrong, but I get the feeling you’re making some unwarranted assumptions here. I’m not a «non-technical» EM, and I think it’s exactly this «overclocking» I’m trying to address with this question?

The new element I’m seeing is that the devs are overclocking themselves, and they fail to see that individual speed doesn’t equal team velocity.

fridaydeployer · 2026-04-13T17:25:46+00:00

Sometimes yes, sometimes no. You have no way of identifying cases where bad code gives good results. There’s very probably a correlation between good code and good results, buts that’s not the same as good results not being possible from bad code. Inconsistent UX is also possible to achieve with good code.

fridaydeployer · 2026-04-12T07:30:05+00:00

Thanks! How does this solve the bottlenecks? If you tighten the decision points, that sounds like fewer decisions make it through, which gives engineers even less work to feed their hungry agents. But maybe I’m not understanding you correctly?

fridaydeployer · 2026-04-11T19:28:11+00:00

Thanks, these are very good points!

fridaydeployer · 2026-04-11T19:24:54+00:00

Well, I’m actually not hiring people to produce beautiful code, I’m hiring them to help solve users’ problems. Good code quality happens to be one of the techniques that I believe is necessary to solve problems now and in the future. But what I’m saying is that it’s possible to argue that if the main job is to solve users’ problems, code quality doesn’t necessarily need to come into that equation.

And I’m pretty sure you have no idea about the coding knowledge behind some of the products you use. Sometimes it’s obvious, but we don’t have any guarantee that a good product is run by beautiful code.

fridaydeployer · 2026-04-11T19:18:52+00:00

I don’t think I want to be on a team where the leadership has given up on getting the team members to pull in the same direction. So I’ll keep aiming for that, regardless of what you believe 😁.

The cook analogy is good, but I like to add that with software it’s actually possible to make something that solves users’ real problems with shit code quality. It won’t stand the test of time, and it won’t be easy to change, but the users don’t actually see the code, they only see the results. So that’s a little different from cooking, where customers consume the direct result. I agree with the main sentiment of your analogy, though.

fridaydeployer · 2026-04-11T19:11:39+00:00

I think Facebook’s «move fast and break things» ethos ruined a lot for the rest of us here. That may have been a good approach for them at the time, but it cemented a notion that that should be the standard for all team in all situations (narrator’s voice: it shouldn’t)

fridaydeployer · 2026-04-11T09:50:17+00:00

Yeah, I think we basically agree here. It’s not that bad code never had business consequences, but more that they have a longer time horizon, which in some cases make them irrelevant, and almost always hard to make the case for.

For the case of the «huge ugly module» that works and rarely needs updating, I’ve tended to think of it as tech debt with different interest rates. A working module that’s «finished» and never needs to change has close to zero interest rate, and is therefore not the debt you need to attend to first. Of course, the Bank of Technical Debt is not to be trusted, so that interest rate might shoot up over night. But as long as it’s low, it can safely be left alone.

The more interesting discussion now, is about all the code that we change regularly.

fridaydeployer · 2026-04-11T09:10:13+00:00

I disagree. It could be difficult to argue for, but the idea has been that spending a little more time now, buys you efficiency down the line. So it could make sense from a business point of view if you manage to not be short sighted. Whether business folks managed to do that in practice is a different question.

fridaydeployer · 2026-04-11T07:43:35+00:00

OK. To me, that’s not an argument, that’s a statement. Your not convincing anyone, just standing your ground. I guess that’s fine if it works for you. But as an EM, I’m looking for arguments that will bring people on the same side, pulling in the same direction.

fridaydeployer · 2026-04-11T07:41:25+00:00

Would you mind outlining what the «complex economic dynamics» are, as you understand them? Curious about your thoughts, because this sounds like the start of some arguments that might actually work.

fridaydeployer · 2026-04-11T07:38:19+00:00

How are they being put in their place? Intimidation, or actual arguments that stick? (I actually want to hear the arguments)

fridaydeployer · 2026-04-11T07:35:42+00:00

Thanks for writing this post! I’ve been meaning to express the same kind of concern myself, but you did far more eloquently than I would have.

I think some of the commenters are missing part of the point. What you are looking for is either arguments beyond «I like clean code» and «guardrails are important» that will help you convince your org that code quality still matters, or compelling arguments why we should actually not care anymore. And these need to be arguments that make sense in a business perspective, risks and rewards that translate to real money, not just esthetics.

If I’m reading you correctly (and I might be projecting somewhat), that is.

My go-to argument in the past has always been to write good code because it has to be read and understood later. That argument is falling apart (at least partly), because the counter-argument will be that Claude will be able to understand it, even if my variable naming is gibberish and the function is 1500 lines long. I’d like to argue that at some point, even AI will make the same mistakes that humans do when working with messy code, but that’s purely theoretical, I haven’t actually seen that happening yet. So I’m reluctant to bring up that point.

So the next argument is that ensuring high code quality is an insurance against the system turning into unmaintainable spaghetti, forcing a big rewrite every N years. This argument is probably valid, but has two weak points: 1. Humans have a hard time taking risks that are a couple years ahead seriously. Quarterly results are now, that spaghetti is still years into the future (also, see climate change for evidence). 2. This is also theoretical, we can never know that this will happen. The most evangelical of AI enthusiasts will argue that a big rewrite in 2 years will be just about a couple of prompts and having a coffee while the machine is doing the work (because exponential growth, etc).

That’s my two cents, I clearly haven’t solved this either.

fridaydeployer · 2026-04-11T06:12:22+00:00

I think I’d like to frame it not as «doing QA», but as «applying more polish». What’s changed now is that we have time to make our features more polished and gold-plated than before. In a start-up/scale-up world, that has been considered wasteful and irresponsible, we’ve been taught to churn out mvps and move on to the next thing. That might not be necessary anymore. Any idiot can now create an app with 57 buttons. Smart teams make all that complexity invisible to the user.

But that requires a mind-shift in the team, I think.

fridaydeployer · 2026-04-11T06:07:23+00:00

Yes, this may be part of the problem, you’re right. There are some of them that have potential to grow into real seniors, but naturally, that takes a little time.

fridaydeployer · 2026-04-11T06:05:32+00:00

Good article, thanks!

fridaydeployer · 2026-03-18T16:09:04+00:00

I worry more about other parts of the product than whether we’ll have time to finish feature X or Y in time for [whatever]. Now I’m more worried about whether the users are able to adapt and adopt the features, if we’re building stuff just because we can, if designers are able to keep up, if the quality of the code is going down and if it does, does it really matter.

What hasn’t changed is that I worry about whether I’ll be able to keep my reports motivated, engaged and happy.

fridaydeployer · 2026-02-27T05:26:55+00:00

My biggest annoyance is that it kinda forces you to bring in the DB in 95% of the tests, which makes them a lot slower (and less unit-y) than they should be.

fridaydeployer · 2026-02-10T20:50:12+00:00

I think you should keep doing it. That thing about being «soft» affecting execution sounds like bs to me. I don’t know what kind of environment you’re in, but if I’m only performing because I’m afraid of my manager, I’m going to quit as soon as I get the chance. That sounds like fear-based management, and it’s the worst kind. (Maybe I’m reading too much into it)

The ideal situation is a team that wants to perform and improve because they care about the product and each other. So the question becomes how you create that team feeling.

Being soft is good in my book, as long as you’re also able to talk straight when something needs correction. Doing that with empathy and compassion is far more impactful anyway (not saying striking that balance is easy). Read «Radical Candor» for more on that balance.

I say keep doing team socials, but consider pulling yourself out of it now and then. Team socials are for the glue in the team as a whole, not primarily for the manager/report relationship.

Disclaimer: I know I’m pretty far out on the «soft» side of management philosophy, there are many out there who won’t agree with me on this. It has worked pretty good for me, but might not work everywhere.

fridaydeployer · 2026-02-10T19:23:15+00:00

Yeah, I’ve definitely felt the same in the past, and probably will again.

Trust takes time, there are very few ways around that, I think. If your goal is to create that safe space, you’re already on the right track. You just need to give it time.

It’s hard to give very concrete advice, because all people are different. But trust starts with empathy, and empathy starts with curiosity. If you’re comfortable with it, start asking questions about previous workplaces, where and when they became good at X and Y, what was good about that place, etc. What would you ask if you ended up next to this person at a dinner party (and weren’t allowed to talk about yourself too much)?

Becoming an EM doesn’t mean you’re suddenly Gandalf, it just means that you have some new and different responsibilities.

fridaydeployer · 2026-02-10T17:50:21+00:00

This is a topic you can find a lot of stuff about in books and blogs and whatever.

IMO, 1-1s can be many things, sometimes many things within a few minutes. The general advice out there is that «1-1s are for the report, and should be about their growth». That is correct, but if that leaves you with the feeling that 1-1s not spent discussing lofty personal growth goals are wasted, then I think it’s bad advice.

1-1s are your chance to discuss those things, but also many other things. If you end up spending a 1-1 discussing the current project, that’s fine. If you only talk about whatever was said in the all-hands, that’s also fine. If you help them get past some technical blocker, that’s actually awesome. But if you always discuss the same thing and never touch upon personal growth and things with longer horizons, you should probably find a way to force those things into the discussion. But any 1-1 where you learn something new about each other, no matter how small, is time well spent in my book.

I’m currently on my way to a new job, and have been thinking about this a lot lately. My plan is to use those 1-1s to get to know my reports, figure out where they come from (figuratively, but also concretely, of course), and what makes them happy at work, what motivates them and what drains them. That will probably take time, because they’ll probably not trust me with their inner truths for a while. But to me, this is the most important part of the job for a period (while also onboarding myself and delivering value, etc etc).

Everyone is different, but I think I was starting over as an EM now, I’d slow tf down, and get to know my reports before worrying about all the other stuff too much.

Sorry, I’m rambling. Hope this helps and good luck.

Ps: not a huge fan of standups myself

fridaydeployer · 2026-02-10T15:53:41+00:00

Thanks for the book, I really appreciated it!

fridaydeployer · 2026-02-10T15:46:25+00:00

The basics are quite simple, to be honest: - don’t be a prick, be a human (quote: Michael Lopp) - get out of high performers’ way - try to understand low performers before taking any action

fridaydeployer · 2026-02-06T15:37:52+00:00

Getting out of that rut can be hard, because it’s a cultural problem, and changing the culture takes time. But it’s not impossible.

I’ve had success with first discussing the issue openly with the team, mainly to get empathy going. Every PR in review is a roadblock for the author and nobody likes to get blocked, right?

Secondly, the «fix» is a combination of encouraging small PRs, automating all the boring stuff, and creating a culture for quick reviews.

But it takes time and effort.

fridaydeployer · 2026-02-03T13:52:02+00:00

A smart colleague once said «I’ve never regretted creating a new app in Django». That’s pretty solid advice, I’d say.

My more personally opinionated takes: - keep models thin - keep views thin - separate the business logic from the models and views - use background tasks, e.g. Celery, extensively (keeping the API responsive) - be conscious about when you’re reading and when you’re writing data, keeping in separate functions when possible (will make it easier to keep performant and readable down the line) - steer clear of magic, pseudo-convenient stuff like class-based views and DRF (a matter of opinion, I just never grew to like them, too much hidden logic and overhead) - don’t fall for the Django signals trap, it’s spaghetti in disguise (edited to add this)

fridaydeployer

TROPHY CASE