Wednesday, December 12, 2012

Autonomy and Progress

Numerous studies have been conducted over the past 90 years on motivation factors. In 1924, Hawthorne conducted studies on female assembly line workers to understand the impact of environmental and social changes on productivity. He noticed that recognition, security, and a sense of belonging were more significant motivation factors than other aspects. (http://www.giovanniasproni.com/articles/MotivationTeamworkAndAgileDevelopment.pdf)

Various motivation theories have since emerged, such as those espoused by Maslow and Herzberg. Recent studies led by Harvard Business Review and economists such as Daniel Pink focused on examining knowledge workers. There seems to be a common theme across most of these studies - salary tends to rank near the bottom. The factors that seem to rank high are:
  • Autonomy
  • Progress
  • Achievement
  • Possibility for Growth
  • Recognition
Yet, in spite of almost 100 years worth of empirical evidence, many managers still hold a belief that salary matters more than it does. I have heard similar statements made by leaders I respect, and have always been surprised by the attitude. In spite of evidence to the contrary (e.g. some respected colleagues left my firm for lower paying jobs to perhaps experience more of the motivating factors listed above), I haven't heard much of a change in the voice track. 

I have head butted with fellow management colleagues on this idea - the part that baffles me the most is why the notion of "autonomy" in their mind means "less accountability." Gmail was developed during a period of autonomy given to workers. You'd think that case, among many, would be enough to prove the point!

I think some of it has to do with fear of change - in order for managers to embrace this idea they need to  drop the illusion of control. As a control freak, I can say this is not an easy process, but the benefits that come from it are astounding. By letting go, I have created more space in my career and in my life, which has given me room to explore. In the past month, I painted 4 paintings, written multiple blog posts, read 4 interesting books, further investigated some research interests, made some DIY holiday decorations, and baked fun treats. I also spent more positive time with family and friends. Symbolically, my first couple paintings had filled canvases with macabre themes, and my latest paintings have much more empty space and themes of growth, acceptance, and upward movement.

I want to let go of more, and see what happens! I hope my team will be more motivated as a result :)

Tuesday, December 11, 2012

We strive to design good products – simple, usable products that improve our customer’s lives – but why is it so hard?

I was in a status meeting with a senior leader a few years ago. He pointed at a screen displaying the Google search box and said “Indrani I want you to make our software look like that.” At the time, I was writing requirements for software that was far from that – in fact, the design was moving in the reverse direction towards increased complexity. Unfortunately, there wasn’t much that could be done to change direction without significant investment and advocacy.

The comment, however, has stayed with me for the last couple years. We strive to design good products – simple, usable products that improve our customer’s lives – but why is it so hard? Software teams include experts trained in understanding the user experience (us). They follow disciplined engineering processes; apply multiple tools and techniques to capture analysis and design, all of which should lead to a great product being developed. Yet, most software is overly complex and bloated with features rarely used by customers.

There are many reasons that could explain why teams develop feature-rich, complex systems at the expense of simple, usable products. Many contracts and processes measure the value of a system based on the number of requirements that are met and test cases that are passed, as opposed to whether a customer can complete a narrow, crucial job task in less time with better output. The Google search tool is incredibly feature limited – it allows the user to complete one task (key word search) but is powerful, quick, and reliable.

Another reason could be rogue developers who tack on “improvements” that look cool but don’t make a customer’s job task easier. Or even analysts who ask the customer “what do you want” and diligently record the information, but don’t take the next leap to investigate why the customer needs that feature:
·         What job task can be completed with it?
·         How often will they use it (is this a common job task or a rare one)?
·         Who will be using it (everyone or a smaller group)?

A trickier reason may be our experiences limit us from seeing new, potentially simpler solutions. For example, if a customer mentions “intense data entry” I automatically visualize an Excel worksheet with a bunch of built-in math formulas. But, maybe there’s a different way to look at it.

The Zen master Shunryu Suzuki says “in the beginner’s mind there are many possibilities, in the expert’s mind there are few.” The first time I wrote a piece of C++ code, probably “hello world,” it seemed like a foreign alphabet with strange syntax. I had no idea of what I was doing. I came up with a few cool code snippets but mostly ended up with code that didn’t compile. I did not know where to start when fixing errors. However, over time I could better interpret obscure compiler messages and fix the problem faster. I discovered I had tendencies to make certain errors and started to watch out for them. I developed a body of knowledge through experience. I figured out some things that worked and some things that didn’t work.

As experienced IT professionals, we all have libraries of knowledge, and patterns for looking at a set of information and determining appropriate solutions. Patterns are not necessarily a bad thing – heck a tendency to drive defensively can save your life on the Beltway. But patterns can become automatic and limiting, and prevent us from seeing new possibilities. For example, when I start a project I automatically have a list in my head of must-haves – e.g., log-in screen, help features – and this list keeps growing and becoming more detailed with every experience. It’s rarely questioned. In fact, it almost seems wrong to question if a help feature is necessary…but maybe continuously questioning these assumptions can lead us to drive to down to the bare elements – what’s essential – so everything else can be thrown out and a system is designed simpler.

A beginner’s mind is uncluttered, and perceives what is essential. Given this insight, how do we return to a beginner’s mind to build uncluttered software? I am practicing listing all of my automatic must-haves and crossing items off…one by one…till a small set is left. Another thing I am doing is attempting the unthinkable like not including help features and continuing to look for other opportunities to “simplify.” 

Observe and Adapt

A coworker sent me the following blog after he heard me rant about how most software is engineered to be unusable: http://www.codinghorror.com/blog/

The latest post ("The organism will do whatever it .... well pleases") points out lessons learned from the Lucasfilm's Habitat project. These lessons learned were presented in 1990 at a Cyberspace conference held at UT Austin.

It’s interesting that Randy Farmer and Chip Morningstar reached conclusions on customer behavior 20+ years ago which are applicable today. A couple of passages are highlighted, but the statements below especially resonated with me:

·         “We could influence things, we could set up interesting situations, we could provide opportunities for things to happen, but we could not predict nor dictate the outcome.”

·         “Instead of trying to push the community in the direction we thought it should go, an exercise rather like herding mice, we tried to observe what people were doing and aid them in it.”

A key takeaway is the importance of observing behavior and adapting to it after a system goes live. This idea is embedded in multiple agile development principles. The ironic thing is that most of the projects I worked on in the past seemed to underutilize observation as a tool to understand the possibilities of a system. During the development process, customers watched demos and provided comments. After releases, change requests were collected verbally or in written formats and moved through the ‘change control’ process (Side note: “Change control” is such a misnomer, almost implies people can control changes).

The value of verbal/written impressions may come from the notion that customers can accurately understand their behavior and pinpoint challenges and ways to fix them. There is some truth to this idea – as a customer, I can say with confidence which tasks take up a lot of time (e.g. answering email), which tasks I do more frequently (e.g. filing out time sheets) and which tasks I strongly like / strongly dislike. For things I care about, I invest the time to reflect and identify workarounds.

To translate this to system speak, if I just see the demo of a tool, I provide feedback on whether it looks cool or not. Moreover, when I give feedback after using a system I state aspects that make me very happy or very mad and improvements for the things that made me very mad. This is why most online book reviews seem highly positive or highly negative.

As designers, overall impressions and very good/very bad feedback is somewhat useful but it’s not enough to create a better product - we need to understand the subtleties of behavior so we can make minor tweaks that can significantly improve utility.  A complementary technique is to also use direct observation of behavior to figure out what works and what didn’t. For example:
·         Review logs to see which features are used most often by various personas
·         Observe trends and themes across customer posts / change requests
·         Video record people using your system. Afterwards, view the tape, take detailed notes of what people did, in what sequence, and observe how long each task took and bottlenecks. Use this information to re-design!

I suspect Facebook utilizes the techniques of observation and adaptation to evolve their system. They seem to frequently release new features and adjust based on customer response. Some of their recent changes have frustrated users and increased discussions on privacy tradeoffs, yet people still haven’t stopped using Facebook. However, it’ll be interesting to see if they are using it differently now.

Wednesday, December 5, 2012

Fear of Success

<continued introspection from last post>

In addition to a fear of failure, I have a fear of success. What if my prototypes do work and I start a successful business? What if I find my soulmate, get married and have kids? What if the vision I created for my life actually happens!

All of the negative tapes in my head - the false beliefs that it is not possible, that I cannot possibly have that - would be proven wrong. This would mean - oh no - a lot of ideas I take to be truths are not true!

The depth of mental patterns and imprints is almost astounding - the fact that there's a voice in my head that would rather not take action so I can hold on to self-limiting beliefs amazes me! I'm so used to playing it small...that I'm scared to realize 100% of my potential. I'm scared to play out a new tape because I don't know the outcomes. 

What do you have that's holding you back? Can you let it go? I'm letting go of my tapes..NOW :)

Why am I afraid to speak my truth?

I looked at my original post - around a desire to speak my truth...and this brought up an introspective question - why am I afraid to speak my truth and stand my ground?

The answer is simple - I do not want to be wrong and I do not want to fail. I am afraid to make a "bad decision" - aka the outcomes being different than what I want them to be. I do not want to piss people off when in a conflict.

There certainly is a lot of value to seeing the other person's side, showing empathy, and understanding where that person is coming from. However, this does not mean that I need to erase my perspective in the mix. There is a middle ground. My fear around messy situations and conflicts holds me back in my career and personal life from doing what I want to do in true north.

Right now, I want to start a company. I want to break off on my own and try out some of the ideas floating in my head. I am scared shitless. I am afraid I will be in that 90% of new business that fail. I am afraid that I'll hear "I told you so" from everyone around me. I am afraid that the rug will be pulled out under my feet, and I will have no support network - just a bunch of disappointed faces. I hear over and over again - "you have a safe job why would you risk it" - but I'm tired of playing it safe and not pursuing my dreams. I want to try out these ideas and see if I can make them work and my heart is ready to take the plunge.

I also want to build a family. I want to get out there and date more. I am afraid to though...I'm scared of disrupting my routine...messing with an order I have established after I pulled myself out of my last messy situation. I am also scared to open up in that level of intimacy with another person and get hurt again.

Ahh fear...I would like to make friends with you :)

Update

So it's been about 1.5 years since I posted last...and lots of changes have occurred since then, but some of the same patterns/stories have crept up.

I completed my 200 HR yoga teacher training and started to teach a weekly class, which has been such an empowering experience. It is an amazing feeling to be of service to so many people by sharing my knowledge and experience. There's so much I learn from my students and fellow teachers every week. I love it!

Work-wise, I built up another project - entered a new market, grew a capability by taking on some of the "bitch work" nobody wanted because I suspected that since it was a high visibility no-glory task something good could come out of it. The client and stakeholder community were satisfied and started to see my company in a better light. I on-boarded a support team and we focused on delivering what seemed to be the best bang for the buck.

At one point, I realized I needed help - I have limited software architecture knowledge, and I knew there was a growth opportunity that required that skillset so I convinced a senior colleague to join the project. At first I cluelessly thought things were going well...then later I realized that this colleague had complained about personality conflicts and other issues to senior leaders on the team (behind my back of course) and proceeded to tell me I had no vision, no strategy, do not understand other perspectives, etc. Furthermore, he told me i'm an introvert (which is fine, I'd be proud to be one, but the other 200 people who know me label me as an extrovert with introspective tendencies). Um, I'm sorry but if I had no vision or no strategy - why would I have onboarded you on to the project - clearly I knew we could grow in the architecture realm and expand our work! Yes, of course I can do a better job communicating my ideas in a way that lands for others...but that's different from "having no thoughts whatsoever." Then, this individual provided strongly negative feedback on my assessment and proceeded to complain to other senior leaders about me getting promoted.

What a jack ass! Anyway, I felt the earth shaking underneath my feet. How could I be so stupid and trusting - I brought in someone to complement my skill set and work with me. Not to erase all of my ideas - I expected some conflict/challenges and then thought we would define a middle ground together, but that was not the case. I know I had no other options - none of our other software architects were free, and either I had to give up growing this opportunity or find a technical partner in crime. I did not realize he had the attitude of is my way, or no way, apparently, and was a know-it-all -> no sense of his own strengths and weaknesses but incredibly be good at making others bad and pointing out their flaws.

And my tape started to play - I started to question myself, figure out what I did wrong, and got hurt. The worst part was this "agent of chaos" and his negative attitude permeated throughout the team so everyone started acted in this hostile/mistrusting way...and instead of supporting each other and collaborating - the walls were brought down and this attitude of me vs. you (my idea versus your idea, instead of combining ideas) crept throughout...so in my head, my old tape of "me vs the world" started to play again, instead of just seeing the situation for what it was.

Fortunately, in the past two months I regained my grounding and emotionally let go of that situation. I rolled off the project and now have the opportunity to create something new again, which I love doing. Except this time, when these sorts of issues come up again, I do not want to replay this tape! I made the best decision I could, and yes things didn't go the way I wanted them to, but that's ok. I will not stop moving forward.

Monday, October 10, 2011

Supportive environments

I had an intense yoga teacher training session all weekend during which we talked about core feelings, fears, and insights, etc. This opening experience in a supportive environment led to extensive personal and team growth and as a result, we each became stronger teachers and more empowered individuals. We gave each other honest feedback throughout this process, and each took ownership to help ourselves and help each other.

This got me thinking this morning about a previous software project during which I had the opposite experience:

Core feelings when I thought about the project
* Anger
* Fear
* Disappointment
* Humbled

Actions during the project
Personal:
* I diminished my own role
* I stopped speaking the truth
* I stopped listening to my own intuition
* I second guessed all of my actions
* I took it personally
* I did not grow

Team:
* We created a inefficient, cuthroat environment
* We did not take ownership over our actions
* We did not hold each other accountable
* We did not give each other honest feedback
* We took things personally
* We made decisions based on "me, me, me" instead of what made sense for the communal good (i.e. producing working software)

Software projects can be incredibly challenging since we bring together individuals with different backgrounds and experiences and have to quickly establish a team dynamic. Unfortunately, for this particular project, the inefficient environment of a sister project carried over because some of the same individuals carried over.

The agile principles and manifesto are a great tool for trying to change an environment, but ultimately people need to be open to the principles and accept that "these will result in a better product." In agile, we talk a lot about team reflection, but there's a degree of self awareness and self awareness required of the team. Everyone has accountability. I can't emphasize that enough - everyone from a tester to the project lead..and it's ultimately on every individual on the team to take responsibility and work to improve the environment so that they can truly have an agile project. We are so used to pinning things in software on leadership, but that is the wrong approach and it's putting an unfair burden on one person. Everyone has to step up.