Loose notes from SXSW 2007 panel: Uniting the Holy Trinity (business, users, developers)
Cameron Adams Web Technologist, The Man in Blue
Sally Carson Interaction Designer, Yahoo!
Dustin Diaz User Interface Engineer, IMVU
Why does a site fail? Because one of the three components is not balanced correctly. If any one of those is too large, then one of the other three is failing. Do your uses really need tagging? They may not even know what it is you’re trying to convey. Or you may have a whole lot of users, but if you’re not making any money, you’re failing. At Yahoo! there are over 1,000 developers. An agency may have 10. If you’re a freelancer you may have only yourself. If you don’t know the objectives, you’re set up to fail from the beginning. Also some good conversation on extreme programming / agile web development.
Technorati Tags: sxsw2007
Business people who don’t understand the technology often over-promise, and don’t have a handle on what’s easy and what’s hard. They can set the org up for failure as well.
Politics: Between business and development there’s always politics. When you don’t have buy-in from everyone involved, you’re set up for failure.
What can you do to mediate teams? Don’t play the game [not sure I agree with this].
Research can be a good way to mitigate conflict: Ethnographic research, business research, tech research.
New blood can be really useful – they can uncover inefficiencies that no one else sees. Through their naivete’ they can have great insights on better ways to do things.
One guy advises: Rock the boat. Even if you’re new. Challenge their assumptions. If they don’t want to hear it from you, you may not want to work there.
“T-Shaped” people – a lot of breadth for starters, but then gaining depth in key areas. But the danger here is in specializing in the wrong thing.
Small teams are good teams. Even at a big company, small groups of 4-5 people tend to be optimal, where possible.
A challenge of a big org is reducing redundancy, communicating with other departments, getting everyone to jump into the same bed. Spending F2F time with real people makes all the difference. Meals work wonders. Having teams in other buildings is really detrimental.
Loosen up the serious guy. Either that or make him squirm. Either way it’s really funny.
Agile teams: Business, Design, Developers all in the same room. “There’s nothing like breathing someone else’s sweat as the best way to understand them.”
Take every opportunity to talk to users – sounds obvious, but this is critical, and people often forget.
Agile development & extreme programming sound like buzzwords, but they really do work – people really do get excited and involved and it greases the wheels. Gotta go whole hog on the process though. Swap workstations around – one day you’re doing ASP, the next CSS.
15-minute standup meeting every day. Talk about roadblocks, give everyone a quick update on where you’re at. All three parts of the trinity need to be involved in the stand-ups. It builds empathy to hear what other people are encountering. If this meeting goes longer than 15 minutes, you’re doing it wrong. Even if you’re a team of two people, do this Agile Stand-Up every day.
Putting together a great team: Don’t hire people that suck. Everyone needs an innate respect for everyone else’s skillset. Ask interview questions like “What kind of beer do you drink?” and “What do you do outside of web work?” etc. – you need to get as much of a sense for their vibe as possible (before it’s too late!)
If person mentions a lot of drama in their previous workplace, it could mean that they’re responsible for the drama. Could be a red flag (but not necessarily).
[ Running out of laptop juice … ]