BlogHer | bet '11: Business Track: Leading Developers ... Especially If You Aren’t One
Welcome to the BlogHer | bet ’11 liveblog of the Business Track: Leading Developers ... Especially If You Aren’t One panel!
You have the big idea, but you may not be planning or able to single-handedly develop it by yourself. You’re going to work with developers, coders, engineers, testers. If you’re not one of that techie tribe, you may feel it’s hard to communicate what you want effectively and even harder to be taken seriously by these stakeholders. But you absolutely can and must lead a development team, even if you’re not a developer. This session will talk about what establishes and maintains credibility, and about communication styles and tactics that work.
Moderated by BlogHer co-founder Elisa Camahort Page, joined by Susan Mernit and Sandy Jen, on this critical relationship.
Elisa Camahort Page's previous start was high tech management, Susan Mernit is formerly of Yahoo and founder of Oakland Local, Sandy Jen is co-founder of Meebo.
This is Elisa's fourth career, she started out in theater in voice, landed here by chance -- started as administrative assistant in tech company. Four years later was a senior manager. Learning to lead was challenging in the beginning, you have to understand the engineering mindset, have to be able to articulate how, what, why you need, and translate that to the developers is critical. You need to speak their language, build a compelling case -- unless you're planning too do everything yourself.
Susan: Original degree was in creative writing. Her last corporate job was a senior job at Yahoo! Personals, led a rebuild of the world's most-visited online dating service. By the end of her tenure, she could write an objective sheet for almost any project. She knows how to bridge the gap in talking to engineers.
Sandy: Studied computer science at Stanford. Graduated in 2003 when the bubble had burst -- everything was dead. When she decided to pull the trigger and start a company, she had to learn how to speak non-engineering language. A really interesting experience. Five years after starting Meebo she does less coding and more hiring, coordination, management.
Elisa: Sandy and I had an interesting conversation about the discipline of learning computer science and how that shapes one's thinking. When Elisa first learned HTML, she couldn't always remember how to resize images via code. Would always have to go online for instructions. She told her coder husband, "If I was an engineer, I would just remember this!" Her husband says, "No, I use the internet and reference books too -- you're doing the same thing." That gave Elisa a different level of confidence, made her feel she could do more things.
Sandy: Engineering is a discipline. You don't have to be a genius -- it's all about problem solving. We are all brought up to think differently. The way you're trained influences the way you interact with others. On any project, you have to know the path you're going to take; you can't just tell your developers. "I have an idea and it will make money." You have to have reasons, logical paths -- then the engineers will be on board. Have to translate your project into steps that are easy to explain.
Common perception: Engineers are headstrong/stubborn. But if you use logic and concise step-by-step instructions, it will help.
Elisa: Susan, how do engineers need to talk to you?
Susan: 90 percent of my job was saying no, the rest was translation. What we're really talking about is how do you find technical people you can build a good partnership with. Some of them enjoy back-and-forth and discourse, but not all. Some enjoy talking about could vs. should (latter is budget issue). Need mutual respect and a shared incentive to get you towards your goals. You have to believe that you're serving your customers' goals.
People who aren't technical often don't have the experience to think through of the entire necessary process to achieve their product goals. It's very important to be sensitive to the fact that engineers want technical specifications. Like with a beautiful house, you need architechrual documentation.
Question from Audience: I don't choose my engineers, they're assigned to me. I try to be detailed with my product specification and business requirements. How do I get the engineers to read the d*** spec? Getting them to read the spec and follow directions isn't working. I'll do wikis, verbal walk-throughs, nothing seems to help.
Susan: With some of my big team and complex projects, we had project managers and we spent hours with walkthroughs, we used development projects -- and there were still people we wanted to shake.
On my own site (Oakland Local), I did a 36 page spec and gave it to my developer. Then I realized my developer was dyslexic and didn't read. Had to figure out what to do! So now I make Power Points with pictures and annotations, it is working much better.
Elisa: Culture of the department is a factor. In my last job, I had to raise my voice and curse to be taken seriously. The leadership of the company did that too. I didn't like it, I'm happy to work in an environment where it isn't necessary - but that's what it took. So how do they interact? How do other people in the company motivate them? How do they motivate themselves?
Sandy: With younger engineers, if they're not passionate, they're not motivated. If you can make a connection, give them an incentive to get into the project, they're more likely to be on board.
Engineers also hate documentation. They just want to get the job done. The visual aspect is really nice -- they can see it, they can grasp it in two seconds. That aspect helps a lot. Makes it easier to move faster. Engineers want results now -- as they do with their coding. Documentation creates delays. The simpler the better.
Elisa: Important to have allies in the engineering department, across levels -- and in upper management, managing up.
Sandy: Emails to engineers: Best to be brief and use bullet points.
Morra from audience: I've been using really simple stick-figure graphics to illustrate my processes, etc. Does Power Point work for you, and how detailed does your documentation need to be?
Susan: Everyone uses the tools they have. But I'm good at Power Point. Important to pick something you're fluent in. Another friend uses Vizio. You need to make a distinction between the detail you need as opposed to your developers. You don't want your own process to drown the developer in details. Give them the information they need to know.
Elisa: Sandy, what kind of visuals work foor you?
Sandy: At Meebo we have front end and back end engineers.
Back end engineers work with data and databases, stuff the user never sees. They tend to proclaim that they're not good with visuals.
With Meebo, we try to use good visuals so the back end engineers can see their role in the story. (But then Meebo has an in-house team with a visual designer to do this.)
If all the engineers see are words, they're not going to necessarily "get it."
Engineering as a whole (front/back end) needs to be working together so all feel equally invested and valuable. Then the product person can bring in their vision/ideas, and the development team will be on board.
Susan: When you have to find a team, it's challenging. Especially if you have to hire an off-shore team, harder to have expectations match, you might not get what you wanted.
But -- on one project, had a back end engineer, had a hard time finding a front end engineer -- things lagged, I ended up shutting it down. Should have gotten an non-onsite front end developer.
Elisa: Have to determine incentive: piece of company? Salary? Finding people who will get in the trenches with you is challenging, but it gives your project an entirely different team feeling/mission.
Sandy: It's hard to find tech industry folks who share your passion. It's not an easy answer. Something practical that has worked is starting by yourself, and hiring offsite team to develop your prototype so you have something to show. Then you can attract people who want to be involved.
Managing offshore/non-onsite team is a challenge. Distance, time zone differences, etc. You have to be very specific in your directions, because their time and your funding is finite.
Susan: A challenge if you're not technical is understanding what the right skills are for a job. For me, going to technology meet ups, working your Linked In network, getting out there and talking to people -- none of us are working for just money. You have to work your network and get out there to find the right people. There's always a selling proposition. Building relationships and looking at it as long term.
Sandy: It might start out as your baby, but you need to be willing to share. Otherwise they won't share your passion, won't be motivated to help build the team.
Elisa: There are times when bringing in professionals, lawyers, external experts will be critical. Contracts, formal agreements, partnerships, etc. People make big mistakes thinking they can do these things themselves. Also improves your credibility, having lawyer language at your disposal. People see that you know what you're doing.
Sandy: Sometimes Silicon Valley lawyers will work for free/equity.
Stephanie O'Dea from audience: When you talk to someone who knows more on the topic than you do, how do you stay on equal footing in the conversation?
Elisa: Do not be afraid to ask the stupid questions! It makes you appear confident and strong, plus they may not be that much smarter than you anyhow. Don't be afraid to ask to clarify acronyms, etc.; other people might have the same question and just don't want to lose face by asking. It's part of on-the-job learning. Don't assume they're going to judge you.
Susan: I've had thousands of discussions with engineers where they tell me what they're going to do, and I ask for other options they've considered. When they tell me other options they've considered, I can then frame solutions in terms of budgets, etc. Reshaping the discussion based on the most relevant criteria. A great non-confrontational way to get folks to be your partner.
Sandy: A lot of times the engineer you're talking to doesn't know that you don't share the same information. It's more about sharing information than assuming they know more.
Advice from audience: You have to be confident in asking for things to be clarified, not wimpy or apologetic. You can also keep a list and ask someone else after the meeting.
Morra from audience: If you're hiring folks, how do you know if you're not getting ripped off when they submit hours?
Sandy: Engineers hate estimating time. It's hard to do. It's creative endeavor for them! In general, you can work by their history, or have them walk you through the steps they took to complete the talk. If they can't, then you may not be getting the value you've paid for.
You can also ask them to break it out into tasks, and have them schedule the tasks/hours that way. Also allows you to measure time/budget, helps them visualize.
Elisa: Use your network, run it by friends who work with engineers.
Susan: If you want them to build something discrete, you'll have a better sense of how to track their time. If it's regular work on an ongoing basis, you want to find someone honest. And always get multiple bids! Comparison shop.
Sandy: There'll be calibration, too, especially in new spaces like mobile, apps, etc.
Susan: The other thing you can do is ask "What are you basing your fees on?" That'll give you some insight, you can determine if those are good justifications for the engineer's time.
Ann from audience: I'm a developer, what you're saying is exactly true.
1) Think big, will help me chart my course.
2) Make sure there's regular communication along the way so you'll know about problems sooner rather than later.
Susan: Classic, but don't laugh: Food is good way to show appreciation. Brownies! Or a special meal that shows understanding of the developer's dietary needs/preferences (vegan, etc.).
Elisa: Last thing: Engineering can be literal. It's not always enough to say "it needs to be a better user experience!" No one's going to want to do something just because you say so. We need to remember that.
Sandy: Don't make assumptions about how engineers think. Assume equal ground.
Liveblogging by Shannon Des Roches Rosa