Category: Uncategorized

Leadership isn’t a title—it’s a journey. From being led to leading teams, products, and strategy, I’ve experienced four evolving styles of leadership every developer should recognize and grow through.

When people ask me how I learned to lead, I usually pause—not because I don’t know the answer, but because there isn’t just one.

Flying While Building is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Leadership didn’t arrive for me in a tidy promotion or a well-crafted management book. It showed up disguised—as a sprint retrospective, a failed project, a confusing job title, or a lunchroom conversation. If you’ve worked in software long enough, you’ve probably met these forms of leadership too. You just may not have recognized them at the time.

Here’s how I came to recognize four distinct leadership styles—each marking a chapter in my journey from junior developer to technical director.

---

🌀 1. Democratic Leadership — The Power of the Scrum Master

My first real experience of leadership wasn’t mine—it belonged to someone else. I was a developer on a team led by a Scrum Master, and they weren’t the loudest voice in the room. They didn’t manage our code. They managed the space.

This was my introduction to democratic leadership: the kind where the leader speaks last, listens most, and helps the team shape its own direction. These Scrum Masters were like glue—facilitators, not commanders. They helped clients understand that software teams aren’t vending machines. They helped developers understand their own voices mattered. And they helped me realize that leadership isn’t always loud. Often, it’s the quietest person in the room holding everything together.

---

🔥 2. Directive Leadership — The Day No One Was Coming to Save Us

The first time I was given a team, I didn’t realize I was also inheriting a problem. What I thought was a consulting gig turned out to be a full-on delivery engagement—product, people, timeline, all on the line.

The Scrum Master was let go. The client was nervous. And someone had to step up. So I did.

Photo by Ricardo Gomez Angel on Unsplash

I rewrote the backlog, reprioritized the roadmap, coached the developers, talked to the client daily. I became the Scrum Master, the Product Owner, the Tech Lead, the therapist. And in doing so, I learned a form of leadership that many of us encounter without warning: directive leadership born out of necessity.

The lesson? When no one else is coming to fix it, the job is yours—whether it’s in your title or not. Leadership here wasn’t about titles. It was about ownership. And I learned that ownership, when done right, earns trust faster than any process can.

---

🧭 3. Visionary Leadership — From Blank Page to Product

Then came a new job. A new kind of leader. And a new lesson: visionary leadership.

🧭 3. Visionary Leadership — From Blank Page to Product

My manager didn’t just run projects. They imagined them—out of thin air. They talked to users, found pain, and pitched ideas that turned into revenue-generating products. One of those was a tool to automate a regulatory report that used to live in spreadsheets.

This was the first time I saw leadership not just as reaction or coordination—but as creation. The ability to see something invisible, align people around it, and build it into reality. It taught me that vision is empathy plus execution. And visionary leaders don’t just see the future—they build the conditions for others to see it too.

---

🧠 4. Strategic Leadership — Building a Team That Builds Teams

At some point, I stopped writing code every day. My job became shaping the environment, not the feature set. As a Technical Director, I started to see the disconnect: developers were isolated, technologies siloed, and nobody quite knew what it meant to be a developer in our organization.

Photo by Maarten van den Heuvel on Unsplash

So I did something about it.

I started Lunch and Learns to cross-pollinate knowledge. I encouraged developers to speak at conferences to grow visibility and confidence. I used those talks to recruit. And I built a playbook to help new hires find their place faster. This was strategic leadership—plotting a course and building the ecosystem to get there.

The strategy was simple: if we could become the best place for software talent in the nuclear industry, everything else—delivery, recruiting, retention—would follow. And it started by giving our team a shared narrative about who we were, why we built software, and how we grew together.

---

Closing Thoughts: You Won’t Be Told You’re Leading—Until You Already Are

Leadership doesn’t begin with a title. It begins the moment you realize that something needs to happen—and you decide to be the one who makes it happen.

You’ll lead long before you’re called a “lead.” You’ll direct without being a “director.” And if you stay long enough, you’ll look back and realize you’ve lived through every style—democratic, directive, visionary, and strategic.

The only question is: what kind of leader are you becoming next?

---

If you enjoyed this post, consider subscribing to Flying While Building—where we explore the messy, magical middle of software, leadership, and growth.

Overcoming Imposter Syndrome and Finding Your Place in the Digital Arcane Arts as a inter or junior software developer.

“Any sufficiently advanced technology is indistinguishable from magic” – Arthur C. Clarke

During interviews, I used to ask, “What does Software Development mean to you?”.

Flying While Building is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

My thinking at the time was, a good candidate would have known themselves, and what drives them to excel in this field that crosses science, engineering, and philosophy.

Software Development is a very opinionated field, with people filled with experience, jargon, explanations for why a for-loop is better than a recursive function, or vice-versa. Why you should use object-oriented language paradigms over functional programming? Why strongly typed languages are superior to weak types? Why you should do E2E testing, or why Test Driven Development is the only way to do software development.

In such an infinitely deep field, I figured great software developers would have an opinion of what software development meant to them.

But I never got anything but blank stares.

Except one time.

One time, a new intern to the field, responded with:

“Software Development is like Magic”

Magic.

I really had never thought of it like that before.

---

“an extraordinary power or influence seemingly from a supernatural source” – Merriam-Webster Dictionary

or

“the use of means (such as charms or spells) believed to have supernatural power over natural forces”

Software Development is Magic.

This is an important thing for a Software Developer to know when interfacing with users, business stakeholders, new developers and generally anyone who is not a software developer. In their minds, building software is akin to the arcane arts. And if you think about it just a little, to someone with no idea how programming works (and to some degree to those who do), yes, this is mag

To a non-technical, this is what it looks like.

The Apprentice’s Burden: Imposter Syndrome in the Magic Circle

Here’s something they don’t tell you when you’re learning software development: everyone feels like an imposter. Everyone.

That senior developer who seems to know every design pattern? They’re googling basic syntax errors. That architect who designed the system everyone admires? They wake up in cold sweats wondering if they’ve made a terrible mistake. The CTO who speaks confidently about technology strategy? They’re constantly afraid someone will discover they don’t know what they’re talking about.

This feeling – this persistent fear that you’re a fraud about to be exposed – has a name: imposter syndrome. And in software development, it’s practically an occupational hazard.

Why? Because software development truly is like magic, and learning magic is hard. You’re expected to:

• Master arcane languages with mysterious rules and exceptions
• Remember countless incantations (APIs, libraries, frameworks)
• Understand complex systems built by hundreds of other wizards
• Create solutions that seem impossible to non-practitioners
• Keep learning new spells as the old ones become obsolete

No wonder 58% of tech workers report experiencing imposter syndrome. For newcomers, this feeling can be overwhelming. You look at experienced developers conjuring solutions with a few keystrokes, and it seems like they possess powers you’ll never attain.

We all feel this as developers.

The Secret All Master Wizards Know

Let me share something I’ve learned after a decade of building software systems: the magic never fully makes sense to anyone. Not completely. Not all at once.

The difference between experienced developers and beginners isn’t that the experts understand everything – it’s that they’ve become comfortable with not understanding everything.

They’ve learned to:

1. Break down complex problems into manageable pieces
2. Know where to find answers (not memorize every answer)
3. Build mental models that help them navigate uncertainty
4. Recognize patterns they’ve seen before
5. Ask good questions when they’re stuck

The journey from apprentice to master isn’t about eliminating confusion – it’s about getting better at dealing with confusion.

<An image of a progression: a beginner developer looking confused at basic code, then a mid-level developer tackling more complex code with some confidence, and finally a senior developer comfortably navigating very complex systems while still having some question marks – illustrating that confusion never disappears, just gets managed better

The questions just keep piling up

Signs You’re Growing as a Developer (Even When You Don’t Feel Like It)

If you’re new to development, here are some signs you’re making progress, even if imposter syndrome is telling you otherwise:

• You’re starting to recognize patterns in error messages
• You can read code better than you can write it
• You know where to look when something breaks
• You’re developing opinions about tools and approaches
• You can explain a technical concept to someone else
• You’re getting slightly better at estimating how long things will take
• You’re more comfortable saying “I don’t know, but I’ll find out”

These are the real milestones of growth, not whether you’ve memorized the entire JavaScript API or can build a microservice architecture from scratch.

It Gets Better: The Path Forward

If you’re struggling with feeling inadequate as a developer, here’s what you need to know:

The learning curve is steep, but it does flatten. There will come a moment – perhaps six months in, perhaps a year – when things start to click. Problems that once seemed incomprehensible become manageable. Languages that felt foreign start to make sense. This doesn’t mean everything becomes easy, but the proportion of things you can handle increases.

Your understanding is cumulative. Every error you fix, every problem you solve, every concept you grasp – these build on each other. Development knowledge compounds like interest. The first years are the hardest; it gets better from there.

Everyone learns differently. Some developers thrive in bootcamps, others in computer science programs, still others are self-taught. Find the learning style that works for you and embrace it without comparing your journey to others.

The industry needs diverse perspectives. If you’re coming to development from a non-traditional background, you bring valuable insights that can lead to better products. The field needs people who think differently.

Community matters more than competition. Find people you can learn with and from. Ask questions in forums. Attend meetups. Join open source projects. The best developers aren’t lone wizards; they’re part of supportive communities.

A Final Word of Encouragement

Software development might feel like magic at first, but remember – all magicians were once apprentices who dropped their wands, mispronounced spells, and wondered if they’d ever get it right.

The fact that it feels hard isn’t a sign you don’t belong; it’s a sign you’re in the right place, doing the challenging work of growth.

Keep practicing. Keep learning. Keep building.

The magic will come.

---

What was your experience when first learning software development? Did you experience imposter syndrome, and how did you overcome it? Share your story in the comments.

Discover the proven pathway from zero industry contacts to employment—including the secret strategy that helped me transform from an overlooked graduate to a technical director who now hires developer

I went through all 4 years of university blissfully protected from the economic havoc outside. But that protection didn’t extend to finding summer jobs.

When 2012 rolled around, the economy was still recovering. Yet, no one was hiring. For anything.

Does this sound familiar?

No engineering coops, no internships. Even getting a job at a fast food chain was a challenge. How could someone with a fresh university degree not yield a job? I was ready and eager to work and learn more from companies.

Photo by Luismi Sánchez on Unsplash

Here, I learned my first crucial lesson in finding a job and beginning my career:

Your network is your net worth.

Every single time I found a new position, it was because someone with a connection had vouched for me.

Every. Single. Time.

---

The Power of Connections

Photo by Mike Erskine on Unsplash

My first and second coop positions came through a family member who had connections to the company.

My third coop materialized because I was in the classrooms with those professors.

My fourth position happened because I was associated with my university.

Every position after that, including my first full-time job, came through leveraging the connections of someone who had a stronger network than mine. In each scenario, I had paid them back by confirming their legitimacy and strengthening their own connections.

In more than 15 years of working, there was not one position that I applied to “cold” and got.

When Your Network Fails You

After 15 years, finding a job without connections remains the most difficult problem for me to solve. The only advice I can offer with confidence is this:

Is your network working for you? Start there first.

If your network exists but isn’t working as you hoped, I recommend reading “Never Eat Alone” by Keith Ferrazzi.

But what if you’ve reached out to your network, told them you’re looking, and they haven’t been able to help?

Starting From Zero

When I graduated and wanted to enter the software industry, I felt like I had nothing. There were no connections.

But wait—didn’t I just say I used a connection to get my first full-time job?

Photo by Sam Mgrdichian on Unsplash

When I say I had nothing, I really meant I felt like I had nothing to offer. I was applying to hundreds of jobs with no response. In retrospect, now with the experience of a hiring manager, I wouldn’t have hired myself back then either.

Reading my resume from that time, all I had to offer on paper was an Engineering Degree. No interesting relevant projects. No portfolio. No relevant software experience. Just some school class projects.

But what I did next would completely change my story and what I had to offer.

Finding My Way In

The tech landscape was different then. Google was massive, Facebook was huge, but Netflix and Amazon had yet to evolve into behemoths. Tesla was a small car company, and SpaceX was barely on the radar.

Photo by Alex Shutin on Unsplash

But there were hundreds of startups and future unicorns (Airbnb, Shopify, Uber, etc.). They all faced the same problem: in an environment with cheap money and investors looking for the next big thing, every issue became a software problem to solve. With so much money seeking returns, finding enough places to invest was becoming a problem. The demand for developers exceeded the supply. They could not find enough talented software developers.

The issue became so severe that startups emerged just to train software developers to get them ready on day one: 14 weeks, full-time, and at the end, a career fair to match you face-to-face with potential companies.

This I saw as my ticket. An opportunity to prove myself, network with fellow developers, train to become competent as a developer, AND get face time with companies in guaranteed interviews. This was a great deal in my eyes.

---

The Second Lesson: Invest in Yourself

This led me to my second realization:

The journey of self-investment always pays off.

Photo by Dominik Scythe on Unsplash

I have never stopped since. I continually maintain a learning mindset, always trying to find ways to translate books, courses, articles, and experiences into something valuable for myself and others. The journey of self-investment first levels you up and second sends a signal to others that you are a self-sustaining growth machine.

People want to be around those who are growing because they hope that growth will accelerate their own development and benefit their companies and teams.

The self-improvement is the value people seek.

So ask yourself:

• What have you done to improve yourself?
• How are you demonstrating that on your resume and profile?
• Did you get a certificate? Complete a new course?

Watching YouTube videos and taking courses is great, but how are you translating that into value? Did you connect with people in your courses? How did you stand out?

If you can’t stand out in your own class, how can you expect to stand out among thousands of applicants?

If you don’t consider what value you can bring to others, how can they bring value to you?

Finding Your Value

If you don’t think you have anything of value, don’t beat yourself up. We all think we start at zero. But take time to list everything you bring to the table. There is something there.

The journey starts with your network and your own value. 95% of the time, if you focus on these two aspects, you’ll get to where you need to be.

For the other 5%, look at what others are doing. Studying what others have done to reach where you want to go provides an amazing shortcut if you learn from their mistakes and follow their successes. It will give you clarity on where to focus your efforts.

Are you applying to a tech company? Most are probably looking for some kind of Agile training or experience. Would it be worth getting an Agile certificate?

Are you applying to an engineering firm? That Agile certificate is nice, but Six Sigma or Kaizen might be more valuable.

Depending on your focus, you need to see what those in that field have achieved and analyze their trajectories to understand what is reasonable and feasible.

Starting Cold: Building Connections From Scratch

But what if you’re starting completely cold, without any connections?

I recently had a developer reach out asking that exact question: How do you make your profile/resume stand out?

Research Former Coop Students

• Investigate who has previously held coop or intern roles at your target companies
• Explore their LinkedIn profiles or company websites to understand their backgrounds and experiences
• This insight will help you gauge the skills and qualities valued for these positions

However, don’t lose hope! There is one opportunity I believe gives juniors the best chance to stand out.

Stand Out by Contributing to Open Source

The profiles that catch my eye always have something notable—like high-profile projects or companies they’ve worked with. While you might not be able to land an internship at Google, you can still make waves by contributing to open-source projects used by Google or other major players.

Here’s how:

• Identify a programming language or library you use frequently
• Explore the open-source repositories for that language or project
• Look through the issues or feature lists and find ways to contribute your skills

By doing this, you’re not only showcasing your competency but also building a reputation as a reliable contributor in a community. This will help you network with the right people and stand out in a crowded field.

Final Thoughts

Getting noticed isn’t about landing the most glamorous role—it’s about proving your value through consistent effort and genuine interest. By contributing to open-source projects or finding unique opportunities at startups, you’ll set yourself apart from the crowd.

So, take the first step today. Pick a project, dive in, and start building your reputation as someone who delivers. Your network is your net worth, but your self-investment is what makes you worth networking with.

You’ve got this!

---

If you found this post helpful, I’d love for you to share it with your network. And if you haven’t already, consider subscribing to my newsletter for weekly insights, tips, and opportunities tailored to junior talent like yourself.

Together, we can make sure no talented developer goes unnoticed.

Every developer who stays in the industry long enough will eventually face a critical career decision: continue deepening technical expertise or shift toward people leadership.

Once you reach the senior developer level, your career often forks: continue deepening technical expertise as a staff+ engineer or pivot into people management as an engineering manager. This post breaks down what separates those paths — and how to choose the one that aligns with your strengths.

If you are starting your career; reading this will really help you set your vision. When you know where you are going, the fog you see today, just becomes a little clearer.

Photo by Jakub Kriz on Unsplash

Flying While Building is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Upgrade to paid

The Journey to Senior

Recently, I had a conversation with a developer intern who asked a powerful question: “What happens after senior developer?” It’s a question more people in tech should be asking early.

The progression from junior to senior is fairly linear: you begin handling tickets with increasing complexity and urgency, building self-reliance, and eventually contributing to key projects. You become someone others trust to deliver reliably. But eventually, that trajectory hits a junction.

Staff Engineer vs. Engineering Manager: What Happens After Senior?

Photo by Tom Parsons on Unsplash

Beyond Senior: The Critical Fork

But taking on more complex projects, or tickets isn’t the differentiator for the next step. The movement from Senior to the next level typically has two paths. One is the Staff/Principal SDE Route. This is defined by the increase in scope beyond Senior as defined by the company, and is mainly technical in nature. There is a major element of leadership here, in the vein of thought leadership, and technical leadership, but most of the time, this is leadership without (DS) Direct Supports.

The involvement of People Leadership, is the distinguishing factor between the path of the post-Senior SDE, and the Engineering Manager. Asking yourself, if you want to be responsible for the success of the projects your Direct Supports, their growth, their careers, their personal lives. When something urgent happens in their life, can you figure out how to cover for them? Can you work with other disciplines, understand the value of design, product management, marketing, build relationships with them? Can you work with HR, and be an extension of them and represent the needs of the company, and senior management? All this, while being technically as competent as some of your top developers?

Two Distinct Leadership Roles

Photo by Jehyun Sung on Unsplash

What Defines the Staff+ Engineer Path

Staff engineers lead through technical vision. They often:

• Design systems and guide architecture at scale
• Influence technical direction across teams
• Mentor developers but don’t manage them
• Own critical projects end-to-end

They remain deeply technical, often pushing the boundaries of what’s possible in the codebase. Staff+ roles reward expertise, context, and problem-solving over people operations.

What Makes Engineering Management Different

Engineering Managers lead through people and process. They:

• Support the growth and career paths of individual contributors
• Align team efforts with broader business goals
• Handle interpersonal challenges, resourcing, and planning
• Collaborate cross-functionally (e.g., design, product, HR)

You’re expected to protect time, manage morale, and still hold technical context. It’s not about being the best coder; it’s about making everyone else better.

“Many developers who excel at the craft of software development don’t choose the management path precisely because it draws them away from the art. Juggling multiple priorities, managing time, and protecting others’ time can feel overwhelming if your primary passion is coding.”

How to Know You’ve Reached the Fork in Your Career

At some point in your career, if you stay long enough in industry or a company, a few things could happen.

1. Knowledge Leadership: All your mentors have left. You hold the deepest context. All your senior mentors/developers have left the team. Congratulations, you now possess the most context about that team/project. This is leadership in the form of knowledge.
2. Experience Leadership: You advise others what not to do — and have the stories to back it up. You find yourself spending more time telling people not to do something because you feel/know it will be a wrong path, and you have a story to explain it. This is leadership in the form of experience.
3. People Leadership: Teammates seek your input on careers, tech decisions, or interpersonal challenges. People are asking you to talk to your manager to switch projects. Or they are asking you what you think about this other person in the company. They seem to value your opinion about what happens in the company and industry. They seem to be asking you questions about your career, advice on what technologies to work on, and your general thoughts. This is a form of people leadership.

You really can’t avoid one of these three things happening when you stay in any industry or career long enough.The thing you also begin to realize, is there are very few people you can now call upon to help solve your problems.

When This Decision Point Arrives

You’ll know you’ve reached this junction when:

1. Knowledge Leadership: All your senior mentors have left, making you the team’s primary context-holder
2. Experience Leadership: You find yourself guiding others away from problematic paths based on your experience
3. People Leadership: Colleagues seek your opinion about company matters, career advice, or technology choices

How you act, how you operate in this situation is a function of you.

Embracing the Fork in the Road

Photo by Drew Beamer on Unsplash

As your software engineering career matures, the path inevitably splits before you. The choice between technical management as a Staff+ engineer and people management as an Engineering Manager represents more than just a career decision—it reflects your core values and how you wish to contribute to your organization.

The technical path allows you to deepen your craft, leading through expertise and architectural vision. The management path invites you to multiply your impact through others, finding fulfillment in their growth and success. Neither path is inherently superior; they simply channel different strengths and passions.

When you find yourself becoming the knowledge keeper, the voice of experience, or the trusted advisor on your team, recognize these as signals that you’ve reached this critical junction. The question isn’t whether you’ll face this choice—it’s how you’ll respond when it arrives.

Which Tech Career Path Should You Choose?

There is no “better” path — only what’s aligned with your strengths.

• Choose Staff+ if you’re energized by solving complex problems and scaling architecture.
• Choose EM if you find meaning in mentorship, team alignment, and shaping culture.

The best leaders in either path have one thing in common: self-awareness.

Final Thoughts: You Can Pivot Later, But Choose with Intention

These decisions aren’t permanent. You can start in one and explore the other later. What matters is that you’re honest about the kind of impact you want to make.

Choose the path that energises you more than it drains you. And remember — reaching this fork is a signal you’re growing. It means others already see you as a leader, even if you haven’t made it official yet.

What’s your experience with this career fork? Have you chosen one path, or found yourself switching between them?

I’d like to offer each of my subscribers a free 30-minute personal session with me.

Photo by Manasvita S on Unsplash

Hey everyone,

I’d like to offer each of my subscribers a free 30-minute personal session with me.

During this time, I can provide:

• Career guidance customized to your experience level
• Resume review with actionable feedback
• Interview preparation strategy and practice
• Development path recommendations based on your interests
• Potential opportunities to work with me directly on projects that match your skills

Book your slot here: 30Min Conversation

The calendar will only be open for the next two weeks, so don’t wait too long to secure your spot.

resume review

To help me prepare and make our time together most valuable:

• Send your resume to me before our session
• Email me at kevin@trussdigital.co or message me directly on Substack with any specific questions or areas you’d like to focus on
• Share a brief note about where you are in your career journey and what you’re hoping to gain from our conversation

Why I’m Making This Offer

Over these past months, I’ve found myself drawn to write about the everyday challenges we face in software development – from reviewing code effectively, to breaking down complex problems into manageable pieces, to seeing systems holistically rather than getting lost in the details.

What drives me is helping developers at every stage grow more autonomous and confident. Whether you’re a student just getting started, a junior dev navigating your first professional role, or someone leading a team – I’ve appreciated how you’ve engaged with these discussions, especially around job searching and career development.

Thanks Substack AI for generating this….reflecet…..

Taking a 3-Month Break to Build Something Better

To focus on these connections and develop higher quality content, I’ll be taking a 3-month pause from regular publishing. During this time, I’ll be:

1. Reaching out to you personally – Understanding where you are in your career and what challenges you’re facing
2. Redesigning my content approach – Creating more valuable, practical insights based on what you actually need
3. Building deeper connections – Because the best content comes from understanding real problems, not assumptions

This isn’t a sales pitch – it’s an investment in our community. The insights I gain will shape my content, and the advice might just help you take your next step forward.

Sometimes the most valuable thing we can do is pause, listen, and recalibrate our approach. That’s exactly what I’m doing.

I’ll be back in July with content that directly addresses your real challenges and opportunities – more focused, more relevant, and more actionable than ever before.

Talk soon,

Kevin

TL;DR: KISS Principle is still king, maybe even more so in the age of AI. The most difficult problems are people problems, and explaining what is important to business.

The Scaling Trap Every Software Team Falls Into

Every software project I’ve been involved in—from two-person startups to teams at national brands with seemingly unlimited resources—has fallen into the same trap: drastically underestimating the effort involved. Projects consistently go over budget and beyond timelines, regardless of who manages them or how detailed their Gantt charts are.

Why is this? We can land rovers on Mars with pinpoint accuracy, yet we struggle to predict the cost and timeline of software products. This isn’t just bad planning—it reveals fundamental misconceptions about software development.

Why Software Development Defies Prediction

Unlike other engineering disciplines, software development lacks standardized templates. Each software project tackles unique problems with unique data structures for use cases. Even platforms like Shopify require third-party assistance to fully meet user needs. When you have a strong vision, off-the-shelf solutions simply won’t cut it.

Here’s why custom software development remains so challenging:

1. Hyperevolution: Software development methodologies today are vastly different from just 12 months ago. Few engineering disciplines evolve this rapidly.
2. Vision-Execution Gap: Vision holders often lack understanding of software development complexities, while developers struggle to communicate these challenges effectively. This is where Product Management and Design become critical bridges.
3. Deceptive Progress Curve: What appears as rapid advancement in the first few months typically slows dramatically by months 6-10. The same effort yields diminishing returns.
4. No True “Final State”: The product journey doesn’t end with the last feature. User adoption initiates entirely new cycles of support, feedback, and development beyond the initial journey.

Photo by Wyron A on Unsplash

The Alternative: Progressive Scaling

Rather than building for scale from day one, successful teams I’ve worked with have adopted a different approach: planning for scale while building for current needs. This means:

• Building modular systems that can be replaced piece by piece
• Focusing on core functionality first, with clear pathways for expansion
• Creating flexible data models that won’t require painful migrations later
• Implementing monitoring from the beginning to identify bottlenecks early

The Hidden Risk on Everyone’s Mind

FLUX.1’s idea of “The Business Lifeline”

There’s an Excel file in your company right now that’s so important, losing it would cause chaos.

Your team knows it. Your boss knows it. And everyone’s terrified to change it. That fear is justified — but the cost of not replacing legacy spreadsheets is even worse.

Flying While Building is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Real Work Starts Before Code

I’ve seen spreadsheet-to-software migration projects succeed or fail across both startups and enterprises. The biggest difference? Whether teams invest in clarity before they code. This is the unglamorous but essential part of legacy system replacement.

Here’s how we should de-risk this transformation, and significantly increase your chances of success:

Define The Actual Problem You’re Solving

First, be very honest with what we are building and why:

Who is this problem really for?

Who is going to be using this solution regularly?

What specific problem are we solving for them? How is it making their life easier?

These shape the real scope. Miss them, and your operational software upgrade won’t land. Your spreadsheet may have “worked” for years, but it’s likely masking technical debt and process misalignment.

A critical question most teams will skip:

• What happens if we fail?
• Who bears that cost and what is the real impact?
• Will they continue to use spreadsheets, carrying the risk to the next year?

This isn’t about fear – it’s about understanding the true value and urgency of what we’re building. All people part of a project, want to feel a purpose and value knowing what they are working towards, and this clarity give direction.

Validate Your Assumptions

Engage your potential user base early, and validate your proposed solution with them.

Talk to users. Present prototypes. Iterate with wireframes.

This is how you prevent costly mid-build pivots in a spreadsheet-to-software migration.

Bring a technical stakeholder in early to assess feasibility. You’re not building yet—you’re aligning on what’s viable, valuable, and validated.

Try to throw a suggestion of what a potential solution would be to your users. Wireframe, draw, paint and somehow walk through with them how the solution would work. Get feedback, rinse and repeat.

This is all critical work to validate that the solution is correct and on the right track. It’s at this stage, you can pivot, change the approach and the whole solution concept, with minimal cost and time. It’s a much more expensive endeavour to do this when it’s being built.

While working with your user base, consider engaging a potential technical implementation resource. Run the concept and idea by them, sense how feasible and viable the idea is.

Map the Requirements

What are the features you really want from your solution?

Start gathering the real dependencies and features:

• What systems will this new tool integrate with?
• Are there external APIs, databases, or security protocols involved?
• Are there constraints from enterprise platforms or IT teams?

These are common failure points in legacy system replacement efforts. Document now, or get blindsided later.

No project lives in isolation and software projects are notoriously unpredictable when it comes to their dependency integration. What are the features you really want from your solution, and what other solutions does this solution have to work with? Another database? An external API? A email server? An EDMS? What about IT security policies or concerns?

We don’t have to solve how we are going to work with these dependencies, but documenting and collecting as much information as possible about them and what we require from them would be valuable. You don’t want to start solving or building a solution only to find that working with an Enterprise Asset Management solution has a high cost or is undergoing an upgrade.

Taking Action: Your Pre-Development Checklist

Many projects even with a seemingly small scope, can seem low risk. The cost of spending the early part of the project to de-risk, is a lot cheaper than the effects of over budget and overtime when these main items aren’t de-risked.Here is a simple checklist to run through to make sure some major items are taken care of.

Before you reach out to IT or a software development team, take these critical first steps to set your project up for success:

Step 1: Validate Your Assumptions

• Schedule conversations with potential end users
• Document their current pain points and workflows
• Test your solution concept with them
• Get feedback from technical implementers early

Step 2: Define Your Problem Statement

• Who is this solution really for?
• What specific problem are we solving?
• What happens if we fail to solve this?
• What does success look like for all stakeholders?

Step 3: Map Your Requirements

• List all must-have features
• Identify nice-to-have additions
• Document any technical dependencies
• Consider integration requirements

---

That spreadsheet isn’t just storing data — it’s bottlenecking growth. The longer you wait to replace it, the greater the enterprise spreadsheet risk. But with clarity, alignment, and validation, you can replace it without chaos.

Building Strong Dev Teams: Beyond Code Tests and Into Culture, Trust, and Fit

“Every act of creation begins with an act of destruction” – Pablo Picasso.

My standard ‘build a to-do list’ interview process was bringing in the wrong people. It took a missed project milestone for me to realize that I wasn’t just hiring developers—I was building cohesive development teams that would either thrive or collapse based on my leadership.

The secret to exceptional software teams isn’t just who you bring in—it’s creating the right environment for them to thrive. For most of my career, I’ve been either leading or part of software development teams, and what I learned is this: the best teams are made of individually productive developers who are exceptional teammates.

Photo by Verne Ho on Unsplash

The Hiring: Design Your Process Around Reality.

If you’re leading a dev team, one of the most impactful things you can do is refine your developer hiring process. Don’t fall into the trap of generic coding tests—build interviews around the actual engineering work your team does daily.

Are they joining a startup where they’ll need to move fast? A legacy codebase with heavy support and debugging? Or a scaling org where structure matters?

Aligning hiring to real context is critical to managing software teams well.

The point is simple: design your interview around the actual work they’ll be doing.

Real-World Example

I took over a four-year-old project drowning in tech debt. Our interviews had tested for greenfield creativity, but what we needed was code comprehension and stability.

Yet our interview process was the standard ‘build a to-do list app’ take-home assignment. While that wasn’t inherently bad, we were hiring people who were great at building things quickly and creatively—but that’s not what this project needed. Our project was mid-cycle and needed stabilization, not new features.

Photo by Joel Muniz on Unsplash

So I built a code reading test. Why? Because developers were spending 50%+ of their time understanding old systems—not crafting new ones. This shift in the developer hiring process directly improved team fit, delivery, and morale.

A cliche on leadership.

After graduating with my engineering physics degree, I landed my first role: solo developer on a real-time inventory system. I tracked my worth in git commits and pull requests. A decade later, leading software teams at Nuclear Promise X, I measure success through an entirely different lens. The journey between transformed everything I thought I knew about technical leadership.

When I became a lead of leads for the first time, I faced a massive paradox: my accountability for technical success grew exponentially while my time writing code diminished to nearly zero. How could I be more accountable for something I couldn’t directly execute? This challenge forced me to completely rethink how I delivered value as a technical leader.

Looking back, I can see three distinct stages in my leadership journey:

Stage 1: Solo Developer – Learning Leadership Through Code

Photo by Clint McKoy on Unsplash

My first leadership role was as the sole developer building a real-time inventory management system. With minimal senior guidance, I approached it from first principles. This stage taught me foundational engineering leadership skills: self-management, technical decision-making, and end-to-end project ownership.

Stage 2: Team Lead – When Technical Skills Meet People Management

Photo by Camille Minouflet on Unsplash

As the team grew, I transitioned into managing deadlines and stakeholder expectations. I had to explain technical challenges while working with junior developers. My biggest challenge? Learning to communicate what I knew — and what I didn’t. This stage was the bridge from developer to leader.

Stage 3: Technical Director – Creating Value Beyond Code

Photo by Jeremy Bishop on Unsplash

The final evolution was transitioning to full software team management. Instead of writing code, I focused on:

• Building and nurturing autonomous teams
• Developing junior talent
• Creating the right culture and environment for success
• Managing across multiple projects and stakeholders

Now, I coach my leads, help them grow in engineering leadership, and focus on the health of the overall delivery system.

The Complete Technical Leader: Teaching, Communication, and Vision

What I’ve learned is that coding is just one part of successful software. Culture, project management, product strategy — they all matter. Great technical leadership is about building environments where other developers succeed.

I believe being an excellent leader of leaders requires three key elements: being an outstanding teacher, a clear communicator, and a compelling visionary. I’m still working on mastering these skills, but this journey has made me a better software developer and leader, with a much deeper understanding of what it truly takes to build successful software products and teams.

Leadership isn’t a destination – it’s an ongoing evolution of letting go of old responsibilities while taking on new challenges. Each stage requires different skills, but all build upon each other to create a more complete technical leader. And I believe everyone has the capacity to be a great leader.

To thrive as a technical director, I focus on:

• Teaching
• Communicating clearly across technical and non-technical teams
• Creating and sharing product and team vision

From Code to Culture: Your Leadership Journey

Photo by Joseph Greve on Unsplash

Looking back at my transformation from solo developer to technical director, one truth stands clear: technical leadership isn’t about climbing a ladder – it’s about expanding your circle of impact. At each stage, I had to let go of familiar tools to grasp new ones:

As a solo developer, I measured success in commits and features. As a team lead, it was in the growth of others. Now as a technical director, it’s in the strength of the environment we create together.

Where are you in this journey? Perhaps you’re a skilled developer wondering about that first leadership step. Maybe you’re a team lead struggling to balance coding with management. Or you might be facing that daunting leap into pure leadership.

Think about it by identifying your current stage. Then focus on developing the skills that matter most for your next evolution:

• Solo developers: Build your communication and mentoring abilities
• Team leads: Practice delegating and developing others
• Technical directors: Focus on creating environments where teams thrive

Whether you’re just stepping into leadership or deep into software leadership, remember: your value is no longer in code volume — it’s in how well you multiply impact through others.

Your technical skills got you here. Your leadership skills will take you forward.

Most software developers are working to provide value to businesses.

Software development isn’t just about writing elegant code or optimizing database queries. That is the art of development, but software project management has a primary functional objective: Delivering value. And to best deliver value, developers need to clearly understand where they fit in the large scope of the project and product.

After years of leading development teams, I’ve discovered that the best developers think like project managers—whether they realize it or not.

The Hidden Project Manager in Every Developer

Think about the last time you broke down a user story. You probably asked yourself, What’s the scope? What are the dependencies? How long will this take? These aren’t just developer questions—they’re project management for developers fundamentals in disguise.

When you’re reviewing code, planning sprints, or estimating tasks, you’re actually practicing software project management skills. That simple task of creating a user registration form? A skilled developer automatically breaks it down into discrete components: form structure, input validation, data persistence, and error handling. Each piece needs to be planned, scheduled, and executed in sequence.

Communication: The Make-or-Break Skill

I learned this lesson the hard way during an agriculture project with multiple stakeholders. We had great developers and solid code, but without clear communication about timelines and progress, we nearly failed. The technical execution was flawless, but developer communication skills were missing.

Here’s what successful developers do differently: They proactively communicate progress, flag potential delays early, and ensure dependencies are clearly understood by everyone involved. They don’t just update their JIRA tickets—they make sure their updates are meaningful to both technical and non-technical stakeholders.

The Developer’s Project Management Toolkit

Every developer already uses project management tools without realizing it. Code reviews? That’s quality assurance. Sprint planning? Resource allocation. Task queues? Dependency management.

To leverage these skills more effectively:

• Break down large tasks into smaller, measurable units
• Document dependencies explicitly
• Keep your task board updated in real-time
• Communicate blockers immediately
• Plan for the unexpected with buffer time

These practices improve developer productivity and make projects more resilient to delays.

Scaling Up: From Solo Developer to Team Lead

As you grow in your career, task estimation and resource planning become increasingly crucial. In my first lead position, I quickly realized that technical expertise alone wasn’t enough. Success required understanding timeline planning, developer capacity, and stakeholder management.

The key is to start small. Begin by improving your own time estimation accuracy and task breakdowns. Then gradually expand to team-level planning and coordination. Keep a log of your estimates versus actual completion times—this data is gold for future planning.

Bridging the Gap Between Development and Management

The most effective teams blur the line between development and project management for developers.

To implement this in your team:

• Volunteer for planning and coordination roles
• Shadow your project managers during stakeholder meetings
• Practice breaking down complex features into manageable tasks
• Learn to translate technical challenges into business impact

Remember: You don’t have to choose between being a great developer and a great project manager. The best developers are both.