Though its mostly written for people who might be running or working for establishments that are into technology, the essence is relevant in any business.
9 Ways to Make Your Developer's Life Easier
As a co-founder and an occasional freelance product manager, designer, and developer, I've worked on both sides of the table: as a developer being managed, and as a manager working with a developer.
So, if you're a founder, product manager, or anyone working with a technical team—I want to share a few things to do to keep your employees happy and make their lives easier.
Why bother? Well, aside from simply wanting to be a good boss, the easier your developer's life is, the faster and more efficiently she'll be able to implement features. And on the internet, where time moves at the speed of dog years, that's definitely an advantage.
Here are the keys to success when working with your technical team.
Understand the Difference Between a CTO and Lead Engineer
You'll either be working with a CTO or a Lead Engineer, and it's important to understand that they're not necessarily the same person.
Sometimes you have an amazing CTO who's not only technical, but also a great manager, communicator, and delegator. These types likely want to know everything about what you're building, what the end goal is for the user, and your overall business goals. That's great! Believe me, it's an asset. Nurture it.
Most of the time, though—especially in this developer-scarce economy—you'll have a Lead Engineer: a person who is amazing at engineering a product, but doesn't necessarily have the skills (or the desire) to manage a team and product.
The faster you realize what kind of person you need (or have hired), the better prepared you'll be to manage that person and the product.
Care About How Things Are Made (Not Just That They Work)
Developers are makers, not machines. So listen to their ideas and make sure you consider them—even if you have no idea what the hell they're talking about when they start throwing around technical terms. Don't know the difference between this and that stack? Ask. Use it as an opportunity to learn. You should have at least a basic understanding of the technical side of your product.
Be Specific
It's much more helpful to your technical team to assign them specific, small tasks—don't just hand off a bunch of mock-ups and tell them to be done by Friday. In fact, you should be the one managing the project for them. Learn how to use project management software like Pivotal Tracker or Trello and track the progress of feature development by day or per work session.
And check in often, both in person and via your project management software. It's much easier to prevent things from going down the wrong path if you can catch them at the fork.
Don't Change Your Mind Every Day
I know, you think this sounds obvious. But when you're out pitching and selling your productevery day, hearing feedback and brainstorming ways to make it better—it's really easy to come back with new ideas all the time. Don't do this to your team.
Define a specific and small thing you want to build: a Minimum Viable Product (or "MVP"). Have your MVP spec'ed out and ready to be built.? And make it small. If you designed a giant app, break it down and start with one part. Ship your MVP—and then change your mind based on data.
Also, if you haven't already, read The Lean Startup by Eric Ries. Follow it—don't just throw around cool jargon at networking events.
Set Goals, Not Deadlines
In the technical world, deadlines don't always work. Even the most experienced developer breaks stuff, and estimating how long it will take to fix things is hard.
I'm really into Tracker's idea of breaking down features and assigning difficulty points, not hours. Mark a problem as "easy," "medium," or "difficult," and track progress rather than stick to deadlines. Assigning mostly difficult tasks? They probably can be broken down further.
Get a Great Designer
Designers solve problems and can make the product build process a whole lot easier. Especially UX/UI (user experience and user interface) designers. They help you figure out what your product should look and act like—pixel by pixel, user interaction by user interaction (think: What button does the user click next? Where is it on the page? Where does it take her?).
This is not your developer's job. I'm serious. Your developer's job is to write code—not design the product. A great designer will actually help you save on development costs, because they'll help the team think through and catch things that others may have overlooked. They can also suggest make simple but powerful changes that will make your product more intuitive and easier to use.
At the same time—make sure your designer is lean. Sometimes it's not worth the cost to build custom everything. There is a difference between attention to detail and being a diva. If your developer is complaining about a design—that's a sign that you need to stop, discuss it, tweak it, and compromise.
Test, Test, Test
If you care at all about your product—help your developer test it. She's been staring at this for hours. Give her a new set of eyes. Praise her for what she did right, and give her specific tasks for what still needs to be done or fixed.
Developers often complain to me that they spent tons of time on something and then it launched with things broken because nobody saw them. Remember, it's your product. And nobody wants to work for someone who doesn't care about the product they're putting out there.
Compensate Fairly?
You're a business person, and business people negotiate. Usually, much better than non-business people.
So, be careful.
You can negotiate with a developer on her rate, but if it sounds reasonable, it probably is. Keep in mind that there are plenty of other people out there willing and able to hire her for what she quoted. And, if she feels like she's been out-negotiated and she's not being compensated what she's worth, chances are she won't prioritize your work over other work (or over other, more fun things). Or, she'll find someone else who will pay her rate, then leave you hanging. I've seen it over and over again.
An alternative is to negotiate a rate for a trial period for a small feature, and tell her you'll pay the full rate if the project goes well.
Trust Your Team
Are you suspicious of your developer padding hours or slacking off by going to the nearest biergarten? Remember that if you're not hiring people who you trust and who are better than you at something, then you are not hiring the right people.
Trust the experts you have hired to do their job. Give them the tools they need to do it, including direction, flexibility, breathing room, and authority. And check in often.
Source: http://www.thedailymuse.com
