Think Outside the Tool [Rino Jose]

Remember this one?

In the figure below, find a way to draw four straight lines through the nine points without lifting your pen from the page.

The answer, of course, is to allow the lines to extend beyond the boundaries of the implied box:

This puzzle gave rise to one of the biggest business cliches ever: "Think Outside the Box".

The next logical challenge then is, can you find a way to draw two straight lines through the nine points without lifting your pen from the page? Not possible, you say? Can't make the box big enough? Here's a hint: "Think Outside the Tool".

What if you used a pen with a really wide diameter? Then you could do something like this:

This is a better tool for the job. Less work for you. Faster results.

Every tool has built in assumptions

When you use a fine-tipped pen, it's assumed that you want thin strokes so you can draw or write with fine detail. You wouldn't want to use this type of pen to paint a wall. Likewise, a paint roller is great for painting walls, but you wouldn't want to use it to sign a contract.

Assumptions aren't necessarily bad things. A more generic tool designed with fewer assumptions often requires more effort to use for a particular job. For instance, spreadsheet applications are great for summarizing tabular data and doing quick computations, but using them to manage projects requires a lot of thought and work (and rework) to set up -- and ongoing effort to keep updated.

Specialized tools make specific assumptions about how they will be used. If you use them as they were intended, they can make your job a lot simpler and easier.

When you start using a tool, understand what assumptions it's making and how these assumptions relate to the work at hand.

Learn Your Tools

If you find yourself using a tool every day, it's probably worth blocking off an hour this week so you can browse the documentation. Skim the table of contents or the index and jot down the features you're not familiar with. Do a websearch on the tips and tricks for the tool so you can get an idea of what others have found useful.

If any of these are relevant to your work right now, figure out how to use them today. If not, keep them in the back of your mind for when the time is right. Investing an hour to learn the tools you use every day can pay for itself many times over down the road.

When all you have is a hammer...

When your tools aren't working well, or when you and your team seem to be spending too much time fighting them, even after you've taken the time to learn them, you might need a different tool.

Take a good hard look at your current tools. What assumptions are built into them? Do they help you do your job, or do you need to hire someone just to keep them running? If you're not using the right tool for the job, find (or build) a better one.

Don't just get by with the tools you have. What if you could save 4 days of effort per week with the right tool? Wouldn't that have a huge impact on your organization? There are tools like this (I've built one). Use them.
(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.
More...

Borrowing Borrowing Brilliance [Matt Schlegel]

In my previous blogs I have described a problem-solving process. By no means am I the first to describe a problem-solving process; there are many, many examples. In fact, I have recently come across David Murray’s book, Borrowing Brilliance, in which he describes a 6-step process. What is the same about Murray’s process and the one I have described in previous blogs? What is different? Why?

Murray provokes his readers by asserting that creativity is, in large part, simply borrowing ideas from others. He says that if you and your team allow yourselves to do this, you will enjoy much better solutions arrived at more quickly. Murray describes the first steps in this process by a series of four meetings:

So here’s how to incorporate the creative thinking process into the daily practices of your organization. Separate the concept development process into four different meetings, each with a different goal and different set of rules. These are:
1) a problem-definition meeting;
2) a borrowing-ideas meeting;
3) a new-idea meeting;
4) the judgment of these ideas at a separate time.

Holy smokes, these are exactly the same first four steps in the process that I have been describing! Coincidence? I hardly think so. If there truly is a fundamental method in the way that humans solve problems, and that method is somehow connected to the way the human brain works, then we would expect to see similarities in any problem-solving process described by a human. And, I think we do.

Here are the steps that Murray uses to describe his entire process:

The Six Steps to Business Innovation
Step 1: Defining ➜ Define the problem you’re trying to solve.
Step 2: Borrowing ➜ Borrow ideas from places with a similar problem.
Step 3: Combining ➜ Connect and combine these borrowed ideas.
Step 4: Incubating ➜ Allow the combinations to incubate into a solution.
Step 5 Judging ➜ Identify the strength and weakness of the solution.
Step 6: Enhancing ➜ Eliminate the weak points while enhancing the strong ones.

While Murray’s process gets off to a great start, it seems to get stuck in the latter steps. Incubating, Judging and Enhancing all seem very much part of the analysis process. Where is the part that the team makes a decision about the solution? Where is the part where the team sells that decision to management? Where is the part where solution is implemented and delivered? Murray’s process seems like a great methodology for an R&D department that is not required to deliver a final result but only well-formed ideas. The great clarity of vision with which Murray describes the first part of the process and the lack of clarity in the delivery part tells me much about Murray and what is important to him. It also provides me with clues about the part of the problem-solving process in which Murray excels – we all like to play to our strengths.

Every problem-solving process has its strengths and weaknesses (including the one that I have described.) In many cases, it is simply because the process is trying to solve only a very specific problem and not a general problem. In many cases, those strengths and weaknesses are attributable to the world view of the author. I love to analyze different problem-solving methods as I attempt to discover fundamental truths about human problem solving. Maybe you can help me? What is your favorite problem-solving method? The Scientific Method? A Bug Resolution Process? The Six-Sigma Method? Please share your methodology here and let’s discuss the similarities and differences between the different methods.
_________________________________________

Matt Schlegel has been developing his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process
More...

The Artist Engineer and the Bottom Line [Courtney Behm]

I once worked for a software company where the developers were a tight, creative team so dedicated to the success of the product that many of them had been with the company for 8, 9, even 10 years…an unusual statistic in this era of 2 years here, 2 years there. Like many companies, it hit some tough times and there was a management change at the higher levels. This new group of managers believed that software developers were interchangeable -- that one was just as good as another; that they could be moved around from product area to product area, or replaced by offshore engineers; that this kind of movement would have no real impact on productivity or morale.

It shouldn’t be too hard to figure out what happened…the core group of engineers that developed the product were broken up, a few went to other product areas, most were laid off, and all future development was moved offshore at a vastly reduced cost. Bottom line, 1. Employees, 0.

I would like to say, as a great object lesson, that the company didn’t survive as a result, but it is still very much with us. What did happen, in the words of the remaining employees, was that the heart of the company went out of it. The extraordinary culture that inspired people to work long hours, to make themselves available at all times of the day and night, to collaborate and cooperate, and, most importantly, to trust their organization, evaporated. People put in only as much work as needed to meet minimum requirements. A culture that had been voted among the best places in Silicon Valley to work became a place where people punched a figurative clock, while they waited out the recession until they could find a more hospitable home. Pretty sad, I say.

To maintain the growth and vitality of our software industry, we need committed and talented software engineers. To retain their commitment and talent, we need to be aware that they are a special breed, with a quirky way of looking at the world, and an idiosyncratic strategy for solving the problems they are given and enabling the future most of us can’t imagine. They are artists of the mind, able to make magic happen with electronics, and they have profoundly changed our expectations of what is possible. They are not, as the company I highlighted believed, interchangeable, any more than you could walk into the Sistine Chapel one day and tell Michelangelo that you were replacing him with an art student. Failure to respect this unique contribution of innovative employees might not take a company down the first time, but eventually the air will leak out of the balloon, and you will have just another formerly great company with a “For Lease” sign on the corporate headquarters. I’ve been there more than once, and I expect you have too.

But there’s a dark side to allowing talent retention to drive business decisions. It’s possible to lean over too far to protect local talent. Pandering to the tyrannical demands of a software Nureyev can paint management into a corner, and make them dependent on one or two key employees to keep the company running. An organization needs balance to survive, and sometimes fresh air and tough love are necessary to free it from the cage into which it has locked itself in a vain attempt to keep key engineers from leaving and taking all that source code expertise with them.

Artists are not the easiest people to manage, and managing artist engineers asks a lot of us Engineering leaders. We need to acknowledge and value the uniqueness of their contribution without giving up our management discretion. We need to document and share the knowledge they have given us so that we are not held hostage to their expertise. We need to respect the necessity to turn a profit without throwing the wrong people out of the boat to achieve it. We need to remember the importance of culture as a motivator, and honor it as much as the situation allows. It won’t get easier, I’m sorry to say, so over time we will be challenged again and again, caught in the exquisite tension between profit and creativity. But we are learning organisms, so perhaps we will in our turn become, at least in small part, artist leaders, more and more flexible as we enable a future that only our artist engineers can make real.

___________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.
More...

The Software Engineer as Artist [Courtney Behm]

There is a perception in the general public about engineers…solid, grounded in facts, serious, cautious. They work logically, methodically, are disciplined by their profession into taking one step at a time. I used to have that perception myself, until I started working in high tech. At first, as a marketing professional, I was looking at the engineers I worked with from the outside in, and the assumptions held reasonably well. There’s no question that they were far more practical and pragmatic than I and my fellow marketeers. But when I moved from Marketing into Program Management, and began dealing with the development process at close range, my assumptions began to change.

Hardware engineers fit my expectations more closely. They were, after all, constrained by the physical limitations of plastic and metal and wire. They were creative, for sure, but their creativity had physical boundaries that couldn’t be ignored, and the physics of matter added a stabilizing keel. I could set up a schedule with hardware engineers, and be pretty confident of our ability to meet it. But software engineers were a different box of chocolates altogether. We would make schedules, and then change schedules, and then unexpected things would happen, and it seemed that I spent most of my time one or two steps behind the volatility of their development process. I would say that my most frequent response in team meetings was “Arrrgh!”

Time passed, I spent a number of years as a consultant, and then returned to the corporate world as a Program Manager in an all-software company. OK, I said, how hard can this be? I’ve been in hardware/software companies, I know the drill, piece of cake. Not! A software company is as different an environment from a hardware/software company as I could have ever imagined. I found familiar the unexpected changes, and the volatility, and the difficulty of planning. But now it seemed more magical than frustrating, as if the absence of hardware restrictions had allowed the creativity of the mind to come into its own. And as I learned more and more about software as an entity unto itself, I realized something fundamentally important about software developers. Most of them are artists.

So what is the perception of artists? They are emotional, volatile, don’t like to be hemmed in by conventional wisdom or practices, are idiosyncratic in their behavior and dress, crave the opportunity to do something different. Conventional wisdom would tell you that artistic temperaments in high tech would only be found in Marcom or graphic design or web creation. But in fact, it is the hunger of the creative artist to break the barriers of the conventional that has fueled the emergence of software as the prime mover in the technology world. This has a number of implications for engineering leaders.

First…how do you manage the creative process to a schedule? Think about Michaelangelo on his scaffolding in the Sistine Chapel. I doubt he could have produced a project plan, and if so, it certainly wouldn’t have been done in Microsoft Project. “OK, Mike, we need you to have God ready by April 23rd, and then Adam by June 16th because the spark of creation has to happen on July 1st.” I think not. But when art becomes business, and there are customers to satisfy and external deliverables to produce, this is exactly what traditional waterfall planning methodologies ask of our software organizations. We tell them there are only so many days to be creative, and then only so many days to code and test. It is this fundamental mismatch that has given rise to disciplines such as Agile and Scrum, in an attempt to put a form around the development process that more closely mirrors how it actually works.

Second, how do you manage the artist developer? There are probably as many different ways to answer that question as there are individual developers. Yes, this is essentially true of all of us, there is no human being cookie cutter, and so we all respond differently. But it is exacerbated in the artistic world of the software engineer by the very nature of the work itself, and by the vision of the unknown miracles that software makes possible. Managers often find themselves caught between the need to meet schedules and the inability to rush the discovery process that gets them there. Sometimes the most valuable contributors are the most resistant to observing the necessities of measurable process and delivery dates. They are essential to the organization, and no one wants to make them unhappy, but at the same time a prima donna can wreak havoc on a product launch.

Clearly, software engineering leadership has its challenges and rewards. In subsequent posts, I’ll look more deeply into how we can make the artistic nature of software development work for us and for our organizations.

____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.

More...