Awesome Blossoms: Horn OK Please (9 page)

Anand glanced over and went back to chewing his pen while staring at his excel sheet and mumbled, “That is Govind. Are you still
hungover? By the way, can you send me a list of Canberra accounts…Puneet”

I didn’t turn around. I ran out of Anand’s cabin and I just locked myself in my own cabin. I pulled up Govind on the employee database, and sure enough the photo matched the chap standing in Govind’s cubicle. Then who the hell did I meet yesterday? Who
m did I help? Most importantly, why did I recognize him as Govind straight away?

In the days to follow, I followed up on every lead to identify Govind. Each lead turning into a dead end – there was no watc
hman, I never drove to St. Mary’s emergency ward as there was no security cam footage of me etc. Days turned into months, and along with an absence of answers came the added benefit of far fewer recollections of that night. I never told anybody, because let’s be honest, this isn’t the standard fare Monday conversation. I imagine the talk would go something like this:

“Oh hey, Bob! Yup, the kids are fine. The weekend…nothing much, did the same ‘ol, same ‘ol. Oh yeah, except I drove a ghost and his dad to an emergency ward. Bob…you there? Bob…”

Finally, long after my failure to glean any further information regarding Govind, I decided to stop. After all, not every single thing needs to be explained. To be honest, I feel blessed.

The words spoken by Govind remain fresh in my mind – “If we live our lives in response to what other people do to us, then we will forever remain just an echo of their actions”. Was this his way of hinting that he is merely an echo? Was he trying to guide me towards a deeper purpose? All I know is how I felt back then – that Govind had answers to questions that I didn’t even know how to ask. Maybe the answers are all around me. Maybe, I just need to learn to ask the right questions.

***
 

CHAPTER EIGHT

By Michael Kögel

***

The single biggest problem in communication is the illusion that it has taken place.

- George Bernard Shaw

Words That Fail

B
roccoli, I love broccoli! So does my daughter. "Oggoli" was one of her first words more than 15 years ago and I still have that picture in my mind. Sitting in her high chair she carefully places one piece after the other in her mouth and is delighted. Those small pieces of broccoli look the same as the bigger pieces we eat. Just at another scale. It's still the same if you look at a full broccoli. This self-similarity is fascinating. Consider an ant making its way up that broccoli plant. It would encounter lots of forks that require a decision as to where to go. No matter which route she takes she’ll eventually end up at the top of the plant somehow.

So it's not about the decisions that one takes, but about the readiness to take them quick and keep going. That's how I've been living my life so far and plan on doing so till eternity. It's nice to have a plan, but more exciting to
go for new opportunities when they arise. As an explorer, I get bored easily; so every two to three years I do something new. Learning, teaching and having fun is my motto. My business card says Design Strategist - for now.

Look, h
ow well I communicated my thoughts with you! Don’t you agree?

Whenever we go for a weekend outing, my wife asks me if we need to carry lunch.

My reply is very standard, “No”. However, what I fail to understand is that she wants to know the plan for the entire day, the time we would start from home to the time we would head back. A simple ‘no’ doesn’t suffice her requirements. But of course, I only understand her intent after five more detailed questions that again get my standard replies that further compound the annoyance of my beloved.

“Communication, Communication, Communication!” That’s how my wife taunts me with after we have had yet another misunderstanding.

If communication can fail like this in a long and loving relationship, imagine how difficult it can get in a corporate setting that ranges across age groups, cultures and time zones; basically spanning the entire globe. And on top of that, communication in such a setting is not that easy as it appears. Many a times, the medium chosen for the expression of thought might be a language that is not your mother tongue, and lo! You are in deep soup!

Anyway, a workplace is an amusing place. You can find innumerable tools that have been specially designed to keep people from being productive by locking them into a conference room, be it physical
ly or virtually. At least three different remote presentation tools let you not only bore the people in the room to death, but they also allow you to annoy people ‘around the world’. Well, ‘around the world in 80 minutes!’ And it’s a vicious cycle that you cannot escape. In turn, your colleagues express their heartfelt gratitude by inviting you in one of the similar session that they would be hosting in near future. And the agenda would be a carry forward from your presentation: to discuss the points that they didn’t get that time either due to their faulty connection or because of coming late to the meeting. But most of the time, these are euphemisms to express the sheer fact that ‘their brains couldn’t match the wavelength that you had used to communicate your thoughts’. To emphasize this fact again and again, the same topic gets draped in new issues and is taken round the table for, God knows how many times, with different people every time. Well, you can invite as many people as you want to which they will later oblige by inviting another set of people to strengthen some points which might need another couple of meeting to get clarified on the table!

And well, surprise, surprise! After going through a rigorous schedule of meetings and more meetings for another four weeks, your company arranges another meeting to decide if the Christmas tree print on toilet paper fosters discrimination towards those who are the non-be
lievers of the Christmas tree. Or even worse; non-sustainable, as it promotes the brutal and premature killing of the innocent trees.

And right then, in the middle of the conversations that lead nowhere, a phone rings and there starts the singing along with that one song that some lunatic choses as the ‘on hold’ music and that too in a middle of an important conference call like this when almost 50 people from all across the globe turn into the choir members! Well, what else can the people do who need to wait for the guy to get back on call
? You can sleep, of course! But in one such incident, one guy fell asleep and made a live telecast of his ‘snores’ without even switching the mute button on! And later, this one particular guy becomes the center of attraction in all the office parties as everyone else has a good laugh on him. Tell me one thing, how did all these morons who are not able to find or operate a mute button, score a job in the industry in the first place? Strange, isn’t it?

And now the Millennials add themselves to the mix. Having grown up in the digitalized era, the old fashioned file sharing through attachments by e-mail suddenly looks so incongruous in the modern times.  It is the epoch of all those hipster tools like DropBox, Google drive and other stuff designed to make older people feel even older and slightly stupid. In medieval times, just mentioning their names would have meant your head ends up on a stake in front of the castle entry as a warning to others. Lord Security Policy and his beloved wife IP Protection would have cheered as the h
eadsmen brought down his double-edged axe. Today it just leads to a total chaos because everyone uses the tools one likes, replicates data and makes complex projects look even more complex from the usability standpoint along the way.

So, the burning question is, ‘Are there any exits to this vicious circle?’ Let’s look at alternative working models that solve at least some of these issues.

Agile software development has been very popular for more than two decades now. The basic ingredients are small co-located teams of around 10 people with a high level of autonomy. Instead of being micro managed they get a set of high-level user stories and have to figure out when and how to best realize them. Communication is condensed into a 15 minutes stand-up meeting every morning ideally held in front of a physical task board. Everyone in the team gives a short overview on what he has achieved the day before and what he plans to get done that day. In addition, problems are raised, but only addressed in follow-up sessions by those whose can contribute to a solution rather than wasting everyone’s time. The SCRUM master takes up every problem that cannot be solved by the team itself and tries to resolve it across teams or with other stakeholders as required. His or her main task is to keep distractions away from the team and keep them as effective as possible. Another special role is that of the product owner who aligns the product vision with customers, explains the user stories to the team and has overall responsibility for the product. Work is divided in iterations (sprints) that can be as short as a week or two. On the first day the team agrees what they want to achieve by the end of the sprint and on the last day they show what they created, most important, by running demos and not slides.

Design Thinking is an approach that was created 10 years ago by the design agency IDEO and is meanwhile taught at various universities around the globe and has been adopted by corporations small and large. The method brings a designers
’ way of working into a corporate setting to solve wicked problems like “Resolve the communication challenges of cubicle dwellers in multi-national corporations”.  The initial reaction of most of us is to directly hop to conclusions like “Let’s give them a webcam so they can see evil Helga while she shouts at them on the phone”. This is somewhat natural given the solution focused education and work style that we all have been practicing for years or decades. Unfortunately we tend to just try to apply solutions that worked in one setting in a completely different situation. In Design Thinking, we break that cycle by first understanding the problem and involved characters in great detail through observation, interviews and a myriad of other research methods. With all the information collected we reframe the original problem definition aka design challenge and create a point of view that includes people whom we focus on specifically and what concrete needs and challenges are. Only then we move into the solution space by collecting tons of potential solutions using brainstorming techniques with the team. From the last set of ideas we select the most promising one and sometimes also a couple of crazy ones that we prototype in order to be able to get quick feedback. Of course what sounds very linear here can be a bit chaotic going back and forth between stages in reality.

What do these two methods have in common and where are they different?

Design Thinking shares the small focused team approach, quick iterations and collecting feedback by showing tangible results with Agile software development. In addition, the team is made as diverse and as multi-disciplinary as possible. While agile teams usually consist mainly of software experts, we add business people, domain experts, end users and designers. Students or interns can act as a fresh set of eyes that see details that we miss due to professional tunnel vision and ask the dumb questions we miss to raise.

Both methods benefit from having the teams in one room that allows them to keep planning and
hence work results on the wall for everybody else to look at. Design Thinking adds this additional level of empathy by getting yourself into the shoes of the people that use your product. You see them as what they are: human beings, not only walking business roles. In contrast to agile software development which, as the name suggests is primarily used for software projects, Design Thinking can be used in a wide variety of areas from physical product design and service design to computerized systems and even policy definition or urban planning.

Design Thinking helps you define WHAT you should create while Agile software development explains HOW you should build it.

The methods complement each other. I’ve seen Agile projects that run the first sprints in Design Thinking mode and also Design Thinking projects that work in sprints to have a better visibility cadence for management.

So consider using elements of both because according to Eric Ries,
‘Building something that nobody wants is the ultimate form of waste’.

Okay, so far so good. But how can this improve my dreaded corporate live?

Remember that neglected whiteboard on your office wall? Start using it! If you don’t have one, put up some brown paper. Windows are great as well; plaster them with post-it notes. Do your planning on the wall. "To do", "In process", “Done” are all the columns you need for a start. Get the team together for 15 minutes each morning to update the board. Read up on
Kanban
boards if you want to learn more. It’s worth it.

But then you say,
“Wait! My team is not in one location” you say.  Well there it gets a bit tricky. You could try to use one of the online tools that I condemned earlier, but your energy is better invested in questioning the status quo. Why is it that the team has to be distributed? If it’s in the same region of the world chances are you’ve got Project A with 5 people in X and 5 people in Y and Project B is staffed in the same way. Why not run A in X and B in Y instead? You have an answer, “Well the people in those locations have different skills”. Let’s see how much those skills matter during the next reorganization. In the end these are only ‘resources’ with the ability to learn fast if you ask HR. So why not give them a little more job satisfaction by running a project responsible with their colleagues on site.

If you are
in an extended workbench setting aka offshore, nearshore, it’s a damn long way to any shore from Bangalore, it’s getting even more tricky. Who came up with this stupid off-shore term? It’s not that your cubicle floats in the middle of the ocean. On the positive side you would pay a lot less taxes out there. Anyway in that situation it will be a bigger challenge to get the whole project responsibility to your location. What would all these highly paid managers on the main land do then? India is a small island, isn’t it? Why would it be offshore otherwise? Try to get the whole team on-site for initial 2-3 day workshop at least. Getting to know the people personally, helps tremendous in further remote communication. Use the time to build a common vision with the team on what needs to be done. Make sure to grill the guys in charge with questions on the end-user and how they work today. Chances are you don’t get good answers. Take this as a warning sign and ask for research and details. Be creative. If you don’t have the budget, ask friends and family if they know someone in that role or industry and interview them.

Stop going to meetings
that have more than 5 participants. There will be no decisions anyway and in the unlikely case you learn about them from a colleague who attended a part of verbal 3-minute summary.

If e-mail thread goes back and forth more than three times, pick up the phone instead and talk to the sender. Drop slides. If you can’t get your point across on a whiteboard or flip chart, 100 fancy slides won’t help you.

I’ve spent 9 years in distributed teams with various levels of travel budget (which helps) and up to 9 hours a day in online meetings. In some of them I had to do simultaneous translation of our fast talking friend, Chief Redbull. I’ve seen it all and never want to go back.

The last three years, I had the luxury to work in co-located teams and it’s just awesome and so much more effective. It’s worth the fight for a change. Put this high on your checklist if you make a career move. If you want international experience go there and get to know the people and culture first hand not via WebEx and the like.