This article is for early-stage (Seed, Series A) founders who think they have engineering management problems (building eng teams, motivating and performance-managing engineers, structuring work/projects, prioritizing, shipping on time).

The gist: if you think you have these problems, it is likely that the correct solution is to do nothing, to not manage, and to go back to building product and talking to users. Put another way, and having managed teams at all scales, I don’t think it’s a good use of your time as a founder to be "managing" engineers at such an early stage.

In the following sections, I'll go through the most typical anti-patterns I've seen, and try to highlight a better use of your time if you think you've hit the situation in question.

Do not try to "motivate" your engineers

A common concern of many founders is making sure that their engineers are working hard. This could mean putting in long hours, working more than competitors, completing heroic codebase rewrites, etc. When these external signs of effort seem to be missing, founders worry that the team is not "motivated", and it can be very tempting to treat symptoms over causes. For example:

• creating cultural norms around putting in long hours (996-style culture) by either requiring or celebrating them
• scheduling recurring or non-urgent meetings on weekends (e.g. standup on Saturdays)
• micro-managing tasks, or asking people for status reports and other evidence they worked hard

These anti-patterns share one thing in common: they start with founders trying to actively do something to motivate the team. This has 2 consequences:

1. This can cause the very engineers you want to retain (those who have many options) to self-select out of your engineering culture. I know several top 1% engineers in the Valley who disengage from recruiting processes when 996 or something similar is mentioned.
2. You are wasting your mental energy on the wrong problem

All of this is a long way of saying that motivation is an inherent trait of great startup engineers. Your only job is to hire these engineers, and then to maintain an environment where they want to do their best work. And yes, at that point, you may see them working long hours and doing heroic actions you did not even think were possible.

Motivation is a hired trait. The only place where managers motivate people is in management books.

I'll dedicate a post to specific ways you can identify motivation during hiring, but in short, look for:

• the obvious one: evidence that they indeed exhibited these external signs of motivation (in an unforced way!) in past jobs
• signs of grit in their career and life paths (how did they respond to adversity, how have they put their past successes or reputation on the line for some new challenge)
• intellectual curiosity in the form of hobbies, nerdy interests that they can talk about with passion
• bias for action and fast decision speed

Finally, as a founder, you should definitely be the most motivated person, in an authentic way (maybe it's some piece of heroic coding, maybe it's taking 2am meetings with European customers, maybe it's something else unique to you). Cultivating your own inner motivation is the most effective way to set the tone for the team.

Do not hire managers too soon

The most obvious external sign that a startup has switched from building a product to building a company is to add management roles. When this switch happens prematurely, a lot of energy gets spent on stage-irrelevant problems.

By definition, an engineering manager needs to manage a team and projects, but if the team is still working on defining what they should be building, there is nothing to manage. Even the most intellectually honest manager will start outputting "management work", such as having 1:1s with everyone, doing some career coaching, applying order to the chaos of potential features by putting them in JIRA tickets or issues, etc. Here's what it means for you as a founder:

• you are still trying to find product-market fit and build your initial product
• an engineering manager is helping you do it in a more optimized way, but they are optimizing a moving target so it does not really improve anything
• you don't know if this engineering manager is bad at their job, or if the engineers are not performing, or if the product has no market anyway, or all of the above

So how do you define "too soon"? Let's look at a few typical inflection points, assuming at least one founder is technical:

The founding stage (5-6 engineers including founders)

Obviously too soon to hire managers or turn someone into a manager. The only management-like tasks for the founders are hiring and firing, other than that the team should largely be self-organizing and self-sustaining with lightweight tooling (a simple doc can even be used as a task tracker, 1:1s happen organically and are infrequent, etc.).

In general, the bias should be towards doing nothing in terms of management and everything in terms of hiring exceptional people who inherently work well together.

This might be late seed or series A, with an inkling of a working product. Many teams will decide to implement management at this stage, because it seems like the natural next step. The decision is full of nuances, but I would strongly advise to have all the engineers still report into a single person (ideally the co-founder CTO). Why? Speed of execution and culture, mainly:

• at 15 engineers, it is very doable for a single person to keep track of everyone's work and ensure alignment.
• this is the critical moment where you build the engineering culture that will bring you from here to hundreds of engineers (how do we hire, what do we value, how do we work together, etc.). It's much easier to do this as a flat team with a single leader.
• pivots and radical decisions could still happen frequently, which will be exponentially harder if you have to manage these engineers through 2 or 3 line managers.

The only nuance I would add, if you really need to start structuring the team, is to go with hybrid roles: maybe it's a very hands-on manager who still codes 70% of the time, maybe it's elevating a few key engineers into informal tech lead positions

The early growth stage (going from 20 to 50 engineers)

This is the sweet spot where the benefit of adding more management and more structure should outweigh the cost of letting the inevitable chaos of a larger team take a life of its own. Still, I would highly recommend a less-is-more approach.

Here are a few signs you've reached that stage:

• the CTO / whoever is managing everyone shows signs of burning out under the load
• adding more engineers no longer increases output, meaning you are constrained by team inefficiency
• the team excels at week-to-week impact, but nobody seems able to play out what will happen in 3 to 6 months

This is a vast topic, and I'll dedicate a future article to that specific stage, including how to hire your first head of engineering.

Do not copy Google

This section addresses two sides of the same coin, both related to the halo effect surrounding great companies and more specifically their management practices:

• Applying management ideas that Google (or other successful company) have talked about and made popular
• Applying the meta-idea of innovating in the field of management (like Google did in their time)

I'll skip to the conclusion and explain it below:

When in doubt, always pick the "node & postgres" stack of management. Do not innovate, keep it boring.

What I mean by the "node & postgres" of management

Node & postgres share these common traits: they have huge communities, their bugs and quirks have been explored by millions of people, and so they are great choices for early-stage startups compared to, say, C++ and OracleDB. No matter what you think about their technical merits, it would be very hard to point to them as a reason why a startup failed. They are just solid, boring tools, and they work at the early stage.

You should use the same type of boring, widely used, stage-appropriate tools when it comes to managing your startup. Every ounce of "innovation" you spend on your organizational structure, title philosophy, or new-age 1:1 is an ounce you aren't spending on your product. At the seed stage, your culture shouldn't be unique because of your clever peer feedback system, it should be unique because of the speed at which you solve customer problems.

What is the boring stack of seed stage management

As a conclusion to this section and to the entire article, I want to share, somewhat paradoxically, a few useful management activities specifically for the early stage. They almost all share the same "reluctant" approach to engineering management, which I think is a healthy leadership approach at that particular stage.

• Hire inherently motivated people: see first section
• Don't manage around a hiring mistake, let them go quickly and gracefully
• Asynchronous status updates: do not adopt all the "Scrum rituals" like standups, retros, etc. wholesale, and if you do, keep them asynchronous. There is little added value to a voiced update, even if it makes you feel good that people are indeed working hard and showing up to the standup on time!
• An avoidant relationship to Slack: while Slack is a given in today's distributed or hybrid teams, it can quickly become an attention destroyer, especially for engineers who need uninterrupted time to work. Keep it in check.
• Organic 1:1s (as opposed to recurring ones): keep them topic-heavy and ad-hoc, as opposed to relationship maintenance like in the corporate world.
• Unstructured documents over systems of records: unless you need to itemize tasks for audit purposes, a few notion or google docs can actually scale for 10-15 engineers, especially given current AI tools. They have very little overhead and are unbeatable in terms of flexibility.
• Extreme transparency: give everyone access to everything (customer call notes, investor updates, budgets, etc.). Not only will you build trust with the team, but you will also remove the need to "communicate" (as in, filtering and processing information), which is a typical management task.

To be clear, many of these practices do not scale past 20-25 engineers, but that's part of the point.

I hope you found this post actionable, good luck with building your team!