<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"><channel><title><![CDATA[The Independent Engineer]]></title><description><![CDATA[Helping software engineers grow their careers and turn their expertise into independent businesses.]]></description><link>https://www.independentengineer.co</link><image><url>https://substackcdn.com/image/fetch/$s_!hm-s!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1c7ac820-3260-4c8d-a5cb-488c446d61db_1024x1024.png</url><title>The Independent Engineer</title><link>https://www.independentengineer.co</link></image><generator>Substack</generator><lastBuildDate>Tue, 12 May 2026 15:19:34 GMT</lastBuildDate><atom:link href="https://www.independentengineer.co/feed" rel="self" type="application/rss+xml"/><copyright><![CDATA[Yaroslav Tkachenko]]></copyright><language><![CDATA[en]]></language><webMaster><![CDATA[independentengineer@substack.com]]></webMaster><itunes:owner><itunes:email><![CDATA[independentengineer@substack.com]]></itunes:email><itunes:name><![CDATA[Yaroslav Tkachenko]]></itunes:name></itunes:owner><itunes:author><![CDATA[Yaroslav Tkachenko]]></itunes:author><googleplay:owner><![CDATA[independentengineer@substack.com]]></googleplay:owner><googleplay:email><![CDATA[independentengineer@substack.com]]></googleplay:email><googleplay:author><![CDATA[Yaroslav Tkachenko]]></googleplay:author><itunes:block><![CDATA[Yes]]></itunes:block><item><title><![CDATA[How to Grow Your Network]]></title><description><![CDATA[Learn how software engineers can build a valuable network before going independent by helping others, nurturing work relationships, attending events, and joining communities.]]></description><link>https://www.independentengineer.co/p/how-to-grow-your-network</link><guid isPermaLink="false">https://www.independentengineer.co/p/how-to-grow-your-network</guid><dc:creator><![CDATA[Yaroslav Tkachenko]]></dc:creator><pubDate>Sun, 26 Apr 2026 22:02:04 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/12c77ad6-f916-44b9-baf6-acf7bed3aa3b_2848x1504.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Growing your network is likely one of the most important things you can do before becoming a full-time solopreneur. And yet, many engineers don&#8217;t know how to approach it.</p><p>Having a large network is important for many reasons. In a services/consulting business, your network (and the references you get from it) becomes the source of your contracts. In a product business, it generates users. </p><p>And even if you don&#8217;t become a solopreneur, your network can provide better employment opportunities, so growing it is a no-brainer. </p><h2>What is Network?</h2><p>But what is it, really? Your network is not the number of followers you have. It&#8217;s about people you <em>can reach out to</em>. People who will respond when they hear from you. And, most importantly, people who will help, refer, recommend, try, and offer their time. </p><p>So, how do you get people like these?</p><h2>The Most Important Rule</h2><p>The rule is simple: you need to be able to <em>provide value</em>. It may sound transactional, but it works. </p><p><strong>Agree to provide feedback on a product MVP. Give advice on how to fix a problem. Write a recommendation later. Support someone&#8217;s promotion case. Meet with an intern for a coffee. </strong>And so on. </p><p>You&#8217;ll likely not benefit from it. But you&#8217;re building <em>relationships</em>, not clients. This is a long game to play.</p><p>And always make sure to follow up when you promise something. You want to be remembered as a person who delivers.</p><h2>Ways to Grow</h2><h3>Your Current Job</h3><p>This is the most effective way. People really value coworkers they previously enjoyed working with. Of course, you have to be that coworker. Offer help. Offer feedback. Unblock. Support. Be generous with your time. </p><p>When I worked at Shopify as a Staff Engineer, I had more 1:1s than my manager. Shopify is a really big organization, and I wanted to engage and collaborate with many brilliant engineers. I had three types of 1:1 meetings:</p><ul><li><p>My teammates. In some companies with heavy processes, you may end up talking to your teammates all the time. Especially if you work in the same location. In other places, especially remote, it&#8217;s not always the case. So, make sure you spend enough face-to-face time and genuinely try to be helpful. </p></li><li><p>My mentees. Shopify had an official mentorship program, but I also unofficially started mentoring more junior engineers. Just because I recognized the potential and wanted to help.  </p></li><li><p>My peers. Staff and Senior Staff engineers who were responsible for other parts of the Data Platform. Some were in different departments. I wanted to stay up-to-date on major initiatives (ideally try to influence them), and offer my help in aligning and unblocking major projects.</p></li></ul><p>Some of these relationships really paid out: when I joined the next company as a Founding Engineer, I built my team exclusively from the folks I previously worked with and mentored. </p><p>Also, this might be another reason to switch jobs. I&#8217;m not proposing job hopping, but the math is hard to beat: working in 3 places 3-4 years each will generally grow your network much faster than staying in one place for 10 years.</p><h3>Events</h3><p>Conferences and meetups are really powerful ways to meet people you&#8217;ve never interacted with before. I&#8217;m an introvert, but I still find these events really useful. In retrospect, they made a huge impact on my career. </p><p>And again, many engineers don&#8217;t really know how to properly attend these events if they want to grow their network. </p><p><strong>First of all, you&#8217;re not there to watch talks</strong>. Most conferences nowadays record their talks; they&#8217;ll be available for watching later. There are only a few reasons to spend your time on someone's talk: </p><ul><li><p>The content is extremely relevant for you right now, and you can&#8217;t wait a few weeks for the recordings to be available.</p></li><li><p>You want to support the presenter and engage them after the talk.</p></li><li><p>You&#8217;re planning to write a post about the conference :)</p></li></ul><p>So what do you do instead? You go to the &#8220;hallway track&#8221;: a place where most of the people hang out outside of the talks. Generally, something like an expo hall. </p><p>Start talking to people. Introduce yourself, but don&#8217;t talk about you all the time! You are there to listen. Ask about people&#8217;s challenges. And when you get enough information, offer to help. Offer to try their product. Offer to provide feedback. Offer to go over their problem yourself, or introduce them to someone else who can help. <strong>See The Most Important Rule again - be helpful!</strong></p><p>If you already offer a service (maybe part-time), you can come much more prepared. </p><p>Many fancy conferences these days show attendees in their apps. So, do your homework and analyze them. Find people from relevant companies, write them down. You can even reach out before the event and say something like &#8220;Hey X! I noticed you&#8217;ll be at the event Y in two weeks, and it looks like your company Z does a lot of N. I&#8217;m really curious about your opinion on N, do you think you can find 20 minutes to chat?&#8221; </p><p>If there is no attendee list, you can do the same thing for the speakers. Thankfully, they&#8217;re always public. By the way, try to become one! Identify the list of events you&#8217;d like to speak at and regularly submit proposals. If you get chosen as a speaker, ask your company to sponsor your travel. Being a speaker is a great way to meet a lot of interesting people quickly:</p><ul><li><p>You may get invited to speaker-only dinners/parties. I met Martin Fowler in Budapest at an event like that.</p></li><li><p>You become recognizable on the floor - people will want to meet you. In some cases, they&#8217;ll line up with questions after your talk!</p></li></ul><p>Also, don&#8217;t forget to find time to check in with people you already know! Just a minute with a friendly face goes a long way. </p><h3>Community</h3><p>You can&#8217;t always visit events; travelling can be hard and expensive. But likely, there are people in your community you&#8217;d like to connect with. So, just message them! If they&#8217;re local, offer to meet for a coffee. If not, offer to hang out over a call. It&#8217;s not as creepy as it sounds if you follow <strong>The Most Important</strong> <strong>Rule</strong> - offer to help with something. The worst thing that can happen? They&#8217;ll ghost you.</p><p>Your community can be anywhere: social media, Slack groups, development mailing lists, open-source maintainers, Reddit, etc. </p>]]></content:encoded></item><item><title><![CDATA[The Many Ways Software Engineers Can Go Independent]]></title><description><![CDATA[How software engineers can go independent: consulting, productized services, SaaS, courses, newsletters, and other realistic solopreneur paths.]]></description><link>https://www.independentengineer.co/p/software-engineers-going-independent</link><guid isPermaLink="false">https://www.independentengineer.co/p/software-engineers-going-independent</guid><dc:creator><![CDATA[Yaroslav Tkachenko]]></dc:creator><pubDate>Mon, 20 Apr 2026 17:06:46 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/207e1644-53e9-4f89-a7b4-49b19e57f181_1852x975.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>When I talk about software engineers becoming solopreneurs, it&#8217;s typically interpreted in one of these ways:</p><ul><li><p>You bootstrap a small SaaS or development tool product. </p></li><li><p>You start freelancing. </p></li><li><p>You become a consultant, helping companies in something you deeply specialize in. </p></li></ul><p>But the reality is more diverse (and also messy). There are many more opportunities. Most importantly, you don&#8217;t need to limit yourself to one thing: you can bet on multiple options at the same time.</p><p>I&#8217;m going to try to cover all of the different ways you can go independent. In some cases, the definitions are not fully established yet, but I&#8217;ll do my best to describe them. </p><h2>Services</h2><p>This is where you <strong>sell your time</strong>. Your income directly depends on the amount of time you&#8217;re willing to spend. </p><p>I know <strong>freelancing</strong> immediately comes to mind for many people. Freelancing can mean slightly different things, but I define it as project-based work that doesn&#8217;t necessarily require extensive experience or a particular skillset. Historically (and it&#8217;s probably still the case today), freelancing was a way for companies to&nbsp;<em>save</em>&nbsp;money: instead of hiring someone full-time, just hire a freelancer to deliver a project. It&#8217;s typically a low-engagement activity (it&#8217;s possible you don&#8217;t even talk to a freelancer). I recommend avoiding it if possible. </p><p>Instead, position yourself as a <strong>consultant</strong>. An expert in a certain domain. Unfortunately, it&#8217;s hard to become a consultant at the beginning of your career; first, you need to put in the hours. But as a result, you&#8217;ll be able to sell your services at a rate that&#8217;s <em>higher</em> than that of a full-time employee.</p><p>There are different types of consulting engagements:</p><ul><li><p>Retainers. Typically, you make a commitment for a client to dedicate 10-30 hours a week. You can be pretty embedded in a team (see <strong>fractional</strong> below) or work on solo projects. </p></li><li><p>Project deliverables. You&#8217;re hired to deliver a certain project. The hours can really fluctuate, but they&#8217;re not as important as shipping the final result. </p></li><li><p>Productized services. Similar to project deliverables, but based on what you offer. For example, you may offer a security audit, a performance investigation, or a cloud cost audit. These can be relevant for many different companies.</p></li></ul><p>You may have also heard about roles that start with &#8220;<strong>Fractional</strong>&#8221;: Fractional CTO, Fractional CFO, Fractional Data Architect, Fractional ML Engineer, etc. To me, that generally sounds like a Consultant with a retainer who&#8217;s tightly integrated with the team. </p><div><hr></div><p><a href="https://corrode.dev/">Matthias Endler (Corrode)</a> is a great example of a software engineer turning consultant.</p><h2>Products </h2><p>This is where you <strong>sell your products</strong>. Your income DOES NOT directly depend on the amount of time you&#8217;re willing to spend. </p><p>Historically, during the SaaS boom, many engineers began building small <strong>SaaS products</strong>. It sounds simple: find a niche, build something useful and start monetizing it. The reality can be much more challenging, especially when you&#8217;re bootstrapping it solo.</p><p>In the past few years, I noticed the explosion of <strong>development tooling,</strong> either with <strong>subscription pricing</strong> or <strong>licensing</strong>. Developers can be a tough crowd to sell to, but if you nail the developer experience and build something useful, you can definitely conquer a market segment.</p><p>Another popular way to sell products is through <strong>marketplaces</strong>: custom themes, plugins, etc. I heard about successful businesses specializing in Shopify plugins, for example.</p><div><hr></div><p><a href="https://shadowtraffic.io/">Michael Drogalis (ShadowTraffic)</a> is a great example of a software engineer building a development tool product.</p><h2>Education</h2><p>I decided to make this a separate section, but practically, you end up either <strong>selling your time</strong> (services) or <strong>building an educational resource</strong> (products). My reason to keep it separate: in the case of services or products above, your goal is still software engineering. But here the goal shifts to <strong>teaching others</strong> about software engineering. </p><p>I believe that a straightforward way to start is using the knowledge you gained from building a product or a service. If the product is successful, or your consulting practice has a lot of happy customers, there is a high chance that some things you learned along the way can be useful to others. </p><p>There are a few different types of offerings here:</p><ul><li><p>Training (a service). Can be online or offline. Typically, you work with a team or company. Some amount of customization is possible.</p></li><li><p>Bootcamp (a service). Generally, a public program. Can be a few intense days or 6-8-10 weeks of ~hourly sessions + homework.</p></li><li><p>Online course (a product). On-demand resource. </p></li></ul><p>An important realization: <em>the same content can be used for any of these</em>! </p><p><strong>Mentoring</strong> or <strong>coaching</strong> is another option. It&#8217;s typically done in a 1:1 format, although I&#8217;ve had experience with team mentoring as well. Websites like <a href="https://mentorcruise.com/">MentorCruise</a> can be a good way to start.</p><div><hr></div><p>I&#8217;m going to use myself as an example here: I launched <a href="https://streamacademy.io/">Data Streaming Academy</a> a few months ago.</p><h2>Crowdfunding</h2><p>I&#8217;m still not sure if <strong>crowdfunding</strong> is the right word, but it&#8217;s the best I could come up with. GitHub sponsorships. Patreon subscriptions. Paid newsletters. Paid communities. All of these are also applicable to software engineers. </p><p>GitHub sponsorship is a big one. If you work on a popular project, there is a high chance that many companies (and users) are willing to support you. Starting from scratch can be really challenging, though. </p><p>Paid newsletters really exploded in the last few years (thanks to Substack). I acknowledge that regular writing is not something that every software engineer enjoys doing, but it&#8217;s an important skill to master anyway. Finding the right niche can be tricky: keep your topics very generic and you get a lot of competition, keep your topics hyper-specialized, and you get a very small audience. </p><div><hr></div><p><a href="https://www.pragmaticengineer.com/">Gergely Orosz (The Pragmatic Engineer)</a> is a great example of a software engineer turning newsletter author.</p><h2>Products &gt; Services?</h2><p>Some entrepreneurs position <strong>services</strong> as a level below <strong>products</strong>. I&#8217;ve seen this take: first, you build your skills, network and a strong services business; then you build another level on top of that, and productionize your skills as a product. It can be an educational product, like an online course or a SaaS / development tool product.</p><p>The reasoning here is simple: there are only so many hours in a day, and your income as a solopreneur is limited if you only offer services. And product income doesn&#8217;t <em>directly</em> depend on the number of hours you invest in it. </p><p>But I find products much harder to build. Finding product market fit is hard. Marketing and sales matter much more. In the end, you need to balance income and happiness, and many people prefer to stick to consulting (and other services) because it&#8217;s a somewhat simpler path.</p><h2>Growing a Business</h2><p>It&#8217;s possible to turn almost all the paths I identified in this post into bigger businesses.</p><p>If you have a successful consulting business and strong client demand, you can start hiring employees and dividing the work. Eventually you can focus on the business side of things 100%, if you want.</p><p>Having a strong, profitable product with an established market fit can be a great target for many VC firms. However, not all businesses can be VC-funded: some, by design, don&#8217;t assume rapid growth. </p><h2>Instead of a Summary</h2><p>If you started a consulting business, it doesn&#8217;t mean you can&#8217;t also launch a product. Or vice versa. Building a consulting business with a big network makes it possible to turn some knowledge into an online course or a training. </p><p><strong>There are really no rules here</strong>. Everyone is trying to figure out what they&#8217;re good at and what&#8217;s interesting for others. </p><p>But what I like most about this journey is that you don&#8217;t need to ask for permission. Every day, you just try to figure out the next most important thing to address. Small steps compound over time.</p>]]></content:encoded></item><item><title><![CDATA[(Re)discovering Your Calling]]></title><description><![CDATA[I may have convinced you that designing your career around a certain specialization is a goal worth pursuing.]]></description><link>https://www.independentengineer.co/p/rediscovering-your-calling</link><guid isPermaLink="false">https://www.independentengineer.co/p/rediscovering-your-calling</guid><dc:creator><![CDATA[Yaroslav Tkachenko]]></dc:creator><pubDate>Mon, 06 Apr 2026 13:03:50 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/98345c92-6bc4-4640-a957-dde55c644b6c_2816x1536.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><a href="https://www.independentengineer.co/p/software-engineers-have-been-lied-to">I may have convinced you</a> that designing your career around a certain specialization is a goal worth pursuing. </p><p>Some engineers know their calling right away. Lucky you. The rest of us need time to figure it out. And even if you&#8217;re not going to switch to a solopreneur career, making a decision like this brings clarity and focus to your professional life. Suddenly, you can quickly decide what&#8217;s important and what&#8217;s not.</p><p>Software engineering is a strange field because software engineers can have very different careers. Many other industries are heavily regulated. Think about law or accounting: the career ladder is pretty straightforward; you need to pass certain certifications; you typically end up in a corporate environment.</p><p>Software engineering can look <strong>wildly</strong> different. Sure, there are a lot of SaaS web product engineers, but there are also engineers who work on game engines. Databases. Linux kernel. Quantitative trading. Robotics.</p><p>And even when it comes to a typical SaaS web products, we still have specializations. Back-end vs front-end. Product vs platform. Infrastructure. QA. Engineering leadership. </p><p>So, let me get to the point:</p><div class="pullquote"><p>Focus on exploring new domains and roles early in your career until you find what you really enjoy.</p></div><p>Because too many people either stick to the same career path (&#8220;I&#8217;m a Java engineer&#8221;) or the same company size (e.g. only working in BigTech, or only working in startups) throughout their life. And some stay <em>miserable</em> all this time. </p><h2>The Best Way to Try Different Roles</h2><p>In my opinion, the best way to try different roles and specializations is to join an early startup during a period of rapid growth. I know, easier said than done.</p><p>I&#8217;ve experienced it several times. In my early twenties, I joined a fintech SaaS company. I started as a front-end engineer, then focused on back-end development, then leaned towards platform development, DevOps and infrastructure. But I also spent a lot of time doing automated QA. I ran Scrum rituals. I planned roadmaps.</p><p>I&#8217;ve also experienced so many technologies and tech stacks. Here&#8217;s what <a href="https://sap1ens.com/blog/2013/12/01/why-is-it-awesome-to-work-in-startup/">I wrote on December 2013</a>:</p><div class="pullquote"><p>Only in a startup can you spend your Monday creating a new module for a single-page app in CoffeeScript, Tuesday refactoring the billing system in Java, Wednesday writing a new endpoint for a RESTful API in Scala, Thursday researching the CSS Flexbox spec, and Friday making changes for an internal Node.js service. This is priceless.</p></div><p>Despite doing all of that, it took another startup for me to discover and fall in love with data platform engineering. </p><h2>When to Stop</h2><p>So, when do you know it&#8217;s time to stop searching and start going deep? </p><p>A lot of it is <em>interest</em> and <em>passion</em>. Is there something that makes you really curious? To the point, it&#8217;s hard for you to do anything else in your free time?<a class="footnote-anchor" data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-1" href="#footnote-1" target="_self">1</a> That&#8217;s a strong sign. </p><p><strong>If you&#8217;re going to specialize in something for the rest of your life, you'd better choose something that really interests you</strong>. </p><p>Another important consideration is whether this specialization is going to be relevant in 10 years. Give it your best educated guess. </p><p>I had a friend who believed that Adobe Flash would be the future. At one point, I thought <a href="https://en.wikipedia.org/wiki/Microsoft_Silverlight">Silverlight</a> would be huge.</p><p>Be vigilant about hype trends. Becoming a blockchain developer a few years ago was all the rage. Just saying.</p><h2>Beware of Betting on a Single Language</h2><p>Or a single technology. I hope Adobe Flash was a pretty good example. </p><p>You could argue this doesn&#8217;t apply to programming languages. Well, I don&#8217;t necessarily agree. Look at what happened with Scala<a class="footnote-anchor" data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-2" href="#footnote-2" target="_self">2</a>. <a href="https://www.tiobe.com/tiobe-index/">The top 5 languages</a> are likely safe, but I wouldn&#8217;t be as certain about everything else.</p><p>I still think betting on a <strong>domain</strong> or <strong>industry</strong> is a much better long-term strategy because it means you speak in the same language as business executives and leadership: and there is a pretty big chance you&#8217;ll be selling your services to them, not engineers. A business may not be interested in a <em>Java developer</em>, but they may be interested in <em>data integration expert</em>. Even though you end up writing a lot of Java. I hope you see the point.</p><h2>Should You Stop at One Area?</h2><p>It doesn&#8217;t make sense to specialize in several completely different things: it defeats the purpose of specialization. However, specializing at the <em>intersection</em> of a domain and an industry can make a lot of sense. It likely narrows your focus quite a bit, but it can be great at the beginning - it&#8217;s better to dominate a small niche market than be nobody in a large one. </p><p>Here a few examples:</p><ul><li><p>E-commerce and Machine Learning. Personalization, recommendations, agentic commerce, etc.</p></li><li><p>Early tech startups and DevOps/Infrastructure. E.g. offering fractional DevOps services for engineering teams who can&#8217;t afford full-time infrastructure engineers.</p></li><li><p>Agriculture and IoT. You&#8217;d be surprised by the amount of smart devices in modern farming.</p></li></ul><h2>Start Becoming an Expert in Your Current Org</h2><p>As I mentioned before, choosing a specialization doesn&#8217;t mean you need to become a solopreneur. It just makes you a proper <a href="https://en.wikipedia.org/wiki/T-shaped_skills">T-shaped</a> person. That means some doors will close, but many new ones will open. </p><p>So, start investing more in your skills in your current org. There are always some opportunties: a new project, an event to attend, a blog post to write. Network with coworkers who can help you in your journey. Offer help in relevant projects for other teams. </p><p>You may be familiar with different <a href="https://staffeng.com/guides/staff-archetypes/">Staff engineer archetypes</a>. Most of the Staff engineers primarily act as Tech Leads or Architects, which benefits the organization. However, if you&#8217;re on the path to become a specialiast (and potentially sell your services as an indepenent later), The Solver is the archetype to embrace. This is the role that encourages you to go really deep in a certain field, which benefits the organization, but also benefits you equally. </p><p><a href="https://www.brendangregg.com/">Brendan Gregg</a> comes to mind as a great example of a Solver persona.</p><div class="footnote" data-component-name="FootnoteToDOM"><a id="footnote-1" href="#footnote-anchor-1" class="footnote-number" contenteditable="false" target="_self">1</a><div class="footnote-content"><p>I&#8217;m not saying you should <em>work</em> 24/7, god no. </p></div></div><div class="footnote" data-component-name="FootnoteToDOM"><a id="footnote-2" href="#footnote-anchor-2" class="footnote-number" contenteditable="false" target="_self">2</a><div class="footnote-content"><p>Long story short: it peaked in popularity in 2018 - 2019, but it&#8217;s been declining ever since.</p></div></div>]]></content:encoded></item><item><title><![CDATA[Software Engineers Have Been Lied To]]></title><description><![CDATA[When I just started my software engineering career, it was very obvious what the next step looked like: get more experience, become senior.]]></description><link>https://www.independentengineer.co/p/software-engineers-have-been-lied-to</link><guid isPermaLink="false">https://www.independentengineer.co/p/software-engineers-have-been-lied-to</guid><dc:creator><![CDATA[Yaroslav Tkachenko]]></dc:creator><pubDate>Sun, 29 Mar 2026 22:00:58 GMT</pubDate><enclosure url="https://substack-post-media.s3.amazonaws.com/public/images/eb4a6f99-c1a0-4066-80a3-629c8eeee93e_2400x1260.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>When I just started my software engineering career, it was very obvious what the next step looked like: get more experience, become senior. Then the goal shifted to becoming a technical leader. At 26 years old, I became a Director of Engineering at a startup. </p><p>I realized I wanted to work on bigger projects. So, back to an individual contributor. Joined a Fortune 500 company. Switched teams after a year, got promoted after six months. </p><p>Then another company. Chasing impact and money. </p><p>Rinse and repeat. It was a simple time: keep your head down, work hard, and hope that your work will be recognized. Get promotions and raises. </p><p>I bet this sounds familiar to many software engineers. Things can become progressively more competitive (and sometimes toxic) the higher you climb. But what else can you do?</p><p>The only alternative I was aware of was starting a company myself.</p><p>To me, that meant grueling experince of raising funds, then chasing goals that were not fully yours. I didn&#8217;t go through that process as a founder, but I had a front-seat experience<a class="footnote-anchor" data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-1" href="#footnote-1" target="_self">1</a>. </p><div><hr></div><p>But, as I learned when I got older, there is a third path. A path that can provide fulfillment and a higher degree of freedom. </p><p>No one told me about this. I had to believe that climbing the corporate ladder or starting your own VC-backed startup were the only two options. That was a lie.</p><h2>The Third Path</h2><p>Unfortunately, there is no single word to describe what I&#8217;m about to explain. </p><p><strong>A consultant</strong> is probably the closest one. Unfortunately, the term has picked up a lot of negative baggage over the years.</p><p><strong>A Fractional CTO</strong> is another one. <strong>Advisor</strong>, in some situations. <strong>Freelancer</strong>, but to a certain degree. <strong>Contractor</strong>? </p><p>Despite very different angles, these are more or less the same job. <strong>A</strong> <strong>solopreneur</strong>. I&#8217;m describing a job where you sell your experience and skills at a <em>premium</em>. A typical freelancer is someone you hire when you&#8217;d like to save. But a consultant brings highly specialized knowledge that costs&nbsp;<em>more</em>&nbsp;than that of&nbsp;your average engineer. </p><p>Consultants can be very hands-on, working alongside full-time employees and going through the same workflows. They can also be more high-level, discussing architecture, strategy, and implementation. Or they can mentor and educate. That&#8217;s why it&#8217;s so hard to define the role. </p><p>What&#8217;s important to realize:</p><div class="pullquote"><p>Consulting can be what you want it to be</p></div><p>Enjoy software engineering as a craft? Consulting doesn&#8217;t mean stopping to write code and build systems, quite the opposite. Most of my hands-on engagements involve full days of design and implementation. Almost 0 meetings. No performance reviews. No daily standups or other meaningless rituals. </p><p>Enjoy problem-solving? Enjoy mentoring and teaching people? You can design your days so you spend 80% of your time doing what you want.</p><p><strong>And I believe that every software engineer can deliberately design their career, making this path a viable option</strong>. </p><p>I&#8217;m not saying every software engineer <strong>must</strong> become a consultant, no. But I think that every engineer should pay a great deal of care to their career. So transitioning into a part-time or full-time role where you sell your expertise is always available as an option for you.  </p><p>Also, this is a great way to start a product company, if you want. I know several engineers (myself included) who used to do part-time consulting while they were bootstrapping a product business. Having that safety net is important.</p><h2>But &lt;Insert Your Reason&gt;</h2><p>Yes, this is not an easy path. It requires dedication, hard work and a bit of luck. </p><p>But I find it much better to bet on yourself and work hard on your own business than dedicate your life to a company and be eliminated due to &#8220;optimizations&#8221;. Or not getting a promotion because of bureaucracy. Or making less than your peers because of your gender. </p><p>Having full-time employment was once considered a sign of stability. It&#8217;s not anymore.</p><h2>But AI</h2><p>Large Language Models have been on everyone&#8217;s mind in the past few years. Even if you&#8217;re extremely pessimistic about the impact of LLMs on coding, it&#8217;s really hard to disagree that some impact is not reversible. </p><p>However, I believe this actually helps professionals with specialized knowledge. By definition, LLMs are great at producing <em>average</em> output. Even if it looks pretty good.</p><p>There is a common misconception that LLMs help generalists the most: finally, you can have an engineer who&#8217;s capable of doing anything! But this doesn&#8217;t work in practice that well: if you&#8217;re building a system that requires specialized knowledge, you can&#8217;t really say if the output generated by an LLM is good or not! LLMs can be excellent at producing <em>seemingly</em> working software and <em>convincing</em> you about it<a class="footnote-anchor" data-component-name="FootnoteAnchorToDOM" id="footnote-anchor-2" href="#footnote-2" target="_self">2</a>.</p><p>But if you&#8217;re able to get productive with LLMs, you can gain a <em>huge</em> competitive advantage. It&#8217;s funny to see job postings like: &#8220;we&#8217;re hiring an engineer who can manage tens of agents in parallel and ship with blazing speed&#8221;. Why would <em>that</em> engineer work for you? Or work for anyone except themselves at that point? I don&#8217;t think most employers realize that.</p><h2>Anyone Can Do It</h2><p>I mean it. It just needs time and focus. </p><p>Pick a niche, a domain. Ideally, something that you&#8217;ve already tried and you like. </p><p>It can be vertical, like e-commerce or gaming, or a skill, like building databases or being proficient in Rust. Ideally, you want to bet on something that&#8217;s likely going to be more in demand going forward. For example, I chose data engineering about a decade ago, which turned out to be a great bet (thanks to ML and AI). </p><p>Start building your expertise. Write a blog or a newsletter, give talks. Publish open-source software. Develop your online brand. </p><p>But also, align your existing career with your direction. Be smart about choosing teams and jobs. Convince your boss that it&#8217;s a good idea for you to write for the company&#8217;s blog. And it&#8217;s an even better idea to cover your travel expenses for the upcoming conference&#8230;</p><p>These are just a handful of examples. I hope you&#8217;ll subscribe to this newsletter to learn more. </p><h2>About This Newsletter</h2><p>I&#8217;ve been doing this for almost a decade. Built a career, carefully chose what teams to join. Grew a strong network, built an online presence. Gave talks at conferences all around the world. As a result, I have a consulting practice that allows me to truly enjoy my craft. I can work 2-3 days a week if I want and maintain my current lifestyle. </p><p><strong>I decided to start this newsletter because it&#8217;s really painful to watch so many brilliant engineers struggle</strong>. Toxic Big Tech culture. Layoffs and the end of <a href="https://en.wikipedia.org/wiki/Zero_interest-rate_policy">ZIRP</a>. Fear of AI eliminating roles. </p><p>I want to contribute what I can to help. I&#8217;m going to start writing everything I learned in the past decade about building successful careers, building a personal brand, growing your network and shifting to consulting, first part-time, then full-time. </p><p>Welcome to The Independent Engineer.</p><div class="footnote" data-component-name="FootnoteToDOM"><a id="footnote-1" href="#footnote-anchor-1" class="footnote-number" contenteditable="false" target="_self">1</a><div class="footnote-content"><p>For example, I joined one of the startups as a founding engineer and a first hire. I even sat on a fundraising call with an investor (who committed to invest $1M within the first 15 minutes).</p></div></div><div class="footnote" data-component-name="FootnoteToDOM"><a id="footnote-2" href="#footnote-anchor-2" class="footnote-number" contenteditable="false" target="_self">2</a><div class="footnote-content"><p>You may disagree with me here. That&#8217;s ok. Everyone has a different experience. </p></div></div>]]></content:encoded></item></channel></rss>