IASA

I’d like to share a recent experience that relates to a long standing issue at large in our industry.

 

A new guy gets hired. He’s pulled into a group that doesn’t have the same seeming level of technical savvy, so they feel awkward commenting on his approach. He knows all the patterns. All the buzz words. And he’s prolific. He’s checking in more code than a dozen code monkeys. His code seems odd and foreign to the members of the group. They’re excited. They feel as if they have found their savior.

 

He is then assigned to assist with a cross-departmental project. The Org’s other development group is full of seasoned, senior designers who all have as many battle scars as successes under their belts. Their architectural style has been informed by this wisdom. They know how to get things done with alacrity and accuracy. They have learned to add only what’s necessary and in doing so, have mastered their own impulses toward complexity.

 

The project turns out to be fairly straightforward. The team outlines some loose requirements and suggests a few approaches. Enough to get the job done. Without over engineering. The new guy, in all his vibrato, completely disregards all suggestions and goes off the deep end. Code Rampage! Check-ins come fast and furious. Soon there’s enough code for 5 projects.

 

As you can imagine, code review reveals there’s patterns galore. A factory based framework for who knows what. Controllers. Activators. Generics. After the first review, numerous iterations ensue without much change. Eventually, at the request of some concerned team members, management joins the fray. Unfortunately, the situation starts to become political.

 

The team, without clear leadership, muddles around in confusion that ends in apathy. And because the project’s cross-departmental, upper management dances around the issue. In the end, the org wastes a great deal of time slowly coming to the conclusion that a team lead should be named, act as architect and actually run the project. Everyone else should fill in the spaces. Yet another architect is born under dubious circumstances.

 

This is a common scenario in our industry and it drives me absolutely crazy. The waste insults my sensibilities as a worker and as an architect. The drag on progress it creates is immense. And it completely erodes the dev community’s sense of equity and equanimity. (You know, of course, that while this whole little drama was playing out, the deadline never changed. Deadlines never move. Only loom with doom in situations such as this.)

 

After having witnessed this type of debacle again and again in my long and illustrious career (new guy or not), I have come to believe there is one core concern at play here. It all revolves around the dreaded ‘T’ word.

 

The first and foremost concern in any team scenario is the dreaded ‘T’ word, trust. Trust within a team and its members. Trust between a team and its management. Trust between management and the Org. From my 20+ year industry perspective, it is hands down the single most pervasive thing affecting dev.org.health.

 

Trust was missing in the scenario above, because management didn’t even think to bestow the mantle of leadership on someone before launching into a new initiative. Only after the debacle rose to catastrophic proportions did they conclude a leader was necessary. Ponderous.

 

Of course, trust is mercurial and precious. It comes and goes and in general is hard to acquire. It takes courage to trust. Because to trust is to relinquish control. So before trust can be bestowed, the Org must know upon whom they can safely lay this coveted mantle. To do so the Org must be willing to recognize their ‘A’ players. And no, I do not mean management speak when say ‘A’ player. I mean the org must acknowledge and anoint their true ‘A’ players, their Architects.

 

But how can management do this?

 

When entering an org, I can often get a feel fairly quickly who falls where. Whether from firsthand observation or from other developers. Of course, there’s been occasion where my early impression was horribly wrong. To both the good and the bad. Only to be quickly corrected by the dev staff.

 

I’m OK with this, actually. When to the good, I am glad to be wrong about my private talent audit. I hope to see everyone I come in contact with rise to their full potential. Perhaps even a rise to a potential they themselves didn’t know they possessed. Maybe I’m one to have inspired them to reach further. Maybe, even, I’m the lucky one to be inspired to challenge myself.

 

When to the bad, I had at least given someone the benefit of the doubt and it didn’t work out. At least they had the chance. In the end, I am a very vocal advocate of the dev community. They are not just ‘code monkeys’.

 

It has always surprised me that the developer community inherently knows where everyone falls on the skill and design scales (yes, they can be mutually exclusive) better than management. Shouldn’t this be the job of management in the first place? Management must know upon whom they can bestow the mantle of trust. They must also have the courage to take a chance on someone. It is absolutely essential.

 

Unfortunately, this mercurial assessment is mostly a feel thing. An equation the result of which is attained by knowing your staff and your goals. The good managers I’ve met all had different approaches to assessment. Though there always seemed to be a common thread of listening and watching running throughout. They also rarely assessed based on ‘output’ alone. In the end it may come down to simply giving someone an opportunity to shine.

 

Too many times I see talented members of the dev community wither on the vine and turn black. I can see that they’re ready. I can see that their technical decisions are sound and the dev community respects their opinion. Their design suggestions seem to frequently find their way into bits. And of course, the best also have that crucial core requirement, the ability to lead.

 

But for whatever reason management doesn’t act. They let these people grind away without providing the slightest opportunity for personal gain. And eventually, even the most ardent positive souls turn black with indifference and malaise. Where did this ‘use them up and spit them out’ managerial approach come from? Is this what they’re taught in management school? It is somewhat of a joke that both sides know the difference in salary between the lead dogs and the puppies is slim. Somehow, as your tenure grows, your reward diminishes.

 

When did the art of cultivating talent die? When did it become fashionable to plug and replace instead of grow. Again there is wisdom here leveraged in other arenas that has been unlearned in corporate culture. The org must be a healthy vine on which talent can ripen, flourish and develop.

 

When ready, they should be given the opportunity to grow. I’ve never understood why organizations are reluctant to empower their top developers. Challenge them. Give them something to really chew on. But don’t leave them in that weird limbo with all the responsibility and no authority. The dreaded middle management zone. Back them in their decisions so that their team can learn to respect their position.

 

All this new found responsibility should of course be accompanied by an equitable amount of recognition and reward. Why organizations are reluctant to do this has never made sense to me. If you’re making money in the software arena there is no doubt you have a talent pool of core people who are carrying the greater part of the burden. There is no question that a fairly compensated workforce is more productive. The shift in morale alone when these people feel taken care of is palpable. And what has always frustrated me is that the difference to the bottom line is almost nil. So empower, recognize and reward.

 

I cannot stress enough the importance of leadership, especially at the executive level. It is the linchpin against which all modern endeavor is set. In other arenas, it remains vital to success, but somewhere through time, this idea has been completely lost to the modern corporate consciousness. In it’s place the pale specter of Manager has been cast.

 

It is clear to all but those in business that to any endeavor of worth, especially the epic odyssey that is the birthing of great software, leadership sees you through. It is not about Gantt charts, scrum meetings or burn downs. It’s about all the extra love you get for free when your team is actually lead with a vision.

 

I’m not saying that these concepts are mutually exclusive, but time and again I see large projects turn to dust due to lack of leadership. I will actually go as far to say that I’ve seen projects succeed where there was strong leadership, but project management was lax.

 

I tell you it makes my blood boil when at the start of a great adventure, that pivotal moment where impressions are cast and intent should be clearly defined, the only message that is conveyed is a brief email from executive management. How in the world can you honestly expect to rally the troops behind your cause from the comfort of your desk? This sort of thing absolutely drives me crazy. Their subordinates are then left to piece together shattered expectations and rekindle the fire. The opportunity to engender trust completely squandered.

 

Leadership begets leadership. And, of course, this is one of the reasons ripe fruit withers in some climes. Those in positions of authority who do not lead, are inherently uncomfortable with those who incline to do so naturally. The opposite of course being equally true. Actually, no that’s not the case. These scenarios are not equitable. The absence of leadership creates only drag on progress, while leadership in bloom is infectious. It has an exponential effect of creating acceleration.

 

So now if we go back to the New Guy and the dreaded ‘T’ word with our newfound insight, what happens? Empowerment and progress. Plain and simple.

 

Management would have had their stable of leaders or given someone the opportunity to shine. They would have had the comfort in knowing their choices were sound because they would have been watching and assessing. They would have been proactive, instead of reactive. No momentum, nor morale would have been lost. They would have been recognizing and rewarding all along. Their leaders would be ready and willing.

 

They themselves would then have shown the leadership to bestow a leader to the team, preferably in the form of an architect. The mantle of responsibility would have been clearly and formally passed and everyone on the team would have known how the situation was to work. There would have been no ambiguity to confuse and complicate.

 

Understand that while I strongly believe someone must lead the team, I also believe in the concept of self-managed teams of senior people. In these team types I also believe in design by consensus. Trusting the team, as well as, the individual. The result of which is surprising architectural consistency. Team members may be cast as facilitator on any given project and while never dictatorial, must ultimately call a vote in discrepancy scenarios. The result of which is final. But let’s get back to that dreaded ‘T’ word.

 

As I’ve made clear, trust is the single most important value affecting dev.org.health. I have never understood why management can’t bestow an appropriate level of control to a team lead or facilitator who is ultimately responsible for the success of a given project. To burden a lead with the responsibility of success without trusting them is to undermine success from the onset.

 

The secret to Trust to Lead is a team empowered with trust and a leader that values a democratic team.  These teams avoid the nightmare of fascist regimes. They also inherently curtail Code Rampage, naturally, without condescension or reprimand. There will no doubt be impassioned discourse. If there isn’t, no one really cares. I’ve learned that apathy doesn’t live long in a democratic team. Everyone gets drawn into engaging the topic.

 

So Trust to Lead and watch your dev.org.health shine.