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.