Motivated

Working in the technology sector, I am familiar with the need to discover and adapt new ideas at a relatively quick pace. I am still in school for my business degree and have learned many things over the last semester. The college of business at my university teaches all of the same basics about business as any other university. What I love is the information that I am discovering on my own as a result of the "normal" teachings.

Looking into motivation from a manager's standpoint, there is a literary ocean of information on the subject. Everybody from Abraham Maslow to Frederick Taylor to Mihaly Csikszentmihalyi has had an evolving theory on what best motivates people. Food, sex, shelter, rewards, and punishment - all motivators and all outdated.

I recently read Drive by Daniel Pink and have been inspired to learn more about motivation theory. It is interesting to see the way that the industrial workplace has evolved into service and knowledge work. I spent time in manufacturing when I worked in a steel mill after leaving the military. The methods that are used to motivate people in that environment are strictly carrot and stick. Work harder, make more money. Slack off, you get yelled at, written up, and eventually fired.

Modern motivation needs three basic pieces to be successful; autonomy, mastery, and purpose. Autonomy is the ability to work on a project that interests you. But it's more than that. It's the ability to build your own team to work on that project. It's the ability to work the hours that you need to work without someone checking your time. Not that you shouldn't be held responsible for something. You should be held responsible for the thing that you are expected to deliver: results.

Mastery is the ability to perfect your art. Working for a company that encourages professional improvement is a huge help in this area. If your company allows you to go to trade conferences to learn about the latest new technology then you have a great advantage over many other people. When a company is fearful of sending developers to conferences because they are afraid that the developer will take his new skills and move on then the company has a lot to learn about motivation.

Finally purpose. This is the ability to align with the mission of the place where you work. This is the very reason that non-profits are at an all time high. People like to do work that has purpose. We all like to make money, sure, but making a living while simultaneously making the world a better place? I'll take that job over building corporate profits every time.

Combining these three basic ideas into the right balance with the right people is what will breed the next Google or Facebook. People that are motivated with these ideas love what they do and that is always a recipe for success.  

--
ciao

Whose fault is your disappointment?

In my opinion, if you are disappointed, it's probably due to your misunderstanding of the intended outcome. 

When someone finds a particular service or piece of work to be a disappointment and I have delivered at a level where I am happy with what I have done, it is likely that the client didn't understand what we both agreed upon. Although this is still something I can correct, I don't take the comment to heart.

Ambiguity will lead to disappointment. For instance, if you enjoy ice cream and I tell you that I am going to get you an ice cream cone, you'll get excited. When I return with a fifty cent cone from the local fast food joint and you were hoping for a large cone (with sprinkles!) from Dairy Queen, you are certainly going to be disappointed. However, if I say "I am going to McDonald's for a cone. Do you want one?", it's likely that you won't be disappointed with the result.

To help mitigate this problem, it is important to communicate clearly. Make sure that you've told the client everything. Make sure that they know what you've committed to, what your intentions are, how you plan to deliver, and what you will all use to measure success. It's not just a matter of telling them - you have to be sure they hear you. These ideas are as important to your business as the ability to deliver a great product. A disappointed customer is a customer that will look elsewhere next time.

--
ciao

Cleveland GiveCamp 2013

This past weekend, I joined 200 developers, designers, project managers, and other volunteers at Cleveland GiveCamp to get tech things done for Cleveland area non-profit organizations. As a truly collaborative group, we successfully created 18 out of 18 solutions that made people cheer!

I work in a relatively quiet environment. We have cubicles and people whisper a lot. It's a pretty closed off and not very conducive to collaboration. This arrangement was a decision the owner made when he designed our new building after getting input from a wide variety of people within the company. To be fair, most of the people that gave him input (including me) have never really worked in any other type environment.

Spending the weekend working for a non-profit in a crazy collaborative environment like the LeanDog boat was an experience that will change how I do things for the rest of my life.

I started the project a bit early by meeting with Mary Kay, the Director of Malachi House, two weeks before the event. I talked to her and her staff about their mission and their message and received a tour to help me understand who they are and what they do. Everyone was great; they were prepared for this with tons of information.

After meeting with Mary Kay, I got in touch with Russ, the guy that handles all of their hosting needs, and he was able to get us up and running with the latest install of WordPress and MySQL. He was super helpful and this gave us a big leg up on our project.

The Friday of GiveCamp arrived and I was excited, like a kid on Christmas morning. A little bit happy and a lot nervous - this was definitely outside of my comfort zone! A handful of us from work were volunteering. We all left about 3pm to get ready and head up to Cleveland to begin our volunteering.

At 5:30, we went through initiation and learned what this was all about and left to meet out teams. Everyone was given a letter on our name tag and pointed to a map with locations that corresponded. I was on Team I and we were in the bow of the ship.

We had a great team - Hank, Joel, Adam, James, Kyle, Mary Kay, and myself. Communication was great. Collaboration was amazing. Mary Kay worked her butt off. I teased her a few times about the fact that she thought she was going to come in and relax - watch a movie or read a book - but she was in high gear, answering questions, giving feedback, detailing content, and so on. She hung tight with us until well after midnight on day one and stayed on with the team the next night as well.

I could get into the details of what we did and how we did it and that would be interesting but suffice it to say that we put in a lot of work over a very small window of time to provide a new content management site for a non-profit that does amazing things for people that have nobody else.

I learned that I need to get out of my comfort zone more often and that environment may be the most important element of collaboration. The workspace provided by LeanDog is open and inviting. Very few walls and not a cubicle in sight. Occasional music pipping from somewhere. A constant hum of busy people. Laughter and a conflict being resolved here and there.

In the end, this was a great experience for everyone that I spoke to. Watching team after team proudly display the results of their project, non-profits beaming and the occasional tear of gratitude; this was one of the best experiences I've ever had the pleasure of being involved in.

I already put next year's GiveCamp on my calendar...

--
Ciao

Anecdotes or Data?

W. Edwards Deming said "In God we trust, all others bring data." We work in an environment where our training and support staff have historically had a lot of input on our end product. Everything from business needs to user interface to deployment strategy.  The struggle we have is that this input is almost completely anecdotal. The stories are dripping with empathy that our support staff (rightfully!) feel for the clients calling in with problems. The end result is, we get software that is easier to support or train instead of software that is easier to use.

Deming and many others since him have put a lot of emphasis on data driven decisions above emotional decisions. It is easy to make emotional decisions and then spend time digging up the facts that support that decision. It is a difficult task to gather all of the data and look through it with an open mind; with no prejudice. I have been involved in medical education for well over a decade so I have a lot of history and collective knowledge. One of the most common mistake I make is thinking that I know what the user wants before I ask her. As a former developer, now business analyst, if I neglect to ask, I tend to steer toward software that is easy to develop.

User driven development is important if you want software that is easy to use - and you do. If you are designing software for a student, talk to the student. If you are designing software for the master, talk to the master. If you are designing software for everybody, narrow down your audience and then talk to them. And after you talk to them and design for them, measure your success. Interface analytics like Clicky give you user data, not anecdotes. Implementing a survey is a great idea. Be careful how you do this or you can end up with a lot of information that isn't helpful. Using the Software Usability Scale allows you to collect data. These things allow you to make informed decisions to create great software that your target users will enjoy using.
--
ciao

photo credit: mkandlez via photopin cc

A [sorta] brief introduction to how I got here

In 1999 I started working in a small start-up software company. We were agile without knowing it. The salesman/CEO would show our product to a prospective client. They would ask if it did X and he would say “It doesn't now but it will tomorrow!” and hang up the phone. He would rush into the next room to the development/training/support/marketing department (which consisted of me and two other guys) to tell us what the new client needed and we would make it so in very short order.

Fast forward a handful of years and we grew up pretty fast. We hired people with “experience” to make us a better company. We hired a VP who in turn hired developers with more experience in making software and as a result, we formalized many of our processes. I became a business analyst (which is still my job title today) and we began to write formal specifications. As I look back, the amount of writing that took place before the start of a project is a little depressing! Our experienced developers made sure that we analysts told them every detail that they needed to know including how the page should be laid out, where the new pieces resided in the navigational scheme, the content, even colors.

Despite all of this, we were successful beyond our dreams. We snared 30%, 40%, eventually 50% of our potential market. We celebrated our wins, all the while, wondering how we could improve efficiency. Stop writing about things we never did. Stop spending man-months doing work that was, in the end, not ever looked at again.

A few more years into this journey and my fellow analyst attended a conference and heard about Agile Development. He brought the idea back to the office and the VP and experienced developers called him a heretic. He didn't know the first thing about how software should be done because his only experience was at this start-up company, not out in the real world.

More years passed, the VP retired, we pushed harder to move to Agile and we were given the go-ahead. We were a dedicated Microsoft shop. Because of this, our transition to Agile was coupled with a transition to TFS as our source control and requirements housing platform. The problems with this approach became apparent to me almost immediately. As we because self-taught and watched all of Mike Cohen's web casts and read all of his writings, I was convinced that an analog solution that we could mold to our evolving process was the way to go instead of using the monolithic trappings of TFS to force us to work in a predetermined pattern. I was ridiculed by the company tech-heads for not wanting to use software in a software company. TFS won out.

Here we are in 2013. We have again restructured with new leadership and new ideas in place. I had little to do with the new round of leadership coming into place, however, they coincidentally(?) align much more closely to what I envision an agile shop to look like. We have designers who design our user experience - crazy! We have an analog work tracking system that works differently for each team (I have dubbed this our 'Information Super-Hallway'). The end of our sprints are a celebration of what we've done over the last three weeks. We break down our work for each sprint collaboratively. Things are coming along nicely.

I want to talk more about how to get to the better place and I hope you'll stay with me for a while and let me know what you think and what you want and what you have to offer.

Ciao!