is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe. Previously, Khoi was co-founder and CEO of Mixel (acquired in 2013), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “How They Got There: Interviews with Digital Designers About Their Careers”and “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children.
Please refer to the advertising and sponsorship page for inquiries.
+
You had the following question that Jason could not answer “So the question is: Is this the only way to integrate your methodology into a big organization? Can a big organization ever fully integrate it except in pirate exceptions?”
The answer is yes with a twist. We have a core cross-disciplinary team that makes the decisions. We supplement that team with specialists to execute and provide feedback based on their experience. This keeps our core team focused on serving the customer instead of programming HTML or keeping up with the latest software features. Do you really need to have all your team members keep up with database throttling techniques in a multi-tiered environment?
We deal with established clients who have infrastructure, processes, and staff that can’t be negotiated. Each client has a different make up so one day we’ll be doing a Microsoft-centric implementation, the next one on LAMP, and the third using a legacy Java system. You have to be a specialist to provide the right recommendations within their budget and timeframe.
Within our core team we have tried various ways to work. The one approached that we never changed is direct contact with decision makers, brutal honesty and humility. Everything else is based on experimentation and experience.
Each client needs different types of management and process. We provide a service to mid to large size corporations. This may be much different for someone who provides a product to a niche market.
Sidenote: I keep reminding people… Software 2.0 will come out but it will always be Problem 1.0
I love Marketing… “Getting Real” is just a variant of Agile http://agilemanifesto.org/ , Agile is a software development methodology and I’d say it works for 37 signals because they produce small, simple applications.
Agile can work if you’re building something small and simple and you’re your only client (37 signals – and 2.0 startup in beta). It can also work if you’re just iterating over an existing framework (Yahoo!, Dell, NYT), where one of the main variables (design/UI patterns) are relatively static. Where it falls down is large complex builds that require intensive technology and design.
I think of it this way.. Yes if you’re just building a shed in the back yard it’s pretty silly to go make blueprints for it, but how would you feel if someone tried that while building your house, or your office building?
“Where it falls down is large complex builds that require intensive technology and design.”
The failure there is complexity and intensive technology, not small agile teams. Ask yourself why what you’re building needs to be so complex and do technologically intensive.
Because sometimes less just isn’t enough 😉
I thought the interview was very enlightening. It certainly has applicability beyond software program development. For example, I see the future of brands as one of “agile brands” where brands are programs to create value, fine-tuned to customer needs. Brand teams, which are now bureaucracies, could be energized by the “Real” approach.