Founders that have scaled to 50+ employees, what processes did you have to establish?

Hi all,

I’m curious about your growing pains from the early days of quick team decisions to a more formal process-driven company.

More specifically, how did you identify what needs to be standardized? What departments struggled the most with establishing process? Was it a natural transition or did you have to consciously make changes? I’d love to hear stories if you have them.

9 Likes

I think supporting processes is the big one.

You know that thing that someone does that’s outside of their job scope but it makes them and maybe another co-worker more productive?

You need someone to specifically own that thing.

Because when you need 5 or 10 more people doing the job that someone does, doing that thing is a full time job.

8 Likes

We defined a good set of Standard Operating Procedures or Operations Hanbook right from the get go. It clearly defines processes, rules, compliance, reporting structures, conflict resolution and escalation for every major, critical business function, particularly for cross-functional work. Then made it part of onboarding for new employees and ensure team leads in a <50 employee company take one day out of month to take team feedback, review process efficiencies or inefficiencies and adapt and improve.

The biggest challenge, especially given the remote nature of work now, was to maintain asynchronous work and limit mundane blocking activities that could’ve easily move forward by referencing relevant company-wide accessible literature; the SOP / Handbook.

When the company gets bigger and more processes are involved, I’ve heard of several companies hiring internal IT BAs / Business Analysts to review their processes, systems, Information Architecture and workflows etc, looking for pain paints and opportunities to improve.

If people want a good sample reference, use GitLab Handbook.

They have provided their entire companies blueprint for SOPs and Operations publicly for people to use. And this act of sharing is why I use GitLab as a tool in our companies DevOps =P

7 Likes

I wasn’t a founder but I was an early employee at a company that scaled in that range.

One thing I noticed that is both a pro and a con: your hires will bring their expectations, processes and company culture with them.

If you hire people who spent 20 years in big bureaucratic corporations, they’ll expect the processes of big bureaucratic organizations. They’ll want formal trainings, make use of HR complaints, expect performance reviews and will want clear development paths, etc etc

If you hire people who have only worked at startups, or had very few career-level jobs (early college grads maybe), they’ll have few expectations about what a corporation should offer, they may take on roles outside their defined position without asking, they might handle conflicts on their own.

I think for founders and scrappy early employees, there is a desire to keep things loose and agile like the early days, but inevitably as you scale you’ll hire more experienced people from big corps that will expect a certain level of infrastructure. Resisting that is kind of like taking on technical debt: you can, for a long while, resist those formal structures, but eventually it will bite you in the ass. Uber is a good example, I think, of a company that wanted to stay young, but paid the price when they outgrew their culture.

6 Likes

@Michael, This is a good response.

Neither of those groups are bad - but I’ll say the ones coming from bigger places sounds “bad” in that people value “people that wear many hats” and “gets things done”.

But in reality, I find big corp has exposed people to a lot of problems and those problems have been solved, and those people can offer solutions with their experience to the problems.

Finding a big corp person that’s going to complain the way you do things isn’t a bad thing if you empower them to enact change to help drive you to standardization and scalability. But don’t hire big corp and then get mad when they want to improve things. They’re often trying to just optimize their leverage.

Hire big because they know what good looks like and you want to leverage them into making things better. Don’t hire them then hamstring them at every move.

6 Likes

@Juan, And that conversation about how many big company policies to adopt and when is really what all of “scaling culture” is about.

The “wear many hats” example is a good one. In my experience, people with corporate experience HATE it when someone does something that infringes on what they might see as their domain. They’re used to rigidly defined roles, with strict calendars and plans and schedules.

But at a young startup, there’s a lot more flexibility and often times, that leads to big gains when people work cross-functionally to find something that works.

Take email as an example. Early days, anyone can send an email. Want to test an offer to promote a new website feature? Get some assets from creative, make an offer and let ‘er rip. After you hire a formal email marketing manager that’s used to planning emails 6 months ahead, you could lose a finger if you did something like that. You lose the quick agility to fire off whatever whenever, but you gain the systematic improvement of a well constructed email program. Inevitably, though, that can cause some friction as the old guard loses a bit of that shoot-from-the-hip attitude and the stodgy corporate types learn to be more adaptable.

6 Likes

Yes @Michael

I run finance departments, and so often I’m coming into companies that are trying to get to whatever the next level is. The last one i went was $150m revenue trying to sell.

I just took a CFO job for a company that’s about 1/3rd the size, cash basis, the CEO reaches out directly to my STAFF accountants and distracts and derails them. I have to fight with him a lot to back off.

Unfortunately, there’s not a lot of good leaders that can simply recognize differences in organizational behavior and employ real strategies - they simply have a mentality that demands one or the other based on their own personal way of working rather than making meaningful adoptions for one direction or another. My CEO will -never- stop thinking it’s okay to just go past managers and direct other team members. He’s simply too stubborn and old and set in his ways. The only thing you can do is build systems to prevent derailing people as you scale.

Designing and talking about the different personalities is one thing. Working with them all simultaneously and trying to get them all going in the right direction is another thing.

5 Likes

No touching in the workplace. Seriously, outsource HR to a reputable organization as soon as your employees number greater than 1.

4 Likes

Are there challenges to employees feeling valued or building an employee-focused company culture?

Do the outsourced company control onboarding and exit interviews as well? Do they also find candidates when you need to hire someone?

I’ve never worked at or know anyone that has worked at a company that outsourced HR.

3 Likes

Happily but I’m some rando on the internet so take it for what it’s worth.

Well this isn’t a massive deviant from one to the next I’m going to model this after specifically one guy who I highly admire. They are all mostly somewhat similar though.

I briefly mentioned this but physical health is a decent priority and obviously part of that is eating they’re not fanatical but he and his wife generally eat on the pretty healthy side. They run the business together.

As far as sleep goes he generally gets five to six hours. A big part of this is a mindset he has decided that that is what he needs and he does not fight getting up. He enjoys it. This is kind of the miracle morning book…

From there as far as not going to sleep too late this is probably the most important part, in building his team he has the right people on the bus. He’s built systems and people in place and he’s now at a point where he’s not trying to develop leaders but it’s developing leaders of leaders. Because he’s hired competent people he doesn’t have to work 80 hours a week and can go to sleep generally pretty stress-free.

If you read a decent amount of business minded books none of this is obviously revolutionary he’s just implemented it well. That’s probably honestly the other real secret sauce, makes the plan and then he implements and fallows through

In 8 years since he took over the business he take his business from under 1m to 15 million. He probably profits about 20% of that.

2 Likes

Second this.

Also create SOPs in Asana as templates with assignees and due dates.

Currently automating as much as possible that comes to mind when I think “if I went on vacation for a month, what issues would I come back to in my inbox.

It’s a good framework for exposing the leaks that cause “death by a thousand papercuts” if you’re at that stage of disorder, or even exposing ways to maximize where your time brings the most ROI to the company

1 Like

Trust but verify:

In a small startup communications are hard enough but still a founder might literally sit 10 feet from most employees. If people are unhappy, etc it is easy to see.

But as you crack a certain number there will be a desire for layers and hierarchy. Some of this makes complete sense as you not only delegate but some of those who you delegate to themselves delegate.

But this is where power-struggles are born. All power comes from a control of information; information flowing down and information flowing up. People will often realize they can use this control of information to become fairly powerful. Thus as a founder you want to nip this in the bud by establishing as much open governance as makes sense.

At the same time it is crucial to make it clear you, as a founder, will continue to interact with the lowest tier of employees in an open and regular manor. This keeps those who you have delegated to from hiding stuff.

In the military you will see fairly high ranking officers doing inspections of the troops. This is because a simple walk down the ranks can tell a general a massive amount of what is going on; moral, fitness, training standards, etc. Those same generals will often wander around during various training and other exercises and ask seemingly innocent questions. This sort of stuff freaks out the lower ranking officers as it entirely removes the “chain of command” as a way to control information; especially bad information.

A recent story for me was a local business guy has about 250 employees. They went all remote for covid, during covid they decided for post covid to break up the one large office into a mixture of remote work and smaller shared office style spaces. People could then self organize into teams. This was done through a set of google sheets where people would find a local office space and then put their name along with others who would want to work there. He noticed an odd thing. Groups of 5 - 8 would sign up for a space, then they would all move their names to another space and then do this over and over again. So, he grabbed a random few and took them for lunch and grilled them as to why they kept doing this. Long story short it turned out he had 8 managers who were nightmares to work under and when any one of them signed up for a space the employees would find another space. He then dug deeper and found these managers weren’t only nightmares to work under but due to piles of useless meetings, fake agile practices, pressure for overtime, etc, they had probably also cost the company many good employees in the past.

He fired all 8. No 2 weeks to bring other people up to speed, not one every few weeks, no second chances, just told IT to cut them off and the accountant to send them their severance while he sent them a bye bye email. From his previous experience he thought these guys were the bomb; their reporting was clear and they seemed super organized. The reality was their reporting was imposing a huge load on the developers who had largely worked out systems and ways to corral these managers into wasting as little of their time as possible. Now his structure is closer to actual agile and he was happy to find out with the simpler system 2 of his existing managers are well capable to do what 10 did before. On this last the 2 surviving managers hated all the reporting the other 8 had effectively set as the standard which they felt obliged to follow.

When it comes to any procedure or practice ask two questions:

  • Would anything bad happen if we didn’t do this?
  • What are the costs of doing this?

For example; micromanagers love to be able to reach out to any developer at any time. Thus tools like slack are popular among managers. The problem is there are a zillion studies out there where you really shouldn’t interrupt developers if you want peak productivity. The shortest cost I have seen for an interruption (even if it is “what time is it?”) is 40 minutes. I would argue it is well in excess of an hour to potentially many hours; all the way to a productivity killer all the time. I would argue it takes time to get in the zone 30min-1h. You start moving the variables into your head, you kind of zone out and there is no world outside of a corridor between your eyes and your monitors, once in the zone productivity flows like magic. Then someone pops in and snaps you out in an instant. Now you are trying to get in the zone. Except if you know you have an immanent interruption like a meeting or lunch you might then just do some busy work like filling out timesheets, or reading reddit (“social media research”). Thus that one interruption could literally be an 1-2 hours of lost productivity. Except if that interruption comes close enough to the end of the day you might just write off the day and not even try to get into the zone as it is harder to do so later in the day. So let’s look at my ideal day:

  • Get out of bed and have an idea
  • bike to office while mulling over idea
  • Walk to desk while firming up first steps. 8am
  • Work until about 11am and realize it is time to actually move
  • Go for walk or an early lunch with fellow, quite possibly discuss dev issues
  • Check a few emails (maybe) and ignore those that are stupid 12pm
  • Start slipping back into the zone, possibly taking into consideration discussion at lunch
  • Work until 3-4 when zone just starts slipping away
  • A few more emails or something annoying like timesheets (10min)
  • Leave

Total in the zone time: 6+ hours.

Here is a day for many programmers:

  • Get out of bed and don’t have idea because work is a drag
  • Go to work and maybe come up with a cool idea
  • Walk to desk but get snagged by the 3 people who consider themselves their manager with three separate requests on three separate projects (or sub projects).
  • Sit down and read through 12 emails from 5 managers and an HR person all requiring thought out questions for things like time estimates, filling in paperwork for benefits, picking what they want for the goodbye lunch for the latest employee to resign.
  • 9am standup while they listen to the 3 useless programmers on the team squirm as to why they have not moved an inch forward with their tasks. Also, in this meeting there will be vague new instructions on what needs to be done and when which the developer may or may not be held to account for.
  • 9:30 do more stupid paperwork for the manager from the standup because he needs it for his reporting.
  • 10am start to work on a jira issue plucked off the pile because the cool idea from the commute has evaporated
  • 11am just as the zone is settling in, have sales guy ask you if you really think some deadline will be met. Then talk about the hockey pool until 11:45, this doesn’t matter as pleas for help were coming in through slack non-stop.
  • Lunch
  • Get back from lunch and have another 2 managers ask if you are able to “squeeze” in their issues.
  • Start work 12:30 on issues these other managers asked you to squeeze in.
  • 1pm you are just getting in the zone when a person with the title senior developer asks to discuss some code you checked in, they don’t like your commenting style because it doesn’t work with their preferred autodoc system.
  • 1:30 return to work to some slack messages which are more pleas for help.
  • 2pm interruption from a manager wondering why there has been no progress on their issue and they are wondering if you can come in on the weekend for an “all hands” crunch. “There will be pizza!!!”
  • Don’t bother with getting in the zone because there is a mandatory meeting at 3pm from the dev manager where he is going to train people how to use the new IDE version where you were the one to suggest upgrading and you have been using it for 5 months.
  • 4:30 leave because you realize all the managers are gone and you won’t stick around until 5 if they don’t.

In the above, the developer who was hired to develop has maybe spent 1h in the zone and another 1h kind of developing. The rest of the time was dealing with issues not of their own making which either could be solved by those responsible or didn’t actually help make the company money. I have seen this BS workday in a huge number of companies. It is critical as a company grows to ask those two questions way above to see if things are spiralling out of control with BS procedures and practices. Often growing startups almost welcome this BS as they feel that they are putting on their big boy pants. But the reality is the opposite. The reason they can run circles around their competition is due to their competition having lost the plot on what exactly is a priority inside the company.

Especially for tech companies look at how some interesting ones out there are organized. For example, gitlab has 1500 employees who basically use gitlab to communicate.