When executives don’t see the outcomes they expect from a technology, they often bring in external help to assess the situation and propose a get-well plan. We have all been a part of those meetings where someone says: Enough is enough! We keep discussing the same issues over and over, but the answer is not in this room. Let’s ask someone outside of this room for an independent opinion.
Often, it’s a management consultant who gets the call for help. But, for most IT issues, executives also need to talk to software developers for their advice and perspective.
1. Developers know technology on a level that executives don’t.
A real-world example: A large-scale SAP implementation was in jeopardy. The data conversion track was the Achilles’ heel. Quality and performance were suffering. The team was desperately trying to make improvements to the procedures, but all efforts were limited because at the core of the process was a third-party tool into which we had no visibility.
We added a developer to the team, who was not familiar with the third-party tool. He quickly wrote his own procedure using a toolset that was native to the hardware we were using. His procedure was lightning-fast and more accurate. After months of trying to work around a third-party tool, we simply threw it out the window and replaced it with a straightforward custom procedure, which saved the project.
This illustrates how developers think outside an executive’s line of thinking. While executives are focused on what might seem like best practices, developers often have fantastic ideas that apply to specific technological circumstances. The trick is not to tell developers how to get something done, but rather to tell them what your objective is, and let them figure out the how.
2. Developers have a different perspective on management.
Another example: A consulting firm was suffering from an identity crisis following a series of acquisitions. While top management was taking gradual steps towards stabilization, sales continued to plummet, and the best talent was walking out the door.
Over lunch, I asked a developer at the firm how much longer until things stabilize. “Never” said the developer. He continued, “This company needs to push the restart button. The only way we can be successful is if we forget about the past and all the plans we made. If we shed all the dead weight, we can use the remaining talent to reinvent ourselves.”
This was a very radical statement and I dismissed it as such. Nonetheless, history proved me wrong. The firm eventually dwindled to a handful of people and was sold off.
While developers may not always have the leadership skills required to execute a strategy, they often have the smarts to come up with or validate a vision.
3. Developers have a unique vantage point.
Executives have a business case view of investments in technology, i.e., “We will enjoy X benefits if we sacrifice Y time and money.”
Developers instinctively see critical execution components that will not only affect the implementation approach, but can also help validate or challenge the investment decision to begin with. They have great insights into a range of topics:
- Quality of technology solutions
- Vendor capabilities and personnel
- Compatibility of technologies
- Internal politics
- Technology trends
The biggest obstacle in communicating with developers is often terminology. Executives tend to talk about ideas, while developers often speak in a practical or technical language. Both sides need to have patience and show understanding for the other in order for the discussion to be productive.
In many cases, it is a good idea to ask developers open-ended questions to solicit input on management decisions. At times, you may want to ask validation questions, especially about a specific technology.
Some questions CIOs can ask of a software developer are:
|Open-ended questions||Why are we having service issues?
If we didn’t have all these urgent priorities, what initiatives would you consider to be important?
What are the top three problems with this project?
|Validation questions||Will this solution work?
What alternatives do we have?
What do we need to learn to make an educated choice?
Establish a cadence.
Let’s be real. I am not advocating that we involve all developers in all decisions every day. Neither am I saying that a software developer can replace all types of management consultants. My suggestion is that a regular cadence of targeted interactions with software developers will provide a steady stream of fresh ideas.
Executives who have mastered the art of “managing by walking around” (MBWA) know how to effectively harvest advice from workers on every level of the org chart.
Contrary to conventional wisdom, software developers do know both technology and IT management. Don’t miss an opportunity to tap into their insights. Try it today!