Sometimes… let things break a little

Read the original article at Sometimes… let things break a little

Have you ever started a new project, just into it you realize that maybe there aren’t technical problems to solve? It starts to dawn on you the real crux of the problem boils down to people & processes?

It’s happened to me on a number of occasions, but once in particular really stands out for me.

I was working for a firm in the education space, in particular around test preparations.

Asked to automate a publish process

The environment had a mix of relational databases, from SQL*Server to MySQL for some applications. The web facing database however used Oracle on the backend.

Their career DBA was real old guard Oracle, he had his ways of doing things, and didn’t want to rock the boat. In particular he managed the process for publishing changes to the website. Publishing amounted to running a few hand rolled scripts and each step was a manual one.

With the process setup this way, the editors had to work closely with engineering each time they wanted to move content to the website. Slow, cumbersome, and not very workable.

The real problem, siloed departments & infighting

As I worked closely with the DBA, quite a few things became clearer. For one he was sometimes a grumpy fellow & he had a strong accent which was sometimes hard to cut through. Knowing the other team members, I knew this all contributed to the trouble. But he maintained quite a bit of resistance to automation of the process no matter what. His view was, if he hands over the reigns to editors who don’t understand the technology, they’ll screw something up, make a mess, and that would ultimately create more work for him. After all that he’d be doing it manually anyway!

Further attempts to communicate between teams or even between the managers and this guy went nowhere.

It’s not easy to find a good DBA. We wrote a MySQL interview guide to help and one for an Oracle interview too. The mythical dbas remain in rather short supply.

We weren’t trained for this in engineering school

When you’re looking for a technical solution and you realize the bigger issue is a people problem, what do you do? You can gently bring it up with the higher ups, but they may have a different style, or prefer the shout orders and bark mode of management.

Things continued to go around in circles, and attempts to get further information from this DBA didn’t prove fruitful. He was protective of his domain, and fought tooth & nail to open up.

Things come to a head

The bigger boss, the one above my direct report, one day called me into his office. Actually it was an off day I was just stopping by to check in on progress.

He pulls me into his office. Since I rarely interacted with the guy, my guard was very much down. I thought we’d have a chat about the weather or perhaps who was going to win the world cup.

He proceeds to tear into me without warning. Practically screaming, he’s giving me a piece of his mind and not stopping to hear what I have to say. Where is this project going, why is there no progress, we’ve got serious deadlines, you’re pushing us right up to the wall … that kind of thing.

As I listened to him fire away at me, I realized some of this had gotten filtered through some sources, who didn’t completely understand the blocking issues either. That it wasn’t technical challenges, but rather people and processes that weren’t working. As I began to explain this, he stopped me and said:

.

A few things ran through my mind at that point. One was well he’s not a consultant, so either he couldn’t last in it, or the life didn’t appeal to him. Or perhaps his skill sets ran truer to management in a large firm, a different albeit tougher role to master.

But it also occurred to me that different folks have very different styles, some like to push, and prefer confrontation & believe that leads to resolution. While others are more listeners and find there way around a problem by giving everyone a chance to voice their positions.

My style is the latter, while his was clearly the former.

The fallout

What ended up happening is a project manager also got assigned to the project, as well as another manager. The PM liked working with me very much, and as things unfolded, much of the departmental siloing began to dissolve, and the bigger communication problems began to surface. From there solutions followed.

Lessons learned

- beware the status quo – some don’t really want to rock the boat
- communicate your position, but beware that others may have a different style
- you may be asked to support a path you see as the wrong one
- let things “break a little bit” so everyone learns the hard lessons
- getting burned can be a lesson for the whole team, and lead to new solutions

Made it this far huh? Grab our newsletter.

No related posts.

For more articles like these go to iHeavy, Inc +1-212-533-6828