Personal Blog | Reviews, Trends & Advice

I began this website because nobody teaches technical leadership in school https://moczydlowski.net/. Yet it’s the factor that determines whether brilliant ideas ever launch. Over a decade heading distributed engineering teams demonstrated to me the divide between a senior developer and an effective leader is stuffed with uncomfortable conversations, architectural trade-offs, and the quiet work of removing obstacles for other people. This blog is my lab for pulling apart those moments. I evaluate frameworks, books, and tools I’ve actually used, follow how leadership conversations are shifting, and supply advice drawn from real post-mortems. If you’re stepping into a staff-plus role or already holding a team, you’ll find honest, tested perspectives—no recycled advice.

Why I Built a Technical Leadership Portfolio in the Open

When I initially considered documenting my leadership journey, the natural urge was to keep everything in a private notebook. I worried public reflection could appear as self-promotion or reveal gaps in my thinking. What flipped the switch was a brutal project retrospective in which I realized my team had zero visibility into the reasoning behind several architectural pivots. I began writing to close that information gap, and the blog quickly became a forcing function for sharper decision-making. Every post compels me to spell out why a particular path was chosen, what assumptions I held, and how I measured success. That external accountability strengthened my internal practices more than any closed-door review ever did.

A public portfolio also works as a credibility signal a résumé can’t replicate. Hiring managers and future collaborators are able to see how I handle ambiguity, navigate conflict, and grow from mistakes over years, not bullet points. Senior engineers have gotten in touch after reading a post on incident management, and those conversations evolved into consulting engagements. The blog serves as a persistent, searchable record of my leadership philosophy. It filters inbound opportunities because people self-select based on whether they resonate with my approach to technical strategy and team dynamics.

Beyond career benefits, going public brought me with a community of practice I didn’t know existed. Comments and emails from technical leaders in Canada and abroad challenged my assumptions and exposed me to models like the CTO triangle and Team Topologies. Those interactions turned a solitary learning slog into a collaborative one. Now I regard every article as a conversation starter, not a final verdict. That shift alone validates the effort—it holds me humble and constantly learning in a field that punishes standing still.

Hands-on Advice for New Technical Leaders

From Builder to Enabler

The toughest transition I undertook was shifting my identity from the person who writes the cleverest code to the person who enables ten others to write great code. That necessitates rethinking your relationship with technical depth. You still must to understand the architecture deeply enough to pose sharp questions, but you have to overcome the urge to resolve every problem yourself. I began blocking two hours every morning for code review and design discussions, then intentionally shut my IDE for the rest of the day. That discipline felt like withdrawal at first, but it compelled me to engage in documentation, pairing, and clearer acceptance criteria so the team could advance without me.

I also had to understand that my technical opinions were now starting points for discussion, not final edicts. Early on, I’d sketch a solution and assume the team to implement it. That approach yielded compliant engineers, not engaged ones. Now I frame problems as a set of constraints and trade-offs, then encourage the team to suggest approaches. This shift not only produces better solutions but strengthens architectural decision-making muscle across the whole group. If you’re stepping into a tech lead role this quarter, try adopting this phrase: “I have a hypothesis, but I want to hear your take first.”

Explaining Technical Decisions to Non-engineering Stakeholders

I’ve seen promising technical leaders derail their careers because they couldn’t turn a database migration into business impact. My advice: always lead with the outcome, not the mechanism. Instead of phrasing “we need to refactor the authentication service to support OAuth 2.1,” I frame it as “we need to invest two sprints to close a security gap that could block enterprise deals next quarter.” I hold a running document of every major decision, structured as context, options considered, trade-offs, and expected impact. That record becomes priceless during budget reviews and retrospectives.

I also advise learning the basic financial vocabulary of your organization. Understand how your work affects gross margin, churn, or compliance costs. When I led a platform team, I initiated tracking how much engineering time our internal tools saved each month and presented that data in quarterly business reviews. That one practice shifted the perception of our team from a cost center to a strategic enabler. You don’t need an MBA, but you do need to align your technical roadmap to the numbers your CFO cares about. This skill alone can accelerate your path to director-level roles.

My Approach to Reviews of Software, Books, and Frameworks

I evaluate resources the same way I review a pull request: context, trade-offs, and evidence. Before I put out a tool review, I try it in a real project for at least three weeks. I note the onboarding friction, the moments where the docs left me hanging, and the specific problems it addressed or created. That hands-on commitment means I publish fewer reviews than most aggregator sites, but each one carries the weight of real operational experience. I also reveal any vendor relationship, though I’ve never taken payment for a review. The trust of this readership is worth far more than a one-time sponsorship fee.

When I review a leadership book, I look for actionable models I can experiment with with my team within a sprint cycle. I’m less inclined in inspirational biographies and more attracted to works like Will Larson’s “An Elegant Puzzle” or Camille Fournier’s “The Manager’s Path” that offer me frameworks I can modify. My reviews break down which chapters are relevant for first-time managers and which are more suitable for seasoned directors, because a blanket recommendation benefits nobody. I also point out where a book’s advice fails in remote-first or heavily regulated environments, conditions typical in the Canadian tech scene I function in.

Frameworks like OKRs, Shape Up, or the RACI matrix get the same treatment. I describe the original intent, then go through a case study from my own work where I applied the framework and measured the result. I’m honest about failures. One post on Objectives and Key Results details how setting hyper-aggressive key results demoralized a team and resulted in sandbagging in the following quarters. That kind of frank post-mortem distinguishes a useful review from a superficial summary, and it’s the standard I hold myself to every time I post.

Sorting Quality Insights across a Content-Saturated Market

The avalanche of leadership advice circulating is daunting. I’ve developed a personal triage system I use with coaching clients. First, I check the author’s operational recency: have they managed a team in the last three years, or are they relying on experience from a fundamentally different era of software development? Second, I look for specific failure stories. Anyone can talk about how great culture helped them succeed; far fewer reveal the time they mismanaged a layoff or released a feature that lost money. Those moments of vulnerability are clear signals of substance.

I also compare advice against the context where it was produced. A scaling strategy that worked for a hypergrowth startup with unlimited VC funding hardly applies to a bootstrapped Canadian SaaS company with fifteen employees. I call out this context mismatch explicitly in my trend analyses because I see too many leaders adopt practices that are excellent in one environment and harmful in another. My rule of thumb: rely on frameworks that honestly state their boundary conditions, and question any source that offers universal applicability.

Finally, I keep a personal advisory board of three technical leaders I respect who work in different industries. Before I implement a major process change or recommend a tool, I consult with them. Their pushback has protected me from pursuing shiny objects more times than I can count. I motivate readers to cultivate a similar circle, even if it’s just a private Slack channel. Peer review is as vital for leadership decisions as it is for code, yet we often ignore it once we move beyond individual contributor roles.

The Evolving Landscape of Engineering Leadership Content

The Rise of Narrative-Driven Engineering Blogs

Five years ago, most engineering leadership blogs read like extended documentation: plain recaps of tech choices with little human context. I’ve watched a sharp turn toward narrative-driven content that delves into the chaotic, emotional reality of leading technical teams. Writers now share the exact Slack messages that led up to a tough call, the burnout signals they overlooked, the stakeholder failures that delayed a launch. That vulnerability resonates because it echoes what leaders actually go through at two in the morning. I lean into this trend by crafting my reviews and advice around particular narratives, never general rules alone. Readers say to me they remember the anecdote about a failed database migration long after they overlook any list of best practices.

The narrative approach also closes the gap between technical and non-technical audiences. When I walk through how I secured a deadline extension with a product VP, I incorporate the data I gathered, the emotional undercurrents in the room, and the compromise we achieved. That level of detail gives aspiring leaders a mental model they can adjust, not just a slogan like “communicate proactively.” I’ve seen this style adopted by engineering directors at Shopify and senior architects at Canadian fintech firms, which indicates the trend is turning into table stakes rather than a differentiator.

Video and Podcast Viewing Habits

While I’m committed to long-form writing, I can’t disregard how technical leaders are taking in more content through podcasts and short-form video. My own reader surveys indicate over forty percent of my audience follows leadership discussions during commutes or while doing chores. That pattern has changed what I choose to cover in text versus what I may delve into in a companion audio segment. Written reviews shine for deep tool comparisons and architecture decision records; career advice and interview-based trend pieces often gain more attention when adapted to a conversational format. I treat the blog as the canonical source and use other media as discovery channels.

The problem with video-centric leadership content is signal density. A ten-minute video often contains the same substance as a four-hundred-word article, stuffed with intros and b-roll. I urge readers to be mindful about format: if you need to understand how to structure a promotion packet, check out a detailed post; if you want to absorb the cultural norms of a specific engineering org, a candid podcast interview might serve you better. I bring that same lens when I evaluate external resources, always asking whether the medium aids or hinders the transfer of actionable knowledge.

Creating a Portfolio That Captures Your Leadership Journey

Choosing the Right Platform and Format

I tested several platforms before settling on a static site generator that gives me full control over content structure and performance. Medium provided discoverability but diluted my brand and threw paywalls between me and readers. Substack simplified distribution but faltered when I tried to embed diagrams and code snippets. A self-hosted blog running a minimal theme allows me to own my content, optimize for accessibility, and integrate with analytics I trust. For Canadian readers who care about data sovereignty, I advise hosting on a provider with servers in Montreal or Toronto to keep latency low and meet local privacy expectations.

Format matters as much as platform. I arrange every major piece with a clear problem statement, a narrative arc, and actionable takeaways. I use callout blocks for key insights so skimmers can still gain value. Every article includes a “decision log” section when relevant, mirroring the architecture decision records I keep internally. That consistency aids readers know what to expect and renders my portfolio feel like a coherent body of work, not a random assortment of thoughts. If you’re beginning your own leadership blog, pick a format template and stick with it for at least six months before you iterate.

Elements to Feature Beyond Code

A technical leadership portfolio should demonstrate your ability to impact, not just your commit history. I include redacted strategy memos, incident post-mortems, and slides from internal tech talks that show how I communicate complex ideas. I also write about hiring processes I designed, onboarding programs I overhauled, and the mentorship frameworks I use with junior engineers. These artifacts suggest that I see leadership as a holistic practice spanning people, process, and technology. When I review portfolios of candidates for staff-plus roles, I search for evidence of organizational impact, not just personal technical achievement.

I also recommend including a section that tracks your learning in public. I maintain a “currently reading” list with brief notes on what I’m applying from each book. I publish quarterly retrospectives on my own leadership goals, sharing what I aimed to improve and how I measured progress. This practice reveals self-awareness and a growth mindset more convincingly than any list of certifications. It also holds me accountable to continuous improvement, which is the whole point of keeping a portfolio in the first place.

FAQ

How frequently should I publish on a technical leadership blog?

I target one significant post every three weeks. Consistency matters more than rate. A thoroughly researched article that captures a real leadership issue will benefit your portfolio for years; hurried weekly posts seldom age as well. I set aside a half-day every other Friday for composing and editing. If your schedule is unpredictable, create a backlog of outlines so you can write when inspiration arrives but publish on a steady cadence. Readers will overlook gaps if the standard stays high.

What indicators should I monitor for a leadership portfolio?

I measure three core metrics: reader participation through insightful replies or emails, inbound chances like speaking requests or consulting contacts, and my own understanding retention. Page views and social shares are vanity metrics for a niche leadership blog. I value far more about whether a post initiated a significant conversation with another engineering director or aided me sharpen my own thought process. Once a quarter, I assess which articles generated the most significant connections and concentrate on those topics.

Is it possible to include team projects without breaching confidentiality?

Certainly, but you have to anonymize aggressively and focus on your own choices and takeaways. I never identify clients, mention proprietary metrics, or show code snippets from private repositories. I outline the type of system, the constraints we faced, and the trade-offs I weighed. I also have former managers or peers to check sensitive drafts before I release. When in doubt, abstract the scenario enough that it could work for any engineering team facing a similar challenge.

How can I discover my individual voice as a technical leader?

Your voice comes from writing about what genuinely confuses or annoys you. I located mine by composing post-mortems of my worst leadership moments and observing the patterns in my language when I was being completely honest. Steer clear of imitating popular tech influencers; their style worked for their audience and context, not necessarily yours. Go through your drafts aloud and eliminate any sentence that sounds like corporate jargon. Authenticity is a skill you cultivate through repeated practice and feedback from trusted readers.

Does a personal blog remain relevant when LinkedIn and Twitter exist?

Absolutely. Social platforms govern distribution and can remove your content at any time. A personal blog is your permanent home on the web, fully under your control. I use LinkedIn and Twitter to distribute excerpts and start conversations, but the canonical version resides on my domain. This also aids with search visibility over the long term. When a hiring manager googles your name years from now, a well-maintained blog delivers a depth of insight that no social media profile can equal.

What constitutes the biggest mistake new leadership bloggers commit?

Writing for an imaginary audience of famous CTOs instead of their actual peers. That leads to abstract, generic content that helps nobody. The best posts arise from solving a specific problem you encountered this month and documenting it for someone one step behind you. I also see bloggers abandon their sites after three posts because they hope for immediate traction. Building a readership in a niche like technical leadership demands eighteen to twenty-four months of consistent, useful writing. Approach it as a long-term investment in your own thinking, and the audience will arrive.