Excellent timing. I'm just coming out of one start up that is now up and running successfully and about to launch another. I wish I'd had some of this advice with my previous company.<p>When we were first setting out I tried to micro-manage everything and while I got things done I nearly burnt out in the process. Assigning roles and responsibilities and holding people accountable to them is an infinitely more sensible approach to management!<p>It's also very easy to be busy when you're running a company. Too easy in fact, and equally easy to work on the wrong things. So to combat this I now follow these steps:<p>1. Identify a goal that contributes directly to useful output (e.g. shipping a product to actual users, making a sale, etc)<p>2. List the steps necessary to reach this goal. Make sure the steps are listed sequentially and that each step is actually necessary to achieve the next one. Eliminate "nice-to-have" steps or "targets of opportunity."<p>3. Do those steps, and postpone everything else. If some other tasks starts nagging on you, just put it off and tell yourself that you can do that after you finish the sequence of steps. Don't ignore it, just postpone it. Tell yourself that you are going to do it later.<p>As a result I now find myself less distracted by work that doesn't contribute to our big goals.<p>* Steps are from <a href="https://www.quora.com/What-are-some-ways-to-work-smart-rather-than-just-working-hard" rel="nofollow">https://www.quora.com/What-are-some-ways-to-work-smart-rathe...</a>
Two things stuck out to me.<p>A lot of the roles/responsibilities stuff is very similar to Holocracy. Like a lot of methodologies, Holocracy may be better taken loosely. And flexible, but clear roles is one of the nicer things from that world.<p>And the bit about having teams work on only one project at a time has a lot of backing in the book Principles of Development Flow. A lot of things done in the name of efficiency actually slow things down. And packing in your spare cycles with extra projects is definitely one of them.
the truth is, this lesson does not fit those who are bootstrapping their first startup or product, when you have no choice but to work in the trench and do the heavy lift _yourself_, once your first product hits, then come back and read this story for improvements.<p>99% fails before passing the first product ship.
I love the idea of honestly acknowledging the tensions in a company, making it clear that they're there and talking openly about them.<p>Companies basically never do that, I assume because if you then <i>don't</i> do anything about the tension, employees get the attitude, "oh, management already knows about the problems and doesn't care. Guess I won't worry about doing better."<p>Of course, the proposed solution here is to just make the tensions public, which seems like it would fall instantly into that trap.
Anyone in any leadership position really should read The Logic of Failure by Dietrich Dorner. It covers the most common things that cause smart people who are experts on their subject matter to fail in complex situations. Overly broad focus, overly narrow focus, ignoring big slow changes and over reacting to small quick changes, making too many changes too rapidly to see their individual effects, etc. I think it's a great compliment to the tips in this article.
I work in a company which provides service/access to a certain kind of data, and I always roll my eyes when executives trot out the "We're a technology company" line.<p>No, if we were a technology company, we'd actually care about reinvesting in things like build-systems, rather than ignoring the technology until they want quick hacks to help salesmen make quota in the last month of the year.
Not related to the article, but can we talk about how fun those little bars at the top of articles are that tell you how far down you've read? I love those. Such a nifty idea.