Do you REALLY know how to talk to your development team?

This is the burning question that I see come up time and time and time again. In today’s marketplace, each company is striving to out-pace, out-deliver, out-sell and out-grow the competition. Information technology capabilities are constantly seen as one of the key propositions in that endeavour. But how often do you encounter a gulf-of-misunderstanding between the business’s management on the one hand and the software development team on the other?

Often times, in my experience, a software developer is not really the least bit concerned about the operational aspects of a business, with how it attracts and retains loyal customers, the businesses strategies for continued growth during the short, medium and long terms and how it runs a profitable balance sheet. All they care about are topics such as:

  • Can I make this code faster?
  • What new technology can I learn and how soon can I do so?
  • How can I make this application run quicker, leaner and more efficiently?

All these questions focus solely around the technical aspects, or the ‘what‘ of software development and procurement.

Conversely, in my experience, a business’s management can fall in to one of two camps with respect to their approach to both technology and a programmer. These can be summarised by the following questions:

  • What’s the minimum investment that we have to make in technology, for the greatest speed, traffic and conversion increase?
  • What is the technology we need to get us ahead and keep us ahead of competition?
  • What is our competition doing that we’re not and how can we utilise technology to surpass them?

This is the ‘why‘ side of the equation. Now, whilst both of these mindsets are valid, they’re generally only focussing around one problem domain – theirs! Neither, a lot of the time, takes in to account the other side of the proverbial equation.

But when management needs a technical team, and this post will avoid the often thorny issue of out-sourcing,  and a technical developer just wants to code, what does it take to bridge the communication and philosophical divide? That’s what we intend to make clear now.

To make this simple, I’m going to summarise it in a few short steps:

Appoint One Key Person

In the organisation appoint one key technical person. This person must have more than a passing interest in and experience with software development to be the liaison between the technical and non-technical people in the business. Sometimes, not every time, the person in the organisation who oversees the technical team is either non-technical or simply lacks a proper understanding of how software development works and how a programmer thinks.

Charging this person with managing the development team can result in a poorer level of performance than can be achieved by a sufficiently experienced, or inclined, person. Strive to place and empower a person who truly understands both development and developers to manage the team, even if they’re not a programmer themselves.

Appoint a People-Focused Senior Technical Person

As the senior developer has the onus of knowing what the development team is capable of and managing the progress of the team, toward the technical goals of the business, ensure that that person is not just highly technical, but also a people-oriented person. Ensure that they are someone that can, and does, relate to those in the development team so that they earn their respect, but also to the business management, so that the business is properly informed of what is happening, where development is going and any impediments restricting the team.

Involve the senior technical people in management discussions

As with any other aspect of a business, generally, when people can take ownership, they are more likely to strive to give better of themselves and those around them. Given this, ensure that the senior members of the development team are involved in management discussions pertaining to business strategy, especially when it comes to the technical developments, improvements and advantages.

After all, the business has taken on a development team to build out their technology infrastructure, so get them involved and draw fully on their knowledge and expertise. In the long run, if managed well, this should help the business craft a more rounded approach over the long term.

Avoid engendering a them-and-us mentality

How often have you heard the clichés and stereotypes attributed to technical people. How often are they referred to as geeks, having anti-social behaviour, nerds and a variety of other references. Now whilst it’s often true that many developers are more introverted than say people in marketing and sales, but developers can be as able to relate to people as any other person in the business. Given that a development team may be so crucial to your business, it’s important to not build an environment of “them and us” between the development team and the rest of the business segments.

Now whilst these points only scratch the surface of the issue, I hope that it helps to make a start toward a more productive working relationship between your technical and non-technical staff. With so many businesses critically tied to technology, as it forms the fundamental means that customers interact with the business, it’s essential to get this combination right.

till next time,

Matt

Developing People People Software deployment Software Development
  • Paul

    Wonderful article! Very concise and to the point. I completely agree with you in that a technical and passionate person has to appointed to oversee the development process. Otherwise (which actually happens much more often in real life than one might think), the team will fall apart with lack of motivation. And consequently the project will not be delivered; in turn the business model might crumble like a stack of cards.