The hottest Engineering Culture Substack posts right now

And their main takeaways
Category
Top Technology Topics

TBM 398: Micromanagement? Or Staying Close to Reality?

The Beautiful Mess • 674 implied HN points • 28 Dec 25
🕹 Technology Engineering Culture
  1. Leaders should set clear intent and stay close to frontline reality so judgment, not rigid targets, drives decisions. This keeps outcomes directional instead of turning objectives into unforgiving contracts.
  2. Tech companies often celebrate empowerment but fail to build the doctrine, rituals, and training needed to support judgment-based leadership, so autonomy becomes performative. Without those mechanisms, people manage optics instead of sharing real problems early.
  3. Visibility from senior leaders isn’t automatically micromanagement; it feels threatening when there’s no safe escalation, trust, or shared practices. If those conditions are established, direct updates enable more useful conversations and better real-time guidance.

5 engineering dogmas it's time to retire

Leading Developers • 139 implied HN points • 16 Dec 25
🕹 Technology Engineering Culture
  1. Don’t automatically reach for a third‑party package; weigh the security, maintenance, and reliability costs of a dependency against writing and owning the code yourself.
  2. Rigid rules like mandatory reviews for every PR and fixed 2–4 week sprints can slow teams and kill creativity; trust skilled engineers, consider pair programming, and try alternative ways of working that fit your team.
  3. Use feature flags judiciously because they add complexity and testing burden, and don’t be dogmatic about comments—short, clear comments can save future developers a lot of time.

The 'delayed opinions givers' - engineering teams everybody hates

Leading Developers • 70 implied HN points • 02 Dec 25
🕹 Technology Engineering Culture
  1. Prioritize unblocking other teams and put their urgent needs before your own most of the time, because being helpful builds trust and speeds up the whole company.
  2. Don’t give delayed attention — slow reviews and late answers cause wasted developer weeks, messy merges, technical debt, and demoralized engineers, so respond promptly to requests you agree to handle.
  3. Make work visible and set boundaries: use simple trackers so requests don’t get lost, help teams the first few times while teaching them to do better, and escalate or block repeat abusers.

How Capital One supports 14,000 technologists with one pipeline | Ameesh Paleja

Dev Interrupted • 28 implied HN points • 06 Jan 26
🕹 Technology Engineering Culture
  1. Standardizing build and deployment pipelines and automating SRE tasks removes repetitive work so large engineering teams can move like startups and focus on high‑value problems.
  2. AI in 2026 shifts from demos to real procurement: organizations will budget heavily for AI and should prioritize applying models to new workflows while enforcing strong security and governance.
  3. Pausing deploys (like Friday freezes) often increases risk by accumulating untested changes; regular, practiced deployments build resilience and reduce surprise failures.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

🗓 Your invitation to this week's CTO fellow discussion & CQRS stream

🔮 Crafting Tech Teams • 39 implied HN points • 22 Nov 23
🕹 Technology Engineering Culture
  1. The CTO Fellow discussion & CQRS stream is happening this week. Streams are scheduled on Wednesdays and Thursdays at 4pm CET.
  2. Crafting Tech Teams is a reader-supported publication. Consider becoming a free or paid subscriber to receive new posts and support the work.
  3. To access the full post archives, you can start a 7-day free trial by subscribing to Crafting Tech Teams.

Scrum is the Symptom, not the Problem

Rethinking Software • 77 HN points • 07 Aug 24
🕹 Technology Engineering Culture
  1. Scrum is often seen as a bad tool for management, restricting developers' productivity and self-esteem. Many developers feel frustrated, yet companies keep using it because it controls people rather than empowers them.
  2. The main issue isn't Scrum itself, but a bigger problem of control in software companies. Developers often lack genuine power and are seen more as replaceable parts than valuable contributors.
  3. To truly change their working conditions, developers may need to start their own companies or work independently. This way, they can reclaim decision-making power and avoid micromanagement.

Zenful Estimates: Ditching Task Estimates to Build a Faster Team

Dev Interrupted • 51 implied HN points • 14 Mar 24
🕹 Technology Engineering Culture
  1. Engineering task estimates are often costly in time and resources, leading to inaccuracies and increased stress within the team.
  2. Distinguishing between task estimation and project estimation can help teams prioritize better and allocate resources more effectively.
  3. By adopting a 'Zenful' approach that focuses on project estimates rather than granular task estimates, teams can save time, reduce stress, and improve overall efficiency.

From Rockets to Roadmaps: An Engineer's Guide to Product Success

Dev Interrupted • 14 implied HN points • 03 Dec 24
🕹 Technology Engineering Culture
  1. Engineers can drive product vision, leading to faster and more innovative development. This shifts the focus from just coding to solving real business problems.
  2. With AI making coding easier, engineers who understand customer needs and market trends will stand out. Their blend of technical skills and business savvy is crucial for success.
  3. Collaboration and teamwork are key in software development. It's not just about individual contributions but how teams work together to create better solutions.

The Case for Nitpicking

David Reis on Software • 2 HN points • 18 Feb 24
🕹 Technology Engineering Culture
  1. Nitpicking in code reviews can lead to better code quality and a stronger engineering culture. It's important to discuss style and best practices instead of ignoring them.
  2. Good taste in code exists and is based on collective standards among practitioners. Competent programmers can generally agree on what makes code better, like readability and consistency.
  3. Having a style guide helps streamline code reviews and makes discussions less personal. It sets clear expectations and allows for respectful and constructive feedback.

There are two systems. Which one are you working on?

Bad Software Advice • 0 implied HN points • 25 Mar 26
🕹 Technology Engineering Culture
  1. You work on more than just the technical code — the system includes users, support, competitors, and the market, and missing that context can make your work irrelevant, wrongly specified, or badly prioritized.
  2. AI is lowering the cost of development, so developers are shifting from hand-coding everything to managing tools and judging agent outputs, which requires higher-level skills beyond writing code.
  3. Spend time learning the greater system and move up the stack; understanding users, support, and market forces helps you build the right thing and make better tradeoffs.

Blameless Postmortems

Certo Modo • 0 implied HN points • 27 Jan 23
🕹 Technology Engineering Culture
  1. Conduct blameless postmortems to learn from failures and improve system reliability.
  2. Create an environment of psychological safety for teams to openly discuss incident factors.
  3. Moderate postmortems by setting blameless tone, avoiding 'human error' as root cause, and probing underlying failures.

Weekly Notes

Rethinking Software • 0 implied HN points • 16 Sep 24
🕹 Technology Engineering Culture
  1. Software engineering often feels like assembly-line work, where programmers are given tiny tasks with no time for deeper thinking or creativity. This can be frustrating for those who want to tackle bigger projects.
  2. There is a growing idea that people should focus on fewer tasks and prioritize quality over just being busy. This philosophy encourages a more balanced and thoughtful approach to work.
  3. Many people dislike strict management practices like Scrum, feeling they limit creativity and autonomy. They prefer a work environment where they can work freely on projects without constant oversight.

🐿️ Bypassing Technical Debt - The Insanely Profitable Tech Newsletter

Squirrel Squadron Substack • 0 implied HN points • 14 Jan 25
🕹 Technology Engineering Culture
  1. Avoid doing a total rewrite of your software, as it often leads to mistakes. Instead, make small, incremental changes to improve what you have.
  2. Technical debt is a common issue in tech. Learning to manage and refactor it can lead to better software over time.
  3. Just as our bodies have remnants of evolution, software can have old parts that still serve a purpose. It's important to understand their history before trying to remove them.