The CTO's role is to find the balance between the competing priorities of business leaders and technology experts, says Dr. Andy Piper, CTO of Push Technology. In an interview with The Enterprisers Project, he explains how the best CTOs meet that challenge.
The Enterprisers Project (TEP): Why is balancing competing imperatives between business needs and developer priorities difficult? Why can't you simply tell developers what needs to be done?
Dr. Piper: The majority of developers that I work with, or who work for me, are very interested in using technology, developing technology, and exploring what technology can do. Many are so passionate that they can get a little bit lost in the work; satisfying their desire for perfection becomes an end in itself. They can lose track of timelines and business imperatives as they explore possibilities and focus on perfectly formed software, while the business is generally deadline-driven. The business needs things by particular dates and doesn't care what the product looks like on the inside, they only care what it looks like on the outside and that it functions properly.
Getting the two groups on the same page can be easier said than done, and it often takes a CTO who is focused on driving them to meet in the middle. There is a great deal at stake if the project veers too far off in one direction over the other. We all know the value of a well-developed, business-driven timeline, but the problem with forcing developers to adhere strictly to it is that the shortest route to a solution is often the ugliest one, which means developers won't want to go that way. You can make people take that approach, but they probably won't enjoy the process and they'll wind up disengaged. In the end, you want to retain your developer talent. If people aren't having fun and enjoying the work, they'll just go somewhere else. The market is that competitive these days.
Another essential reason why you need engaged developers is that it's only through the process of really looking at a project from all angles that true innovation emerges. If the business side takes too much precedence, everyone is so focused on delivery and deadlines that they aren't given space to think inside the problem and around the problem. You don't get the happy coincidences that lead to new solutions that you wouldn't normally think to explore. You've got to allow enough space for developers to have the opportunity to do things they're not supposed to be doing, but which might lead to stuff thats more interesting, and in the end more valuable for the business.
TEP: In many organizations, developers have little understanding of the business needs and objectives they're creating software to meet. Is that the case at Push Technology?
Dr. Piper: I would say this isn't the case at Push Technology, but I have come across this in other organizations I've worked for. A lack of business understanding on the developer side seems to come about when developers don't interact with customers. You want, and need, developers to interact with customers in order for them to truly understand the problems that they're trying to solve. The truth is that most developers will happily not talk to customers. So you not only have to give them the opportunity, but also sometimes force the issue as well.
At Push, I try to make sure that developers are very involved not only in development, but also things like proof of concept work with customers, fixing bugs and the released product itself. Doing development-style tasks that come with more customer involvement and more problem solving helps developers become more business minded.
TEP: In general, how do you bring the two sides, business and developers, together?
Dr. Piper: A good friend gave me a piece of advice: When you're in senior management, a huge part of your role is to shield people from some of the tensions unfolding above. That's definitely part of the CTO's role. I strive to filter through what's helpful for either side - development or business - rather than just giving the unvarnished truth. For example, developers have a tendency to see small things as the end of the world. If the business got wind of their perspective, the business might panic. The CTO must bridge the two different mindsets and let through the right kind of information.
But, bringing them together also requires direct communication. We do various things within the company to bridge the gap. We have constant company meetings. We send out information about current sales wins and development projects that are going on. These are good little ways of bringing the two sides together.
TEP: What are some of the problems that can result if developers don't understand business imperatives? What about the other way around, if business doesn't understand developers' imperatives?
Dr. Piper: The two things I'd highlight are building the wrong thing, and delivering too late. Those are the two actual problems that arise if developers don't understand what the business needs. If the business doesn't understand developers, they can often have unrealistic expectations about timescales and the difficulty of the project. This is one of those things I've steered us away from at Push Technology.
When forced to meet unrealistic timescales, developers may take shortcuts that come back to bite you later, or they may obscure the truth, or say something exists when it doesn't. So you may have happy customers initially, but then when they dig a little deeper, they find things that don't work. You'll wind up spending far longer sorting stuff out with customers looking over your shoulder, rather than just the business side keeping tabs.
The business expectations around timescales are one of the biggest issues, just because software done right takes some time. The business often wants to just get a deal across the line, and that's sometimes the wrong thing to do. But, it's a trade-off. Given the choice, development would take the longest possible time to get to perfection.
TEP: What solutions to these problems have you seen work or not work?
Dr. Piper: The main solution here is the CTO acting as a buffer to the two sides, making sure there's reasonable pushback on expectations and timelines to the business. But, this comes hand-in-hand with reasonable whip-cracking on the development side to make sure timescales are reasonable for the business, allowing us to get the job done at sufficient quality.
TEP: What advice would you pass along to other CTOs about working with these competing imperatives?
Dr. Piper: First of all, don't tell everybody everything. You've got to really think carefully about what is the right information and what is the wrong information for specific interest groups. You need to have good relationships both on the business side and on the development side so that there are certain individuals on both sides of the house who have some information on the trade-offs that are required, and are able to have a rational dialogue about them.
And, secondly, business responds well to data. If you can expose why things are taking the time they are, or why you can or can't do something in a structured way, the business can be responsive to that. With developers, you give people good reasons why doing certain things is important, then they respond to that. It's also really important to set incentives correctly and make sure people are being incentivized or rewarded in a way that makes the project respond to the needs of both sides.
The other thing I'd advise is to have a weekly meeting with stakeholders that have the maturity to absorb the right information. This is just to make everyone aware of what's going on. That way, if people have concerns or issues, they can raise them and feel like they're in the loop.
ALSO READ
- Learn how leading-edge enterprises are experimenting their way to success with DevOps
- How to hire top tech talent and keep them engaged
As Chief Technology Officer, Dr. Andy Piper is responsible for a team of highly skilled engineers ensuring that the platform delivers the step-changes in scalability, reliability and robustness that have become synonymous with Push Technology. He was previously a Technical Director at Oracle with 18 years of experience working at the forefront of the technology industry. In his role, Andy led development for Oracle Complex Event Processing (OCEP) as well as driving global product strategy and innovation. Prior to Oracle, Andy was an architect for the WebLogic Server Core at BEA Systems, a provider of middleware infrastructure technologies. Andy has a depth of knowledge that spans both business and technology, along with experience that has seen him command a global network of some of the most skilled minds in the industry, as well as delivering potentially revolutionary product innovations within his field.
