Bill Atkinson...who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
...He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2,000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
Get embedded in the team. Designers should use sprint planning, grooming, standup, and retro as opportunities to provide design to — and receive feedback from — the rest of the team. Designs can take the form of written or verbal descriptions, not just wireframes and high-fidelity mockups.
Only design what’s needed. Use constant communication between engineering and product partners to understand what your collaborators will need next. Then, plan on delivering only what is needed, and nothing more. Use the agile process — grooming, planning, and retro — to find any shortfalls or excesses.
Avoid creating a backlog of designs. Designs don’t age well. In the time between finishing design and shipping code, it’s likely that you’ll learn something new that changes your understanding. If you’re producing more design than can be implemented, focus more on the quality of each design.
Central planning has been repeatedly shown to give poor results (consider the Russian experiment, for example, or our own bureaucracy). The persons on the spot usually have better knowledge than can those at the top and hence can often (not always) make better decisions if things are not micromanaged.
Direct Management does not include or permit the concept of profit to occur. The management is fee-based, or based as a fixed salary, and all construction costs are fixed ahead of time, and the building design is modified during construction, to make up any over-runs. The manager is not able to move money around at will, or put it in their pocket. At the same time, the design is approximately fixed, but with the understanding that it may be changed, during the evolution of the building, so that subtle adaptations can be included in the emerging building. In the Direct Management method it is the architect themselves and the direct manager who together manage the building works and all on-site construction for the owner.
We have emphasized, from the beginning, that in order to achieve really profound quality in this project, it is necessary to be able to modify it continuously, during the process of construction. This in turn requires that the Manager is alive to the fact that important decisions are being faced at every stage, and is aware that one of the most important things that is happening, is the evolution of the building designs, while they are being built.
We have a strong intuition that a general contractor will interfere with this process, no matter what is said in advance. The reason is this: All the large general contractors we have interviewed are strongly oriented to the problem of schedule. Of course, this is one of their strengths. However, we are convinced that they are so strongly oriented to this problem, that they will ultimately kill the life of the project, in order to achieve enough management control to be able to guarantee schedule.
In 1969, the people in charge of Apollo 11 trusted a 23-year-old engineer in a back room of mission control to make one of the most consequential decisions of this decade-defining mission. And they did so in seconds, without deliberating or debating.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
Innovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.
The graph shows 3 research-related tasks and the percentage of PMs and UXers who agreed on whether PM or UX should be responsible for each.
A survey of people in user experience and product management shows that these professionals disagree on who should be responsible for many key tasks, like doing discoveries and early design.
"Someone recently told me that 'difficult to work with' often really means 'difficult to take advantage of' in creative industries, and I haven’t stopped thinking about that for weeks" — @AdalynGrace_