What Developers Want

If you are a Development Manager here are 5 things that your Developers will thank you for.

1. Quiet: Developers want and need quiet uninterrupted time to write code and solve problems. The need for continuous hours of quiet, uninterrupted code writing is crucial. Uninterrupted means absolutely uninterrupted. Do all you can to restrict direct access to Developers.

For the definitive answer on quiet, and why it is a Developer priority, see Paul Graham’s post: Maker’s Schedule, Manager’s Schedule.

2. GSD: Cut the non essentials and Get Stuff Done: Read Getting Real, by Jason Fried and David Heinemeier Hansson (37 Signals, now Basecamp).

3. Trust: One good Developer will accomplish more than 10 average Developers. Find your top-10 Developer(s). Trust him/her to guide you in the right direction. Don’t manage developers by committee or consensus.

4. Flexibility: Developers are unique individuals. Developers will get more done working at home than when working in the office. They will thank you if you can solve simple life problems, like suggesting work at home while waiting on a delivery. Learn the unique ways to reward each developer.

5. Professionalism: There are 2 types of Developers: (Type B) those that go home after 8 hours and (Type A); those that code at home for fun, read about development, go to meet-ups and conferences, teach others, and contribute code to the open-source community. Promote and protect your Type A professionals.

One last idea for the non-Developer Development Manager. Learn how to code and learn the language that your Developers speak. If you take this as a homework assignment to do on your own time, you will better empathize with the Developer who is working after hours or the one on call for production code.

“One really good person will get done in a day what ten not-so-good people will never get done.”
~James M. Spitze, SCC Sequoia

Website Activation

Where’s Waldo? How to activate a website with a contest!

I’d like to share a technique once used to activate a new website and get 100% of existing clients to happily switch over to a completely new version of the website.

  1. First we launched the new website and kept the old site running.
  2. Next we promoted the new website from the old one using a “Where’s Waldo?” contest.
  3. If you found an image of Waldo on the new site you could enter a drawing for prizes.
  4. Every day we would give hints about where to find Waldo – and over a period of time directed everyone to the major areas of the new website.
  5. Once a week we would announce the latest contest winners, which would bring more clients over to the new site.
  6. After users found their way around the new site, they didn’t bother to go back to the old one.
  7. We also discovered that our particular client base loved contests and awards.

I can’t take credit for this idea. My friend (and he paid me to add this: creative genius, wine connoisseur, dog lover, philanthropist, master of irony and all around trend-setter) David Pearson came up with this idea that we used for a large insurance agency portal implementation in 2004. In 2005, the website was awarded recognition by A.M. Best as the top Insurance Agency Portal website in the U.S. Our Where’s Waldo website launch technique was part of the presentation leading to the award.

“Sales reps are coin operated.”
~Mark Vayda

Ground Hog’s Day 2.0

The hallmark of a true professional is the ability to treat each person and situation with the same enthusiasm and interest as you did the very first time. This means that you will repeat yourself any number of times on the same or similar topics with the same or new clients. This is especially difficult for developers, who are trained to get to end point as efficiently as possible and, specifically, don’t repeat yourself (DRY principle).

I’ve recently put myself in someone else’s shoes – practicing patience and empathy. All I asked was that they do their job at the same quality level that I do my job. Is that too much to ask? It may in fact be too much to ask if the other person is put into an untenable situation, with no support from the company they represent. Imagine if you lacked the wherewithal to make a difference and had no control over your time or schedule and did not have the tools and resources to get things done. This person is responsible for delivery and installation of expensive equipment. However, the very company that stands to lose from a bad customer experience almost guarantees failure upon final delivery. Why so much emphasis on selling instead of delivery and service?

If you don’t support your team all the way to delivery of the end product you may in fact have a broken process. What kind of feedback loop do you have in place to find out what the customer experience is really like? I highly recommend that you follow your service or product to the end delivery point to see the results from your customers perspective. If you use 3rd-party sales, delivery or service reps then it is even more important to monitor final delivery results and follow up after the sale and delivery. A “Voice of the Customer” survey is not nearly enough to ensure customer satisfaction and good word-of-mouth referrals.

Repeating a broken process on a daily basis will not eventually fix the process.

“Success consists of going from failure to failure without loss of enthusiasm.”
~Sir Winston Churchill

Real World Responsive Web Redesign – Jonathan Stark

Breaking Development Conference – Nashville – July 2014
Conference Session: Real World Responsive Web Redesign
Jonathan Stark

This session discussed the RWD/redesign of Entertainment Weekly. I took away more about about project management than RWD but I was more so looking for PM tips.

My Notes:

  • RWD Guiding Principles: speed is a feature; progressive enhancement from low device to high; assume low; easier to progressively add features than to degrade gracefully.
  • Design: No Big Reveal – Constant feedback during design. Final design is 1 week from last review.
  • Big Pieces From Client: we knew all photos, videos, etc. from current site, and challenges before we started design process.
  • Advertising is a big challenge for mobile.
  • Prioritize Design with typical sticky note voting. Allow 20 seconds for +/- reactions to similar sites or comps/mood boards.
  • Set Initial design decisions: e.g. no carousels, progressive content, etc. Now you have a roadmap.
  • Did not use Agile or Waterfall but a hybrid, with information architecture, visual, and development in parallel.
  • Weekly build and push to dev site. Weekly all hands review with client. Weekly freeze.
  • Throw out elements client doesn’t like (e.g. which callout do you not like). Thereby weekly not a sign off.
  • Always design and demo in the browser, not comps.
  • Emphasize phone view in weeklies.
  • Start with small scale elements for review (e.g. and build to footer, then pages).
  • JavaScript: “Every script has a cost”
  • Consider starting with a site that works without JavaScript.
  • Create your own JavaScript library is better for minimum footprint. Don’t go to extremes with JavaScript.
  • Help yourself out: Use a common/single bug tracker; lots of screen shots for bug documentation with re-creating; we used multiple trackers – should have learned GIT better; automate deployment.

“Communication Trumps Process!”
~Jonathan Stark