Three Key Principles to Operating as a LeanUX Team

Coaching teams here at PayPal on what it takes to operate like in a LeanUX manner. I have typically boiled it down to just 3 key principles.

Three Principles

1. Maintain a Shared Understanding at All Times

This was key when I was at Netflix and I see it even stronger now. A lack of a shared understanding means you will have have to lots of documentation. Having documentation that is predictive in an iterative environment is problematic. It is not realistic since you need to be able to change assumptions and solutions early in the cycle. Historical documentation becomes more necessary as teams downstream need them.

A good way to alleviate much of the documentation normally needed is to pull the teams that are normally downstream (like QA, Localization QA, Localization, etc.) and bring them up further in the earlier cycles. Additionally you can create tools earlier in the process that proxy for these teams and reduce the number of those representatives you will need. Tools downstream should be automation driven as much as possible.

In a recent LeanUX project I kept referring to a/b testing. At some point it became apparent that not all the team understood what I meant by a/b testing (remember this is what I ate, drank & slept at Netflix). It was an easy solve to get us a shared understanding, but the mistake was assuming we had one already on all topics.

2. Collaborate, Collaborate, Collaborate

Walls between teams get erected whenever teams get big, become overly specialized and work in isolation. Agreeing to work as a team, trust each other and make collaboration the underpinning of the team's ethos will ensure the walls will come down.

It's not easy. We like to retreat back to the comfort of going solo or dictating to another the way things work. How can you tell where the walls are? It will be at those hand-off points that happen across disciplines. Collaboration is the opposite of this toss it over the wall mindset.

It's ok for teams to take time to work separately or have sessions to reflect. But if you are doing this to avoid working as a team then watch out. Trouble is already at your door.

3. Build/Test/Learn -- or Get to the Customer Early & Often

This is the secret to getting rid of team politics, getting rid of the prima donna, getting rid of analysis paralysis. Getting to the customer in usability tests, research, a/b testing and so on and doing it on a weekly or bi-weekly basis if at all possible keeps the team pure. It is the difference between a stagnant pond or a clear lake fed by streams. User data & user feedback will keep the team focused on the customer and the real goals of the product. 

Believe me this really works. It is astonishing to see how much ownership takes over the team when they sit in all the usability sessions as a team and watch the successes and failures of their work. I have seen the full team time & again go out of a session that didn't go so well with a renewed determination to nail it next time. Customer feedback is the elixer to what ails you (now I just have to mention that all of the standard practices of how to gather this feedback and what to do with it still apply).

It's Pretty Simple

Fragile is often the name given to agile projects that are busted. I have used the term "Lean-Fall" to describe that ugly mix of waterfall & LeanUX. When I talk with teams that are struggling to work in an agile manner it could be a host of issues. There is a lot of machinery from an agile practice standpoint that might need tweaking.

But frankly, over and over I have seen it come down to one or more violations of these three principles. If you don't have shared understanding, collaboration and continuous customer feedback, no amount of scrums, scrum of scrums, agile coaches, etc. is going to make a difference.

View what you are doing as a team in light of these principles and see if it doesn't give you a fresh perspective on acting like a startup.

If you like this article, you might want to check out my Anti-Patterns for LeanUX presentation.

The Who, What, How of Satisfaction for Frontend Engineers

This is an over-simplified view. But I was thinking about what really matters to frontend engineers in their jobs (besides money).

It matters who they work with

• They want to be challenged by people smarter than themselves.
• They want to work for someone who gets it and values what they do.

It matters what they work on with who they work with

• The experience must matter. It must not be an afterthought.
• The technology stack must be industry standard and make development fast.
• The work must be relevant to our customers.

It matters how they work on what they work on with who they work with

• They want to partner early & often with product & design.
• They want to work in a lean, collaborative environment.
• They want to have customer feedback integrated throughout the lifecycle.
• Some parts of their work must be given back to the open source community.
• They must be valued for the unique contribution they make.
• They must be able to grow in their job to reach new heights.

What do you think?

Forming a new Accessibility Team at PayPal -- Welcome Victor Tsaran & Srinivasu Chakravarthula!

I am excited to share that we are formalizing the already ongoing effort at PayPal in Accessibility by forming an official Accessibility team.

And to kick things off right, I am thrilled to announce that Victor Tsaran will be joining PayPal on Monday 9/10 to lead this team. Many of you know that for the past 7+ years Victor has been the face of Accessibility at Yahoo (along with the excellent Alan Brightman) And if you were reading my blog back in 2005 you will also know that I wrote a piece about Victor's impact on my views about accessibility. I was just 2 months into my career at Yahoo! Here is a snippet from that article:

Confession

Ok, I'll start with a confession.

I think accessibility issues have always been an abstract concept to me.

It usually was an afterthought, something that the usability folks dinged us for. You know the text wasn't dark enough or the font was too small. It seemed to me that every experience I had with accessibility was from the negative perspective.

You see, I love rich interfaces. I love visualizations. I enjoy pushing the envelope. Somehow in my mind I just saw accessibility and richness as mutually exclusive.

Conversion

This all changed over the last two weeks. It happened almost the first time I met Victor Tsaran, Yahoo!'s Accessibility Evangelist/Manager. Victor is an incredibly bright engineer who happens to be non-sighted. If ever there was an evangelist and champion for accessibility, Victor is the man.

Victor does not come at accessibility from the negative aspect. Not at all. He approaches it with an enthusiasm, a sense of humor, and a challenge to create rich interfaces that are richly accessible.

My thinking hasn't changed. That's why when I started thinking about forming this team there was only one person in my mind -- Victor.

Here is a great intro to Victor and his work at Yahoo!



In addition, I want to call out an equally incredible hire by our QA team in Chennai, India -- Srinivasu Chakravarthula. Vasu was the Senior Manager, Inclusive Design at Yahoo! Bangalore. Vasu is well known in the industry (like Victor). You can follow Vasu on twitter @vasutweets.

We are stoked to have these two great advocates for accessibility on the PayPal team. We look forward to bringing Inclusive Design to the fore on all of PayPal's products & services.

They will join together with the excellent work that Cathy O'Connor, Dennis Lembree and Nawaz Khan have been doing to bring accessibility to the fore at PayPal to form this multi-disciplinary team (design, engineering & QA).

Welcome Victor & Vasu!

Looking for "UI Engineer, Developer Experience"

Just one of the many places we are upping the game at PayPal is in our developer experiences. A few months back PayPal formed an Application Platform team. Part of its charter is to create great developer experiences as well as simple developer APIs. Deepak Nadig, the Technical Director of this team, is looking for two UI Engineers to work on exciting projects in this area. Here is part of the job description:

We are creating a world where ‘payments’ is synonymous with PayPal. The PayPal Application Platform is a suite of web services, which are used by internal and external developers to enable payments anytime, anywhere and anyway. The Application Platform is complemented by a comprehensive Developer Experience that enables these developers to find, learn and use these APIs effectively. The Application Platform processes billions of requests each month, and enables PayPal and its partners to rapidly innovate on new payment scenarios and enable new experiences. Therefore, the evolution of the Application Platform is integral to PayPal’s long-term strategy. 

As a UI engineer in our development experience team you will be responsible for the development and delivery of the web experience used by developers to find, learn and use our APIs. You will work closely with our product and experience and/or integration teams to understand the developer needs and deliver the experience that meets their needs.

 Please reach out to me directly if you are interested. bill.scott _AT_ paypal.com.

Why You Should Work with Me at PayPal

I have blogged a little in the past as to why I came to PayPal. Today I want to talk about why you should come to PayPal to work with me.

To start with let's be frank. Last year when I contemplated joining PayPal it was clear PayPal had long lost its luster as the darling innovator of Silicon Valley. PayPal had changed the face of payments when it came on the scene. And the innovators DNA is evidenced by one of its founders going on to create the first viable electric car and the successor to the Space Shuttle program. To get a fuller look at the innovator DNA of early PayPal, check out the wikipedia article on the PayPal Mafia.

But what I sensed when I joined PayPal last October was a desire to get back to its innovation roots. Back to a desire to innovate again. This desire coupled with a very healthy financial position seemed to me to be a no brainer. I decided to take the chance. So what has happened in the past 10 months? From my perspective three things: New leadership, new way of working and new talent.

New Leadership

How often do companies the size and age of PayPal get a complete makeover? Not often. But that is just what has been underway here. Take a look at just some of the new leadership in the company:

• David Marcus. President. David came into PayPal a year ago as part of the Zong (mobile payments) acquisition. David is a product, user experience, social & mobile guy at heart. He is passionate about innovation and his motto is GSD (Get sh*t done!). Before PayPal I believe the largest organization he led was 200 people (Zong). He believes in small teams empowered with really smart people working with great business context. I could not be happier than I am working at PayPal with David at the helm.
• James Barrese. James became the CTO of PayPal earlier this year. James brings the challenge to think differently to the technology organization. James also brings a wealth of experience leading technology at eBay with lessons learned from what worked and what didn't. 
• Hill Ferguson. Head of Product & Mobile. Hill also joined PayPal through the Zong acquisition. Hill has strong mobile & financial roots and is a passionate leader bringing together all of our product & mobile teams together in a single team.
• Hendrik Kleinsmiede. VP of Global Design (UED). Hendrik joined in January and brings with him a passion to create great experiences by attracting top talent and collaborating deeply with product & engineering. Hendrik & I have a very close working relationship and in our short time have collaborated on bringing LeanUX and Mobile First thinking in as first class citizens of PayPal.
• Kirsten Wolberg. VP Technical Business Office (Project Management). Kirsten believes in Agile approach through & through having led the Salesforce IT org to become agile there. I am working in a team with Kirsten to make working in small teams a reality across PayPal.
• Allen Olivo. Head of Global Marketing. Allen is a luminary in the industry having led Apple during the Steve Jobs transition back in the fold. He has places like Amazon & Yahoo in his past as well. Like the new fresh PayPal look? That is Allen & his team.
• Doug Crockford. JavaScript Architect & Industry Luminary! Need I say more?

This is not an exhaustive list. I am sure I am forgetting to mention someone. I could also make a much longer list of VPs, Sr. Directors and Directors that have joined in the last year bringing fresh perspectives into the company. But I should mention that there are many existing leaders (like my former boss who recruited me) that also have this DNA of change.

New Way of Working

I have mentioned before that PayPal is in the midst of a transformation from working in silos in a slow waterfall manner to a lean, startup approach. Earlier in the year I had the privilege of helping to kick off a new way of working on a core part of our business. We took lessons from startups and decided that going forward (this was with David's total blessing as well as mandate) we would not work the way we had in the past.

We gathered our designers, our product folks and our engineers and took over a few conference rooms and began to operate like a startup. Design was done on whiteboards and coded in real time. Usability tests were weekly so the pace was fast and furious. But we were able to try dozens of experiences across desktop, tablet and mobile in the time that would have taken years at PayPal before. Build/Test/Learn became our mantra.

To date we have trained several hundred designers, engineers, product, QA, and other employees in Lean UX methodologies. In addition, we are in a huge transformation project bringing more and more of PayPal into this mode of working every day. Currently I am involved in at least 6 new innovation projects all operating like a startup within the company.

You can read about this approach in my presentation on the Lean UI Stack as well as see my cautions for what can go wrong in the presentation Anti-Patterns for LeanUX.

New Technology Stack 

I am really excited about this part of the transformation. For years PayPal's UI has been built on top of XML/XSLT technologies. If you know me you will no doubt have heard me rant violently about how this technology is the bane of good UI engineering. I won't go into it here, but suffice it to say that the only thing worse than XML/XSLT is a proprietary form of XML/XSLT -- which of course is what PayPal was built on (C++ on the backend).

In the last year the company has moved to Java for all new projects. I am very comfortable with Java. In fact since 1996 I have personally built 4 UI frameworks on top of the Java stack. However, I long ago lost my excitement for using Java in any way, shape or form for the experience layer. Typically Java Server Pages (JSP) is the standard Java solution for UIs. And not very surprisingly this is exactly what was in flight when I joined PayPal.

Knowing that Java was an improvement over C++ and JSP was an improvement over XML/XSLT wasn't enough to satisfy my requirement that UI Engineering (UIE) needed to be able to "Bring great design to life quickly". Elsewhere I have written about how the UI layer is actually the experimentation layer. And that you must design for build/test/learn. Which means designing for volatility and throwaway-ability. Iterating in Java and JSPs just didn't cut it based on my experience.

So with the launch of the new "startup" for one of our core businesses we began to experiment with nodejs. Node is an extremely powerful development environment for applications. Many node modules exist to bootstrap an application. And coupled with the right stack on the UI layer we saw it as a winning combination.

We wanted to be able to iterate faster than we could with the JSP stack and we wanted to be able to bring new talent in the door and have them checking in code within the first few days of hiring. In our mind this was only possible by using open source software as much as possible. Here are some of the choices we made at the UI layer:

• Dust JS for our templating. We are partnering with LinkedIn as well as contributing to their fork of the Dust JS code on github. Dust is great because it compiles down to JS and so the same templates can be run in the server as well as in the client (page-oriented vs applications).
• Backbone JS for eventing/model/structure to our applications. Of course underscore JS comes along for the ride.
• Twitter Bootstrap. For our components. Very nice.
• jQuery. Naturally.
• For mobile: jQMobi. Although we are continually re-evaluating choices here.
• Less. For CSS pre-processing. 
• Require JS. For module discipline, dependency management, packaging and minification.

However, we were faced with a dilemma. PayPal had invested significantly in the Java layer. It was easy enough to develop with these UI technologies on top of node. But what about the Java/Spring foundation below?

What we did was a rather elegant hack. We added a new ViewResolver in Spring to handle running Dust templates within the Java server stack. We use RhinoScript as the resolver since it is the JS execution engine for the Java VM world.

On the node side, we continued to use it for all of our mockup/prototyping of the actual product. The UI stack sits nicely on top of this node stack. And at anytime we just push the UI portion of the app over to the production Java stack and it runs the same as it did in node. In effect we have made our UI prototyping code be the same as our UI production code.

We continue to investigate the feasibility of using Node in production and working with our PayPal infrastructure team are continuously adding modules to Node to have it operate as a first class citizen in the PayPal environment. In addition, the team has built a node bootstrap that allows you to gen up applications, views, controllers for our node apps -- a lot like the Rails scaffolding.

Another great change internally has been the addition of GitHub to our full enterprise. Nothing like having GitHub as your blessed code repository. All of our node code lives there so the whole org is can make it better.

What has been the result?

• New UI Engineer hired and within 4 hours was checking in code! PayPal record as far as I know.
• "Coding is fun again" -- quote from UIE after working in our new  tech stack.
• Spun up half-dozen new projects behaving like startups using the new technology stack with very little training (if you can google it you don't need a week-long class to teach it).
• Innovation is happening. We are seeing high levels of collaboration and continuous build/test/learn cycles happening in multiple teams.

New Talent

Last but not least is the talent. I was pleasantly pleased to find good to great talent within PayPal when I joined. Two top engineers at Netflix joined my team and are leading out on a lot of the innovation. The existing members are actually folks I sought out to work for me before and are doing excellent work. I have hired great talent from Yahoo! as well as other places and am looking to deepen the talent further. But I don't want to stop there. I am looking for talent density within my organization and across PayPal.

What about you? If you are a top-flight UIE (frontend engineer, web developer, etc) and it jazzes you to imagine the change we can bring with the resources of PayPal focused correctly, then why not drop me a line. I always have room for top talent. Come help be part of the new PayPal mafia :-)

Contact me now at bill.scott _AT_ paypal.com.


.