Great point here: "One simple jewel of advice given to me by one of our senior software engineers, Joseph, was that if we shared our motivations as decision makers (e.g. "We're working on this project to generate revenue in the short term, instead of infrastructure improvements because we're trying to hit a short term revenue goal
of X") it helped him understand why he was working on a project, and which aspects of that project to spend time thinking about improving."
Sources of Power by Gary Klein[1] is a great read about decision making and there's a whole chapter about communicating intent and motivation.
"When you communicate intent, you are letting the other team members operate more independently and improvise as necessary. You are giving them a basis for reading your mind more accurately."
The U.S. Army actually uses a Commander's Intent statement, which was streamlined into:
- Here's what I think we face.
- Here's what I think we should do.
- Here's why.
- Here's what we should keep our eye on.
- Now, talk to me.
Obviously this can be applied to any organization. It's always in your best interest to tell someone why they should be doing something and not just what they should be doing.
This is how I build consensus or vet out ideas with a team. I make a statement for a solution based on the information I have, and ask for a better solution from the team, for them to poke holes in it or simply ask "please tell me why this wont work".
Invariably, you get a lot of good thought.
The reason I have found over the years is that great designs are iterative and by giving out a starting point - even if it is wildly wrong, the team can use that to build upon.
If you simply say "give me a design" you get a lot of hesitancy, especially when in a group environment like a whiteboarding with the team.
If you say "here is an idea, whats wrong with it" you get a lot more engagement from the team because the people involved don't have anything at risk, instead each individual only stands to gain should they be able to improve the design.
If there is a headstrong tech in the group who is divergent in opinion, this approach can provide him with an opportunity to say exactly why his opinion differs and an alternate plan inclusive of his comment can be drawn in parallel and then either direction can be taken. with the other plan as a backup.
> Having a hierarchy isn't a bad thing. Having no idea who has the final say is a bad thing.
This is an absolutely classic rule of managing any organisation where competing priorities must be settled.
Chains of command have a very high cost, but they can ameliorate internal politicking and remove uncertainty about what, if anything, has been decided.
However, decision making power must come with accountability for the decisions, or it will NOT turn out well.
A purely flat organisation will wind up with de facto bosses, minus any institutional constraints on their activities and minus any accountability. If you're dealing with a sociopath the damage they can wreak will be magnified by the lack of structure to constrain their power.
How does a purely flat organization lead to no constraints or accountability? In a flat organization every member needs to be responsible for actively upholding the organizations vision in the same way that this article is advising the managers need to actively uphold their companies vision.
It's the lack of an active vision that creates problems not the hierarchical or flat structure of the organization.
For example a democratic process can be used to maintain an organizations active vision including resolving disruptive people and processes.
It leads to unconstrained, unaccountable behaviour because nobody has any clear procedure for punishing divergence from the group's interest. There is, if you like, no "immune system". In such an environment parasites thrive -- and indeed a major driver of both evolution and civilisation is adaptation to parasitic behaviour.
The idea of a democratic process presupposes an institution, which includes explicit divisions of power, which is independent of the individuals taking part.
It is still a hierarchy as someone will hold the power. It is an explicit hierarchy because those powers are enumerated. That the process of replacement is democratic is slightly besides the point (though not entirely, as it prevents all-or-nothing power acquisition).
Whereas a loose, "flat" organisation with no differentiation between the rights, responsibilities and power of members is utterly vulnerable to the first sociopath who happens upon it. Such a person will wind up with an informal dictatorship and everyone else will be stuffed.
The problem with direct democracy is the same as for voluntary voting: voters on the fringe, who are more highly motivated, will come to dominate the polity.
Oh god, that is the worst. I have seen this plenty of times. Boss won't give direction because either he is intimidated or, he is the "idea man" who shouldn't have to be bothered by implementation. It's fine if you want the dev to just wing it, but you have to align expectations constantly. I ping senior management at least every couple days with screen shots or questions asking for input, even if they never read my emails, I want to be able to say that I informed them of exactly what direction we were taking and that they had input.I keep my PM looped in on almost every email I send just incase someone pops into his office he won't have to say "I don't know" if someone asks him where the project is.
Even then, we still run into "misfeatures". I have no idea how you could tell a dev to wing it, let him work for months with no oversight and then be shocked when he came back with something unexpected.
I have no idea how you could tell a dev to wing it, let him work for months with no oversight and then be shocked when he came back with something unexpected.
I hope he's exagerating the examples for effect. It can't really be that idiotic, right?
"
Instead, get rid of people you don't trust enough not to micromanage. If you look around and that's everyone, then the problem is probably with you...
"
Good stuff. I think leaders in general need to be more proactive pruning their employee tree if they want it to bear good fruit.
I'm amazed how difficult it is for managers to admit that they made a hiring mistake, even if the person that needs to go is just a contractor.
Most managers I know would love to have the ability to prune and rehire staff to rebalance teams and optimise skills, enthusiasm etc. However in many cases (particularly in big companies), managers have very little say in their headcount numbers - most of it being controlled by HR who in turn are watching the bottom line.
As a result, HR can often make it extremely difficult, if not impossible, to hire backfills or additional staff and hence managers quickly learn that it is better to retain a 60% effective person than have no-one at all.
This lesson is even further reinforced when managers are forced to sack staff to hit some corporate cost take-out target which means they have to cut staff regardless of the teams actual resource needs and without the 'low performers' in the team, you would have to cut the good performers.
It's a sad state of affairs, but one I've seen on so many occasions.
Most managers I know would love to have the ability to prune and rehire staff
I bet they would, but such a system would be wide open to abuse. So the market has fixed it: contractors. You can get rid of them easily when no longer needed, but you pay a premium while they are.
Empowerment does not mean letting everyone do whatever they want.
A real gem (describes many "ghosts of employers past"). Most employees don't even want to do "whatever they want" since they know at the end of the day they have a job to do and if they're doing "whatever they want" it means they're flying blind and hoping they don't crash.
This article hit a lot of buzzers for me from my last job. Especially the signs there may be a problem. Burnout was rapid and high, confusion abounded, and so on. If I still worked there I'd email it to my coworkers so we could ruminate on how spot-on it described the office.
Justin, what a great story about self-realization and growth. This is a very common problem among young, successful, technical entrepreneurs. But it seldom turns out as well as it did with you. Good luck and Godspeed.
Was not meant to be at all. Hang around the valley long enough and you'll see this happen a million times. I've been that technical founder and I've worked for the same type of guy. Self realization is difficult as is forced growth. Justin struck me as a real leader and a real example to technical founders. Job well done.
Yes, good points all. It's also one of the hardest things to do when it's your business. I've been running my company for over 15 years. It's STILL hard to let go sometimes.
The best you can do is try, and ask your employee's forgiveness when you slide back into micromanaging.
One good way to move the process along: Never let an employee come to you with a problem unless they have 2 possible solutions. The solutions can be ridiculous, but they need to have 'em.
It gets them involved in the decision-making process from the get-go, and tends to prompt discussions among team members before you, the manager, has to get involved.
Although great points were made in the article, I find this to be a failure on the part of the CEO and COO. Their individual profiles on justin.tv are both vague and lacking in focus; public statements often reflect management styles and objectives. If the key directors of a company don't direct, the whole company will suffer regardless of the number of management books they read.
"Vague problem definition: "Create an automated test suite for the website.""
This is not a vague problem definition. And "Create an automated test suite for the website." is not "I just wanted something that pinged five URLs and checked for 500s."
The problem definition lacks concrete measurable goals that identify when the problem solved. Without those, there is much room for interpretation and disagreement and the actual problem isn't well-defined. It only seems well defined, because you instantly fill in the gap in your mind.
It's unclear when the manager would consider the website 'tested'. If a manager said something like this and the first thing that came to mind was 'Selenium, full test-suite, 1 month', then the next thing to come to mind would be "that's probably not what he meant, since he doesn't want me gone for a month'.
This is a case of where "commander's intent" would have been useful.
"We need to ensure that the site remains up. It would be helpful to know very quickly when it goes down. I need you to write a test suite to do that."
Without the framing of knowing why something is asked for, the risk is that the work will zoom off in unexpected directions, or, just as bad, get stuck on a triviality.
Staff can do their bit by asking for intent, if the corporate culture allows it.
We call it "definition of done", e.g. the project is complete where everything on this list is true. This is agreed upfront with the stakeholders/sponsor/whoever.
Sources of Power by Gary Klein[1] is a great read about decision making and there's a whole chapter about communicating intent and motivation.
"When you communicate intent, you are letting the other team members operate more independently and improvise as necessary. You are giving them a basis for reading your mind more accurately."
The U.S. Army actually uses a Commander's Intent statement, which was streamlined into:
- Here's what I think we face.
- Here's what I think we should do.
- Here's why.
- Here's what we should keep our eye on.
- Now, talk to me.
Obviously this can be applied to any organization. It's always in your best interest to tell someone why they should be doing something and not just what they should be doing.
[1] http://www.amazon.com/Sources-Power-People-Make-Decisions/dp...