Just throw

I had a good conversation with someone yesterday who made me remember what I think is probably the best motivational speech ever given to a coworker who is doing great work but is losing a little bit of confidence.

The thing is that this speech fits very well as something that software or service vendors can give customers when the going gets tough.

In this scene of the movie “For love of the game,” veteran pitcher Billy Chapel of the Detroit Tigers (a team that is about to wrap up one of their worst seasons in history) finally realizes that he is two innings away from throwing a perfect game, but feels he is running out of juice. His catcher Gus Sinski then does what great catchers would do under the circumstances: he gives him a heartfelt speech (you really have to listen to it):

Sinski: What’s the matter?

Chapel: I don’t know if I have anything left.

Sinski: Chappy, you just throw whatever you got, whatever is left. The boys are all here for you. We’ll back you up, WE’LL BE THERE. Because Billy, we don’t stink right now. We are the best team in baseball right now, right this minute, because of you! YOU ARE THE REASON! We are not going to screw that up, we are going to be awesome for you right now. Just throw.

I can watch this scene over and over again and never get tired of it. Keep this in mind next time a member of our team just needs a little confidence boost. Or use something similar with customers when they struggle with the products or services they bought from you, and then make sure to come through with the support.

Categories: Career, Other Tags: , ,

Thought leadership: I know it when I see it

US Supreme Court Justice Potter Steward once famously defined a rather complex and controversial term using the phrase “I know it when I see it.” I think the same applies to thought leadership. What is it? What do we “see” when a company “has” thought leadership?

  • We see a point of view: I have written before about the importance of having a perspective or a point of view about a subject. Why do we believe that a certain position or vision is the “right one”? Under what conditions does that hold true? Sometimes the point of view is missing or not properly articulated. Maybe it is implicit, but in our world where complex technology and terms obscure even the simplest of the conversations, having a clear and concise point of view or perspective allows us to define a future that customers can see and buy into. Even if the realities of the customer’s environment indicate that the conditions are not there, then they can at least learn and say “that is not for me.”
  • We see an understanding of the present state: It is important that we articulate the “present state.” What do we hear from customers? What are they telling us now? Articulating the present state is useful because it helps us see the pain that we presumably solve for. It helps us answer the question “What is wrong with the status quo?”
  • We see the future as it could be: an understanding of the present state sets up the stage to discuss the alternative future we advocate for. We clearly paint that future in terms of the value to the customer and in term of what business advantage would the customer derive. More importantly, this future state is presumably differentiated (if our solutions are) and allows customers to see the unique value we bring to the table. Here, we focus on addressing the questions of “What does the future look like if we did this?” and “What is the future if we did NOT do this?”
  • We see the focus “surface area”: good thought leadership implies an area of laser focus for the company. What is this company good at? When should I consider them? When should I not consider them? Those are questions that customers deserve answers for. There is nothing more frustrating for a customer than a company that is all over the map, attempting to solve all kinds of problems for all people. They would then remember you as a company that wasted their time.
  • We see an effort to educate: I said above that “at least they can learn.” I think that is crucial. Customers do not have the time that we probably do in our jobs to be experts at everything. In my experience, they really like it when they read a white paper or blog and they come out saying “I just learned something I did not know yesterday.” Customers will remember you for helping them learn. From a more selfish perspective, the point of view helps frame the conversation in terms of the issues that customers face, which helps them understand who from their side needs to be involved and identifies areas where more information may be needed before making decisions. Even more selfishly, hopefully that articulation helps you highlight your own differentiators and strengths.

There are a couple of benefits that come from this which are positive to our internal organizations. The first one is that, because defining these thoughts is hard, people really need to work hard at clarifying how exactly a product or company is different, what products should be developed, and how they should be sold. These are not easy conversations but they are worth having. The second benefit is that, once this has been done, then everybody leaves the room feeling that they understand what they are supposed to do, and act very consistently across the organization regardless of whether they come from engineering, sales, marketing or any support function.

DevOps: defining the interface between development and operations

October 20, 2011 Leave a comment

I remember a few years back (sometime around 2004 or 2005, when I was with BMC Software) we started to notice an interesting little trend. We were having conversations with CIOs and other managers of IT on the Operations side who were articulating pains related to the lack of visibility over the applications they were tasked with managing. At the time, these needs were focused on addressing resolution and root cause analysis of performance and availability problems in applications.

The conversation was more or less like this:

  • An application is built on the Development side of IT
  • The application is thrown over the fence to Operations
  • A problem surfaces while operating the application
  • The Ops teams lack the appropriate visibility over the app to solve the problem
  • Traditional management frameworks do not help: the infrastructure “looks green” (i.e. the database is ok, the app server is ok, etc.)
  • A significant amount of time is spent figuring out where the problem is as opposed to fixing the problem (which is frequently easy to do once the location of the problem is identified)

We then started to think about what type of software would be required to “close the gap” between Operations and Development/Test groups. For one, we started to think about solutions for Application Discovery. I clearly remember a conversation with the CIO of a major financial services company who lamented how he really “did not know what apps he had.” We also started to think about solutions for Transaction Management to provide Dev and Ops groups a common view of transactions, as experienced by the end user, across the stack, with various degrees of instrumentation based on the severity of the problem (from tier-level instrumentation data to server data all the way down to instrumentation data about classes and lines of code in a Java or .Net app. There were a number of other parts to the solution: central configuration management, incident management, automatic problem resolution, automated run books for Ops, etc.

It wasn’t until a year or more later that I had the realization that we were solving some of the symptoms, and not the real problem. The real issue was that there had never been a formal definition of the interface between Dev and Ops. While ITIL and other IT management processes had been coming out of the Ops side, the problems really only became apparent or more pressing as Dev teams embraced XP, Scrum, or other Agile development processes, starting to put pressure on whatever minimum and mostly manual interface existed between a Dev org and its Ops counterpart.

What is that interface between Dev and Ops like? In many cases, it is an undocumented process of actions, automation, tasks, documents, emails and IMs that flow between members of the Dev team and members of the Ops team. The interface is also high-stress. It never quite works perfectly, maybe because it is highly undocumented, reactive, and manual, or maybe because Developers continue to push the envelope with more frequent releases into an organization like Ops that thrives on stability. More importantly, the interface between Dev and Ops is not managed, mainly because the two orgs have not defined what needs to be managed or measured (the actual releases). It is possible that there is a language barrier in place that contributes to the problem. People in Ops talk about terms like SLAs, QoS, uptime, availability, etc., whereas Devs talk about classes, modules, web services, APIs, etc.

It seems that the interface between Dev and Ops is also an afterthought. At the very least, it probably is for many on the Dev side, which does not seem to be proactive about engaging their Ops counterparts until very late in the development process. But I think it is also a problem on the Ops side, which has stereotypically never been as proactive at reaching out to the Development org and inquire about release plans and needs.

The DevOps movement, which aims at establishing a closer relationship between Development and Operations, is the realization of a solution that was only ideas a few years ago. With better established processes, more visible release plans, better defined automation of tasks, and a better view of the infrastructure required to run the application, DevOps has the potential to unify two of the most important arms of software development by establishing the policies and procedures. and the tools for release management, change management, configuration management, among other. That is all good. But just the fact that the term “DevOps” has triggered a conversation between previously separate and many times antagonistic sides of the software process is great progress.


I did not think this was going to happen this soon…





Categories: Other Tags:

Steve Jobs retires: great quotes

Now that Steve Jobs announced his retirement, there are tons of writing about him. Yesterday’s article in the Wall Street Journal about his quotes is probably the best one so far.

Here are my top picks:

  • “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
  • “Unfortunately, [creativity is] too rare a commodity. A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have.”
  • “For something this complicated, it’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”
  • “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.”

About software measurements and humans

What is wrong with this chart?

Number of Bugs

Number of Bugs

The picture shows the bug count of a number of software engineers of a fictitious large software product. Let’s first react to the picture by observing the things that stand out:

  • Patricia has the largest number of bugs at 35.
  • Sam, on the other extreme, has very few bugs. He only has 9.
  • Somehow, Patricia’s number is RED. But Sam’s and others’ numbers are colored a cool BLUE.
  • Somehow, Peter’s number is YELLOW.

What are the first things that come to people’s mind who are looking at this chart? Every observer reacts differently, but I don’t think it is hard to imagine people (either observers, managers, or team members) thinking the following:

  • “Something must be wrong with Patricia. She is carrying way too many bugs.”
  • “Sam must be the best Engineer, but Sandy is right up there too by just one bug. Let’s go to their offices and congratulate them.”
  • “If Peter is not careful, he will beat Patricia as the worst engineer here.”

Now, let’s think about what members of the team are probably thinking:

  • Patricia probably thinks: “I am going to spend half a day fixing 20 really easy bugs. They are just one-line fixes. Customers really don’t care about these bugs but at least I’ll stay off the radar next time the scorecard comes out.”
  • Peter probably thinks: “I think I am just going to ask Patricia how she is doing. I must find what she’s up to! Hopefully she tells me what her strategy is for fixing her bugs this week. I will fix a few but if I think she will go under me I am going to have to fix a few easy ones to go into BLUE.”
  • Jane, John and James probably think: “Whew! One more week without having to worry about the scorecard.”
  • And Sam thinks: “Maybe I should take the day off. I really don’t think it is the right time but right now I am on top of the world. The VP came over and congratulated me, so everybody will think I deserve it.”
  • Worst of all, Patricia probably also thinks the following: “I think I am going to ask Jeff, the engineer testing my code, for a daily meeting next week. If I get to keep him 5 hours away from testing my code I will certainly go under the radar too. I don’t think he would mind, especially if I pay for the coffee. He just loves that.”

There is something about measurements that give people reassurance:

  • “If it is a number, it must be correct.”
  • “If we don’t measure, people will think we are not good managers. We must measure. Everybody measures!”
  • “Given that when everything is ok the bug count is low, then if the bug count is low it must mean that everything is ok.” (notice the fallacy)
  • “If the VP asks me how my teams are doing, she will be easily impressed when I give her the bug count. She is SO data driven!”

Unfortunately, things are more complicated than that:

  • Are we comparing apples to apples? It is not evident that all bugs are “equivalent” or approximately equivalent. Is it possible that Patricia just has a lot of easy, unimportant bugs? Is it possible that somebody else has a couple of bugs that are actually putting the product at risks even more than Patricia’s all bugs combined?
  • Unintended consequences: As we saw above, measuring a single thing (bug count) creates behaviors that may not be what we intended as managers of this software process. People will act to satisfy what is measured instead of doing what makes more sense or what is better for the product. Or they will do weird things (taking a day off, fixing bugs using the wrong priority, etc.).
  • More importantly, why are we measuring? Are we trying to identify who to reward, and if so, is bug count what should determine that? Are we trying to improve the software development process, and if so, how is this information used to that effect? Do we just want to know the bug count to have an idea of progress to product completion, and if so, what is the point of having the names by the numbers?

One of the problems of “managing to the number” is that observers and managers tend to not go any deeper. It is just too easy to simply focus on the number instead of asking questions about the bugs themselves. Why? Well, going deeper is just way too much work. It requires the observer to know about the bugs themselves, to learn, to inquire, to think.

Another consequence of “managing to a number” is that people will stop doing other things that are not measured to dedicate themselves to what is measured (in this case, fixing bugs). While some managers will then try to create additional scorecards for those “other” parts of the process (for example, number of completed features, percentage of work left, architecture reviews, “checklists,” etc.), the reality is that it is difficult to cover every single relevant area. It is even more difficult to identify the areas that are relevant.

So, is there a way to use charts appropriately? Probably. The most important thing is to know what we are trying to accomplish with the chart itself. If we think that it is an important aspect of rewards, then we must look at it hard, and decide whether the resulting behaviors is an appropriate cost. If we want to just measure progress, then maybe it is not as important to label numbers with people’s names.

In my opinion, the most negative consequence of wrong measurements is how they affect the culture and integrity of a team. It focuses people on a chart, instead of on a customer, or a market, or a mission, or a new product. It is hard enough already to create high performance technical teams without simplistic charts that create the wrong dynamics. If it is not possible to create and use a chart or charts that have absolutely no negative impact or consequence in the performance and culture of our teams, then those charts are probably not worth the impact to our people, our products, and our customers. A high performance team, one in which its culture is to focus on what is the most important task for the customer or the mission, and where the mission is clear, is then able to perform that mission without being told “how” to do certain little things during the “heat of the battle.”

On design and the “scarcest resource”

Fred Brooks, author of the Mythical Man-Month, has a new book called The Design of Design. In the book he talks about the process of Design, as opposed to, say, focus exclusively on the user interface elements. In an interview with Kevin Kelly for Wired Magazine, Brooks mentions the following:

Brooks: The critical thing about the design process is to identify your scarcest resource. Despite what you may think, that very often is not money. For example, in a NASA moon shot, money is abundant but lightness is scarce; every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage. You have to make sure your whole team understands what scarce resource you’re optimizing.
We had an internal email thread about that quote when someone asked “What is the scarce resource in the development of (one of our products)?” and something that caught my attention was that some were calling out two or three things as the scarce resource in our product development (these two or three things are internal IP and not relevant to this post). But I decided to throw in my two cents on the conversation.
If you read carefully, the quote does not talk about what are your scarce RESOURCES, but it actually says to identify your scarce RESOURCE. I think that there is a huge difference there between the plural and the singular form.
One of the problem with trying to optimize for two constraints is that there are many solutions to a given problem and as a result it is not clear what the right choice is for a single situation. What happens in those cases is that sometimes we make the sub-optimal choice and maybe in other cases we make the optimal one. This actually has the effect of diluting the benefit of the good choices. For example, one could argue that in order to help a user do something very quickly, you need more “concepts” in your product, each thing optimized for something to be done really quickly. If you actually have fewer concepts for the same scope, then each concept is by necessity more generic which means the process of using it has to account for many more choices, and the user will take a little more time in getting something done. I brought up the example of a calculator app. Why do we have more than one calculator app in our phones? Because we want one for scientific calculations, another one for restaurant tips, another one for mortgage calculations, etc. On the other extreme, you could have one app, say a spreadsheet, and it will take you a little longer to calculate your restaurant tips.
This is important in software development organizations, particularly in bottoms-up development ones where there is significant empowerment all the way down the organizational chain. If we say that we have two or three “scarcest resources,” then Employee Sam somewhere over there makes a decision based on one of those constraints (say, “time it takes the user to do something”), creating multiple super-efficient, time-reducing concepts for users, but somewhere else Employee Sandy makes a decision based “reducing the number of concepts in our product” and effectively increasing the time it takes a user to get something done in your product, while keeping a very tight set of concepts. All of this reduces the effectiveness of the design choices across the board as users navigate from one area to another area in the product.
Having one clearly defined target scarce resource does not mean that there are no other ones, but there is always a hierarchy. I would say that Mr. Brooks probably did not mean to say that the scarce resource is lightness and that that’s it. There is always another resource: number of astronauts, for example. You want to bring them all back, and not leave them behind as you optimize for lightness. But it is good to identify the one you need to focus on first.
Every product development organization should know what the ONE thing is that it needs to optimized for. It is likely that people think that you are “already doing that all over the product” but it is more likely that everybody has a different idea as to what that scarcest resource is.
You will find this conversation fascinating.

Get every new post delivered to your Inbox.