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...

New Tool: The Path of Least Danger [Matt Schlegel]

In the previous blog, I described the step in the problem-solving process of how a team will analyze the various ideas proposed to solve a problem. During that analysis, the team logically thinks through the pros and cons of each idea. The team will also want to consider peoples’ emotional reactions to each idea, as that will impact the overall acceptance of a proposed solution. Having done that, the team has equipped itself to formulate a plan to move forward. In order for the plan to be accepted, the costs must be reasonable and the risks must be balanced. In my experience, I have found that after bringing a team of people through the problem-solving process to this point, there is a remarkable amount of consensus around the solutions to use in order to solve the problems the team faces. Building on that consensus, the team at this point in the process decides on a plan to move forward. This plan I like to call the Path of Least Danger.

Fear is a remarkable thing. Each of us has a different reaction to fear. I will stretch myself here with my lay knowledge of how the brain processes fear. There is a part of the brain, the amygdala, that serves as the information processor that outputs the fear response to the rest of the brain. As with much of our bi-cameral brain, the amygdala has a right part and a left part. My understanding is that one side tells our brain that something is really scary and that we should avoid it if at all possible. The other side tells the brain that you should go and destroy the thing that is making you feel this way. And, just like people can be "right-brained" and "left-brained" or "right-handed" or "left-handed", some people will have a strong reaction to fight and some will have a strong reaction to flee. (Please correct me if I have misrepresented the function of the brain, this is a blog after all.)

Since we are not quite to the point in our problem-solving process where we need to fight (I will talk about that more in the implementation phase), we can tap into the thoughts of the more "run-for-your-life" types, and I put myself in this category, to help the team formulate the path to move forward. Since the team has collectively decided already to do something, they now need a plan to get them to a solution that solves their problem. And, since all the scary pitfalls and landmines have been laid out in the analysis phase, and by this I am referring to the resources that the team would need to implement each idea and the threats that would prevent an idea from being implemented, then it is a matter of finding that optimal path that minimizes both resource utilization and threats to failure. On that path the team can build the reasonable-cost, risk-balanced plan. In other words, we can use our fear response to empower the team to choose the Path of Least Danger.

Now that the team has decided on a path forward, it is time to acquire the resources you will need to take the team down the selected path. In the next blog, we will talk about the important step of advocating the plan not only to get the permission to proceed, but to get the resources, as well.

__________________________
Matt Schlegel categorizes himself as a "fear aware" type. He taps into that characteristic as he finds that it gives him the ability to create project plans, schedules, test plans and manage quality for products. He finds that he is a "natural" at worst-case analysis, and uses that natural ability to help teams avoid pitfalls, create reliable solutions, and build high-quality products.

More...

New Tool: Building your problem-solving team [Matt Schlegel]

My previous blog entry discussed the first step in a problem solving quest: the formulation of a problem and goal statement for the initiative. The next step is to pull together the team you will need to achieve those goals and solve those problems.

First, break all the rules

Marcus Buckingham, in his book “First, Break All the Rules,” describes the metaphor of people having super-highways or bumpy country lanes for executing a given task. His point is that not everyone is good at everything and assigning folks with super-highways to a task will get you there much faster than will the person with the country lane. I have found that this is true of problem solving as well. Some folks are great at describing the problem. Some folks are great at coming up with creative ideas. Some folks are great at analyzing the ideas. Some folks are great at building a plan to execute the idea. Some folks are great at selling the plan. And, some folks are great at driving the plan through to completion. And, while you can find people who can do more than one of these areas well, it is difficult to find one person who can do them all well. You will want to keep the strengths and weaknesses of your team members in mind as you construct your team.

Beyond the Stakeholders

In defining the problem, you have already pulled together a team of stakeholders. In addition to these folks, you will want to think about who else may need to be involved in the initiative. Were there other groups identified during the problem description meeting that contribute in some way to the problem? If so, you would want to consider including them. Is there certain expertise required to solve the problem? If so, enlist the help of an expert. Will there be an impact on the workflow of any group or groups in solving the problem? If so, make sure those groups are represented. How about systems and IT infrastructure? If yes, ensure an IT representative is part of your group. Simply put, ensure that the people who need to be involved in both designing the solution and living with the solution are represented on your team.

Roles and Responsibilities

Take the time to ensure that every member on your team understands his/her role in the initiative. Prior to meeting with the entire team, I tell all the participants that they will be expected to describe how they will contribute to the team. At the meeting, I document what each member says, and this document becomes the Roles and Responsibilities document for the team. Challenge the team to think about what other resources they think they will need to solve the problem. Also, challenge those with a clear vision of their role on the team as to whether they need to participate in the initiative at all. At the end, you should have a clear description of each team member’s role and how they plan to contribute to solving the problem.

Housekeeping

If you have added new members to the team since the original “Problem” meeting, then you will need to loop back with the new members and ensure that the problems from their perspective are aired and recorded. Once any new problems are captured, you will want to check to make sure that the goals will address the new problems. This is an important sidetrack to ensure that new team members feel vested in the process.

Check in with the Sponsor

Once you have identified your team members and each of their respective roles and responsibilities, you will want to check in with the sponsor. Brief the sponsor on the team you have assembled. Also, get feedback to make sure you have your super-highways in the best places. With your team in place you are ready to move on to the next step. In my next blog entry I describe the creative idea brainstorm.

________________________________
Matt Schlegel learns a great deal about teams by watching his children participate in team sports. He finds it fascinating to watch how children identify with their budding super-highways. He also finds it fascinating to watch how great coaches inspire kids with a positive attitude that carries over into their support for each other.

More...

New Tool: Sausage Survivors [Matt Schlegel]

Not all problems need a systematic approach like the 8 phase methodology outlined in the previous submission. People are solving problems all the time. Some problems can be addressed in a few moments. Others take longer. Generally, the more people involved in the problem solving process – the more stakeholders there are – the more benefit would be gained by a systematic approach. Here are some examples.

Take the start up founded by a couple clever folks that have worked together for years at their previous big company. When they start developing a new product together, things just click. They know exactly what needs to happen. Then, a few folks join from another large company, some of them managers. Now it gets interesting. The development processes were similar enough so that everyone has a general idea of what needs to happen, but the words they use to describe the process, and the details of who is responsible for what are different enough so that confusion arises, gaps appear, and balls are dropped. Now, add a few junior developers to the mix. These fresh folks are looking to the leaders to understand the development process. Depending on who they listen to, they will get a very different picture of roles and responsibilities on the team. And, the balls continue to drop.

Next, take the two companies that just merged and are integrating development teams. Both development teams have their own terrific product development process. Now, they have to work together to deliver products. Which process should they use? How do they resolve the differences? And, how do they do this in a timely way that allows them to continue to meet the demands of the market?

Most people don’t take a systematic approach, and problems can be solved without one. I have heard people characterize their problem solving process as similar to “making sausage” – it is messy, and you do not want to know what goes in, but in the end it makes a delicious product. As with most endeavors, the smart application of the right tools will allow tool-wielding sausage makers to thrive and prosper.

_____________________________________________
Matt Schlegel has a German last name which belies the fact that his heritage is mostly Irish, English and Scottish. He does have a fondness for sausage which may be traced back to those Germanic roots. He also enjoys the meats of other cultures. He lived 3 years in Japan, where he indulged in sashimi, Matsuzaka-gyu, basashi, and other delicacies.

More...

New Tool: Reinventing the Wheel [Matt Schlegel]

To a person holding a hammer, everything looks like a nail. This great cliché, in a backwards kind of way, says that there are many different tools and many ways to solve problems. Here, I will describe a tool that I have used successfully to solve complex problems in cross functional organizations. Perhaps my analog electronics engineering background compels me to formulate an analogous tool to aid me in describing this tool.

The analogous tool that I propose to use is the wheel. Like the wheel, this tool is an efficient way to move teams forward. Once the team is in motion, it wants to stay in motion. Conversely, once it gets stuck, it takes effort to get it rolling again. It requires balance for smooth operation: once out of balance, the ride can get bumpy. You get the idea. The wheel will be a good way to describe both the pros and cons of this approach.This wheel tool is a methodology consisting of 8 steps or phases. Each step is critical to smoothly getting to the next step. The steps must be done in sequence in order to keep the wheel moving forward. And, each step allows the opportunity for team members to contribute in different ways, some steps will resonate with certain team members’ strengths. Those resonances will provide opportunities for those members to play to those strengths, providing leadership during that phase. Without further ado, here are the steps:

1. Problem – Goal: List the problems, define the goals
2. Team: Build a balanced team
3. Ideas: Brainstorm ideas for solutions
4. Analysis: Analyze the ideas
5. Proposal: Prepare a promising plan
6. Advocate: Present the promising proposal
7. Implementation: Implement the plan
8. Debrief: What worked? What didn’t? Start again.

Does this look familiar? I would expect most to say it does. That simply may speak to the natural way we humans solve problems. The magic, if I may use that word, of taking this systematic approach is that the solution the team chooses to implement has buy-in from all, everyone has a vested interest, and solutions are effective and lasting. Magic indeed.

Ah, yes. And, my favorite part about the wheel analogy is that the beginning and the end are at the same point.

________________________________
Matt Schlegel is a rare native to the Bay Area having grown up in Pleasanton and having gone to high school at Mission San Jose in Fremont. He went south to study engineering at Harvey Mudd College as an undergraduate and UC San Diego as a grad student. Perhaps his favorite education has been at the poker table, where he there learned about another kind of wheel – a five card hand consisting of A-2-3-4-5.

More...

New Tool: When you need to repair your Cross Functional Product Delivery Engine [Matt Schlegel]

As a smart, young engineer, it may have crossed your mind, as you toiled away on projects, how things would be different if you were in charge. Perhaps these thoughts inspired you to pursue a management position. As a manager, you imagined, you would have more influence over how things got done.
You became a manager. You enjoyed the influence you now had over your group’s business. Your team performed well, and you were successful in the position. Yet, you remained unsatisfied. Business within the entire engineering group was not run as smoothly as you imagined it could be. And, again, you aspired to a position of overall engineering leadership.

You became the engineering leader that you imagined. Engineering runs well, and you have a great, productive team. Yet, you still remain unsatisfied. The overall product delivery engine still does not run as smoothly as it could. You speak to your peers, the leaders of marketing, sales, operations, in the company and they would agree. Ideas are bandied about. Few are tried, and fewer are seen to successful conclusion. The CEO asks you to figure it out and get the entire cross functional product delivery engine to work as well as your engineering group works. Now, what do you do?

Any engineer worth their salt loves tools. They maintain a full tool box. They are on the search for tools to better perform a task. When a tool does not exist to perform the task, they will fashion a new one. In the next few submissions, I will describe a tool that I fashioned to help solve organizational and operational issues both within an engineering group and within the cross functional organization as a whole.

_____________________
Matt Schlegel has held management positions in engineering, product development and program management at a number of Silicon Valley start up companies. Now, Matt enjoys consulting for companies in the areas of engineering leadership, product delivery, joint development with Japanese and Asian partners, and telecommunications. Before he started working on product delivery engines, he cut his teeth (and hands) on Chevrolet engines.

More...