The Apple 8.0.1 Debacle: Whom to blame?

Marc Andreessen drew my attention to a Bloomberg article that laid out what it purported to be “links” with the failed Maps launch. @pmarca was properly skeptical of the article:

And indeed, the piece starts in on the leader of the quality assurance effort, noting that:

The same person at Apple was in charge of catching problems before both products were released. Josh Williams, the mid-level manager overseeing quality assurance for Apple’s iOS mobile-software group, was also in charge of quality control for maps, according to people familiar with Apple’s management structure.

If you didn’t read any further, you’d think the problem was solved. Some guy wasn’t doing his job. Case closed.

But are quality problems ever so simple? After all, Isn’t quality supposed to be built into a product? If this guy was the problem, then why was Apple leaning so heavily on him to lead its bug-finding QA group?

Well, reading on is rewarding, for it becomes clear that the quality problems at Apple run deeper than a bad QA leader. For example, turf wars and secrecy within Apple make it so:

Another challenge is that the engineers who test the newest software versions often don’t get their hands on the latest iPhones until the same time that they arrive with customers, resulting in updates that may not get tested as much on the latest handsets. Cook has clamped down on the use of unreleased iPhones and only senior managers are allowed access to the products without special permission, two people said.

Even worse, integration testing is not routinely done before an OS feature gets to QA:

Teams responsible for testing cellular and Wi-Fi connectivity will sometimes sign off on a product release, then Williams’ team will discover later that it’s not compatible with another feature, the person said.

So all you Apple fans, just remember the joke we used to make late in a project: “What’s another name for the release milestone? User Acceptance Testing begins!”

Project’s End: The Career Progress Dilemma

In more than one project, there’s been lots of happy talk about people’s future roles in the organization. Yet everyone knew that some colleagues simply wouldn’t have a place after the project, including themselves.

Beyond the formal career path discussions — if such things exist in your firm — I suggest that one should be very clear about the fact that this is a project. It’s incumbent on the project team to think about “what’s next?”. My experience is that while project may not lead to something within one’s own company, what it can lead to may be even better. As long as firms are clear about this potential trade-off, they’ll be able to recruit a better mix of colleagues to the project team.

To that end, I was struck by the Alliance approach suggested by two principals of LinkedIn itself: Reid Hoffman and Ben Casnocha. Follow this link to an Econ Talk podcast and further information. A longish quote (Ben, I believe) from the podcast transcript will give you flavor of their argument:

[A]ctually I think one of the themes we are navigating here in The Alliance is both trying to get employees to sign up for an inspiring company mission. At the same time, you the company are trying to understand what that employee’s personal mission or vision is in their own life. And trying to define it toward the view that it’s both of those missions at once. Right? So it’s no longer: Subsume yourself toward corporate mission–rather than: Hey, maybe your long-term vision is you want to start your own company someday. Or you are really interested in some other field in addition to this field. So you are going to sign up for a tour because you care about our mission, sure. You really care about your mission. And we’re going to make sure that this tour of duty helps you get closer to being able to fulfill that mission. But it’s that recognition of the fact that there may be some difference. And that you are only looking for sufficient alignment, for a specific tour of duty.

Adapted from a LinkedIn comment regarding this post by Don McAlister.

The Incentive/Behavior Nexus

Steve Kerr uses a General Motors cautionary tale to show us that it isn’t enough to have incentives that appear to reward desired behavior. In this HBR blog post, he notes that:

Although managers’ bonuses are based partly on vehicle-quality improvements, and safety is supposed to be paramount, cost is “everything” at GM, and the company’s atmosphere probably discouraged individuals from raising safety concerns. Earlier this summer, a former GM manager described a workplace in which the mention of any problems was unacceptable.

Kerr’s critical insight is that while GM could point to formal quality incentives, these incentives didn’t have the required impact on its managers’ behavior. The money quote for me is this:

In order to properly align its incentives to support its mission and objectives, a company must determine what managers and employees believe they are being encouraged to do and not do.

Doubts about BYOD promotion schemes

[The proposal of a BYOD (Bring Your Own Device) communications campaign] strikes me as a bit too “happy/clappy” about promoting BYOD adoption. Explaining the process won’t address deep-seated privacy concerns like Peter Nolan’s. If done the wrong way, such promotions smack of the old IT “if we explain it to you lunkheads one more time it will sink in” mentality.

I started as a BYOD advocate and I’m OK with it for myself, at least for certain devices (e.g.,work email on a personal tablet). However, if we in IT want to control devices, we should expect that some won’t want to hand over their personal property. Therefore, if we want to control them, we should be prepared to provision them.

Also, I’m just not sure that BYOD is a great lever for preventing shadow IT. My suggestion would be to start with a more open IT portfolio process, which would ensure that everyone buys into what’s proposed, being executed, and how approvals and controls work.

Adapted from a LinkedIn comment on this post re: shadow IT and trust as a strategy to prevent it.

New Study on Organization Change Management Failure

[The study delivers] a tough, but needed, message. HR leaders get thrown under the bus for these projects too often, which leads them to reach for visible, but ineffective, change implementation tactics.

To that end, I really like the point about realism re: expectations. Many change initiatives are heavy on marketing-style communications, which are easy to produce and point to as a tangible work product. But they’re often only one-way messages about how great the Brave New World will be. A multi-layered stakeholder management approach is a lot tougher, requires sustained effort over time, and has less-tangible payback.

Ultimately, function and process leaders need to own the change initiatives for their areas, which is why CEO ownership and involvement — again, sustained over time — is so critical. Line managers and staff won’t respond if it’s just a speech, new PowerPoint templates, and a monthly newsletter. They will wait until the change project is noticed, measured, and rewarded by the leadership team.

Adapted from my comment on a LinkedIn post re: this Forbes article from Victor Lipman: “New Study Explores Why Change Management Fails – And How To (Perhaps) Succeed“.

IT Cost Levers

Caught this post on Apptio’s blog re: optimizing IT budgets. It summarizes a Gartner report — I’ve seen earlier versions — which is interesting and Apptio will provide the report if you provide them your contact info. The analysis:

…breaks down IT spending and identifies four best practices for strategic IT budget management. Of these, the recommendation to “follow the money,” is of key importance to IT leaders. Knowing where the IT budget currently gets spent is the most important part of your budget strategy.

The post then highlights the top four areas of spend, which typically make up around two-thirds of an IT budget: Data Center, Application Development, Application Support, and End-User Computing.

One point: the separation of mobile topics into the categories of “End-User Computing”, “Data Networking”, and “Voice Networking” is both useful and potentially confusing. It’s useful because it reminds us that just because we get billed for mobile in one package, we should decompose the costs like we would for other capabilities. It’s worth the time to break bundled costs down: you may need to differentiate service levels among your customers or find that mobile is providing capability that makes other options redundant (e.g., mobile hotspot vs. reimbursing WiFi/home cable subscriptions).

It could be confusing because the costs aren’t as easily severable as other capabilities. In other words, trying to economize on a data plan may mean we lose credit on voice or device costs. In fact, the model itself is very PC-centric in that way: each of these cost drivers is typically provided in separate invoices or line items. Even worse, if you do try to account for it in a model, I’ve found my telecom staff can get deep into the weeds trying to model those last few mobile dollars.

Quick, useful programming learnings?

From a Quora question: What can I learn right now in just 10 minutes that could be useful for the rest of my programming career?

This was an excellent answer that focuses on planning for code vs. jumping right in. I learned this working with my son on his Scratch game. When it had a bug, I had to steer him back to the storyboard, then back to diagnosing the problem.

Answer by Jeff Darcy:

That programming is about solving problems, not writing code.  Here are the four basic tasks that an individual programmer must perform.

  1. Define the problem (requirements and constraints).
  2. Define the solution (algorithms and data structures).
  3. Express the solution in code.
  4. Prove and/or test correctness.

A lot of people get really good at #3 because it’s by far the easiest, but never master the other parts and as a result remain mediocre programmers at best.  Often a good programmer can solve a problem without writing any code at all, by using their knowledge and experience to avoid a problem or find solutions that don’t require new code.  In a team, an experienced programmer can often contribute most by helping people with the other non-coding tasks, including a vast array of tasks and skills that don’t even come into play for an individual working alone (and were thus left off the list for the sake of brevity).

Once you’re proficient in using the tools of your trade, further expertise comes from understanding a particular problem domain other than programming.  It might be something serious like physics or medicine.  It might be something venal like ad targeting or high-frequency training.  It might be something frivolous like games.  You might switch specialties several times during your career.  In any case, being a great programmer means applying the technologies and techniques at hand to some goal other than programming itself.

 

Follow

Get every new post delivered to your Inbox.

Join 1,577 other followers

%d bloggers like this: