The Art of Doing

As the owner of a digital agency, I’m always on the lookout for hard-working, motivated, and talented people. I go all out to find them, whether it’s through schools, placement agencies, or even friends and family. When these talented folks join my team, they work incredibly hard. But sometimes, the results just don’t match the effort they’re putting in. It feels like the juice isn’t worth the squeeze. And I keep asking myself, why is this happening? Why? Why? Why!

Then it hit me; an old cliche struck me square between the eyes. I didn’t need our staff to work harder; I needed them to work smarter. It was this thought that pushed me to develop what I call “The Art of Successful Doing.” The ironic thing is it starts with nothing but stopping and thinking, but more on that later.

The Art of Successful Doing is a simple yet effective approach to problem-solving in the workplace. Because it is methodologically agnostic, this strategy can compliment Agile, Iterative, Waterfall or any other implementation process used at your place of business. The Art of Successful Doing consists of the following five steps which, when executed correctly, create a more effective and efficient work environment. These steps include:

Thinking

This first step seems obvious, yet it is the single most underutilized step in any problem-solving exercise, especially with our young developers and architects. We are continually asking our staff to solve problems; it’s what we do! Clients are coming to us because they have issues they lack the skill, time or resources to address. We are selling our services to them because we can solve those problems. How do we do effectively do that? Simple, we think the issue through. Here are some suggestions on how to maximize the effectiveness of this critical first step:

Consider the problem holistically. How does what you are doing effect the system in its entirety? See the forest. Ditch the computer. When thinking, a computer is honestly just a distraction. It is easy for an undisciplined mind to have a creative thought early in the process and then want to google it right away. This can take you on a wild tangent. Stay focused. Do have a notebook and a pen. Yes, it might sound old-fashioned to put pen to paper, but it works. Draw pictures, take notes, create user flows, process flows… use whatever aids you have available to make your abstract thoughts more concrete. Change your environment. Do not do this first round of thinking at your desk. Your desk is what I call a “DO” environment. It is where you DO things: write code, project manage, document, and other such tasks necessary to perform your job. It is too easy to get distracted by wanting to DO instead of wanting to THINK. Change your environment: go for a walk, sit outside, sit in a quiet room. Think the problem through to the very end. Get to the point where you believe you have a complete working solution, not a partial one.

Collaborating

Here is where you take the result of all that thinking and open it up to some good old-fashioned constructive criticism. You are kicking the tires of your ideas. Gather up some of your co-workers and present your solution to the problem you’re tasked with solving. If you can’t coherently talk about your solution, odds are you do not fully understand your solution. Here are things I find helpful during Collaboration:

The first thing you present to them is the definition of the problem or challenge you have been tasked to solve. Make sure they fully understand the reason you gathered them together Take the discussion into a conference room, outside, into the hallway — keep it out of your DO environment. You don’t want to get sidetracked by anything concrete such as a code block at this point. Keep the discussion on point. You are talking about your solution to a problem, not working on your collaborators’ issues. Take notes. If needed, create visual aids. Pictures paint a thousand words but don’t spend 10 hours making it with a computer when simple tools like a pen and paper or whiteboard sketch are good enough. Copy, photograph, or take quick notes of the results of the collaboration. You may have a brilliant mind but don’t depend on it for remembering every detail of the meeting!

Re-thinking

Once the collaborative process is complete, take the feedback from your collaboration and incorporate it into your solution. Then, think the process through in its entirety to make sure it all still works. This is the part of re-thinking that people typically skip, which leads to ineffective problem-solving. If a significant portion of your solution has to be retooled based on the suggestions presented, you might want to go through another collaborative process. You can cycle through the re-thinking and collaboration steps a few times until you are comfortable with your solution. During this step, I recommend the following:

• Stay away from your “DO” space when re-thinking. By now, you know why.
• Don’t be afraid to get a second opinion. If you feel the collaborators you selected didn’t understand what you were trying to do, find others. If they do not understand as well, then you may have to look into a mirror and re-evaluate your solution. This is NOT a bad thing. It is a learning thing.

Documenting

Ah, the dreaded D-word. Hey, simply put, it is essential. Flowcharts, user diagrams, and UML diagrams are brought to life. At this point, you should not only be able to create a concise task list of all the steps needed to implement your solution, but you should also be able to give accurate timelines on achieving the tasks. However, remember documentation should be created with a purpose. Do not document just for the sake of documenting. Like everything, documentation should fit into your organization’s development methodology. Consider the following during this step:

• If you can’t successfully create tasks and time estimates for your solution, you exited the re-thinking phase to early. Grab your pen and paper, remove yourself from your “DO” space, and finish fleshing out your idea.
• You can safely create your documentation in your “DO” space. You have officially started doing.
• Before creating a piece of documentation, ask yourself if it is relevant to your solution. If not, explain to your management why you feel you should not be creating it. It may not be your call (business is not a democracy).

Finally! You now get to implement. You will probably notice you are creating things in record time. You are refactoring less. You are taking care of exceptions before they happen, instead of as an afterthought, which saves both time and money. Your actions corroborated by your peers and justified through your documentation is a home run. In short, you’re working smart and hard, and a business owner can’t ask for more than that.