Personal Blog | Critiques, Movements & Advice
I began this website because no one educates technical leadership in school. Yet it’s the thing that determines whether brilliant ideas ever launch. Over a decade managing distributed engineering teams taught me the difference between a senior developer and an effective leader is stuffed with uncomfortable conversations, architectural trade-offs, and the quiet work of unblocking other people. This blog is my lab for dissecting those moments. I assess frameworks, books, and tools I’ve actually employed, follow how leadership conversations are evolving, and offer advice ripped 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.
FAQ
How frequently should I publish on a technical leadership blog?
I strive for one substantial post every three weeks. Consistency matters more than frequency. A well-researched article that reflects a real leadership problem will benefit your portfolio for years; rushed weekly posts hardly ever age as well. I set aside a half-day every other Friday for drafting and editing. If your schedule is erratic, create a backlog of outlines so you can draft when inspiration strikes but publish on a regular cadence. Readers will excuse gaps if the level stays high.
What indicators should I monitor for a leadership portfolio?
I monitor three core metrics: reader engagement through reflective replies or emails, inbound chances like speaking requests or consulting prospects, and my own learning retention. Page views and social shares are vanity metrics for a focused leadership blog. I care far more about whether a post initiated a significant conversation with another engineering director or helped me refine my own thinking. Once a quarter, I evaluate which articles created the most valuable connections and double down on those topics.
Is it possible to include team projects without violating confidentiality?
Yes, but you have to anonymize aggressively and center on your own decisions and lessons learned. 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 considered. I also request former managers or peers to check sensitive drafts before I publish. When in doubt, abstract the scenario enough that it could work for any engineering team facing a similar challenge.
What is the way to find my individual voice as a technical leader?
Your voice develops from writing about what genuinely intrigues or irritates you. I discovered mine by drafting post-mortems of my worst leadership moments and spotting 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. Read your drafts aloud and remove any sentence that sounds like corporate jargon. Authenticity is a skill you develop through repeated practice and feedback from trusted readers.
Is a personal blog still useful when LinkedIn and Twitter exist?
Absolutely. Social platforms control distribution and can remove your content at any time. A personal blog is your enduring home on the web, fully under your control. I use LinkedIn and Twitter to share excerpts and start conversations, but the canonical version resides on my domain. This also supports with search visibility over the long term. When a hiring manager looks up your name years from now, a well-maintained blog offers a depth of insight that no social media profile can compete with.
What constitutes the biggest mistake new leadership bloggers commit?
Writing for an imaginary audience of famous CTOs instead of their actual peers. That results to abstract, generic content that helps nobody. The best posts emerge from solving a specific problem you dealt with this month and documenting it for someone one step behind you. I also notice bloggers abandon their sites after three posts because they anticipate immediate traction. Building a readership in a niche like technical leadership requires eighteen to twenty-four months of consistent, useful writing. Approach it as a long-term investment in your own thinking, and the audience will follow.
My Approach to Reviews of Resources, Books, and Frameworks
I evaluate resources the same way I review a pull request: context, trade-offs, and evidence. Before I publish 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 fell short, and the specific problems it fixed or created. That hands-on commitment means I release fewer reviews than most aggregator sites, but each one carries the weight of real operational experience. I also disclose any vendor relationship, though I’ve never accepted payment for a review. The trust of this audience is worth far more than a one-time sponsorship fee.
When I assess a leadership book, I look for actionable models I can test with my team within a sprint cycle. I’m less drawn in inspirational biographies and more drawn to works like Will Larson’s “An Elegant Puzzle” or Camille Fournier’s “The Manager’s Path” that offer me frameworks I can adapt. My reviews break down which chapters apply to first-time managers and which are more appropriate for seasoned directors, because a blanket recommendation aids nobody. I also point out where a book’s advice breaks down in remote-first or heavily regulated environments, conditions prevalent in the Canadian tech scene I function in.
Frameworks like OKRs, Shape Up, or the RACI matrix get the same treatment. I outline the original intent, then walk through a case study from my own work where I used the framework and measured the result. I’m transparent about failures. One post on Objectives and Key Results outlines how setting hyper-aggressive key results demoralized a team and caused 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 maintain myself to every time I post.
Building a Portfolio That Reflects Your Leadership Journey
Picking the Right Platform and Format
I tested several platforms before settling on a static site generator that offers me full control over content structure and performance. Medium provided discoverability but diminished my brand and placed 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 enables me to own my content, optimize for accessibility, and integrate with analytics I trust. For Canadian readers who care about data sovereignty, I recommend hosting on a provider with servers in Montreal or Toronto to keep latency low and meet local privacy expectations.
Format plays a role 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 helps readers know what to expect and turns my portfolio feel like a coherent body of work, not a random assortment of thoughts. If you’re starting 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 showcase your ability to impact, not just your commit history https://moczydlowski.net/. I include redacted strategy memos, incident post-mortems, and slides from internal tech talks that demonstrate 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 signal that I see leadership as a holistic practice spanning people, process, and technology. When I review portfolios of candidates for staff-plus roles, I look 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 shows 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.
Why I Created a Technical Leadership Portfolio in Public
When I first thought about documenting my leadership journey, the natural urge was to keep everything in a private notebook. I worried public reflection might seem like self-promotion or reveal gaps in my thinking. What flipped the switch was a brutal project retrospective where I realized my team had zero visibility into the reasoning behind several architectural pivots. I started writing to close that information gap, and the blog soon 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 enhanced my internal practices more than any closed-door review ever did.
A public portfolio also serves as a credibility signal a résumé can’t replicate. Hiring managers and future collaborators can see how I handle ambiguity, navigate conflict, and grow from mistakes over years, not bullet points. Senior engineers have reached out after reading a post on incident management, and those conversations turned 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 connected me with a community of practice I didn’t know existed. Comments and emails from technical leaders in Canada and abroad tested 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 treat 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.
The Changing Landscape of Engineering Leadership Content
The Growth of Story-Driven Engineering Blogs
Half a decade ago, most engineering leadership blogs felt like extended documentation: plain recaps of tech choices with minimal human context. I have observed a notable move toward narrative-driven content that delves into the chaotic, emotional reality of leading technical teams. Writers now reveal the exact Slack messages that preceded a tough call, the burnout signals they overlooked, the stakeholder failures that delayed a launch. That vulnerability connects because it mirrors what leaders actually go through at two in the morning. I lean into this trend by structuring my reviews and advice around specific stories, never general rules alone. Readers tell me they recall the anecdote about a failed database migration long after they lose track of any list of best practices.
The narrative approach also closes the gap between technical and non-technical audiences. When I walk through how I worked out a deadline extension with a product VP, I incorporate the data I gathered, the emotional undercurrents in the room, and the compromise we reached. That level of detail offers aspiring leaders a mental model they can adjust, not just a slogan like “communicate proactively.” I have noticed this style embraced by engineering directors at Shopify and senior architects at Canadian fintech firms, which suggests to me the trend is evolving into table stakes rather than a differentiator.
Video and Podcast Consumption Patterns
Even though I’m committed to long-form writing, I can’t disregard how technical leaders are consuming more content through podcasts and short-form video. My own reader surveys reveal over forty percent of my audience listens to leadership discussions during commutes or while doing chores. That pattern has shifted what I choose to cover in text versus what I could investigate 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 transformed for 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 holds the same substance as a four-hundred-word article, padded 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 wish to soak up the cultural norms of a specific engineering org, a candid podcast interview could be more useful. I use that same lens when I evaluate external resources, always questioning whether the medium aids or hinders the transfer of actionable knowledge.
Sorting Quality Insights within a Content-Saturated Market
The avalanche of leadership advice circulating is staggering. I’ve developed a personal triage system I use with coaching clients. First, I examine the author’s operational recency: have they led a team in the last three years, or are they drawing on experience from a fundamentally different era of software development? Second, I hunt for specific failure stories. Anyone can speak about how great culture helped them succeed; far fewer reveal the time they mismanaged a layoff or launched a feature that lost money. Those moments of vulnerability are clear signals of substance.
I also cross-reference advice against the context where it was generated. A scaling strategy that functioned 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 notice too many leaders implement practices that are outstanding in one environment and destructive in another. My rule of thumb: rely on frameworks that honestly state their boundary conditions, and mistrust 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 adopt a major process change or propose a tool, I check with them. Their pushback has shielded me from chasing shiny objects more times than I can count. I motivate readers to build 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 neglect it once we move beyond individual contributor roles.
Actionable Advice for New Technical Leaders
From Maker to Multiplier
The toughest transition I made was changing my identity from the person who writes the cleverest code to the person who helps ten others to write great code. That demands redefining your relationship with technical depth. You still need to grasp the architecture deeply enough to pose sharp questions, but you have to resist the urge to fix every problem yourself. I started setting aside two hours every morning for code review and design discussions, then purposely shut my IDE for the rest of the day. That habit felt like withdrawal at first, but it pushed me to invest in documentation, pairing, and clearer acceptance criteria so the team could progress without me.
I also had to understand that my technical opinions were now baselines for discussion, not final edicts. Early on, I’d outline a solution and assume the team to implement it. That approach generated compliant engineers, not engaged ones. Now I frame problems as a set of constraints and trade-offs, then invite the team to propose approaches. This shift doesn’t merely creates better solutions but strengthens architectural decision-making muscle across the whole group. If you’re moving into a tech lead role this quarter, start adopting this phrase: “I have a hypothesis, but I want to hear your take first.”
Communicating Technical Decisions to Non-Technical Stakeholders
I’ve watched promising technical leaders halt their careers because they were unable to convert a database migration into business impact. My advice: always start with the outcome, not the mechanism. Instead of stating “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 keep a running document of every major decision, structured as context, options considered, trade-offs, and expected impact. That record becomes essential 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 began tracking how much engineering time our internal tools saved each month and shared that data in quarterly business reviews. That one practice changed the perception of our team from a cost center to a strategic enabler. You don’t need an MBA, but you do need to connect your technical roadmap to the numbers your CFO cares about. This skill alone can accelerate your path to director-level roles.