31–40 of 85 posts
- Are you hiring senior people or juniors?
- How good are the managers?
- Are you able to get people to buy in on the need for consistency?
- Are you micro-managing it or are you delegating?
Usually the problems start at the top, so that's where I would start looking for solutions. A really good coach for your CTO if they're not very experienced would be a nice start.
It’s up to the CEO to fix all of it, directly or indirectly. Except perhaps the chat one. You need someone with community-manager DNA and a light touch, lest the CEO come off as control freak. (Which is ironic bc they have to be one in many areas but this is one where it will alienate people)
This might not be the first to break, but it will eventually, and if corrected NOW will make things much smoother: Your documentation of processes and procedures is NOT adequate. 'everyone used to know about are getting lost' - oh good thing your documentation makes this clear, because it is obviously their fault. 'New hires take forever to ramp up' - oh good thing you have complete ramp up plan and documentation, be…
[flagged]
As you grow, that stops being the case; to echo what @Peroni and @sloaken said - a good first step is good documentation and clear, repeatable and where possible automated processes. A second, related challenge is company culture - as you grow and interactions between each & every individual become less & less possible, getting everyone aligned on what it means to work at your company (and how to achieve company goals) is harder. You'll need to make a conscious effort to maintain that (see below).
The core team will need to start delegating more, which can be a hard if you're not used to it (some may also want to remain ICs), and will change the shape of your organisation. This is particularly hard to do gradually, as you'll need to work out the right point at which to transition different areas of the business. This comes with the risk of silos developing - a good way to work around that at mid-size is to continue arranging teams by project, but make sure that there are both opportunities to gather across functions (e.g. dev, qa, project management etc.) and more widely (e.g. company events, social events etc.). The main thing here is making sure people talk to each other, exchange information, getting good at collaborating with each other and know who to reach out to in case of issue. Again, you are going to have to dedicate time to this which will seem strange coming from 15 people (but will pay off handsomely in increased efficiency).
There are many good other points in this thread (on hiring experienced people even though they cost more, the importance of good hiring, clear ownership, us vs them), but a last one is the need more generally for the leadership team to adapt. They will have less visibility and control; the company will become less efficient which might be frustrating (it will still be able to do more overall); changes of direction will become harder and slower. This applies to all 15 people working there now, but particularly for the founders/leaders. Having some thoughts on how to handle this ahead of time (established reporting structures, clear goals and reporting metrics) will help minimise growing pains. It's always easier to say this than to do of course.
Source: did something similar a couple of times (4->25 people, 600->1000 people).
"We just talk to each other" doesn't work well enough when you no longer know who to talk to. Email aliases for teams can help, so that you don't need to know who the right person is for your question, you just need to know the right team.
Things can't live in peoples' heads anymore. Task lists need to live somewhere. Tribal knowledge needs to live somewhere. Priorities need to live somewhere. Some tools may help. You probably eventually will need a bug database. Depending on what world you're in, you may need a requirements database.
Earlier quoted context omitted.
So, documentation is the solution? But do people have time to document everything?
Art is knowing what to document. And how to organize it. This is probably not a solved problem and needs constant care and refactoring like the code itself. Giving people additional documented responsibilities helps. Lucy is responsible for API docs and swagger up to date and for building that out as business needs. Varun is responsible for coding practices docs. And so on. If something is out of date they update it.…
The first is that you had a system with a given set of ownership and now lines need to be drawn between groups to grant each sub-team their own piece of the larger pie. This is where Conway's law comes to bite you because your code is likely structured around your existing team and practices. Deciding how to draw that boundary is a challenge (API-based? Separate services?). Do not skip this part, otherwise you'll have an awful mix of old and new and everyone suffers.
The second is how work is structured. With a small team, anyone can edit anything (ownership again). With multiple teams you need to accept that changes will require multiple stages of development and the rate of change can take a hit due to scheduling and prioritisation for each team. In the small team a single sprint (assuming this is your working practice) may have been sufficient, but with multiple teams those changes will need scheduling.
You're in the hardest phase - 15 until about 60 people. Right now, you are transitioning from needing generalists to needing to hire specialists, but you don't have the infrastructure for specialists. You are likely to start hiring managers now.
Compounding the difficulty, people are going to expect all the services of a 60 person company but you haven't built them, and probably don't know exactly what you want. Have you started getting requests for "HR" to do something yet? Requests for "policies"? In the thread here, people mention documentation. This will be a theme. And your vision for what you want that to look like is important; in my experience if you leave this up to a new hire that's "bigger company" experienced - they will generally rebuild what they have experienced without a lot of thought about adapting it to your company and the size you're at.
Like a lot of startup problems, a) this is a good problem, so don't be mad, and b) there is no magic bullet, you just have to get through it.
My two cents, having mentored a number of companies through this and done it a few times myself, here are my non-negotiables:
1. Keep hiring managers that can execute. It's too early for corporate VP types at your size. And you're probably not ready to manage the political and management skills and needs of corporate VPs just yet.
2. Double down on engaging with hiring - you're likely to be hiring new people with organizational leverage (managers) - you need to be able to explicate the values and make CERTAIN they are being carried out and improved on and broadcast by new management hires; they will be doing things you don't know anything about, so you need to be totally in sync with them. I've read a few startup CEOs that say they stayed personally involved in their first 1,000 hires. That sounds incredible to me, but I like the aspiration.
3. Build reporting process - could be digital could be soft, e.g. periodic standup meetings where numbers are reported - but you're going to need this as you get a bit bigger, and it's culturally easier if it's embedded in the org as you recruit and hire and grow than if you impose it as a "founder/CEO project" later on.
Anyway - what breaks first is your old methods of alignment. A lot of people talk documentation here, which makes sense. Culture is more important than docs IMO.
The way I would say it is: communication becomes exponentially more important. Basically every doubling in size means you will need to say things twice as simply and four times as often for them to get through the org. You will need partners in the org as it grows to help with all this, but you will not be able to give up the responsibility of communicating vision, standards, direction, and to the extent you don't build that skill, you'll send an org spinning, or lose it to someone who is doing this.
Enjoy the ride! It will be fun. Also, things do get easier in many ways as you grow - you get some money to invest inside the company - you'll get to work with great people - it's a lot of fun.