Dr John Kenworthy

Principles of Successful Tech Leadership

Bridging the Gaps to Unity of Cohesion and Effort Between Tech Leadership and the Business

Dr John Kenworthy and Barbara Dossetter

The common ground is the frustrations with scope creep, budget specifications, programme management and poor leadership.

Unfortunately, this hasn’t changed in 40 years, and won’t change until both parties ante up to the bar properly. As the need for projects has exponentially increased, it’s seriously outrun our ability to field talented people to make this happen.

Our response has been to qualify Project Managers in Prince2 or PMS and not the life skills of standing your ground on issues of principles and having the courage to call out potential failure points wherever they occur.

Another area that most Project Managers need to hone their skills is in stakeholder management and positive politics.

The undercurrent of many responses was that the “other” side were primarily responsible for the frustrations experienced. When tech leaders refer to “poor leadership”, they were mostly referring to the business leaders, while the business leaders consider that it is poor tech leadership. Programme management as a frustration clearly landed in the tech leadership camp with more junior tech respondents frustrated with their tech leaders.

Programme management is another kind of leadership issue. We suspect there are some basic management techniques missing here, such as planning organising directing and controlling.

It is also likely that the area of stakeholder management and business engagement is sub-optimal. As we all move forward together, we need full engagement of both parties to be successful.

Business leaders are not taught leadership skills either. With the delayering of organisations, we’ve taken out the management to leadership apprenticeship that used to happen and think that we can make managers and leaders by attending a course or reading a book.

Business leaders though are highly frustrated with the lack of alignment of tech to the business; tech leaders see this as the stakeholders changing their minds and excessive user expectations.

This is a very interesting lack of alignment because both are right. Wrapped up in this one is the length of time that it takes to deliver a major project or programme and the speed with which the business changes. One solution that tech is trying is agile, which requires much more engagement with the business sponsor or subject matter expert. These have higher satisfaction because both are engaged in a joint enterprise and so share joint results. They also tend to deliver something quicker. Where this doesn’t work is in places like the Universal Credit project where it is still too long a delivery cycle.

The solution here is an engagement in a joint enterprise – easier said than done.

By far the most cited consequences of these frustrations is wasted time and money and the stress created to both the business and tech leaders. The cascading effect on business partnerships and failure to deliver what was promised then dominate for the business leaders, while tech leaders face rework and endless unproductive meetings.

These are important, but again they are symptoms and results. The cause is the engagement piece. Negotiating the correct level of engagement should be a part of the beginning or a Programme or project, and it should not start until that has been agreed. Then the challenge is keeping it going.

In earlier research in 2009 and 2013, I noted that tech leaders showed significant differences in leadership competencies when compared with business leaders.

It looks like this 2016 survey shows that those results probably have not moved much if at all. My big concern is that we see title inflation – particularly here in Singapore – and the people are not able to work at the level. Eg Assistant VP? Is that the VP’s PA?

Certainly, many of the responses to this survey suggest that the business leaders seem to think so. It appears that it is up to the Tech Leaders to develop specifically in their self-awareness and Engaging communications skills. That Tech leaders need to develop in critical analysis and judgment from a business standpoint to be able to more effectively gain the trust of business leaders and influence them to buy in and remain engaged by effectively communicating in a timely fashion with a complete appreciation and understanding of the business viewpoint.

If we use the analogy from the medical field: I expect my doctor to tell me, in a language I understand, what is wrong, what are the options and implications and help me make the right decision. I hope that I don’t need that information later, and probably won’t retain it because life for me (assuming I survive) will revolve around other things.

On the engagement with business colleagues, Tech folks need to speak business unto business, couch the advice in terms business people understand and with a clear understanding of their business and personal drivers. I think that this is a good spot to start looking at some of the ‘Trusted Advisor’ criteria in addition to our usual skills and behaviours and probably start to build them in.

Some business leaders can and do understand the tech perspective, but after 25 years of working with both business leaders and tech leaders, my experience tells me that it is relatively easy to help a tech leader understand the business, and considerably more difficult to help a business leader understand the nitty gritty of specific tech.

Probably one change in this area is that we are talking the tech in the company. Most of these people can handle the tech at home; they have home pcs, use smartphones order things online and do all sorts of daily tasks supported by tech. If we can leverage this, it will help. Also in some areas of the business, they are very tech savvy –e.g., social media marketing, engineering – product life cycle, finance – look at what they can do with Excel spreadsheets. We should move away from black and white to shades of grey. Also, the vendors of software solutions go straight to the business now – Salesforce to the Sales Director.

Often, what we need to learn is a language and the nuances of that language as our various stakeholders use it. To understand what matters and why and how this impacts something else.

Business leaders, too, need to be able to communicate what they want and need much more clearly and tech leaders need to stop assuming that they know what the business means or worse, allowing pre-existing biases and solutions to fit every situation.

This is the cause of so many of the perceived issues with tech projects. We need to ask more questions, probe more deeply and be willing to understand that most of us don’t know all the answers. Here we think there are two problems.

Tech – unwilling to admit they don’t know an answer and the engineering mindset of being perfectionists
Business – wanting to get on and do other things that are key to hitting goals. Willing to abdicate responsibility to the tech guys.

From the business leader’s perspective, time is wasted in delays and re-iterations dues in the main to poor specifications or business alignment.

The challenge here is to get the business leader/sponsor to spend enough time up front to ensure that everyone understands the outcomes, to take time to understand the journey proposed and the cost before getting started.

Time was mentioned by a third of tech leaders, but two-thirds of business leaders.

Not surprising because the tech guys could be confusing doing something with achieving something. They need to question what they are doing by what it might achieve.

Less surprising, a third of business leaders and just 11% of Tech leaders stated that these frustrations were costing money.

Failure to deliver a project on time means the ROI is delayed. Failure to deliver the BAU service for a period cost the business. This means that for the tech folks they need to think and talk in those terms to set priorities.

Quality and credibility in the eyes of stakeholders or clients was mentioned by more than 40% of Tech Leaders, while less than 20% of business leaders considered that this was a big cost.

This could be a success point. Business leaders see it as less than an issue because most of the deliverables are fit for purpose, while the tech guys rate it higher because they know what it takes to get there.

We might summarise that business leaders find that their frustrations of poor specifications, delays and lack of business alignment with tech programmes is the cost in time and money.

Tech leaders meanwhile, are frustrated by the waste of time but more importantly the cost in quality and their credibility when stakeholders keep changing their minds.

This is the clarity of the goals of the two groups, and neither of them is wrong. Improving across the board would be good. The credibility issue I would equate to the communication challenge that most tech leaders have – not knowing how and when to deliver bad news.

When Tech leaders take the time to get crystal clarity on specifications that are aligned to helping the business and consistently engage all stakeholders effectively, many of these frustrations will disappear.

Investing time up front on tech programmes to ensure that all stakeholders completely understand and that the programme is aligned with what the business wants and needs is likely to save swathes of wasted time and effort later.

To do that, we believe that Tech leaders need to understand the business and engage and influence their clients with a fresh mindset of serving the business and their stakeholders.

The implication of this is that the onus on the managing communication and relationship and the stakeholder engagement is on the Tech leaders. They also have to explain why (and often) it is critical to the business leaders to take this time.

Similarly, for business, as usual, clarity on the service level agreements required by the business and funded by the business is extremely important. Those need to measure business needs and outcomes and reflect the shared goals between departments.

This means that the tech leaders need to stop doing some things:

Accepting what the business leaders say they want without a deep dive to understand what the true outcomes wanted are
Getting agreement by putting things under a business leader’s nose to sign, knowing that they probably won’t even read let alone understand it. Communicate in terms that they can understand and assess.
Allowing projects to run on by being willing to suspect or call a halt to a project with any of the major issues to reassess with the purpose of halting this project with no loss of face
Allow the communication to disappear into a dark hole and then to deliver the finished product by regular and meaningful feedback on progress which will include changes of direction
Not listening to the business in how its changing and linking those changes to the effect on the project
Thinking they are a separate entity from the business – they are part of the business.

In short, tech leaders need to be inclusive of the business and be ready to serve their needs and business leaders need to be inclusive of their tech teams. Yes, what tech teams create might look like magic, but it’s a lot of drudge work in the background to make that magic happen.

Contact us today to discuss how we can help you

Bridge the Gap between Tech Leadership and the Business

Principles of Tech Leadership – Download the PDF Report

Free to Download

Download Now

Leadership AdvantEdge – Principles of Successful Tech Leadership…

Bridging the Gap Between Tech Leadership and the Business. Report following the research undertaken in late 2016 on the frustrations and issues faced by tech leaders and business leaders in…

view.publitas.c…