The Founding Phase

in which the dev org gets started

Phase Characteristics

These are the early days. The engineering team is small (less than 10) and operates as a serialized, tightly-knit team. A couple of us are co-founders. We have the seed of an idea, and we’re working together to rapidly build out product experiments, hoping to find product-market fit (PMF). There’s lots of greenfield development. We’re playing with some newer tech stacks, and everything feels shiny and new. There’s excitement and everyone is motivated by the idea of being on the ground floor of creating something valuable and cool.

What I'm Thinking

As an engineering leader, I'm responsible for building the Machine that builds the product, but my emphasis in this phase is heavy on technology.

As a young company, we’re trying to achieve escape velocity. The best thing I can do to bolster our chances of survival is to build a product that feels like magic. At a high level, my effort is split like this:

Product
85%
People
14%
Process
1%

I'm an advocate for quickly building MDPs (minimum delightful products) after testing ideas with MVPs (minimum viable products) to see what sticks. MDPs have a magic moment and naturally take more effort, but -- in my experience -- make a much bigger impact on prospective customers and investors. If there's traction, we'll pour gas on the fire.

We will probably over-rotate towards a single or small group of customers that are giving us early attention. This inherent tug of war between what we want to build (our vision) and what our one paying customer wants from us is natural and ok; we just need to be aware of it and consider it as we move ahead.

We are going to be ultra-light on process. Almost nothing. Just enough to make sure we don't shoot ourselves in the foot. My focus on the people of the dev team will be similarly light; we can build a compelling v1 with a small, high-quality team. I inspire by being in the trenches with the team, leading by example and walking the walk.

I think of the startup life as a game, and I'm making moves. I know I can't do everything, so I need to make the best, highest-leverage move I can at every moment.

What I'm Doing

Since we are small and scrappy, the vast majority of practices we employ at this stage are done only on an as-needed basis. A handful, though, follow a regular pattern.

First and foremost, I think it's important to establish a set of shared beliefs to act as guideposts for the team's decisions. In this early phase, we adopt the principles of 'faster is better', 'simpler is better', and 'change is good' to fuel our rapid efforts to find and secure product-market fit.

As I recruit our first few developers, I also set the expectation that -- with each other -- we will be vocal, helpful, dependable, and kind.

Grounded by these shared principles, we take action, working backwards from an idea we have for a magic moment.

We pick a tech stack to build our software.

We also pick tools and technology to support the team and the build. Key early selections:

The dev team has no real structure at this time. It's composed of mostly-senior talent that came in via my personal network (trusted folks I've worked with in the past). This small team needs to be able to deliver on both the front and back end; for maximum flexibility, I'd love for these to be fullstack (or at least fullstack-willing) devs, but I'm ok if we have at least one specialist in each domain.

Every engineer reports to me. In parallel, we have a designer and a product manager who do NOT report to me, but we work closely with them on a daily basis.

Each developer is paid their personal top of market salary.

I start with daily exercise, solid nutrition, and a good night's sleep. I do the best I can on all three, and advocate the same for the people on my team. If someone on the team is struck by inspiration and feels the need to crank through the night, they can go for it, but I'll expect a down day to follow.

I'll share my primary #focus for the day -- the One Big Thing I'm looking to accomplish -- with the whole of the team. They each do the same.

I code. To get into the flow state, I dedicate at least a 2-hour block of time in the morning, eat lunch, then pursue another 3-hour block in the afternoon. If technical decisions need to be made and others are waffling, I'll be the one to make them.


(hover to expand rough example week)

We operate on a tight weekly cadence: hack, demo, plan for next week, repeat.

Our planning effort happens at the end of the week so that we can hit the ground running the following week without a soul-sucking meeting to start each Monday. The Friday planning meeting is a debate: 'what big rocks should we move next week?'. The dev team, in conjunction with our designer and product manager, gains a shared understanding of what we intend to deliver by the end of the week.

During the week, we divide and conquer, collaborating (virtually) as needed, hacking on the product efforts we've agreed upon. We ask questions and share any notable updates asynchronously via our #eng group chat channel.

On Fridays, in the early afternoon, we showcase our notable wins.

Every Tuesday night, we have a completely-optional hack night; it's my favorite night of the week.

I have 1-on-1 meetings (aka 1:1s) with each of my direct reports scheduled every 2 weeks. However, in this early phase, I'm ok with a quick pre-meeting check (via group chat direct message) to see if we have a blank agenda; if there is not a notable set of topics to discuss, we can mutually cancel.

Since I've got ~8 of these meetings in total, I like to split them up and stagger them across weeks.

With my peers in leadership, we step back and revisit product strategy. At this stage, we're not really roadmapping since SO much (the problem we're solving, our target users, the market) can change SO quickly. We monitor progress of the experiments we've built, looking for signals that indicate product traction.

We debate product strategy shifts and experiments we might pursue. If we're making a notable shift, we communicate it to the breadth of the team.
Every 6 weeks, I like to use the 1-on-1 meetings with my direct reports to explicitly revisit their career path (compensation, title, and trajectory) and their Life Path.

Coupled with paying personal top of market for each engineer, this regular process serves as a nimbler alternative to the concept of yearly performance reviews.

Evolution and Phase Exit

Although the line is blurry, I look for a few things to indicate that my engineering organization has evolved into the Growing Phase. I ask myself these questions:
  • - Do we have a product idea with real customer traction?
  • - Do I feel the need to expand the team beyond a single set of developers to deliver on this product idea?
  • - Am I getting pressure to deliver more product faster?
  • - Am I spending significant time thinking about effective hiring and onboarding, and less time thinking about building product?
  • - Am I getting pressure to help compose and communicate a product roadmap?
If the answer is yes to two or more of these questions, then that tells me we've shifted into the Growing Phase.