Ryan Leaf
Organizational Alignment Expert | Entrepreneur | Software Engineer
A screenshot of me working on this very article...

A Bold New Start

This is the beginning of something new.

After not having a web presence of my own for a couple of years, I've decided to launch a site as a place to share my thoughts and insights into things that don't fit elsewhere (namely my primary publication, Alignment Management)

While much of my day-to-day work is focused around organizational alignment, business strategy, and general business development, I'm also heavily involved in product development and software engineering.

How I got involved in software engineering

I became a software engineer by way of necessity. I started my journey as an engineer a few years back, when I was working on the first iteration of Minsilo.

One of the unwritten realities of starting a company is that you need some kind of proof that you're invested in the process, before others will join you along your way. This is particularly true for engineering talent, since they likely have several other opportunities on the table. Some startup ideas naturally attract people, because they're interesting or cool (unfortunately, many of these ideas are just existing ideas that have been recycled, like starting a new social network).

Another way to get engineers is to throw money at the problem. I've seen some founders try to do this and I think it's fundamentally a bad idea: if you're building a technology company, you need to have someone who deeply understands the tech on your founding team. You'll end up spending way more money than you need to and may not even have a product to show for it.

Many engineers are not competent product managers, but early stage companies need both. And just sharing the "brilliant new idea" isn't enough. Good product managers will spend time out in the field talking to potential users, researching competitors, and nailing down user stories. You should not build a product in a vacuum - if you're not talking to users early and often, you'll likely end up building something nobody wants. I've made this very mistake earlier on in my startup journey and I'm very fortunate to have survived it.

Good startup founders are their own first product managers.

Another key activity that good product managers do - especially if they have strong technical skills - is ruthlessly prioritize and weigh different opportunities. Many startups fail because they try to pursue too many opportunities, rather than not having enough opportunities to pursue. Being constrained - in terms of cash and time - is an asset for many startups. Focus and discipline are key factors to the success for any company.

Focus and discipline are key to being successful. Grit too.

One of the key life lessons from starting a company is that you cannot ignore reality. If you don't make something happen, it won't. If you aren't willing to leave the building and meet potential customers, you won't have any customers. If you're not willing to write code, then no code will be written.

When investors talk about wanting "founders that are hungry," this is exactly what they're referring to: they want people who are going to do whatever it takes to get to an outcome. They want people who will keep going until they're successful.

Many people will give up. They're not willing to make long-term investments to be successful. They want immediate results. No wonder "get rich quick" schemes are so popular.

But it's this long-term focus that enables you to be successful. Learning to code isn't hard: it's tedious, frustrating, and sometimes confusing. In reality, it's more about endurance and persistence than it is about being smart.

I'm not a believer in only doing things that play to your strengths. Instead, focus on doing things that will get you to where you want to be. If you come in with a learning mindset, you'll be able to turn weaknesses into things you're good at. Many of my "strengths" were once things I was naturally bad at. People would tell me "maybe you should do something different - I don't think you're cut out for this" and I would initially believe them (because they were half right), but then I would work even harder to be successful.

This hard-learned life lesson has led me to work through these "weaknesses" and turn them into strengths. Becoming a successful engineer is really about putting in the hard work, rather than innate ability. I remember someone telling me early on to "focus on becoming an engineer or a business person, because you're not going to get good at both."

But that's who I wanted to become. So I put in the effort, slogged through technical challenges for a long time, constantly educated myself (I'll write about this more, but this is critical to success -- it doesn't just come from working hard), and learned to code.

I started with a book on Ruby on Rails, then moved to learn AngularJS. I built an application, spent many hours trying to figure out how to work through bugs and kept going. I just kept going. About 3 years later, I'm still writing code...

These days, I spend a lot of my time juggling:

  • Building web applications primarily in the React, Rails stack.
  • Configuring and deploying said applications using Kubernetes.
  • Designing new product features using tools like pen + paper, Figma, and draw.io.
  • A whole host of things around product management, including customer research, roadmapping, prioritization, and user story development. I use a combination of Trello and JIRA.

Why technology and business?

You may be wondering what thread ties together business and technology.

While I spend a lot of time writing code, I don't think building software is the objective itself. I'm more interested in answering the following the question:

How can we solve some of the biggest challenges facing people at scale?

My interest is in solving challenges that people face, rather than building a solution in search of a problem. There's a whole world of activities that humans do, but don't scale (or, more accurately, cannot do at scale).

The technical details (of this new site)

You might notice that this site isn't using a standard template for its design. That's because it is isn't - I caught the GatsbyJS bug recently when I built out Minsilo's new website. I built this site in Gatsby, so it's fast and reliable.

In the past, I would have probably built out a website on Wordpress, but I really like being able to:

  • Write my content using Markdown (and use the amazing Markdown editor in Nuclino -- in fact, I'm going to write an article soon about how Nuclino offers a best-in-class text editing experience).

  • Not have to worry about infrastructure. The number of times I've had a MySQL database server crash because of a memory leak (probably a broken Wordpress extension than anything else) is infuriating. I want to write content, not play sysadmin.

  • Not being locked to a complex deployment setup. Gatsby lets me host this site anywhere that supports hosting static files.

    To that point, my site cannot be Slashdotted because there's (essentially) nothing to break. Hosting static content has become unbelievably reliable in the past several years, especially if you put the site behind a CDN.

    I'm still debating on whether to host this on GitHub pages or using a combination of S3 & CloudFront.