Zitat des Tages von Steven Sinofsky:
I've always advocated using the break between product cycles as an opportunity to reflect and to look ahead, and that applies to me, too.
When you delegate work to the member of the team, your job is to clearly frame success and describe the objectives.
Assuming a specific resource is high cost is often a path to disruption when someone makes a different assumption.
The best work for creative folks on the team is when the problem is big and the solution escapes everyone.
The industrial revolution that defined the first half of the 20 century marked the start of modern business, typified by high-volume, large-scale organizations. Mechanization created a culture of business derived from the capabilities and needs of the time.
When you build a product, you make a lot of assumptions about the state of the art of technology, the best business practices, and potential customer usage/behavior.
Continuous productivity manifests itself as an environment where the evolving tools and culture make it possible to innovate more and faster than ever, with significantly improved execution.
As much as we think of performance management as numeric and thus perfectly quantifiable, it is as much a product of context and social science as the products we design and develop.
No matter how you look at it, one person cannot be evaluated and paid in isolation of budgets.
Disruption is a critical element of the evolution of technology - from the positive and negative aspects of disruption a typical pattern emerges, as new technologies come to market and subsequently take hold.
From a product development perspective, choosing whether a technology is disruptive at a potential moment is key.
It's not cool to have your name in print when it's not the truth.
BlackBerry required tethering for some routine operations, and for many, the only way to integrate corporate mail was to keep a PC running all the time.
While my friends were busy listening to the Talking Heads, Police, and B-52s, I was busy teaching myself to program on the Atari.
When faced with something complex, spend the time to think about some structure, write down sentences, think about it some more, and then share it.
Macintosh felt like a system. As I learned more, I felt like I was able to guess how new things would work. I felt like the bugs in my programs were more my bugs and not things I misunderstood.
