Lean UX

Lean UX

I have learned a lot over the past 5 years working at GetHuman, but as far as product development goes, this past year has been like drinking from a fire hose. Besides launching two new products, Swish and VendorSmith, as well as working on several others that haven’t come out yet, I have spent a lot of time thinking and discussing product development strategy with my amazing team members.

The linchpin and primary driver for many of our product discussions is Tim Noetzel. Tim is a long time designer and UX expert that has a number of amazing publications (like this Lean UX course and this awesome article about Data-Based Personas on Smashing Magazine).

Here are the top 5 lessons I have learned from my good friend, Tim, about Lean UX:

  • You don’t know anything for sure. You have a theory. You can test that theory to see whether it is true or false.
  • Good design starts with a good design process.
  • Every team member should be involved in product design at some level and treat UX as a first class citizen throughout the organization.
  • Until you achieve product-market fit, avoid heavy investment in development. Try to validate theories and design your UX through a series of small experiments. You should be able to do this with days of development, not months.
  • You don’t need every single person to have a great user experience. You just need to focus on your target audience/persona. That means first figuring out what your target persona is. Once you have that, it becomes much easier to create the best possible UX for the users in that persona.

The 4 Characteristics of Highly Effective Managers

The 4 Characteristics of Highly Effective Managers

I originally posted this in 2011 while I was managing 25 developers at Wells Fargo. The pop culture references are a little dated, but the core messages are still relevant.


“Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too…” – Bill Lumbergh

Bad managers and bad management teams are everywhere. Movies and TV are filled with shows that rip on managers and/or put them in a bad light (i.e. Office Space, Devil Wears Prada, The Office, The Simpsons, etc.). These characterizations are often popular because, well, hasn’t everyone had a boss they disliked or disagreed with at some point in their lives?

The fact is that any shmoe can be a bad manager, but it is much tougher to be good, highly effective manager (note: the term “manager” meaning anyone in a position of leadership). I have been lucky enough to work for one the past 7 years and I have had the pleasure of getting to know many others as well. While I think that good managers come in different shapes and sizes, the most highly effective ones often display the following 4 characteristics.

1. Prognosticate like The Mentalist

The formula for the CBS TV show The Mentalist is pretty straightforward. Someone is murdered, Patrick Jane comes up with a theory of who did it and then he orchestrates a series of wacky and somewhat humorous events that ultimately reveal the murderer. Although it almost seems like Mr. Jane can read minds and see the future, there is nothing magical about what he does. His power comes from his ability to read other people, his knowledge of similar situations in the past and a knack for pushing the right buttons in other people to get a desired result.

Managers often need the same skills when they set goals and formulate product strategy. Sure, some people fall into killer products by sheer dumb luck, but more often managers need to do the following in order to reach their goals.

  • Understand Other People – This includes understanding the needs of their customers, the expectations of their superiors, the velocity of the team and the aspirations of individual team members.
  • Know the Past – Good managers use their previous experiences to get ahead of the curve and prevent potential future issues.
  • Orchestrate the Future – The great Peter Drucker once said that ”the best way to predict the future is to create it.” Highly effective managers at times need to come up with outside-the-box solutions to help the team achieve their goals.

2. Execute like Michael Weston

Any non-fake person thrown into all the crazy situations that Michael Weston has to deal with on Burn Notice each week would be dead in about two seconds. Each episode has Michael run into a number of surprise twists and turns that force him to think on his feet, focus on the task at hand and make quick decisions to overcome the latest set of challenges. Some of these skills include:

  • Prioritization and Multitasking – The best managers find ways to effectively work through dozens of tasks that all lay claim to be the highest priority without dropping the ball on any one of them.
  • Focus and Perspective – It can be difficult to focus when multiple business stakeholders each hold a gun to your head demanding to have their requests fulfilled immediately. Effective managers, however, stay cool and laser-focused.
  • Making Quick and/or Difficult Decisions – Being an effective leader means at times stepping up to make the quick, difficult decisions. Some examples include settling minor disputes, holding team members accountable and terminating a poor performers.

3. Develop Talent like Mike Krzyzewski

There are a lot of Duke haters out there, but even the haters respect what Coach K has been able to accomplish in over 30 years of coaching college and national team basketball. His strength centers around his ability to find and develop individual talent as well as gel talent into high-performing teams.

“A common mistake among those who work in sport is spending a disproportional amount of time on “x’s and o’s” as compared to time spent learning about people.” – Coach K

Even the best software development practices will fail if a team is made up of poorly performing, low-skilled individuals. The most effective managers take a page from Krzyzewski’s book of developing a highly productive team.

  • Recruit Top Talent – It’s pretty simple, really. The more smart, talented people on a team, the easier a manager’s job will be. Recruiting can be time-consuming and frustrating, but an investment in recruiting has the highest ROI of any other single action a manager can take.
  • Put Team Members in a Position to Succeed – After getting talented team members, a manager needs to figure out a way to maximize their productivity. This requires understanding the strengths and weakness of each team member and figuring out the best way to put all the pieces together.
  • Encourage Innovation – Nothing and no one is ever perfect. While a good manager typically has ideas about how the team and individuals can grow and develop, the best managers and companies find ways to create a culture of innovation. Some examples of formal programs to encourage innovation include Google’s 20 Percent Time, Hubspot’s Experimentation Framework, and Apple’s 10-3-1 Strategy. Formal programs may be impractical due to an organization’s culture, but good managers find ways to bring elements of these innovation programs into the team.

4. Fly Like Viper

One of my favorite scenes in Top Gun is when Maverick takes on his trainer (i.e. manager) Viper. Viper is an old fighter pilot that is no longer as skillful as he once was, but he manages to out maneuver Maverick and put him into a position where his wing man, Jester, can shoot Maverick down from behind.

The odd thing about software development managers is that the technical skills that got them into their current positions are often not used once they get there. No one expects that managers will be writing code all day, but as a manager loses technical skills, he or she has to rely more and more on other team members to make major technical decisions. There are a number of things managers should do to keep up their technical skills.

  • Audio Books, Podcasts, Twitter and RSS Feeds – Of course it is great to read technical books, but who has time? These days, techies have to maximize their time and jam knowledge into their brain in the most efficient manner. Driving to work? Listen to TechZing on your car MP3 player. Bored in a meeting? Check out what @mattcutts, @dharmesh and @guykawasaki are talking about on your Twitter app. Sitting on the pot? Scan through RSS feeds of the top 100 tech blogs using Google Reader on your iPhone.
  • Write Code – There is no substitute for writing code, but it becomes progressively more difficult for technical managers to do so over time. For those managers that are overloaded with administrative overhead, they need to force themselves to schedule at least a couple of hours a week to write code.
  • Test Your Skills – In addition to coding on a regular basis, it helps to test your skills periodically. One way to do this is to enter a coding competition with your team members or on a website like TopCoder. The point is not to prove that a manager is better than other developers. The point is that simply by going through the process of participating in coding competitions, a manager will be keep his or her coding skills sharp.

Conclusion

The reality is that there are many different types of effective technical managers. A manager does not have to excel in every area described here to be effective. However, those managers that can prognosticate, execute, develop talent and write code are more likely to be highly effective and create highly productive teams.

Tech Debt Ceiling

Tech Debt Ceiling

I originally wrote this post in 2011 before I accidentally deleted my entire website. I am re-posting it now because both the analogy I use (i.e. a debt ceiling) and the underlying issue (technical debt) are even more relevant than ever today.


There has been a lot of talk recently about the U.S. Debt Ceiling. Before you all hit snooze and click the back button as quickly as humanly possible, I am not going to get into any boring financial discussion. It’s just that while I was watching Meet the Press last weekend, I realized that there is an interesting parallel to software development and technical debt.

What is technical debt? I think Martin Fowler does a great job of explaining technical debt, but it is basically a metaphor to help illustrate how systems are affected by less-than-perfect changes. There are two common scenarios:

  • Unintentional Debt – This is when a developer inadvertently introduces flaws to a system. These flaws can come from lack of skill, lack of knowledge or just not paying enough attention. Have you ever hired a bad plumber to fix a leaky faucet and after he leaves faucet falls off or the pipes burst or some other new weird problem happens? It’s sort of like that.
  • Intentional Debt – In this situation, the developer knows that a change may cause issues. The imperfect solution is consciously accepted, however, because doing things the “right way” will take too long. The quintessential example of this is the Boston Big Dig where they decided to cut corners all over the place. For example, they decided to cement most of the tunnel without rebar to save time. I guess they figured ensuring the tunnels don’t collapse and crush thousands of people to death was a “nice-to-have”.

I am not sure if any of the following suggestions would help congress with the U.S. debt, but they may help you manage and reduce the technical debt within your systems.

1. Write it down

The first thing you need to do is figure out a way of effectively tracking when debt is added, what issues result from that debt and how you plan to address that debt in the future. This is easier said than done because our natural tendency is to avoid documentation and just focus on getting past any issues that come up (then have a drink and try your best to forget about them). This is one of those situations, however, where it pays to enforce a little bit of discipline within the team. Sure, it will require some extra effort from everyone to spend 5 – 10 minutes recording information periodically, but this effort will create a transparency that would not otherwise exist. Imagine if you used your credit card carelessly month after month without ever looking at a statement or having any sense of your financial health. A couple ideas for how to track of your technical debt:

  • Use Tools – Defect tracking tools (ex. Quality Center, Jira, etc.) or agile development tools (ex. VersionOne, Rally, etc.) can make it much easier to track technical debt. Most of these tools allow you to create custom issue types, associate those issues with other units of work and create workflows around issues. To go an extra step, you can use wiki software such as Confluence or MediaWiki to provide summaries and analysis of the technical debt being tracked.
  • Post-Change Debriefing – During the process of driving toward a goal, most productive developers are very good at blocking out anything and everything that would distract them from achieving their goal. That is a good thing, so simply modify your standard development process to include a post-implementation debriefing stage where you then can have the team document what was changed and what technical debt was eliminated and/or added. Note that for unintentional debt you may not see issues until further down the road, so be sure to document any debt from previous changes that was discovered as well.

Even if you don’t have a fancy tool or implement a new process, just do something. It doesn’t have to be perfect. The goal is to have tangible reference points to help make decisions rather than simply relying on anecdotal evidence.

2. Draw a Line in the Sand

Now that you have started to record technical debt for a particular system, you can set the Technical Debt Ceiling. This does not mean that technical debt can be measured to the point of knowing exactly when the “limit” has been reached. In fact, the reality is that in most cases the alert that a system is getting close to a debt limit comes from the general “feel” of the system owner. This general feeling typically is a result of things like production issues, support issues, development issues and (hopefully) a comprehensive list of technical debt that you wrote down per suggestion #1. Regardless of what you use to determine the limit, once you feel the system is close to it, you will basically need to make sure that the benefits for a particular change along with any technical debt you are removing is greater than any technical debt that is being introduced (i.e. benefits + debt reduction > new debt). You should probably try to do this for every change regardless of the debt limit, but the point is that it is even more important to follow this as you get closer to the limit. Essentially, the purpose of this Technical Debt Ceiling is to help provide justification for taking the extra time needed to do things the right way so that you can prevent adding more issues to a system that is already overrun with problems.

3. Clean Out Your House

My wife and I have a pretty good system for keeping my town home relatively clean on a day-to-day basis. We try to never leave dishes in the sink, clean up the baby toys each night before we go to bed and every Saturday morning we do a quick sweep and vacuum. Over time, however, my home has started to get wear and tear with things like kitchen tiles that break, scratches on the walls, the outdoor fence starting to fall apart, etc. The problem is that wear and tear can’t be fixed along with daily maintenance because typically those small things end up taking a couple of hours to fix and/or require some special equipment. So, what do I do? Well…usually nothing. Actually, I shouldn’t say that. I do write things down so I certainly have a very nice looking Google Spreadsheet with all the details of what needs to be done. But the problem is that someone has to actually do the work. Besides the fact that we are so busy with so many other things, when there is free time, it is like, “OK, would you rather watch the latest episode of Burn Notice orrrrr clean the gutter?”. Hmmm, let me think….well, I am exhausted and have a headache, but yeah, cleaning out the gutter sounds like a blast.

It is the same thing with software as we let technical debt grow little by little over time with the wear and tear of periodic changes. If you do nothing, it will continue to build up to the point where you are near that Technical Debt Ceiling and the issues within the system are causing a lot of pain within the organization. The thing is, though, it is truly hard to try to proactively put a plan in place to eliminate existing technical debt on a regular basis. The reason for this is that until we get closer to the Technical Debt Ceiling, the impact of technical debt is not painful enough in many cases to get a high priority on an organization’s backlog. It is way too easy for the business to just ignore technical debt for the sake of short-term tactical goals.

The solution is to establish some form of a Technical Debt Recovery Program. This means dedicating resources to debt reduction efforts on a regular basis as part of your standard processes. This does not have to be one specific person whose only job is to go through the technical debt list. It is much better to have every developer participate in some way. There are different ways you can do this, but one suggestion for Scrum-based teams is to try to have at least one debt reduction story with every other sprint. This would be a relatively small amount of time, but it would allow your team to get some traction. There are times, however, when it takes a larger effort to remove a particular debt. For example, moving an application off the mainframe. In those cases, you would need to get support for a larger project. If you do a good job tracking your debt, however, gaining support shouldn’t be a problem because we all work with reasonable, logical people, right?

Conclusion

Large, steadily increasing debt is not a good thing (duh). The situation with the U.S. debt illustrates how most people don’t think about debt until it is too late. Don’t make the same mistake with your software. Treat technical debt seriously and deal with it before it becomes a serious problem. If it already is a serious problem, aggressively work to reduce and eliminate it.

 

The Root of All Evil (in software)

The Root of All Evil (in software)

This is another post I originally wrote in 2011 before I accidentally deleted my website. I had to deal with a log of legacy code at Wells Fargo at that time, but tbh all developers struggle with technical debt to a degree regardless of how modern their stack.


What are you scared of? Snakes? Spiders? Sith Teddy Bears?

I am pretty desensitized having grown up in the era of great horror flicks in the 80′s, but there is one thing that never fails to create a pit deep in my stomach. It is when complex code changes are deployed into production for a system that already has a lot of outstanding issues. I hold my breath until those first users get onto the system and start using the modified code. To some degree, I feel this way with every production release, but there is more of a tangible fear when the target system is already messed up.

“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.” – Yoda

To get to the root of all evil in software, we need to analyze where this fear comes from.

Q: Why do you feel fear in this situation?
A: I worry that something will go wrong and the business will be adversely affected.
Q: Why do you think something will go wrong?
A: There have been times in the past when we thought we were implementing a simple, non-intrusive change, but once the change got into production there were major issues. So, the fear is not specific, it is just a general feeling that something could go wrong.
Q: Why not fix the root cause of those previous issues?
A: We do make small, quick changes to fix specific issues that occur, but the problem is that there are bigger, more general deficiencies within the system that continue to start new fires even as we put out some of the old ones.
Q: Why not fix these bigger issues before additional changes are made?
A: It is a matter of technical debt because the business wants something and they don’t want to wait so they are accepting the risk (i.e. adding technical debt) in order to get their change in faster.
Q: What specifically is it about the existing system issues that makes it so difficult to fix them?
A: Because in order to resolve the issue we will need to change a lot of code and touch a lot of components that would likely then require a lot of testing.
Q: Why do you need to change a lot of code at once?
A: Because it is not possible to change one section of code without affecting many other components. Everything is intricately tied together like one big ball of twine.

Bingo.

Tight Coupling

What my internal Socratic dialog reveals here is that true root cause of the challenges I face is the extreme tight coupling of code within the system. For the non-dorks out there, you can understand the concepts of tight and loose coupling by thinking about the difference between building a robot by welding pieces of scrap metal together (i.e. tight coupling) versus using Legos (loose coupling). When you weld metal together, you can do it quickly (assuming that know how to use a blow torch) and you can customize the shape into whatever you want. The only problem is that once you are done, the robot may be functional but kids would not be able to make any changes to the robot like putting on a new head or upgrading the robot’s arm canon. The scrap metal robot is what it is and if you want something different you likely need to toss it and get a new one. The Lego robot, on the other hand can still be built relatively quickly, but it is designed so that kids can customize the robot to their heart’s content. They simply switch out a couple blocks and they have a revamped, cutting edge robot.

It should be noted that not all tight coupling is bad, though. Each Lego piece (i.e. smaller component within a system) is made up of material that is tightly coupled together. The key is that at a larger system level there needs to be loose coupling at least among the major components so that they can be upgraded/replaced/removed without major impacts to the other parts of the system. Many legacy systems don’t even have this high level of loose coupling and that is why there are still so many Cobol-based programs out there today.

In 2008 the Governator tried to cut the salaries of 200,000 state works but he was unable to do it because California’s Cobol-based Payroll System couldn’t be changed fast enough. The state controller, John Chiang, basically said that the legacy “constraints” (i.e. tightly coupled code that couldn’t be modified quickly and easily) prevented them from achieving their goals. You can see this type of situation in many big businesses where the emphasis is usually on cutting corners to get to the quickest possible solution.

Conclusion

The root of all evil in software is the tight coupling within a system that slows down or prevents system changes. A system may have many other problems that come up from time to time, but the point is that most issues should be able to be quickly fixed and thus not cause any heart ache in the long run. If you are saying something cannot be easily fixed over an extended period of time, then it almost certainly mean the system is tightly coupled in some way. The reason why I can say this with a high degree of confidence is that if a system has the appropriate level of loose coupling, an issue within any individual component should not affect the other components. Problems will always be somewhat contained and limited in scope.

The 4 Characteristics of Highly Effective Developers

The 4 Characteristics of Highly Effective Developers

This was a post I wrote in 2011 that hit #1 on Hacker News. I accidentally deleted all my old posts at some point, so I am bringing it back. Some of the references are a bit dated, but most of the core messages still ring true today.


“We may be very busy, we may be very efficient, but we will also be truly effective only when we begin with the end in mind.” – Stephen Covey

It seems like everyone is busy these days. Especially when you are in IT. You are constantly being asked to do more and do it more efficiently. But, the important question is, how truly effective are you? In other words, you may work 100 hours a week and perhaps you do a particular task faster than anyone else, but that does not necessarily mean that you are effective.

Effort and efficiency are related to what you do while effectiveness is more about what you achieve. In other words, does it really matter how long or fast you work if you are not achieving your goals? Of course not! Hard work and intensity are valuable but only insofar as they help you reach your end goals. Effectiveness, therefore, is what organizations should look for in their developers and how developers should gauge their own abilities. I believe there are 4 primary characteristics of effectiveness for software developers.

1. Accountability

Everyone makes mistakes. Everyone. I mean, seriously, ev – ery – one. In one sense, saying that no one is perfect is like, “duh!”, but understanding and accepting this does not come naturally. When a software developer makes a mistake, the reaction of the developer typically falls somewhere between the following two extremes.

  1. The developer gets defensive and focuses most of his/her energy on deflecting blame and/or protecting himself or herself. After the problem is resolved, the developer does his or her best to make the issue a distant memory.
  2. The developer sees that there is a problem and focuses most of his or her energy on solving the problem. After the problem is resolved, the developer reflects on what he or she did wrong and what changes can be made to ensure a similar mistake is not made in the future.

Both Developer 1 and Developer 2 have some sense that they made a mistake, but their reactions to that information are vastly different.

In the mind of Developer #1, making a mistake is not normal. It is not something that can be explained easily to others without losing face. Developer#1 thinks that mistakes are a black mark against him or her that will never go away. In all likelihood Developer#1 will continue to make the same types of mistakes again in the future because he or she learned nothing from the experience.

Developer#2, on the other hand, may not like that a mistake was made, but he or she accepts the mistake and focuses on solving the problem. In fact, you could even say that Developer#2 typically owns the mistake. He or she openly and clearly says to everyone “yes, (this) is what I did wrong and (this) is what I am doing to fix it and (this) is why it will not happen again in the future”.

“When you make a mistake, admit it, correct it, and learn from it immediately.” – Stephen Covey

Over time, Developer#2 makes fewer mistakes because he or she understands what went wrong and he or she is able to make the changes necessary to avoid future recurrences. Because of this, the overall productivity (i.e. effectiveness) of the accountable developer continuously increases over time.

 2. Ability to Work with a Team

Prior to the start of the 2010 World Cup, it was common knowledge that the French national soccer team was in disarray. In spite of that team strife, however, the team was regarded as one of the best in the world with players like Thierry Henry, Frank Ribery and Patrick Viera. They were runners-up at the previous World Cup and many people expected them to contend for the 2010 World Cup. Unfortunately, things didn’t go so well.

  • Game 1: France 0 – Uruguay 0
  • Game 2: France 0 – Mexico 2
  • Game 3: France 1 – South Africa 2

France didn’t just lose and get knocked out of the tournament. They thoroughly embarrassed themselves. Despite all their talent, they couldn’t even pull off one win. Soccer is an unforgiving sport when it comes to teams that don’t have chemistry. Teams that work well together generally do better than teams that don’t work well together.

The same can be said for software development teams. You can do a great job of collecting the best collection of individual technical talent, but if they can’t work with each other things start falling apart and the overall team productivity takes a nosedive. Some of the symptoms that are pretty typical with dysfunctional development teams include:

  • Issues during testing or in production due to the fact that the developers were not in sync.
  • Time wasted arguing and complaining instead of solving problems.
  • Dissatisfied customers that don’t get the products and/or service that they expect.
  • Unhappy workers that quit or become less productive.

So, how can developers get better at collaboration and IT managers build teams that have synergy? I think it all starts with instilling a win-win mentality throughout the team.

“Win-win sees life as a cooperative arena, not a competitive one. Win-win is a frame of mind and heart that constantly seeks mutual benefit in all human interactions. Win-win means agreements or solutions are mutually beneficial and satisfying. We both get to eat the pie, and it tastes pretty darn good!” – Stephen Covey

There are many small things that people have to do to work well together, but if you don’t start with a strong foundation based on the win-win mentality you will face an uphill battle. Win-win represents the earnest intention to work well with others. People don’t just pretend to want their other team members to succeed. They actually do want them to succeed. When this happens, the overall productivity of the team can skyrocket.

3. Ability to Learn

“I know kung fu.” – Neo

I love how everyone in the Matrix can learn whatever they need to on the fly in a matter of seconds through a program that uploads the information directly into their brain. Totally cool. Whenever they encounter a situation that requires some new skill, they just tell the operator and then two seconds later…BAM! Neo needs to learn how to fight and after one sweet, 10 minute training session with Morpheus he is suddenly a martial arts expert. Trinity needs to know how to fly a helicopter and a couple of seconds later she knows how to fly a helicopter.

If only software developers had a way of doing the same thing in the real world, things would be a lot easier. The need to learn new things is just as strong in this world as it is in the Matrix. It is just that actually learning takes a little more time and effort. Highly effective developers usually display the following two characteristics:

  1. Desire to Learn – The developer understands that the skills and knowledge he or she has is only valuable insofar as they help achieve the desired goals. Therefore, whenever the situation requires learning a new skill in order to achieve a certain goal, the effective developer doesn’t think twice about diving right in and figuring out what is needed to properly equip himself or herself.
  2. Ability to Learn Quickly – There are no expectations that developers learn as quickly as Neo, but the faster a developer can pick up a new technology or learn a new system, the better. It is a skill unto itself to be able to learn quickly. The specifics of how this can be done differ from person to person depending on their how their brain is wired, but at a high level, it generally involves grasping the overall concept very quickly and then being able to filter out the important information from the less important information.

There is very little chance that new developers will know everything when they start a new job. Newbies will most likely have a learning curve as they get up to speed on the business and technical environment. Existing developers must also constantly work to keep up with the business and IT due to the fact that they inevitably change and grow over time. The ability to learn, therefore, is more valuable than any single technical skill on a developer’s resume and it is an essential characteristic of highly effective developers.

4. Passion

Passion is what drives all of us with what we do and is critical to the success of a developer. If you don’t love what you do, there is no way you are going to sit at a computer and write code for 12 hours a day. I love what I do (some would say borderline obsessed) and every single highly effective developer I have met has had a similar passion for designing systems, writing code and thinking about technology in general.

Conclusion

For employers, highly effective developers are very difficult to find. For developers, becoming a highly effective developer can be extremely challenging. In either case, a focus on these 4 characteristics can help a great deal. Employers should attempt to test for them during interviews as well as integrate them into the team goals. On the developer side, the more someone is able to show accountability, act as a team player, learn new information quickly and have true passion, the more effective he or she will be which should ultimately translate into various benefits, rewards and recognition.