More on this book
Community
Kindle Notes & Highlights
Half the battle is the ability to translate, not just knowledge of how to fix things. Knowing how to fix things doesn't help if you can't figure out what's wrong.
A great fallacy born from the failure to study culture is the assumption that you can take a practice from one culture and simply jam it into another and expect similar results.
No technique, no matter how good, can turn stupid coworkers into smart ones. And no method can magically make employees trust each other or their boss if they have good reason not to.
Few people have the skills to evaluate, much less change, a culture, even if they have the courage to try. It's far safer to simply wait for the next trend to come along and rally behind it, hoping the excitement for the new method distracts everyone from noticing how little impact the previous method had.
A classic betrayal of this idea is when the IT department dictates to creatives what equipment they can use. If one group has to be inefficient, it should be the support group, not the creatives.
My theory on meetings was simple: if what is being discussed is important, people will pay attention.
Making lists is a great way to clarify thinking. You put down thoughts, refine them, order them, and even share them with other people. And if you're willing to do the hard work of putting a list in priority order, you can condense great visions into a few simple sentences. The first thing I tell teams of people who are struggling is ML: Make a list. Write down the list of problems to solve or issues to fix. Get it out of their brain and on paper. It's less stressful when its written down. Then put them in order of importance, with an order that everyone understands: what comes first, what
...more
The inability to scale is one of the stupidest arguments against a possibly great idea: greatness rarely scales, and that's part of what made it great in the first place.
He thought I'd do fine, but that the best results would require commitment to improvisation. It was fantastic advice.
The nonmakers are in charge of the makers and insist on spending the off-site not making anything.
A simple process affords three things: 1. It is easy to launch projects. 2. If it's easy to launch, small projects will get launched. 3. If small things are launched, there is a fast feedback loop about what worked and what didn't, which can be quickly improved because of #1.
The fundamental mistake companies that talk about innovation make is keeping barriers to entry high. They make it hard to even try out ideas, blind to how much experimentation you need to sort the good ideas from the bad.
More than anything else, I recognized that the big cultural bet wasn't on process but on people. Instead of betting on the enforcement of an elaborate fifty-step process or the magical talents of management, Automattic put the onus on individuals.
Half the challenge of being a project manager is the things you must deal with that have nothing to do with your own team.
With about five people, there's always enough oxygen in the room. It means on average that every person gets to speak once every five times, which is enough for everyone to feel they are at the center of things. At this level of participation, their pride can be invested in the team instead of focused inwardly on themselves.
“Man is after all a finite being in capacities and powers of doing actual work. But when it comes to planning, one mind can in a few hours think out enough work to keep a thousand men employed for years.”
He told me the central way he'd evaluate me was the quality of what made it out the door.
Although my job title was program manager, I wasn't granted power to run around making demands all day. There would be days I'd need to make demands, but I'd have to earn them. I had to earn the respect and trust from the programmers and designers I worked with. With trust, everything was possible.
And as the days at Seaside went on, I had to bite my tongue every time my ego came up with something to say or do to force myself into the center of the work.
When a new team forms or the central project gets cancelled, there are lingering doubts on everyone's mind. And the more unusual the circumstances are, the bigger the doubts are. Leaders have two good choices with that uncertainty: use that tension to your advantage or diffuse the tension. I'm the kind of leader who kills uncertainty. I want to identify the doubts and nail them to the wall. They might linger there for weeks, but by making everyone's private fears public, they become far less dangerous.
Experiments were awesome. The only way you learn is by doing things where you don't know the outcome. The only problem with experiments is not when the go wrong, but when you can't end them.
Bringing it up together surfaced those doubts so we could work out answers together. As the lead, I could raise these issues without being confrontational, whereas they could not. So I did it.
Like a company that changes its floor plan from private offices to an open floor plan, public P2s didn't completely eliminate privacy; it just changed the rules.
All traditions are inventions; it's just a question of how old the invention is. There is nothing wrong with tradition until you want progress: progress demands change, and change demands a reevaluation of what the traditions are for and how they are practiced.
The responsibility of people in power is to continually eliminate useless traditions and introduce valuable ones.
Schneider described his philosophy in this way: 1. Hire great people. 2. Set good priorities. 3. Remove distractions. 4. Stay out of the way.
Granting authority is more powerful than any software, device, or method.
In his classic book The Soul of a New Machine, Tracy Kidder noticed that Data General's efforts to hire people with strong internal motivations changed things: “Labor was no longer coerced. Labor volunteered. When you signed up you in effect declared, ‘I want to do this job and I'll give it my heart and soul.’”
Degree programs are highly structured and have the greatest appeal to people who depend on structure.
In some ways, the power they offer individual contributors is greater than what middle managers at large Fortune 500 companies have.
A trick of leading creative teams is finding creative ways to nag people. You get more mileage if you make people laugh, even if it's at themselves, at the same time you're reminding them of something they've forgotten.
The realization that everyone is different when you talk to them alone is a secret to success in life. In private you have their full attention. If you talk to two children in front of their mom and then each alone, you hear different things. The mystery for why some people you know succeed or fail in life is how courageous they are in pulling people aside and how effective they are in those private conversations we never see.
The same goes for speaking the deepest truths and having them heard. Almost no one can convince an entire conference room of coworkers with a speech. That happens only in the movies. Some things are never said, or heard, if more than one pair of ears is listening.
Regarding clarity, most teams in the working world are starving for it. Layers of hierarchy create conflicting goals. Many teams have leaders who've never experienced clarity in their entire lives: they don't know what to look for, much less what to do when they find it.
Design was the ultimate provider of clarity. In situations involving technical details I didn't understand, the saving question was always, “How will this impact the user experience?”
As long as programmers and I identified the alternatives, I could ask, “What are the pros and cons of approaches A and B?” Raising the level of thinking to trade-off decisions allowed me to have valuable input on technical decisions I couldn't fix myself.
Provided there were clarity and trust, my lack of programming ability was an asset provided I took advantage of the perspective it offered our work.
Leadership centers on abstractions and trade-offs: Is X faster or Y? Is A more reliable than B? Is Sally a better programmer for this than Bob?
Being a good lead is all about switching hats: knowing which level of abstraction to work at to solve a problem. It's rarely a question of intelligence; instead, it's picking the right perspective to use on a particular challenge.
Anthropologically speaking, the way you study this is simple. Much like how you'd tag a wild tiger with a radio collar to observe what it does in the wild, to evaluate a culture you pick an issue. Then you watch and ask: How and where do issues get reported? Who responds? How long does it take? Who decides what issues are worked on first (triage)? Who decides how the thing will be fixed? Who does the actual work? Who checks to make sure it was done properly?
On Team Social we tracked issues in the simplest way possible: we made lists. As programmers fixed them, we crossed them off. It was easy to see how many were fixed and how many were left, or to add comments to a particular issue. Where it failed was triage: all bugs tended to be treated equally. Important issues, trivial issues, challenging bugs, and easy fixes were all listed in the same way. The common designations of priority (Is this priority 1, 2 or 3?) and severity (Are we deleting customers' blog posts, or did we just misspell something?) didn't exist.
A few days later, another person reported the LinkedIn issue. Finally Mullenweg reported it too. The volume of reports increased, ending my fire experiment. I asked Beau to take a look and sort it out. The lesson wasn't surprising: mostly what I learned was that I wanted a better way to prioritize defects. Depending on anecdotal reports from users was a poor system. It'd be like running a restaurant where you waited for customers to complain about the food instead of tasting it ourselves before it left the kitchen. But I stayed patient. I floated my observations now and then, but I'd wait
...more
The trap is that even if you find a good metric that avoids the trap IBM fell into, people will naturally, even subconsciously, work to game the metric. They want to “do good,” and once leaders put up a scoreboard that everyone sees, it has unexpected power.
All metrics create temptations. Even with great intentions and smart minds, data runs you faster and faster into a stupid self-destructive circle. Data can't decide things for you. It can help you see things more clearly if captured carefully, but that's not the same as deciding.
When a culture shifts too far into faith in data, people with great intuitions leave.
When I was hired, I paid attention to how Mullenweg commented on discussions on various P2s. He frequently linked to charts and tables relevant to the discussion. Although he was not using these as a hammer to end arguments, he regularly referred to data as part of his thinking. He wanted a data-influenced culture, not a data-driven one. He didn't make data the center of the conversation but wanted to ensure they were part of it. His balance of respect for both intuition and analysis was one of his most notable qualities.
The fear of big mistakes or falling behind schedule is what motivated most of the project management processes used around the world. The more experienced that managers are, the longer the list of bad things they've seen that they're trying to avoid. This is what I call defensive management, since it's designed to prevent a long list of bad things from happening. Defensive management is blind to recognizing how obsessing about preventing bad things also prevents good things from happening or sometimes even prevents anything from happening at all.
The worst builds were called self-toast, meaning you'd destroy whatever machine you had dared installed it on. Whenever we had three days in a row with self-toast builds, all new work stopped until we got the build quality up to a good level (a measure to prevent the project from digging a dangerously deep quality hole for itself).
safeguards don't make you safe; they make you lazy.
Employees were treated like adults. By not having too many safeguards, we were trusted to pay full attention. Keeping things a little dangerous made things safer.
