> The person who was assigned to an action will report on progress and everyone is held accountable. We take minutes so that everyone is held accountable for the next monthly Leadership meeting.
Uh-oh, sounds like a big company already. The phrase "is held accountable" is in the passive voice.
When you have to implement process in order that people "are held accountable", you are acknowledging that you have a problem: There are people in the company who would shirk some or all of a task. OK, at 50 people perhaps it's unavoidable. However, if you need to counteract shirking by being held accountable, then you really want to switch to the active voice. Where is the active subject of that sentence? It really wants the active voice. Also: What happens when someone fails on a task?
I think you might be reading too much context in to something where none exists. Possibly - I never heard about Treehouse before. Assigning a person who is responsible for the execution of an item is a good idea. Recognizing the need of having point persons for issues is not the same as acknowledging that employees are slacking off.
I think there's a subtle, but distinct, semantic difference between someone being "responsible" for something vs "accountable" for something. The former means that someone is expected to do something or have that thing done, while the latter implies the person will face consequences if something is not done or not done well. Or, put another way, accountability means negative consequences if someone doesn't do what they're responsible for.
In most project management approaches, the difference between responsibility or accountability doesn't have to do with consequences, it has to do with separating out the person responsible for actually completing the work from the person who is accountable for making sure it happens, even if they aren't the one doing it themselves. Once a company gets big enough that people have teams, its not unreasonable for a senior level manager to delegate a task to someone to get done. The CEO doesn't need to be involved in the details of who they delegate it to, or how that person does it, they just need to be sure that the work is going to get done. If they micromanaged to that level it would get annoying fast.
The necessity of holding people accountable is the first thing I learned when managing folks. As well-intentioned as everyone is, people consistently deliver on things that they're held accountable for. They ignore things that you never ask about or measure.
I find it's better to have a culture where everyone holds each other accountable on a continuous basis, rather than a privileged few lording over the rest periodically.
See: Valve, Github, WL Gore and Associates
Not that you can't run a company that way, but you start to introduce too much overhead for too little gain, and you start to look like the traditional, highly hierarchical, command-and-control companies. Once you start down that path, it's really, really difficult to come back.
So it's you holding them accountable, as opposed to the nebulous passive voice? As the post reads now, it was not clear whether the accountability was to you or to the leadership group.
Clarity of task is important when making the transition to mid-size company, but clarity of hierarchy is also very important. It will save you trouble later on.
Switching to a 90 day planning cycle was one of the best management approaches I ever implemented, and helped me get more done in a smaller period than I ever had before. A few reasons:
1) Shifting from an annual planning process to a 90 day plan lets you try things out faster and learn from what works and what doesn't. It also keeps you away from huge initiatives that quickly become boondoggles without breaking them down into smaller pieces.
2) Once you get to a shorter time horizon, you can get down to specific actions, rather than broad objectives. In doing so, you can actually verify if the goal is being accomplished.
3) Most companies struggle with getting one-off project work done at the same time as their normal day to day jobs. When you have a longer time horizon, people don't spend more time on the project, they just wait until the last minute to get it done. So the further off you put the last minute, the longer you're going to wait.
4) You build momentum by ticking things off the organizational to-do list at a regular clip. Keeping the pace light and fast makes sure things move forward and don't get bogged down (or if they do, that you can unblock them quickly).
5) This last one might sound simple, but when you write things down, you make it harder for people to forget to do something, or what was said, or what the expectation was.
Seems like there's a lot of parallels here between a scrum style sprint and what you're doing, except the iteration is muuuuch longer.
(ie: setting the iteration for a fixed length of time, ideally freezing the features in the sprint, post sprint review, etc).
One wonders if you could either take more practices from scrum to make this better (90 days seems like a really long sprint cycle), or if lessons from your 90DP execution could make your development practices better.
We had to go with 90 days because it gives us enough time, company-wide, to execute. Anything shorter and you're constantly changing course and distracting everyone.
Interesting. Might be something to evaluate at the end of the 90DP - sounds like you are assigning too big tasks and doing waterfall style work. Maybe it works for these things, but seems to me, "Can we iterate fast enough with a 90 day cycle? How could be cut that in half for the next iteration?" would be my first retrospective question.
> As I said, I never went to Business school so I’m now hiring folks who know how to scale companies and build out operations.
This is going to sound like a rant - please take it as free advice and worth every penny.
Don't get me wrong, the folks you hired may well be peaches and we love them. But the world has changed - Instagram scaled to ridiculous levels with 8 people and no HR department. Build out operations - you mean repeatable processes right? If they are not already scripts on a server make them so.
You don't need people who deal with the processes of scaling or building out. You need source control tools.
Everything that is repeatable is automatable. Anything being done for the first time is a human's domain.
Everything else is either scripted and so zero marginal cost or is an anchor on your profitability.
I appreciate your comment but I don't think you know what our business is. We're a school with full-time Teachers. We need to teach more and more content so we're going to have to scale our Content Team. This isn't a typical SaaS product with just an app team.
Treehouse is a bit different from something like Instagram, the product is is something that can't really be automated by computers: teaching via video. About half of the company is directly involved with writing, shooting, and editing video, split almost evenly between teachers and video professionals.
The team that manages the web app, and most of the other teams, are small in comparison, they are certainly small and effective teams that utilize automation.
I agree with your points on automation, I just wanted to point out there are still things that require human interaction and creativity to produce.
Uh-oh, sounds like a big company already. The phrase "is held accountable" is in the passive voice.
When you have to implement process in order that people "are held accountable", you are acknowledging that you have a problem: There are people in the company who would shirk some or all of a task. OK, at 50 people perhaps it's unavoidable. However, if you need to counteract shirking by being held accountable, then you really want to switch to the active voice. Where is the active subject of that sentence? It really wants the active voice. Also: What happens when someone fails on a task?