More on this book
Community
Kindle Notes & Highlights
by
Scott Berkun
Read between
November 15 - November 25, 2020
An open vacation policy had little negative impact on people who would choose to work on their own time anyway.
The decision took minutes. I'd told the team the day before that we might need to switch, and when the deadline came, we switched. No e-mail was sent or stakeholder consoled. There was no master schedule to update or conference calls to schedule. We simply posted the change on our P2, listed the remaining work for Highlander, and moved on.
It was the consequence of using schedules, having marketing plans, and executives wrapping their reputations around projects that made all of those stressful costs around making changes unavoidable.
Continuous deployment made these downsides and benefits irrelevant. WordPress.com continually added new features, each launch creating another wave of attention generated largely by customers, the best possible advocates.
Look at it myself.
possibly seen as a lack of trust.
Ask another programmer to look.
same as the first option through...
This highlight has been truncated due to consecutive passage length restrictions.
Change som...
This highlight has been truncated due to consecutive passage length restrictions.
could sharpen the goal, ask better questions, or simp...
This highlight has been truncated due to consecutive passage length restrictions.
Kill the project.
Keep going.
simply because you have a fancy word for something doesn't make you any smarter. It probably makes you stupider because you confuse your precise vocabulary with precise skills.
Clarity again is key for starting projects.
No matter what technologies you use, when half the team is waking up while the other half is going to bed, things will feel weird, at least at first.
These snack projects prevented our team from going dark in output and gave us sparks of morale.
I don't see the wider distribution of our team as the cause for our poor productivity. Instead, it was the division of labor and the low morale
Programmers are competitive by nature, and someone has to set the pace on every team, constantly demonstrating what can be done.
Success demanded a different culture.
Programmers would have to do estimates. I hadn't seen a single work estimate at Automattic. You can't be on time unless you estimate work. The first time that a team that has never done estimates before does them, accuracy is poor, as is how much they care about the consequences.
We'd need more people on the team.
Jetpack needed a simple user interface.
users' experiences had to be as simple as flipping a switch and forgetting it was there.
We'd need release management and compatibility testing.
Mullenweg clarified the importance of the project, and as a good leader should, he offered whatever resources I needed. It's a great bullshit test of any boss who says, “X is important.”
If she doesn't match that statement with resources, she's incompetent, insincere, or both.
Importance is always relative to other projects, not verbal fairy dust to sp...
This highlight has been truncated due to consecutive passage length restrictions.
The natural mistake engineers make is to build from the bottom up. They leave the user interface last, assuming it is the least complex technology. This is wrong. Humans are much more complex than software, and since the interface has to interact with people, it's the most difficult to do well. By building from the bottom up, technologists paint themselves into a corner, resulting in ugly, hard-to-use things. By the time they finally got to the user interface work, so many constraints exist that even the best designers in the world couldn't salvage the project.
it doesn't need a sales team because the product sells itself.
Teams create territories. This is a force for good since it helps people focus and feel pride. But it creates problems for projects that fall between teams. If you try to cover everything, the teams are unfocused, and if you cover too little, there's no room for growth.
Organizations become bureaucratic as soon as people define their job around a specific rule, or feature, rather than a goal.
We haven't had a slide deck in years,” was what he typed over Skype).
raises and bonuses simply weren't as central to how people thought about their jobs.
the more complex performance reviews become, the less effective they are.
Employees can yell and complain, but there is no louder message to management that something is wrong than forcing them to watch a great employee walk out the door.
WordPress was filled with layers of distracting complexity, a classic symptom of engineer-led design.
it was simply easier for designers, and everyone else, to avoid tough problems like ease of use and stick to the safety of fixing bugs or adding new features, even though new features contributed to the decline of simplicity.
If we couldn't show polish for one of the few things we make every visitor to WordPress.com see, we had no right to claim that we cared about quality design at all.
Ideas are evaluated differently depending on the mouth they come out of.
people tend to respond to the most recent thing, not the most important thing.
I'm all for incrementalism but some projects are harder to take on this way.
If Toni and Matt wanted more people to take risks, they needed to hire and coach for it, which worked against the hands-off, autonomous culture they'd created.
A good sign as a leader is when output is high and meetings are short. This means all pistons are firing, there are few roadblocks, and things are on track with just a soft touch. It also means meetings can be used to stay ahead, flagging issues before they become blockers.
Managers often wrap their egos around meetings, and long meetings ensure they always feel that they're the center of attention, even if the meeting is a waste of time for everyone else.
even when working within a list of postponed things, you still postpone things no one wants to do.
The real story behind some people you meet with fantastic reputations isn't notable talents or skills, but merely an exceptional ability to choose the right time to join and leave particular projects.
We all make judgments of ability at the most superficial levels. If the results are good, we give praise. If the results are poor, we criticize. We rarely give credence to the feeling in the back of our minds that the winner or loser doesn't quite fit the part.
the truth is how a leader handles things going wrong—not the show that happens in front of crowds but in the daily meetings and decisions where there is no audience.
If they genuinely share credit but take the lion's share of blame, you might just have someone sincerely invested in doing what's best. A leader who shields others from things that get in the way inspires everyone to do the same.
The conversation centered on the same four big personal questions I asked everyone in e-mail once a month: What's going well? What's not? What do you want me to do more of? What do you want me to do less of?