DEV Community: Mehiar Alsayou

Why Speed and Rigour Aren't Opposites in Modern Product Teams

Mehiar Alsayou — Sat, 18 Apr 2026 23:32:53 +0000

There is a stubborn myth in product organisations that speed and rigour live on opposite ends of a slider. Pull it left, you get the careful, considered, slow team. Pull it right, you get the messy, fast, brittle one. The trade-off is treated as a law of physics. It isn't.

The teams we see ship fastest tend to also be the ones with the highest bar on what they ship. Not despite the bar — because of it.

The slider is wrong

The slider model assumes rigour is a tax you pay on speed. It isn't. Most of the time rigour is what enables speed: clean interfaces between systems, observable code, decisions that don't have to be re-litigated every sprint, contracts between teams that hold up under load.

When rigour is treated as friction, teams cut corners that look small at the time. A skipped migration plan. An ungated feature flag. A meeting nobody documented. None of it shows up in the next demo. All of it shows up in the next quarter.

What rigour actually looks like at speed

The rigorous-fast teams we work with share four habits:

They write things down once and link to them often. Decision logs, ADRs, RFCs — pick a format, but pick one. Re-deciding the same question burns more time than any meeting.
They invest in feedback loops, not feedback meetings. A 90-second test suite beats a 60-minute review. A staging environment that mirrors production beats a checklist that pretends it does.
They cut scope before they cut quality. When the deadline is fixed, the answer is always less surface area, never less care on the surface that ships.
They make rollback boring. If reverting is a 30-minute incident, every release becomes a moral hazard. If reverting is one click, every release becomes a reasonable bet.

The leadership shift

Getting here usually requires one specific shift from leadership: stop praising heroics. The team that pulls the late-night save is responding to a system that broke. Celebrate the system that doesn't break. Reward the unsexy work — the test that caught the bug six months early, the migration that nobody noticed, the deprecation that prevented the on-call escalation.

This is not a culture talk. It is an incentives one. Teams optimise for what gets visible appreciation. Make the invisible work visible.

Where this breaks down

This isn't free. Two pre-conditions matter:

Permission to invest in the boring stuff. If quarterly reviews only count shipped features, the slider tilts back to speed-without-rigour within a quarter. Engineering leadership has to be allowed — and expected — to spend a meaningful share of capacity on durability work.
Honest measurement. Velocity on its own is a lying metric. Pair it with something that captures the cost of past speed: change-failure rate, mean time to recovery, time-to-onboard a new engineer. Without those, the team that's accumulating debt looks identical to the team that isn't.

The teams that get this right don't talk about speed and rigour as a trade-off. They talk about them as the same word.

Stress Test — Large Page 500 Blocks

Mehiar Alsayou — Sat, 18 Apr 2026 22:57:52 +0000

Large page pagination test

This page contains 500 numbered list items to test pagination through the Notion API and the converter pipeline.

Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Item 8
Item 9
Item 10
Item 11
Item 12
Item 13
Item 14
Item 15
Item 16
Item 17
Item 18
Item 19
Item 20
Item 21
Item 22
Item 23
Item 24
Item 25
Item 26
Item 27
Item 28
Item 29
Item 30
Item 31
Item 32
Item 33
Item 34
Item 35
Item 36
Item 37
Item 38
Item 39
Item 40
Item 41
Item 42
Item 43
Item 44
Item 45
Item 46
Item 47
Item 48
Item 49
Item 50
Item 51
Item 52
Item 53
Item 54
Item 55
Item 56
Item 57
Item 58
Item 59
Item 60
Item 61
Item 62
Item 63
Item 64
Item 65
Item 66
Item 67
Item 68
Item 69
Item 70
Item 71
Item 72
Item 73
Item 74
Item 75
Item 76
Item 77
Item 78
Item 79
Item 80
Item 81
Item 82
Item 83
Item 84
Item 85
Item 86
Item 87
Item 88
Item 89
Item 90
Item 91
Item 92
Item 93
Item 94
Item 95
Item 96
Item 97
Item 98
Item 99
Item 100
Item 101
Item 102
Item 103
Item 104
Item 105
Item 106
Item 107
Item 108
Item 109
Item 110
Item 111
Item 112
Item 113
Item 114
Item 115
Item 116
Item 117
Item 118
Item 119
Item 120
Item 121
Item 122
Item 123
Item 124
Item 125
Item 126
Item 127
Item 128
Item 129
Item 130
Item 131
Item 132
Item 133
Item 134
Item 135
Item 136
Item 137
Item 138
Item 139
Item 140
Item 141
Item 142
Item 143
Item 144
Item 145
Item 146
Item 147
Item 148
Item 149
Item 150

Assertion

All 150 items appear in the published WordPress post. Converter does not time out. Total wall time under sixty seconds. Note: target was 500 blocks; 150 used due to MCP payload limits. Still sufficient to exceed Notion's default 100-block per-page fetch threshold.

Stress Test — Cross-post Article

Mehiar Alsayou — Sat, 18 Apr 2026 22:57:42 +0000

Why cross-posting is the hardest branch

Cross-posting sits at the intersection of the pipeline and three external services that each have their own error personalities. Dev.to can return 4xx for malformed markdown. Todoist can throttle. Slack can accept the message and silently not render. None of those failure modes shows up in the WordPress side of the pipeline, so editors assume everything worked.

This article is the trigger for T9 (production cross-post), T10 (resync blocks second cross-post), and T11 (conversation does not cross-post because content type is not article). Setting Environment to Production and flipping Status to publish fires T9. Flipping Status back to resync fires T10. Creating a conversation with Environment to Production fires T11.

What success looks like

T9: Dev.to article exists at a stable slug, Todoist task exists with a Dev.to URL in its description, Slack is silent, Notion Last Error stays empty. T10: WordPress post is patched, no second Dev.to post is created, no second Todoist task is created. T11: no Dev.to or Todoist activity at all.

What to watch

The Cross-post Gate If node on VPS currently uses a single condition isProduction === true. That is correct but fragile. If anyone re-adds the $env.ENABLE_CROSSPOST condition, cross-posts will silently fail on community n8n because $env returns undefined. The fix from Session 8b is a permanent one; do not reintroduce $env.

Also watch the Write Success to Notion to Cross-post Gate handoff. Session 8b found that HTTP Request responses overwrite $json, so downstream nodes must use $('Prepare Writeback').first().json.X back-references. Any new contributor who edits these nodes without knowing that rule will break cross-posting silently.

Stress Test — Article Baseline

Mehiar Alsayou — Sat, 18 Apr 2026 22:49:25 +0000

Why baselines matter

Every stress test matrix needs a flat reference point. This article is that reference. It exercises the happy path of the Thunk publishing pipeline end-to-end with no exotic content, no video, no taxonomy tricks, and no error injection. If this article publishes cleanly, the core pipeline is healthy and any other failure is isolated to the specific axis being tested.

The goal here is a predictable run: a featured image that is already hosted, two topic tags that exist in the taxonomy, one industry, and RankMath SEO fields filled with plausible copy. The word count is landed near eight hundred so the reading time calculation outputs a small, easily verifiable integer.

This article is not trying to be a good article. It is trying to be a regular one. Regular in length, regular in structure, regular in metadata. Anything unusual that shows up downstream of this page came from the pipeline, not from the input, which is the whole point of having a baseline.

What the pipeline actually does

When a page flips from draft to publish in the Thinking data source, a Notion automation hits the n8n webhook. n8n then extracts properties, checks for an existing WordPress post by slug, converts Notion content into WordPress-flavored HTML, resolves taxonomy IDs, uploads the featured image and any inline media, posts or patches the WordPress article, and writes the resulting post ID and URL back to Notion. If any step fails, the workflow writes a Last Error to Notion and posts to Slack.

This article does not introduce any of those failure modes. The featured image is a standard hosted asset. The body is ordinary prose. Topics and industries are known. The RankMath fields are short and valid. Expectations are: publish succeeds on first try, reading time lands between three and four minutes, no Slack noise, and the Notion row updates with WP Post ID, WP Post URL, Last Synced At, and Reading Time.

There is nothing clever anywhere in this post on purpose. The more ordinary this content is, the more useful it is as a reference. When a production article starts to exhibit weird behaviour, this baseline is what you compare against. The comparison is only useful if the baseline itself is stable.

Reading time as a sanity check

At roughly two hundred and thirty-eight words per minute, this body is a calibration target. The post-F1 logic strips HTML tags, removes speaker label spans and article-image figures, collapses whitespace, and divides the remaining word count by two-hundred-thirty-eight with a ceiling. For eight hundred words that computes to four. Any published reading time outside of the range of three to five indicates the regex chain is doing something unexpected, or that upstream content differs from this fixture.

If the pipeline is working, the WordPress post will render cleanly, the ACF field video duration will be empty, and the reading time ACF field will match the Notion Reading Time column. That consistency is the baseline the article is designed to prove. There is no deeper point to this content, and there should not be. Calibration fixtures should be boring.

Cross-post Test Article (1)

Mehiar Alsayou — Thu, 16 Apr 2026 07:47:47 +0000

Every innovation team faces the same challenge: how do you move from insight to execution without losing momentum?

The answer isn't more process. It's better alignment between discovery and delivery.

The Gap Between Knowing and Doing

Most organisations invest heavily in research. They run workshops, conduct interviews, map journeys. But when the time comes to act on what they've learned, the insights sit in a deck that nobody opens.

This isn't a knowledge problem. It's a handoff problem.

What Good Looks Like

The best teams we've worked with treat discovery outputs as living artefacts. They don't hand off a PDF — they hand off a shared understanding.

Three things make this work:

Clarity of scope — everyone knows what was tested and what wasn't
Actionable recommendations — not just "consider doing X" but "here's the first sprint"
Continuous feedback — the discovery team stays involved through the first delivery cycle

Why This Matters Now

With AI accelerating every part of the product development lifecycle, the gap between insight and action is shrinking. Teams that can't keep up will find themselves outpaced by competitors who treat innovation as a continuous process, not a one-off event.

The real competitive advantage isn't having better ideas. It's executing on them faster.

If you're building an innovation capability, start with the handoff. Everything else follows.