Project Management

“How many meetings should I have?” is an important question that programmers don’t spend a lot of time thinking about, except to complain that we’re having too many. We’re pretty sure managers should be having a lot, and programmers only a few. But how few? We know that if programmers have zero meetings then they get to build stuff that no one will ever use. We also know that if they have too many meetings then they don’t get to build stuff. There’s a correct number in between there, and SCRUM has a good answer for that. ...

In 1984 Microsoft decided to port MacWord to Windows. They expected it would take about one year. It did not. It took five. In one of the many, many great documents unearthed by the Comes v. Microsoft antitrust lawsuit is this great postmortem of what went wrong. The Opus Development Postmortem is 47 pages long, and should be mandatory reading for all project managers. The timeline WinWord dreamed up in August 1984 Prototype demoed in September 1985 Real work begins in November 1985 Windows 1.0 ships in November 1985 Windows 2.0 ships in November 1987 WinWord ships November 1989 Small Notes and Select Quotes Management of the development team, from within and from above has been one of the major failures of this project. ...

When there are failures at a small level, like a deployment goes wrong, there’s a meeting, and a blameless post-mortem written is shared publicly. Normally this happens quickly, while everyone’s memories are still fresh. When entire projects and movements fail, the opposite happens. There are no public post-mortems, and no meetings. A couple people leave the company, some blame is privately assigned, and the rumor mill goes into overdrive. At this level, a failure can mean a derailed career. ...

Here are my notes for week 2 of my product management education. This week is all about metrics, goals, and strategy, with a dive into Pirate and HEART metrics. A metric measures progress towards a goal. The PM should only focus on features that help achieve that goal, although there will be multiple goals to juggle. Pirate (AARRR) Metrics Pirate metrics are about measuring the user’s lifecycle. Acquisition - How users find you. Activation - When users have their first defining experience. Retention - How often a user returns. Revenue - How you make money. Referral - How users are recommending the product. You want to have measurements in each stage. You want to balance them. Some metrics are destructive pairs. Like acquisition and retention (it’s easy to spike a new-users metric in ways that won’t increase retention at all). ...

I’ve started an online Product Management class because, I dunno, I like learning new, non-coding things related to my job. I’ll be posting all my notes here. A PM effectively solves user problems while meeting business needs. (Product manager is not the mini-CEO of the user. We are responsible for the success or failure of the product.) A PM knows that there are questions that need answering before development starts. ...

In the aftermath of GE’s price fixing scandal, we learned that GE executives had a culture of winking while they told subordinates not to break the law. Sometimes. Each salesperson had to interpret the word and the wink, and the occasional lack thereof, according to their own internal rules. Effective communication was, effectively, absent. Suppose, purely as a hypothesis, that the owner of a company who orders his subordinates to obey the antitrust laws has such poor communication with himself that he does not really know whether he wants the order to be complied with or not. If his order is disobeyed, the resulting price-fixing may benefit his company’s coffers; if it is obeyed, then he has done the right thing. In the first instance, he is not personally implicated in any wrongdoing, while in the second he is positively involved in right doing. What, after all, can he lose? ...

There is one scene that gets referenced several times in Rapid Development by Steve McConnell as an example of a hugely productive team. Witness, 1985, Barn Raising Scene

If you’re responsible for a large, legacy code base, here’s my hint to you: delete your failing tests. Good code bases have a large suite of unit tests, probably around 80% coverage, that are run automatically by integration scripts. Getting to this is step one. Step two is managing those tests, and the most important job now is to make sure they aren’t failing. Unfortunately, in any large code base, failing tests are everywhere. ...