Showing posts with label process. Show all posts
Showing posts with label process. Show all posts

Randy and the Seven Habits

Randy Pausch came up at work, and he wound up giving me good advice years ago, so I added that to the discussion; while it's on my mind, here goes.

His advice boiled down to:

  • look at how you spend your time, and list it out.
  • prioritize that list, based on how much you and your society gets out of it.
  • start at the bottom, and start cutting.
  • actively choose replacements that make future-you a better human being.
  • include a balance of physical, emotional, and intellectual improvements.

It's project management of yourself, your skills, your happiness and your life.  You should be doing things that make you better, instead of things that simply pass the time, with the explicit bit that passing the time is occasionally the best thing you can do for yourself.

Randy religiously recommended Covey's "7 Habits of Highly Effective People", and had hundreds of copies in his office to give away to anyone willing to read it.  That said, it's a medium-length read, and the two minute summary might give you a good bit of insight.  Paraphrasing:

  1. Be proactive about what you do with your time, and who you spend your time with.
  2. Know your goals before you start working on them.
  3. Take care of yourself before others; put first things first.
  4. Always try to create situations where everyone wins.
  5. Listen and understand before moving to action.
  6. Good teams are more than the sum of their parts.
  7. "Sharpen the saw".  This was the advice he gave me; actively manage your life.

I'm not a rabid fan of self help books, but as far as doing more with your life?  It was good advice; it let Randy accomplish quite a bit more, and I'd like to think it helped a ton of folks he shared it with.  On my end, it got me to actively recognize time-wasting activities that could be swapped with more productive things that made me at least equally happy; thanks, man.

Creativity at Work

A friend asked me to answer questions for a survey, with respect to whatever experience I have that's relevant. Here goes.

Please briefly describe your current position at your company, your professional background, and any involvement you've had with new product development.

I've spent ten years doing web development, largely in Java, HTML, and CSS2, but also touching C#, PHP, and JQuery.

Currently, I work for a large web company. I've learned C++, and do some of my code at the user interface level; actual users see the changes I make to our software.

How would you define new product development? What constitutes a new product?

I think of two things here. One is "a completely new product"; something that hasn't existed before. Much more common are "big improvements on existing products", which seems much more descriptive of how "new product" is used today. We're not always inventing the idea of a mousetrap, but we are making better mousetraps. When the difference between the old way and new way of doing something is noticeable to even the most casual user, it's a new product.

What percentage of your time would you say is dedicated to working on new products?

Of the time at work I spend on technical projects, nearly 100%; the company is only ten or so years old, so all of the products are new. In fairness, about half of what I work on was started by others, and about half is code where I wrote line #1, so call it a 50/50 split between new and old.

What percentage of the products that you work on which make it to market/production would you classify as new products?

Again, 50/50; everything we work on that's successful goes to production.

Please walk me through how you've seen successful new products developed, from ideation to launch.

There are three ways to drive ideas:
- Sales driven
- Engineer driven
- User driven

Some mix of the three is necessary. I've found that it's never wrong to put more focus on the users - all of them! - for long-term planning and success. Sales-driven organizations are *great* in the short-run, but fall flat if sales is sacrificing overall user quality for the opportunity to close one or two extra deals. Engineer driven companies are odd the other way; they might produce the best product that no one ever wanted to pay for. But user driven, *if* you can hit it, is ideal; you make a product. People like it.

Have you ever had a great idea for a new product that was started but never saw the light of day? Please expound as much as you can.


Yes. I have more good ideas than I have time to push them right now. I don't know if any of them are great; I haven't pushed on them yet.

On the plus side, having extra ideas gives me a large list to pull from when I have free time. When someone asks "what should we be doing with X", I usually have an answer; it's not always a great one, but something to get conversations started.

What are some typical reasons or roadblocks that prevent good ideas from coming to fruition at your company or in your experience? Any suggestions for how to avoid them if you were given a blank slate?


Getting the right people in the driver's seat - and letting them get the right people on the team - are the most important things I've seen for getting ideas into reality. Those people need to be:

- skilled at that task
- interested in that task
- optionally, but preferably: have their compensation/promotion benefited by success at that task,
- while measuring success in a way the team *all* agrees on up front.

Do idea raisers have the opportunity to stay involved, and if so, how? Do you feel it's important to keep them involved and why?


Largely, yes; you want to have two sets of people working on any project:
- The people who can Get The Job Done, and
- The people Most Passionate about the task.

Hopefully, these are the exact same sets of people. In the case of the person who had the idea, they're often the most passionate person you could possibly have on the job; it was their idea, and if they weren't passionate about it, it wouldn't have taken off! As long as the inventor is a productive part of the team, they should be kept in the mix.

Productivity Boost: Multiple Monitors

So, on my desk, there's a laptop, a 17" screen, and a 23" behemoth of a LCD screen. The 23", I purchased myself at Costco; it was $200, and the biggest boost to my productivity since the invention of coffee.

For web developers - or any complex computer-based task - multiple monitors often lets you lay out your computer desktop like your actual desktop. Instead of having exactly one stack of papers on your desk that you shuffle through, you have multiple stacks for multiple purposes, so you don't have to fish out the right paper from the pile every few minutes.

Taking the analogy to the computer, you might keep your development environment - RAD, WID, Eclipse, Visual Studio, whatever - front and center. It's your most common task, and you want to look at it head-on. But if you have a second monitor, you can put a web browser there, and leave it open, so you can see the output of the code you're writing. Change the code, save it, hit ctrl-R in the browser, and see what changed (or didn't!) If you have a third monitor, you can put the server console over there; that way, there's no shuffling from A->B->C and back again to get this common task done.

Ever cut and paste from one document into another? That gets a lot easier if you can simply see both at the same time.

However, there's one major piece not to be ignored; it was covered well last week by another tech blog: Don't Multitask! Using one monitor to keep email and Sametime open all the time is counterproductive; those will continually distract you from the work you're trying to get done. Same with not-work-related items, keep those for lunchtime or at home, *not* for the second monitor.

Remote Working and Volunteerism

The last post didn't quite cleanly segue into this, so a separate post.

When I lived in DC, a good friend and I were looking to volunteer with a nonprofit organization, doing web work for them. They happily accepted remote volunteers (they're in San Francisco, we're not), and had a shiny-new teleconferencing system setup just for folks like us to be able to help out.

That was great, everyone agreed, until the rubber hit the road. The video camera in the conference room was often pointed randomly, never at any presentation that was going on. The microphone either wasn't mobile or wasn't passed around; in either case, our ability to hear decreased exponentially with the distance of the person speaking to the microphone.

I gave up volunteering soon after, as did my friend; we weren't able to be productive. Talking to a friend who works with the organization locally, their perception was that there just wasn't "enough interest" from remote volunteers to make it worth their money and time to support. We chatted more about it, and they may restart the program, but in any case, it's efficiency lost, which really does count, especially when time and money are very limited.

So, what's the upside?

With my current job allowing remote work, I've taken some lessons learned away from that experience. If you have a significant number of people outside of the room you're meeting in who are part of the meeting, it's quite simple: have one local resource outside the room connect to the meeting in the same way.

If you have five folks in the room, and ten folks in Kentucky, take one of the five and have them participate from their desk. If they're having minor difficulties hearing, seeing, or contributing, have them take notes on how to improve it. Rotate which team member is sitting outside each meeting. If they're having major difficulties contributing, make it absolutely acceptable for them to walk in and fix the issue. If those are too extreme, make it okay for them to instant message or text message people in the room to ask for a correction on the problem.

Sometimes it's as simple as someone sitting next to the microphone ruffling through a large stack of papers; sometimes it's a dead microphone, and there's not much you can do. But having a process in place to proactively address both technical issues and distractions amplified by an misplaced microphone makes it easy to get remote workers up to 100%.