Software programmers are not blue-collar workers

Like many skilled workers, software developers are smart creative people. Leading or managing such people requires finding a way to guide, support and empower them, while letting them do their job. Writing software is inherently a process in which trade-offs and compromises are made continually and iteratively till the end. It is therefore essential that all parties stay as close as possible together so that they can weigh decisions when it matters and actively take part in the game.

Like many skilled workers, software developers are smart creative people. Leading or managing such people requires finding a way to guide, support and empower them, while letting them do their job. This sounds easy, but I have seen many organisations and individuals failing at it, leading to the very issues they were trying to prevent. The recurring mistake people commit is that they treat skilled workers in the same manner that they would do blue-collar workers.

I have built and managed technical teams throughout my career, I’ve always been aware of the need to balance communication with smart and skilled folks like software developers. I continuously practice software development myself. By staying hands-on on both sides of the equation, I’ve continuously kept tap of the challenges involved. It’s one thing to be programming, but leading and managing developers is an entirely different game.

Instructions can be crippling

Some believe in providing extremely detailed instructions to developers, as a way to manage work. That is misguided for a number of reasons. Every software programming endeavour is as unique as can be. Micro decisions need to be made at every step of way, the conditions that might have been prevalent in a prior project context would have been largely superseded by new ones. However detailed, instructions will leave gaps that developers will run into. As such speed bumps are encountered, people want them to be removed swiftly and they would feel better if they could that themselves. If developers are not properly empowered, such gaps will lead to frictions, could cause tensions and result in defensive behaviours. While well intended, detailed instructions is not a very effective instrument for managing software development work.

If everything goes, nothing does it

The other extreme to too much instructions is having none. Without any guidance, anything goes. Such software development will lead nowhere. For software development to succeed, all those involved should be able to describe in a consistent and coherent manner what the aim is and what the final product should be. Software developers don’t work in isolation of other units in an organisation, they need to know what is intended, what is expected of them. An optimal set of guidance accepted across teams is a necessity, not a luxury. Working out exactly what such guidance is and how much of it is needed, is part of the job that leadership must facilitate.

Bean counting may be useless

Some are painstakingly tracking developer hours, lines of codes, and other misleading metrics, in the firm belief that that is the way to manage development resources. For the kind of work that doesn’t require thinking or coming up with solutions, typically repetitive tasks, that may yield some results. In software development projects this is a fruitless endeavour, developer productivity does not lie in any of those things. Bean counting is only useful if used anonymously as a learning tool, and perhaps as supporting documentation in the event of a dispute over resource usage. This last one is typically what software consulting bureaus are worried about, they then unfortunately put so much emphasis on it that it becomes a damocles sword over people’s head. Finding the metrics that matter is a skill.

Perfectly codified work is demotivating

If software development work could be codified to such extent that it could be flawlessly executed without any thinking, exploring, personal problem solving skills, then nobody would ever want to do it. That would be the most boring job ever for anyone. It makes people feel insecure, a feeling that could be summed up in an imaginary thought quote:

If I am not bringing anything special to this work, I can be easily replaced by someone else, or a robot! I don’t like that. I want to be perceived as being special to this project, I reject any shoddy instruction that would make my job look plain and simple.

This is also something that team managers and leaders should be careful about. When providing guidance turns into hand-holding, people stop thinking for themselves and the group may walk blindly straight into trouble. And when trouble strikes, finger pointing is often what follows. Besides, people learn when they can get themselves stuck and work their way through hurdles. When the conditions are right, the outcome will almost always exceed expectations.

Architecture: just enough guidance

Writing software is inherently a process in which trade-offs and compromises are made continually and iteratively till the end. It is therefore essential that all parties stay as close as possible together so that they can weigh decisions when it matters and actively take part in the game. In my experience, what works well is to provide just enough guidance to developers so as to establish appropriate boundaries of play. When that is well understood, leadership must then work to establish metrics that matter, and closely manage such metrics for the benefit of all those involved.

Treating software developers as blue-collar workers to be told “here, just go and write software that does this and come back when it’s done” is fatally flawed. People who typically make such mistakes are:

  • project managers, who are clearly making assumptions that only they espouse and neglecting the basics of creative work process
  • architects, who believe that developers are lesser capable workers that just need to do as told, follow the blueprints
  • technical managers, who have the impression that managing people is about shouting orders, being perceived as having authority
  • people enamoured with processes, tools and frameworks, oblivious of the purely human and social aspects of software development

In my experience, the root cause of such mistakes are relics of obsolete management practices that favoured hierarchy over social network. Note, my use of the term social network has absolutely nothing do with the multitude web sites that hijacked this vocabulary. By social network, I am referring to situations when a group of humans are engaged in making something happen together, it is social because of the human condition, and it’s a network because of the interdependencies.

This subject is vast and can be treated over a much larger text than I am doing here. In this post I’ve only touched upon a few of the most visible and recurring aspects, I’ve stopped short of discussing issues such as applying learning,  methodologies or tools.

If you recognise some of the shortcoming listed above in the context where you are in, and if you are in a position to influence change, I suggest that you at least initiate a dialog around the way of working with your fellow workers.

Doing Things Half Right for Better Results, a little story.

In a technical leadership position, it helps to be comfortable in giving others some space to grow. This doesn’t threaten a leader’s position, on the contrary the leader gains more respect from others, others would more easily take ownership

In this post, I intend to share a learning point drawn from my personal experience, as you might recall if you’ve been following my tweets. I would appreciate any comments you might have. If you would share your own experience, that would be wonderful. I have reopened the blog for comments, the threat of spams having been largely contained by recent WordPress updates.

For a start, I should clarify what the title means: this discussion is really about intentionally half-baking solutions with the purpose of encouraging people to take ownership. It is about leaving room for someone else to blossom. To give another analogy, my local supermarket sells half-baked bread, when put in the over at home you get a deliciously fresh bread that gives you the illusion that you made it yourself. This post is not about doing a bad job, it is not about hiding behind excuses or avoiding getting one’s your job properly. This is about a good leadership practice when success depends on people taking onwership of parts or parcel of an initiative or a project. I hope this clears any potential misunderstandings.

Now, I would like to give you a taste for my personal experience, trying my best to keep it anonymous and neutral. I’ve boiled it down to one example, to keep the text focused and prevent any direct link with specific events and people.

In the early days of my carrier, I had the impression that I needed to have anwers to any technical question that came my way. I couldn’t help it. I would feverishly research and prototype technical solutions, work long hours to find answers that I could show to my colleagues (I still research as thoroughly as I can, but I’ve just learned to work better on the communication side of the equation). I thought that was the only sure way to gain respect and recognition amongst my peers, my reportees and my managers alike. I thought it could be damaging to my career if I failed to demonstrate knowledge and proficiency in technical matters This attitude served me well whenever I was directly responsible for designing or programming a solution, I could just show off my abilities quite easily.

At some stage though, as I got more and more project responsibilities, I was often annoyed to see that I sometimes failed to get sufficient support for my ideas even though I had checked everything and thought I had good answers. This was even more puzzling and frustrating when, in a leadership position, i would get the impression that people were simply ignoring me or refusing to see the light. Worse!, I had the impression that some managers were prepared to steal my ideas but seldom prepared to empower me, oh the outrage such feelings gave me!

Then one day, something happened that taught me a lesson: someone (higher up in the pecking order than me), rephrased and presented several ideas of mine, in my presence, without giving me credit (I had presented him my ideas and he rejected them). I was boiling during the whole presentation, but somehow I managed to stay calm and showed no emotions throughout. At the end of it I simply left the room and made no comments to anyone about the subject. The presentation was well received, the person in question did not dwell on it. I was so upset that I had the worse of thoughts for this person and didn’t wish to have anything to do with him again, if I could help it. A couple of weeks later though, as I ran into this person at the coffee machine he simply congratulated me on my contribution and left. It was clear that he knew how I felt, I took it as an indirect apology, but didn’t make much of it as I had moved on. The episode made me ponder a bit however, I realised that I would rather be associated with a success story than staunchly defend some bragging rights. This accidental epiphany would serve me again and again later on, as I stepped into leadership roles and I often worked with bright people. I tried to remember my story and control my instinct for bragging about, something that is generally against nature for technically inclined folks.

I had spotted a learning pattern that I have been trying to nurture ever since: to successfully collaborate with people, particularly in a leadership position, it is good to try and show humility and give others some room to grow. Nobody wants a superman-like figure around, especially when he (or she) is the boss. Appearing to have all the answers (or a lot of it) can easily breed resistance and cause projects to fail, if only because other people could be overshadowed and would have no motivation to take any ownership.

Despite what one might think, it is always beneficial to hear other people’s perspectives on issues. When I got humbled the way I did, it also made me realise that I had always thought people have a lot more potential than they give themselves (or are given) credit for. In my urge to try and grow, I was often loosing sight of my own belief and surely would not be able to lead had I continued on that path. I had learned to change in an accidental shock therapy.

If you manage technically savvy people, one of the things you learn is that unless you gain their respect you can’t effectively lead people. To gain their respect, you often have to have demonstrable superior technical ability. In any case, you have to allow them to express themselves as freely as possible, you have to pay more attention to egos as people take pride in what they do. The matter becomes more complicated if you are a consultant and that you are trying to demonstrate your abilities to your client stakeholder groups, conflicts can easily arise with the technical recipients of your work. When the recipients don’t buy your solution, it won’t add any value and your endeavour kind easily end up in failure.

The lessons I’ve learned:

  • Do not be afraid to see some of your ideas “getting stolen”, at the end of the day it is better to be part of a success than otherwise
  • Even if, as a leader, you can bring about all the answers that are needed, doing that would be a show of poor leadership and a demonstration of a lack of delegation skill
  • In a technical leadership position, it helps to be comfortable in giving others some space to grow. This doesn’t threaten a leader’s position, on the contrary the leader gains more respect from others, others would more easily take ownership

Credit & disclaimer:

This blog post was inspired by an article I read on HBR by Peter Bregman, under the title Why Doing Things Half Right Gives You the Best Results, http://bit.ly/31DI. I wouldn’t be telling this story, had I not read this article.

I tried to keep this discussion as general as possible. Should the reader recognise any event or people or any particular situation in this text, that would be entirely fortuitous and a simple demonstration that nothing is really unique under this sun: it’s all been done before, I’m just one guy talking about something that happens regularly everywhere. So there should be no surprise there.