At 16 I started a ranking site for high school debate. Though I originally never intended for it to be a "company", it ended up getting acquired by a large player in the space last year.

Overnight the team went from 2 to 12. Instead of interfacing with my "co-founder" (high school best friend), there were now several other aspects of the business:

• 3 engineers
• 3 marketing
• 2 product managers
• 1 business ops.

(along with several ancillary stakeholders...)

Going from a hobby project to a legitimate business involved a new degree of accountability. As the head of engineering, here are the lessons I've learned on the job—call it trial by fire.

On Communication

There is no such thing as overcommunication, though this isn't a hot take. I've found that people won't get "mad" at slipping timelines, surprise bugs, or pretty much anything else if you're keeping them in the loop (though this isn't a reason to do poor work).

But there's another aspect of communication that isn't discussed nearly as much as its frequency: mode. Previously, sending updates via daily FaceTime calls sufficed. This isn't sustainable (see On Async.).

The best communication is written down and not backchanneled. In other words, all pertinent members of the team should have full visibility into any updates at any time. Keep things organized in Slack threads and CC relavent parties.

If it isn't acknowledged, assume it wasn't read.

On Async.

Meetings

Working on an intercontinental team spread across 4 timezones inherently limits the amount of synchronous work that can be done. This isn't a bad thing. Even if you're in-office, spending excessive amounts of meeting time (especially on mundane daily updates) hinders agility.

However, when you do have to meet, it's important to structure discussion with some sort of written agenda circulated at least 24 hours prior. This gives attendees adequate time to perform any necesary due dilligence, speeding up the discussion and decision-making process in the meeting.

It's equally important to update the agenda with any new deliverables and choices that were made. Those who couldn't make it won't be left out and, more importantly, doing this steers conversations towards a tangible plan of action.

Debugging

When a team member faces a problem, encourage them to detail it thoroughly, along with what solutions they've considered in writing. For engineering work, this might include steps to reproduce, stack traces, and relevent StackOverflow/GitHub Issues. Oftentimes, fixes are found during this process, but if not, it ensures any team member has full visibility and can assist.

On Management

Self Advocacy

When scaling a team, one of the first things you notice is that if you go out of operation (sickness, rest days, etc.), the productivity hit quickly snowballs to everyone you oversee. Never missing work isn't a feasible option, so it's adviseable to have multiple people read in on short term priorities and the overall roadmap. (Good) management isn't about holding all the cards.

Let your team be self-sufficient.

Onboarding

When adding a new member, it's important to temper expectations for impact and contribution. There are, of course, the rare 10x'ers who'll get going right away, but basing your long-term strategy on consistently finding these people isn't sustainable, nor is it necessary to build a great product. Initially, the net productivity of your team might stagnate (and likely even decrease) due to the effort needed to train the new addition.

It's critical to view this time as an investment, not a burden. If you've chosen the right person, you'll see productivity return to normal and eventually increase. Depending on the type of work and person, this could happen over the course of a couple of weeks to a few months (maybe years if the role is complex).

Your people are long-term investments.

There's the unfortunate reality that not all investments work out. The idea here isn't to sell as soon as the "stock" goes down, but rather to provide feedback and guardrails to as guidance—this is your job as a manager. Only after this fails can you fully conclude that the responsibilities of the role simply cannot be met by this person.

Long-term feedback

When providing feedback (both in the onboarding stage and beyond), there needs to be a balance between building up and taking down. Objectively, criticism by itself takes someone down—regardless of how strong their mental resolve or your "company culture" is.

Constructive criticism isn't critiquing someone while telling them it isn't personal.

Instead, emphasize the successful parts of a deliverable before critiquing it to build a good working relationship. After implementing this feedback strategy, if you notice a repeat issue, isolate it clearly and include written reminders in any assignment writeups. This isn't something that should be viewed as "babysitting"—we're all human. If you take the time to do this now, you'll save yourself countless headaches in the future, more so if you end up re-hiring for the role.

Outside the context of communication regarding specific deliverables, be sure to provide adequate space for 1:1 discussion. This is a great space to provide high-level feedback and to see how you can help. You should be equally receptive to feedback on your management style.