In this article — effectively a summary of the lecture in our Digital MBA for Technology Leaders — Andrew Bryant, business coach and public speaker whose book on this subject is used in MBA programs worldwide, explains what self-leadership is, why you need it and how to develop it.
What is Self-Leadership?
Self-leadership is the practice of intentionally influencing your thinking, feelings and actions towards your objectives. For some, this comes naturally, while others have to train themselves in it.
The problem the latter group needs to solve first is the so-called, framing or the nature of an individual’s central belief system that’s been influenced by social and physical factors. Framing effectively influences the way we see the world and, therefore, affects our decision-making process.
So the first step to solve this is to step back from that frame and accept the fact that we have all been pre-programmed. Otherwise, you will continue being just a passenger on the bus of life, as Andrew put it in his lecture.
Are You Capable of Self-Leadership?
One of the ways to check that is to confirm the potential absence of self-leadership abilities.
How to recognize the absence of self-leadership?
If a person has tendencies for reactivity, randomness, blame and a victim mindset, then it’s safe to say that self-leadership voids.
Why is Self-Leadership Important?
A) To become the driver of that bus of life and, thus, take full control of your actions and reactions.
B) To avoid the aforementioned symptoms that indicate the acute or chronic absence of self-leadership abilities.
The maxim here is, therefore, that you can’t lead others unless you first lead yourself.
This brings us to our final and most important part of this lecture:
How to Develop Self-Leadership Skills?
To test the ability to self-lead, we first need to measure self-awareness, self-regulation and self-learning.
As you know, self-awareness is the tendency of an individual to focus and reflect on psychological processes, inner experiences and relationships with others.
Let’s do a quick psychometric test on you right now.
Psychometric Test of Self-Awareness
Now, choose a chess piece that best represents your professional (work) personality.
Let’s see what each piece means.
PAWN: Eight on each side, they move slowly towards the opposition and are likely to be sacrificed early in the game. If you are feeling powerless at work, you’d be a pawn.
ROOK: A risk-averse piece that doesn’t move early in the game. Audit or compliance and sometimes technology are in the rook category. It is a very powerful, but not necessarily a good position early in the game.
KNIGHT: This is a risk-embracing piece, an entrepreneur. Jumps forward, sideways, surprises the enemy. The problem is that, sometimes, knights get so far ahead of the other pieces that they lack the support.
BISHOP: A piece that cuts diagonally across the board. Always in a hurry, hates stand-up operating procedures and just wants to sell even before R&D develops a product or Operations come up with the delivery process. Bishop is also the arch-enemy of the rook.
QUEEN: In the original Indian game of chess, the queen was the vizier and wasn’t gender-specific. The queen can go forward, backwards and diagonally. In other words, she can go everywhere. However, she’s so busy looking after everybody else that she sometimes forgets to look after herself.
KING: If you chose the king, maybe you have delusions of grandeur and narcissistic tendencies because the king, whilst the most important piece on the board, requires the support of all other team members.
And now for the real kicker – it doesn’t matter which piece you chose. This was a setup because you’ve been framed.
The reallesson here is to have a high level of self-awareness to step back from stereotypes and play all the pieces.
Building a high level of self-awareness is critical for the next fundamental – self-learning.
What is Self-Learning?
Self-learning is the process by which individuals take the initiative in diagnosing their learning needs, goals, resources and outcomes.
Our students, for instance, have already demonstrated an intention for self-learning simply by enrolling and following the lectures. That’s why you need to apply self-leadership to all the things that you learn here or anywhere else, adjust your behaviour and move forward.
In chess, for example, you will often find yourself cornered and locked up. But a self-leading mindset perceives such a situation differently simply because it is aware that when we feel stuck, there’s an opportunity lying in there somewhere. So if you just stick for a moment and take a good look at the board, you’ll find an opportunity to not just get out of the trap but to turn the game around. In other words, your self-learning tendencies will start looking for options.
From those options, we move into self-regulating mode, otherwise known as, self-management.
A self-regulatory process modulates attention, emotion and behaviour for a given situation/stimulus with the underlying purpose of pursuing a goal. Self-regulation, therefore, allows us to find the opportunities.
In other words, with self-regulation, we can take action when opportunities arise.
There are various things we can do to track our self-regulation but one of the most effective is to set up our work environment to trigger us into our best state to do the work that we need to do. It can be time management, focus or better organisation.
The Big Picture
The big picture here is to set an intention to see the frames (options) to set your own frame (opportunity).
You see, at the C-level, you are not taking orders anymore or acting reactive. Instead, you are proactive, strategic and part of the senior leadership team (SLT) – the single most important team in every organisation.
So you must articulate your intentions, ideas and insights. In other words, you must use self-leadership to convert those into executive presence; the ability to project gravitas, confidence and poise under pressure. When you do that, you develop the so-called, influence capital.
Conclusion
Self-leadership is the foundation. It leads to options and opportunities. And it has only three principles:
Always look for options and opportunities.
Be self-aware to assess the nature of the frame you’re operating from.
Learn to take and process feedback and make necessary adjustments.
And here is a good quote you should remember:
“Everything can be taken from a man, but one thing, the last of the human freedoms, to choose one’s attitude in any given set of circumstances to choose one’s own way.”
Dr. Victor Frankl
Self-leadership is that inner resilience. It is the flexibility to find the course by choosing your frame rather than accepting the frames of your birth and upbringing.
Remember, it doesn’t matter what has happened in the past because when you change your intention, you change your future.
“You have a meeting to make a decision, not to decide on a question”.
Bill Gates
Meetings can easily become an onerous element of any leader. When they’re scheduled back-to-back, they a) consume more time than you thought they would and b) don’t solve a thing.
With this article, we want to ensure that, if a meeting is needed, you have the exact tools to make it productive, engaging and, finally, get the work done while the meeting is on.
The Key Learning Points
How to prevent cognitive overload and improve information retention.
Ensuring inclusiveness.
Creating an engaging environment.
Asynchronous work and the mindset needed for productive teamwork.
The Harvard Business Review found it’s too hard for humans to say no to a meeting invite. Some of the reasons are the now infamous FOMO and the false belief that everything is urgent.
Now, we all know that extroverts enjoy interaction while introverts would rather avoid meetings altogether. In both instances, however, the event can cause cognitive overload.
Preventing Cognitive Overload and Improving Retention of Information
It happens when a meeting triggers stress and anxiety. For example, a technical meeting that requires extra concentration from attendees.
The key here is to avoid overwhelming people with too much, too quickly.
Always remember that some people in the meeting don’t have a technical background so go easy with the tech jargon.
Never assume knowledge. Never make it harder than it needs to be for the people in the room. Instead, use metaphors and analogies to bridge that gap.
Next, be clear about the structure and agenda of the meeting so people know what to expect.
During the meeting, pay close attention to the speed at which you deliver points. In other words, give people the necessary time to digest and process information so they can better retain it.
And, whenever possible, deliver content with a hands-on activity because it improves learning and personal connections between the people.
Also, debrief during and at the end of every topic (and meeting) to ensure that everybody is a) engaged and b) understands. Ask open-ended questions like, “What particularly excites you from today’s meeting and is there something that worries you?”
What to do if an attendee zoned out?
Throw in a fun question to distract people or bring attention back.
Make them move.
Change the tempo.
Inclusiveness
Our brains register exclusion the same way they register physical pain. And without that sense of belonging, fear and anxiety kick in. Consequently, we shut down.
So, to increase inclusions in meetings, allow all participants an equal opportunity to participate and contribute.
But for that to happen, you must create a safe environment where everybody feels comfortable to speak and be heard.
There is, however, a slight problem with this. You see, what extroverts perceive as a safe environment, introverts may not.
Unlike extroverts, introverts need time to absorb information and reflect on questions. To tackle this, distribute the meeting agendas in advance.
Introverts also shy away from verbal processing and prefer to crystallise their thinking before vocalising it. In other words, they like a finished product.
And since they experience fatigue rather quickly, you should hold shorter meetings.
Creating an Engaging Environment
Use tools.
Run a creative sprint, different from daily stand-ups or retros.
“The longer the meeting, the less is accomplished”.
Tim Cook
Lately, a lot of workplaces are adopting asynchronous work. A good example is GitLab. According to them, the easiest way to enter into an asynchronous mindset is to ask this simple question:
How would I deliver this message, present this work or move this project forward right now if no one else on my team or in my company were awake?
If the answer is, “I must wake everybody up”, then it’s fair to call a meeting.
Maintaining a Productive Meeting
Leave as much as possible for asynchronous collaboration outside the meeting.
Assign duties at the end of it (if you fail to do it, the meeting is pointless).
Assign a supervisor (to track and report deliveries).
Follow up on items you didn’t cover and revisit each in the next meeting.
You don’t have to lead every meeting (remember inclusiveness).
In Module 1 of our Digital MBA for Technology Leaders (Leadership and Team Building), expert lecturers break down the meeting issues in detail and provide actionable solutions to each problem. We briefly went over a few of them here, but that was just the tip of the iceberg. For example, how to identify introverts/extroverts or how to assign specific tasks and to whom.
Remember, meetings are, effectively, problem-solving sessions, and it is imperative to understand every aspect of them to, ultimately, make them productive.
This guide explains the main external driving factors that could influence technology strategy – from start-ups to large enterprises.
As you will soon learn, your technology strategy will, ultimately, reflect the landscape in which your company operates. For example, if it’s on a growth trajectory or repositioning, then it’s going to address its weaknesses.
External Driving Factors
(click to download/enlarge)
Going Multi-Region (Common Strategy)
Even today, many things do not support proper localisation or internationalisation. Just consider the fact that we still force people to enter their first and last names when two-thirds of the world don’t have that concept.
So the basic information and how it’s categorised can become an issue. Additionally, a lot of suppliers don’t support that kind of internationalisation as well. It is a soft spot in every tech strategy.
Mergers and Acquisitions as Significant Factors
As you can imagine, there will be a lot of overlapping systems. The first thing we must decide is which ones we want to keep.
Two seemingly similar systems are, in fact, different because each company operates differently. And that’s going to affect your technology strategy.
Take, for example, Microsoft’s Dot.Net and merge it with a Linux-based company. Such a merger would cause a myriad of problems. In such a scenario, you, as a technology leader, must evaluate each option and decide what goes and what stays. Because, in the end, you want your strategy to be clear, simple and easy to follow.
Rebalancing Between a Group
As a rule of thumb, on a group level, every division has its individual tech strategy and tech stacks. However, major decisions are made on a group level. As you can imagine, this can create significant friction and cause major delays in optimisation and synchronisation between group companies.
One way to tackle this common problem is to take the initiative and pitch/propose a specific strategy/tech to a group – with a promise of driving it.
The issue you can expect in a group rebalancing scenario is resistance to adopting new technologies or, on the other hand, reluctance of multiple teams to switch to a single (common) tech.
Here, you need a tactical approach, especially if you’re considering more risky technology choices. What you need is a group of people who did due diligence or, even better, used it so you’d have tangible arguments.
Considerations when choosing a new technology:
What level of assurance do I have?
How does anybody use this in production?
Is there anyone in any of the teams that have already used it?
What are their experiences?
Dealing with the legacy tech
The first thing to do in this situation is to understand who thinks it is a legacy and for what reasons.
There are instances where people flag the tech as legacy just because they’ve depreciated it on a balance sheet. It’s an accounting view.
Sometimes, it’s depreciated because there’s a competing in-house technology standard, only they can’t decide which one to retire. So they simply flag one as a legacy.
Or the system has been around for a long time which, by no means, makes it a legacy.
What are the determining factors that could make a system potential legacy?
It’s legacy if it has some problematic features that do not exist in a new substitute tech. For instance, tight coupling, invisible business logic, it isn’t easy to read and understand, returns unusual business results and similar.
So how do you decide to retire a system or extend its use?
STEP 1: Find out who could potentially raise an issue if you switch it off.
STEP 2: Understand what exactly a system does.
STEP 3: Interview users to get feedback.
Remember, every time you try to flip a legacy system, you always run the risk of running out of goodwill and funding. If there is strong resistance caused by fear, it’s better to stop. Because if you don’t have support, it won’t matter how great your tech is. They are not going to adopt it.
Cost of Transition to a New Technology
We will take cloud services as an example here. The big promise was that the cloud would be cheaper. However, that’s not exactly the case. It can get really expensive really fast. Because, unlike data centres that have a limit on a number of servers, clouds enable you to keep provisioning new things and never turn them off.
As a rule of thumb, large companies never turn things off because nobody is managing the systems.
Now, from the technology strategy perspective, you should choose a single provider instead of trying to build redundancy on several systems just to have that safety net.
The choice, ultimately, depends on the volume metric projections, the overall cost and potential compatibility (eg, if you have Microsoft products in your environment, the integration of active directory will go smoother on Azure than on AWS or GCP).
TIP: If you don’t have an explicit function that looks after your cloud operations and finances, you’re going to have to set that up and make sure that you stay on top of the cost of your cloud provider.
Skills Availability
The availability of skills in your market is another important decision-making factor. In some instances, you will have to choose technologies that are more widely adopted to have a larger pool of available skilled workforce.
Remember that you can always check the TIOBE Index to see what technology is trending.
Summary
TECH-INFLUENCING EXTERNAL DRIVING FACTORS
Going multi-region, multilanguage:
Inadequate suppliers’ support for internationalisation
Merger, acquisition:
Overlapping systems, difficult to decide which to keep
Scalability issues
No compatibility between flagship technologies
Group rebalancing:
Different tech strategies between divisions
The tendency toward popular technologies and big suppliers
No synergy
Technological monoculture, high resistance to new tech
Cost of transition to a new technology
Skills availability
These are the most common external drivers that will influence your technology strategy. Module 3 of our Digital MBA for Technology Leaders, consists of over 20 lectures explaining technology strategy and business goals. Starting with alignment to value drivers, planning and, most importantly, execution.
An important part of each module in our Digital MBA for Technology Leaders is a discussion panel where a group of experienced tech leaders dive deep into critical problems of senior technology management. Here, we are bringing you a summary with key points on the subject of Tech Strategy and its alignment with the company’s business goals.
Is Tech Strategy a Common Weakness in Companies?
It sure seems like there’s often a big misalignment.
There’s a challenge with technology leaders understanding the business strategy and being able to translate that into what their team and their function need to do.
Because of that, we get misdirection. The tech goes on one tangent while the business is on a different one and the alignment is not happening. The tech strategy or product strategy is simply not aligned with the business.
How to solve misalignment?
Technology leaders and other members of the management team need to have compassion for technology and each other and understand all the pros and cons.
In the majority of strategy documents, technology doesn’t deliver on what strategy needs to be.
Strategy is supposed to focus our minds and say, these are the critical few things that we’re going to put all our energies against.
More importantly, these are things we’re not going to do.
It is rare to see tech strategies that say we are not going to do this or that. As a result, lows of focus bled out doing wild goose chase stuff, which technology is particularly great at.
It’s great at burning time and money on things that will not move the business needle at all.
And the other part is that technology strategy is often something that seems to be communicated upward to the board.
However, there are a lot of Staff Managers, Senior Engineers, Heads of Development and even VPs of Engineering who have no idea what the technology strategy was that was presented to the board last week.
As a result, alignment is not just happening.
Whose fault is it?
Is it the fault of the technology leader?
Well, there are different types of leaders. Some that manage upwards, some that manage downwards and some that don’t manage at all.
So it depends on the specific context. The general opinion is that the one who pays your wages and who are you most afraid of (ie, who generates your anxiety) is probably going to show where your focus should be.
Consequently, a lot of leaders just create things.
And it is often too difficult to cross the chasm, like trying to explain it to people who are doing the day-to-day job.
You’re running systems or you’re integrating systems, trying to get the relevance of what’s happening in the board room and that strategy and translate that into something relevant for those people.
It’s time-consuming and hard.
That’s why a lot of people just give up and say, you know what, I’m going to protect my teams from this nonsense and I’m just going to do a document.
It’ll keep the owners happy.
It’ll keep the board happy.
And we’ll just carry on.
The problem is that you’ll find yourself in a pickle sooner or later when a senior leader goes, “Hey, hang on a second. Didn’t you say you were doing all this stuff? I was just talking to somebody in the hallway and this doesn’t seem to be happening.”
Therefore,
A strategy needs to be communicated at multiple levels and be reinterpreted on every level.
There could also be monetary incentives to understand the tech strategy of the company and to figure out how it interacts with some departments.
In other words, to improve the way we communicate tech strategy to individual departments (ie, how it affects them, why it’s important for them), there could be a monetary incentive attached to that, depending on the organisation, the structure or the product.
A lot of things are going to depend on that.
One of the main issues is that Chief Technology Officers and tech leaders in general aren’t being allowed or just aren’t on boards of companies, which is affecting the strategy coming from the top down. Consequently, communication is failing from the bottom up and from the top down.
Here’s an example of this.
An outfit that was a retail bricks and mortar was moving online to e-commerce and it was a sort of bolt home, so to speak. It was one of the larger players in that particular industry.
But there was some serious competition, particularly one company which was founded by people who have technical backgrounds.
The latter put technology front and centre in their strategy and are now the largest in the industry, in the United Kingdom. Just because they use the technology correctly.
It does not matter that some of them were technologists. They simply embraced technology and made it work.
Younger generations aren’t quite as afraid of technology as older ones. That’s the positive side.
The negative side, on the other hand, is that we’re still going down alleys, promising stuff that may or may not deliver anything, particularly things like Blockchain or Metaverse.
We’re chucking all this stuff in and it’s just going to ruin our reputation again.
Because we’re just trying to make sure that technology works and we deliver all the business.
How can emerging tech leaders make a difference?
There is a kind of negative feedback here about what’s going wrong. We’ve got these emerging tech leaders, some of whom are already in senior positions.
So where and how can they make a difference?
How can they change the dynamic of what is going wrong in these various scenarios?
For a starter, make sure your voice is heard while spending time understanding the business.
In other words, don’t do tech for tech’s sake.
It is okay to buy something.
It is okay to knock something up and give it a go.
It doesn’t need to be perfect.
But it needs alignment with what your business is trying to do rather than the latest fad.
If you can then communicate that well in all directions and spend the time communicating it, it’s as simple as that in terms of getting it right.
Some of us tend to over-index on communicating the tech strategy and going over it again and again with teams or peers, believing that we’ve done something wrong. We think that we should’ve been doing something fancy. But it worked and it helped with alignment.
So that’s the area where tech leaders need to spend their time.
How different levels of tech leaders might be able to have an impact?
Not every tech leader is on the Board of Directors.
So the question is, if they’re not on the board or they’re not able to have a direct voice in that strategy meeting, how do they make themselves heard?
In essence, it’s a campaign trail so you probably need a running mate. On top of that, you need to do an awful lot of video conferencing with people to get the point across, making sure everybody understands your tech strategy.
That way, they feel like they have an input.
Hence, it’s about the human field.
Strategy is as much about this as it is about numeric. You do need numeric and you do need it short, you need it punchy, you need it simple, but you also need to have that human thing going on.
There are other potential stakeholders — operations especially — where technology is a super leverage point for them.
So the other point is that simplicity is the key.
There are so many strategy decks, which are war garble, just pages of PowerPoint.
Here’s a concrete example.
There is this company in the holiday sector that owns holiday parks.
There’s a huge amount of increased uptime, reduced cloud costs, and all these typical things that we’d see in their tech strategy, but there’s one thing missing that can bind that business together. And that would be reducing queues.
You see, holidaymakers hate going to holiday parks and standing in line for ages.
This is where this particular company can utilise technology as a key leverage point.
Unfortunately, that idea is regarded as an operational problem which doesn’t make much sense. Instead, there should be a technical strategy strand that says we are going to reduce queues.
And how are we going to do that?
We’re going to produce booking systems that enable people to schedule the park’s tools and features online while, at the same time, allowing us to check people in and deal with their requests and, thus, reduce failure in, for example, discounts.
So it makes it tangible and real for people.
Now, not every business is fortunate enough to house such a physical context, but if you can get something short and sweet and say, boom, this is in strategy, then it also enables you to say that’s not in strategy.
And that’s the critical thing because your job half the time is to go around saying, “Why are you doing that again?”
Managing inevitable anxiety
For a lot of people, it brings anxiety when they need to go and speak with their CTO. It makes them nervous. They automatically assume that this is a person who knows everything and we have no idea how to talk about it.
So how in the world are you possibly going to go toe to toe with them when it comes to tech strategy?
The root of that anxiety is simple: you don’t know how to confront your lack of knowledge about a particular situation.
On the other hand, for a lot of tech leaders, it is difficult to communicate to “lower” levels because it sounds condescending.
So how are they supposed to speak on a level that another person is going to understand?
It comes down to the ability to communicate things in a way that anyone can understand.
In other words, keep it simple!
Keep the flow simple and explain things in an easy-to-understand way. Two or three sentences at a fifth-grade level.
That way, non-technical stakeholders can understand what you’re doing and what your strategy is.
For example, if you’re in operations and you want to optimise a flow when an order comes in from your Shopify store, there is no reason your tech leader should be the one setting it up on Zapier when you can do it yourself.
When you have these different flows that you can work with, why shouldn’t you be trying to figure them out yourself, subsequently improving yourself and your career?
Dealing with the sense of loneliness
Being in a top leadership position often feels like you are alone. Hence, you need people to help you get forward. But to get them on the same path, you must give them the needed confidence.
The more confidence technology leaders have in what they’re doing, the easier it becomes.
You see, part of the problem of any communication is not necessarily knowing what the other side is thinking or what you think they’re the experts in. Often, they’re not the experts at all. After all, everyone rises to the level of their incompetence.
The first thing is to understand the business.
The next thing is to understand does anything else has to do with the strategy, whether it’s a tech strategy, marketing strategy or sales strategy.
If it doesn’t, there are some communication issues. In that case, you simply stand up and start talking about that.
In other words, you get that confidence through exposure and practice.
This applies to all levels of technology leaders.
Our role, wherever we are, is supporting those people and bringing them along with us.
Even if you’re not a CTO, but you have teammates reporting to you, bring them along so that everybody understands the tech strategy.
If you bring people in, they generally have better ideas.
Let’s say, for example, that you’re trying to work this damn thing out and somebody comes up with something brilliant. Some technology you’ve never heard of that solves the whole thing straight away. Someone was confident enough to propose such a solution.
The bottom line is that it’s about getting the confidence. You’re on a journey and bringing people with you will drive the technology in the business.
So there are three steps you need to take:
Bring people with you.
Talk to them about it.
Help them understand how it relates to them.
As Kent Beck said in his book about extreme programming, pick all the things that don’t work for you and stop doing them. Take the things that do work for you and turn them up to 100.
That’s how you become effective in communicating the tech strategy.
A word of advice
Sometimes it’s just not worth integrating something in your stack or trying to do something too complicated, just because it seems like fun and should be done because it’s complicated.
So before you engage in something like that, ask yourself this:
Are we wasting time on something that could be simplified?
Because, if it’s simple, it will be much easier to communicate it to a non-technical stakeholder.
In the high-octane world of technology, “Collaborative” is more than a buzzword; it’s the engine of progress and innovation.
The essence of collaboration in tech leadership revolves around creating a culture where a common mission, openness, complementary strengths, and collective problem-solving are the pillars. Each team member, with a clear understanding of the overarching goals, contributes uniquely towards achieving breakthroughs.
Real-world tech marvels, like the development of Linux and the collaborative projects on GitHub, underscore the monumental achievements possible through collective effort. These platforms exemplify how leveraging diverse talents and perspectives under a unified vision can push the boundaries of technology.
Effective collaboration distinguishes itself from mere cooperation by the depth of engagement between team members, actively working together to innovate and resolve complex challenges. This synergy is not automatic; it requires clear communication, shared objectives, and leveraging individual strengths with strategically chosen tools to optimise the collaborative effort.
In cultivating a collaborative tech environment, leaders must champion these principles, fostering an atmosphere where innovation is not just encouraged but expected. Through embracing the multifaceted nature of collaboration—behavioural ethos, structured interaction, and tool enhancement—tech leaders can navigate their teams toward unprecedented heights of technological advancement and success.
A technical leader bridges the gap between technical teams and business objectives. Unlike general managers, they possess strong technical expertise and can therefore guide engineers and developers. In contrast to tech specialists, however, they have strong leadership and communication skills.
But we need to distinguish the two roles here: Technical Leader and Tech Lead. While differences can be blurry in some instances (depending on the company size and stage of development), they commonly differ in the scope of the work and focus.
Tech Leads
Tech Leads are often individual contributors in a specific technical domain or project. They provide technical guidance to their team members and have more hands-on responsibilities (eg, coding, problem-solving, code reviews…) but within their area of expertise.
Technical Leaders
A Technical Leader, on the other hand, has a broader scope, overseeing the technical direction of a larger team or even multiple projects. They are responsible for the overall technical strategy and architecture decisions. While they might still possess strong technical skills, their role involves more leadership, mentorship and communication with both technical and non-technical stakeholders.
Differences Between Technical Leader and Chief Technology Officer Roles – Technical Leadership vs Management
The best way to understand the difference is through a simple analogy of a large and complex construction site.
The Technical Leader is like the foreman, responsible for the quality and efficiency of multiple crews (eg, framing, plumbing and electrical). They ensure all these teams work together cohesively, adhering to the overall construction plan while maintaining quality standards. Technical Leaders manage the project schedule, address any roadblocks and communicate progress updates to the project manager.
The CTO, on the other hand, is like the architect who designed the entire building project and oversees its overall execution. They have a vision for the entire complex, ensuring the design aligns with the intended purpose, functionality and budget.
CTOs work more closely with the client (the owner) to understand their needs and translate them into a technical blueprint for the project. They might also be responsible for sourcing new materials or technologies (like innovative roofing solutions) to ensure the project’s success. Finally, they collaborate with the project manager (a general contractor who oversees day-to-day operations) to ensure the vision is translated into reality on-site.
In this analogy, the Tech Lead would be, for example, a skilled carpenterleading a team of framers. They are experts in their specific area (framing) and ensure their team builds high-quality walls according to the blueprints.
In summary, a Technical Leader is typically a mid-level to a senior management position within a specific technical department (eg, software development, data science). The focus is on the technical direction and execution within a specific team or project. They report to a higher-level manager, such as a Director of Engineering.
A CTO, on the other hand, is a C-suite executive who reports directly to the CEO. They are a part of the strategic decision-making team responsible for aligning technology with business goals, evaluating and implementing new technologies, managing IT infrastructure and ensuring the security and compliance of all technical systems. These responsibilities may span the entire organisation and involve multiple technical departments.
Now that we understand where the Technical Leader fits in the overall organisational structure, let’s take a closer look at the responsibilities and, more importantly, practical strategies deployed by effective TLs on day-to-day, project-based and long-term bases. In the process, we will develop a perfect understanding of a technical leader job description not limited to the tech industry alone.
Responsibilities and Optimal Strategies Employed by Effective Technical Leaders
The list of common responsibilities of a Technical Leader (click to enlarge or download)
1 Day-to-Day Operations
1.1 Overseeing technical roadmaps and project plans
1.1.1 Strategic Alignment
Ensuring the technical roadmap aligns with the overall business strategy by translating business goals into achievable technical milestones and features.
Prioritising projects and features based on their impact on business objectives. To do this, we must consider factors like market needs, resource availability and technical feasibility.
1.1.2 Roadmap Management
Communicating a roadmap to technical and non-technical stakeholders. (This fosters transparency and ensures everyone understands the direction and priorities.)
Adjusting a roadmap based on market changes, technological advancements or unforeseen challenges (ie, being highly adaptable).
1.1.3 Project Plan Oversight
Breaking down roadmap goals in collaboration with project managers and team leads. We want to end up with smaller actionable project plans.
Monitoring progress against the plan and addressing roadblocks or deviations from timelines and resource allocation.
Identifying and mitigating potential risks that could derail projects or delay the roadmap.
1.1.4 Empowering Teams
Delegating tasks and responsibilities according to the project plan.
Empowering team members to take ownership of their roles while ensuring accountability.
Providing technical guidance and support to the team.
Encouraging knowledge sharing while fostering collaboration and problem-solving capabilities.
1.1.5 Continuous Improvement
Conducting regular reviews of the roadmap and project plans while incorporating feedback from stakeholders and the team.
Analysing past projects to identify areas for improvement in future planning and execution.
Staying in the loop with emerging technologies and assessing their potential impact on the roadmap and project plans.
1.2 Conducting code reviews and ensuring code quality
1.2.1 Defining Guidelines and Enticing Collaborative Learning
Establishing clear coding guidelines and best practices that developers should follow to have a consistent framework for code reviews on the one hand and reduce subjectivity on the other.
Encouraging reviewers to focus on specific areas for improvement, such as code structure, logic flow or variable naming to provide actionable feedback for the author.
Conducting high-quality code reviews to demonstrate the importance they place on the process.
Focusing on improvement, not just bugs (ie, viewing code reviews as opportunities to foster a constructive environment where code authors and reviewers can learn from each other).
Emphasising code maintainability, readability and adherence to coding standards.
Always remember that clear, well-documented code is easier to understand, modify and debug in the future.
1.2.2 Leveraging Tools
Utilising static code analysis tools to automate the detection of common coding errors and potential vulnerabilities (frees up time for reviewers to focus on more complex issues and code style).
Ensuring the team leverages version control systems effectively to track code changes and facilitate collaboration during code reviews.
1.2.3 Promoting a Culture of Quality, Reinforcement and Upskilling
Fostering an environment where developers feel comfortable asking questions and receiving feedback on their code.
Recognising developers who consistently write high-quality code to motivate the team and, thus, maintain and improve coding standards.
Identifying areas where developers might need improvement and providing mentorship or resources to enhance their coding skills.
1.2.4 Prioritisation and Delegation
Prioritising code reviews based on potential impact and urgency (triaging) and delegating less critical reviews to senior developers while personally reviewing complex or high-risk code changes.
Focusing on high-impact areas rather than reviewing every single line of code (ie, codebase, core functionalities and/or areas prone to errors).
1.3 Mentoring and coaching team members (people management)
1.3.1 Building Relationships and Understanding Needs
Scheduling regular one-on-one meetings with team members to discuss career goals, challenges and opportunities (fosters open communication and allows the leader to customise approach to individual needs).
Encouraging team members to express their concerns and aspirations.
Active listening and providing constructive yet specific feedback.
Setting clear expectations for learning and development within the role.
Collaborating with team members to define specific developmental goals that align with their career aspirations and the team’s needs.
Providing resources and opportunities (eg, access to relevant training resources, creating opportunities for team members to apply their new skills on real-world projects…).
Focusing on psychological safety (ie, the environment where team members feel comfortable asking questions, making mistakes and trying new things without fear of judgment).
1.3.3 Guiding and Empowering Growth
Providing opportunities for team members to take on challenging tasks outside their comfort zone while ensuring proper support and guidance (helps them develop new skills and gain confidence in their abilities).
Demonstrating commitment to continuous learning by actively learning new skills yourself and sharing your experiences with the team.
Enhancing problem-solving skills and decision-making capabilities by delegating tasks and demanding ownership.
Being flexible and adapting the coaching approach based on individual needs and progress.
Encouraging knowledge-sharing sessions, hackathons and code review sessions where team members can learn from each other.
1.4 Identifying and resolving technical challenges
1.4.1 Proactive Problem Identification
Anticipating risks and problems by encouraging a culture of proactive thinking within the team and open discussions of potential roadblocks, technical dependencies and emerging trends that could lead to future challenges.
Utilising monitoring tools and performance metrics to identify potential issues early on.
Creating an inside ticket system where team members raise concerns and report bugs, potential performance bottlenecks or security vulnerabilities.
1.4.2 Structured Problem-Solving Approach
Defining the immediate challenge after identifying the problem (analysis of symptoms, error messages and user experiences).
Using techniques like root cause analysis to delve deeper and identify the underlying cause of the technical challenge
Encouraging collaborative brainstorming to explore potential solutions.
Ensuring that everyone is working on the same problem.
1.4.3 Effective Resolution and Implementation
Evaluating the potential solutions based on factors like feasibility, impact, resource requirements and risk.
Prioritising solutions based on urgency and potential impact on the project or system.
Developing the implementation plan.
Communicating the problem, solution and implementation plan with all relevant stakeholders.
Documenting the process (and lessons learned!) to prevent similar issues in the future.
1.4.4 Continuous Improvement
Scheduling post-mortem sessions after resolving a critical challenge.
Encouraging knowledge sharing.
Adapting to change.
2 Project-based
2.1 Defining technical architecture and design decisions
STEP 1: Understand Business Needs
Align the technical architecture with the overall business goals and objectives (consider factors like scalability, security, performance and cost-effectiveness).
Gather stakeholder input (eg, product, sales, marketing) to understand needs, challenges and future expectations so that the architecture caters to diverse user needs.
STEP 2: Evaluate Technologies
Consider factors like maturity, adoption rate, community support and integration capabilities with existing systems.
Foresee trends and potential growth to future-proof your decisions. In other words, choose solutions that are scalable, adaptable and can accommodate future changes in user base, data volume or technological advancements.
STEP 3: Involve the Team
Involve key team members (eg, senior developers and architects) in the design decision process (!fosters a sense of ownership).
Once decisions are made, effectively communicate the chosen architecture and design patterns to the entire team so that everyone understands the rationale behind the decisions and can implement them consistently.
STEP 4: Identify and Mitigate Risks
Engage in scenario planning and threat modelling (consider factors like security breaches, system outages, data loss, scalability limitations and single points of failure).
Develop mitigation strategies beforehand (eg, implement redundant systems, robust security measures and contingency plans for disaster recovery).
Develop proof-of-concept prototypes or limited-scale implementations of the different architecture options you consider.
Conduct a thorough cost-benefit analysis for each architecture option.
Assign a risk factor to each potential issue and consider its financial impact on the project.
Involve key stakeholders from different departments to ensure diverse perspectives.
STEP 5: Iterate After Receiving Feedback
2.2 Estimating project timelines and resource allocation
STEP 1: Define and Decompose Project Scope
Begin by ensuring a clear understanding of project requirements, functionalities and deliverables. Remember that ambiguity can lead to underestimation of effort and timeline slippage. Instead, break down the project into smaller, well-defined tasks to facilitate accurate estimation.
When done, develop a Work Breakdown Structure (WBS) to outline the project tasks, subtasks and dependencies. This will a) give you a visual representation of the project scope, and b) help identify potential bottlenecks or overlapping resource needs.
STEP 2: Employ Estimation Techniques and Utilise Expertise
Start by leveraging historical data. For example, if your organisation has a history of similar projects, you want to leverage past data on development time and resource allocation. This will provide a baseline for estimation. Do however adjust for any differences in complexity or technology stack.
Make sure that you involve experienced team members in the estimation process. These developers can provide insights based on their technical knowledge and understanding of the specific tasks. Use techniques like story points and T-shirt sizing to estimate relative effort.
STEP 3: Consider Risks and Buffers
First, identify potential risks that could lead to delays, such as technical dependencies, unforeseen bugs or resource availability issues. Factor in these risks when estimating timelines and allocating buffer time.
Now add a reasonable buffer (safety net) to the estimated timeline to account for unforeseen challenges or scope creep. This buffer helps you manage expectations and prevents project deadlines from becoming unrealistic.
STEP 4: Communicate Timelines and Resource Allocation to All Stakeholders
STEP 5: Iterate Estimations
Throughout the project, iterate on the estimates as the project progresses and new information emerges. Don’t forget to communicate any adjustments needed to maintain project timelines and resource allocation.
Leverage project management tools that offer task dependency mapping, resource scheduling and automated reporting. These tools will help you to better visualise the project timeline, identify potential bottlenecks and optimise resource allocation.
2.3 Collaborating with stakeholders on project requirements
As we said, Technical Leaders serve as a bridge between technical teams and non-technical stakeholders. The point is to ensure that everyone is aligned so that the product meets everyone’s needs.
The question is, how do you, ultimately, achieve this?
Well, first, you must identify all relevant stakeholders involved in the project, including product managers, business analysts, end-users and, potentially, even clients.
Use meetings, interviews and workshops to better understand their needs, goals and pain points so you can architect the desired functionality and user experience.
However, at this point, you are still missing one crucial piece of information: the definition of success. So you have to collaboratively engage the stakeholders to define clear success metrics for the project.
It is only after we define what success looks like that we can all work toward the same goal and prioritise features based on their impact on achieving that goal.
The definition of success comes as a result of analyses of gathered requirements. For this, Technical Leaders utilise techniques like user stories, use-case diagrams or prototyping to capture and document requirements.
Now, not all requirements can be implemented simultaneously. So we must facilitate discussions with stakeholders to prioritise features based on factors like user needs, business impact and technical feasibility. Most commonly, we need to spend time explaining technical limitations and proposing alternative solutions or phased implementation plans.
Here’s the problem: many stakeholders don’t understand often complex technical terminology. It is, therefore, imperative that we translate those concepts into language they understand. We can, for example, use visuals, diagrams and demonstrations where necessary to ensure clarity.
But, whatever you do, always remain transparent about the technical feasibility, resource constraints and potential limitations of certain requirements. This helps manage stakeholder expectations and avoid disappointment later in the development process.
To further facilitate expectation management, establish regular communication channels to keep stakeholders informed about the progress, potential roadblocks and any changes in requirements. Also, solicit feedback throughout the development process to ensure the final product aligns with their expectations.
Remember, it’s all about trust, collaboration, focus on shared goals and something that can easily make a difference between success and failure – acknowledging stakeholders’ expertise in their respective domains.
You see, as a Technical Leader, you will provide technical guidance. But you should also value input from other perspectives to ensure the solution addresses a genuine business need. More often than not, a specific expertise of one of the stakeholders can turn into a game changer.
2.4 Implementing risk management strategies
Five general strategies enable you to minimise the impact of certain risks that are inevitable in any project:
Consider external factors (eg, changes in technology, market trends or resource availability).
Risk Assessment and Prioritisation
Assess the likelihood of each risk occurring and the potential impact it could have on the project (cost, schedule, quality). This will help you to prioritise risks based on their severity.
Use the Risk Rating Matrix to categorise risks based on their likelihood and impact. You’ll end up with a visual representation of the most critical risks that need immediate attention.
Developing Mitigation Strategies
Develop mitigation strategies or contingency plans for each identified risk.
Allocate resources (time, budget) to implement these mitigation strategies and contingency plans.
Monitoring and Communication
Conduct regular risk reviews throughout the project lifecycle to assess if identified risks are still relevant or if new ones have emerged.
Communicate the identified risks and mitigation strategies to all stakeholders involved in the project.
Learning from Experience
Upon project completion, conduct a post-mortem analysis to review the effectiveness of the risk management strategy. In other words, analyse how well risks were identified, and mitigated, and if there are any lessons learned for future projects.
Update the Risk Management Process using the insights from the post-mortem analysis for future projects.
3 Long-Term
3.1 Fostering a culture of innovation and continuous learning within the team
We’ve already discussed some of the strategies required to develop a culture of innovation and learning, namely creating a safe environment for exploration, leading by example, the necessity for open communication and feedback loops, providing growth opportunities, assigning challenging tasks, knowledge sharing and recognition of individual and groups successes.
But there is one strategy that is seldom utilised to its maximum and that’s setting the tone and expectations.
What this means is that you must clearly communicate the importance of innovation and continuous learning as core values of the team. At the same time, articulate a vision for how these values can contribute to the organisation’s success. In other words, connect the dots for your team members to motivate them to embrace these values.
3.2 Staying up-to-date on emerging technologies and industry trends
It may seem trivial, but our experience here at the Academy constantly reminds us that future technology leaders sometimes have a hard time planning and executing activities that keep them in the loop with new developments.
So how about we create a simple checklist?
STAYING UP-TO-DATE w/ TECH & LEADERSHIP CHECKLIST
Subscribe to curated technology newsletters, blogs and publications from trusted sources
Attend at least two relevant industry conferences, workshops and meetups a year
Engage in mentorship programs at least twice a year
A monthly proof-of-concept and prototyping session
A monthly hackathon session with team members
Okay, that was our checklist. Now we move into more complex strategies that set apart effective technical leaders from the rest of the crowd.
The first thing on this list — and the most challenging at the same time — is building a network of early adopters.
You see, by learning from their experiences and challenges, you can make informed decisions about adopting these technologies within your teams.
Now, obviously, you don’t just take their word for it because the downside of early adopters is that they are often too hyped about certain solutions that tend to break down along the way.
Hence, you need to evaluate Hype vs. Reality. That means critical thinking and maintaining a critical perspective when evaluating emerging technologies. The point is to distinguish genuine advancements from marketing hype and focus on technologies with real-world applications for their projects or the industry.
A good example here is numerous blockchain projects that, when stripped to their cores, don’t offer any significant application and even lack feasibility.
One way or another, you must always consider the long-term implications of emerging technologies. You want to analyse how these trends and solutions might impact the industry landscape, user behaviour, and your organisation’s overall strategy (eg, how could LLMs impact our daily routines).
When you consider everything we mentioned so far, it is clear that you should cultivate a continuous learning mindset. In other words, always remain open to new ideas and embrace the ongoing process of learning and adapting to stay relevant.
3.3 Aligning technical strategy with overall business goals
This is, arguably, the most challenging aspect of every technology leadership role. So here, we are going to explain the three capital steps with corresponding strategies and methodologies that will help you align the tech with the business.
STEP 1: Understand Business Objectives
Don’t operate in a silo but actively engage with business stakeholders like CEOs, product managers and other executives to gain a deep understanding of the organisation’s mission, vision and strategic goals.
Go beyond just technical capabilities and focus on how technology can be leveraged to achieve specific business outcomes. In other words, focus on business outcomes (eg, increasing revenue, improving customer satisfaction, gaining a competitive edge…)
STEP 2: Translate Business Goals into Technical Initiatives
Start by mapping technology to business needs. In other words, translate business goals into actionable technical initiatives. This might involve identifying the right technologies, architectures and development practices needed to support those goals.
Prioritise projects based on their potential impact on achieving business goals, considering factors like return on investment (ROI) and innovation potential.
STEP 3: Communicate Technical Strategy to Stakeholders
Of course, there’s parallel work that needs to be done:
Constantly monitor progress and business landscape
Now, none of this will bring results if you don’t employ data-driven decision-making. So you want to leverage data and analytics to track progress and make data-driven decisions when adjusting the technical strategy. This ensures your approach is based on evidence and not just a gut feeling.
Becoming a Technical Leader
What leadership skills do you need to excel in this role other than those hard skills like programming, system design, data structures, etc.?
As you could learn by now, soft skills like communication, leadership, teamwork, problem-solving, critical thinking, mentoring, interpersonal skills and negotiation are at the core of this role.
But if we are going to list the most important traits of a Technical Leader, this is what organisations are looking for:
Strong technical background and ability to stay current with advancements.
Excellent communication skills (both technical and non-technical).
Proven leadership abilities – inspiring and motivating others.
Problem-solving skills and the ability to make sound technical decisions.
Ability to delegate tasks effectively and empower team members.
Now, the pathway to the role often involves demonstrating technical leadership skills and qualities already within the technical role. So some of the best strategies to show initiative and demonstrate many of these abilities are these three:
Volunteering to mentor junior team members
Taking on ownership of complex projects
Actively participating in technical discussions
However, formal management training, while not always mandatory, is frequently a determining factor. After all, you are expected to progress to senior leadership roles like Head of Engineering, CTO (Chief Technology Officer), or even leadership positions outside technical departments when you develop strong business acumen.
So, as the next step of your journey to a Technical Leader role and, quite possibly, a senior leadership one, we encourage you to take a moment and book a free discovery call with our CEO to discuss your current career trajectory and how we can help you on your future path.
An Engineering Manager (EM) at TechGlobal Ltd seeks advice on improving the working relationship with a Principal Engineer (PE) who, despite having extensive experience and a strong principled approach, poses challenges in team interactions and project progress.
The PE’s direct and often critical communication style has led to a division among team members, impacting their willingness to engage and collaborate effectively.
This case study delves into the complexities of integrating a high-level strategic vision with practical implementation steps in a technology-focused environment.
I think on the topic of perception, what I have seen over many years leading teams is that perception becomes reality, so leaving a person on a team that makes others “afraid” to participate unintentionally says it’s OK.
Dallas G.
Context and Challenges
The PE brings a wealth of experience from a major tech company, holding strong and principled views on engineering practices.
Described as loud and curt, the PE’s approach in technical reviews and meetings has created discomfort among team members, leading to avoidance or unnecessary adjustments in project scopes.
The PE often critiques current architectures and proposes advanced future state architectures, but lacks intermediate steps and practical guidance to achieve these visions, leaving a gap in execution plans.
Specific Incidents
Some engineers avoid presenting their work if the PE is involved, while others over-engineer solutions to preempt potential critiques.
A specific instance involved a junior engineer documenting the use of cloud-native tools, where both the junior engineer’s and the PE’s proposals lacked practical details and actionable steps, reflecting a disconnect in expectations and execution.
Discussion Points
How can the EM facilitate a shift in the PE’s approach to offer more constructive, actionable feedback without dampening the valuable critical perspective?
What strategies can be implemented to improve the communication style of the PE to enhance collaboration and reduce team division?
How can the EM work with the PE to develop clear, actionable transition plans that bridge the current state to the desired future state architecture?
Considering the belief that teams need replicable patterns to succeed, what frameworks or methodologies can be introduced to support this need?
We invite you to share your insights and experiences on navigating similar challenges within your organisations.
How have you managed to align senior leaders with practical team dynamics?
What approaches have you found effective in balancing visionary technical leadership with actionable team guidance?
Peer Advice (Actionable Solutions from our CTO Community)
Vigi J.
If I were the EM I would provide feedback immediately after the meeting to reference the specific scenarios as they are fresh in people’s minds. If the PE is open to such feedback I think they would use the opportunity to grow. It’s also best to follow up verbal feedback with written feedback as well and make sure the hiring manager is aware of the situation. If the PE does not receive the feedback well perhaps a conversation with the hiring manager is needed. If the PE does not receive the feedback well you should follow up with a hiring manager conversation. I’ve been in the beer buddies situation before and it’s hard. In my case I continued to give honest and straightforward feedback and eventually the beer buddy was replaced.
Catherine
I’m going to be potentially a bit controversial here and say this sounds like a people problem that in my experience is hard to resolve with a process or strategy. Hence the outcomes (dismissal) described.
People problems are inherently contextual and relational, but I’d recommend the line manager open conversation with the PE to understand how they see their role, how they see it needing to be executed, how confident they are in discharging their role, etc. I’d also set out (as line manager) clear expectations on not just what they do, but how they do it.
It’s important to be both open but also clear and factual in this case, and not editorialize, but provide reasonable support to the PE. I don’t believe in just dropping them into soft skills training – they need to understand and appreciate the problem, and their contribution to it.
If that doesn’t work then performance management steps are appropriate. But I’ve had very good results with a coaching approach if it’s done early and nipped in the bud.
Seetharam S.
I have served as a Principal Engineer/Architect for many years, leading teams in both startup and large corporate environments. My success has stemmed from building trust and effectively communicating my ideas. When faced with disagreements, rather than imposing my views, I encouraged the team to develop a proof of concept before progressing to a comprehensive solution. This approach allowed the team to encounter and address challenges early on, with my guidance.
The primary challenges I encountered were from upper management who sometimes perceived me as a threat rather than a collaborator. However, the support from my immediate supervisors, primarily Senior Vice Presidents, was instrumental. Their faith in my abilities and experience was crucial, as they advocated for me among their peers.
Paul W.
I’ve seen this kind of thing happen a few times. One particularly memorable case was after a change of CTO. One particularly senior engineer ( essentially a PE) used this as an opportunity to quite publicly attack the credibility of several engineers. This same individual had a history of aloofness, over engineering, slow delivery and being generally ‘superior’. He was indeed a very good technical guy but would ignore business realities in favour of technical perfection then critique others who were forced to make trade-offs in order to deliver. It backfired horribly, with the new CTO immediately identifying the guy as toxic and dismissing him virtually on the spot. This really made the rest of the team feel protected and valued ( and sent a clear message re toxic team behaviors). I think people like this are extremely difficult to change, and can be incredibly bad for team health. If they don’t show immediate change after mentoring, performance plan etc.. then I know what I’d be doing ( of course it will depend of the severity and context of the problem also )
One response to “Enhancing Collaboration with a Principal Engineer at TechGlobal”
Holger Hammel
Given it is not a clear case of a “brilliant jerk”, that has been covered already in the comments – it is basically a coaching topic. The step from senior to Staff/PrincipalArchitect usually implies a significant shift in role expectations – is this clear to the person? Is it stated in a role/level description and properly discussed and reviewed in 1:1s?
Imho it helps to find out together where the ineffective behavior comes from? Is it that they are feeling like an imposter, defensive, overwhelmed? Or rather bored by the same problems, same questions, mistakes, arrogance of more junior engineers or managers for decade(s)?
Different coaching strategies can be developed based on this self-reflection by the PE and 1:1s or 360s.
A few tools I have used or seen working include: 1) re-framing it as a problem to solve – not a character flaw or soft skill to get better at – here is the problem: we shall lift the quality, flow, avoid risk: how do you do that w/o you doing it?
2) Succession planning: for managers it is more common to make succession planning an explicit part of someone’s goals. Apply the same to senior technical leads and ask them to identify, support, coach and make sure that the next generation of principal engineers is growing (and seniors ..)
3) Write things down – it is OK to be opinionated and define guardrails, standards for many aspects, but then write them down and be accountable; help PEs to do so in an inclusive, open way
Constantly evolving user needs and expectations are challenging traditional leadership styles. That’s why technology leaders are switching to a design thinking model which is, basically, a human-centred approach to problem-solving.
Design thinking focuses on understanding user needs and experiences to create innovative solutions. Such products and services resonate with their target audience.
This article explores the critical role design thinking plays in modern technology leadership.
Remember, just because you’re utilising Agile methodologies, doesn’t necessarily imply that you’re a design-thinking leader. You’ll see why shortly.
Limitations of the Traditional Leadership Approach
The speed of technological advancements and ever-shifting user demands expose traditional models’ limitations. Key problems are:
Prioritising technology over users
Siloed thinking
Limited innovation potential
Slow decision-making
Old school leaders often prioritise the technical feasibility of a solution over understanding the user’s needs and pain points. This approach can lead to overly complex and unintuitive products or miss the mark altogether.
Traditional structures can also create silos between departments like engineering and design. Such solutions lack a holistic perspective due to collaboration breakdown.
Silo thinking and focus on tech over the actual users’ needs means that the team is most likely risk-averse and prioritising proven solutions. It is the definition of a culture that stifles the level of creative exploration needed to drive breakthrough innovations.
Add lengthy research and analysis to this mixture and you end up with sluggish decision-making and missed opportunities.
Benefits of Design Thinking for Technology Leaders
Design thinking helps you navigate all these challenges and removes limitations. By prioritising user needs, fostering collaboration and embracing rapid iteration, design thinking gives you five distinct advantages.
1. Your solutions win the market
Since you’re flipping the script by fostering empathy and user research, you develop solutions that address user pain points. This leads to products and services that gain traction and win in the market.
2. The team operates with enhanced creativity and problem-solving
As a design-thinking tech leader, you are encouraging experimentation while, at the same time, breaking down silos between departments. This fosters a more creative environment where engineers, designers and other stakeholders can collaborate to generate innovative solutions to complex problems.
Design thinking allows you to tap into the collective intelligence of your team and explore a wider range of possibilities when facing a demanding technical challenge.
3. Improved decision making
Decisions are based on user feedback (data-driven decision-making). The emphasis is, therefore, on prototyping and user testing throughout the development process.
This, in turn, allows you to gather real-time user feedback and refine your solution based on data, not just assumptions.
Such an approach mitigates the risk and helps CTOs make more informed decisions about product direction and resource allocation.
4. Effective communication and collaboration
Dedicated workshops and collaborative prototyping sessions break down communication barriers between teams and departments. This fosters a more cohesive work environment where everyone is aligned on the user’s needs and vision.
What makes this possible is your improved ability to effectively communicate your vision to your team and ensure everyone is working towards a common goal.
But how exactly does design-thinking leadership break down silos and foster a more collaborative work environment?
As we said, design thinking places the user at the centre stage. This creates a common ground for teams with traditionally different priorities (e.g., engineers vs. designers) to come together and work towards a shared goal: developing solutions that address user pain points. To put it bluntly, everyone is focused on the same “why” behind the project, fostering a sense of unity and collaboration.
The process itself is inherently collaborative. Workshops, user research activities and prototyping sessions necessitate teams from different departments (engineering, design, marketing…) to work together. This breakdown of departmental barriers enables better communication, knowledge sharing and a more holistic understanding of the problem.
Since the emphasis is on open communication and active listening, there are no more communication silos. Subsequently, the environment encourages a more open exchange of ideas.
However, for the process to work more or less flawlessly, team members from different backgrounds must learn to effectively communicate their perspectives while fostering empathy and understanding for each other’s roles. Hence, the workshops and leading by example!
The iterative nature of design thinking means everyone contributes to the refinement of the solution. This creates a sense of shared ownership and accountability. Subsequently, the teams are increasingly motivated to work together towards a successful outcome.
The important thing to remember here is that recognition for the final solution is not limited to a single department because shared recognition further strengthens collaboration.
This leads us to the critical role of empathy and understanding.
Design thinking heavily relies on user research techniques like interviews and observations. By participating in these activities, engineers, marketers and other stakeholders gain a deeper understanding of the user’s perspective. This shared empathy breaks down departmental divides and builds a stronger sense of teamwork.
Some might argue that such an approach may easily eliminate departmental structures. The reality, however, is that it simply utilises them more effectively. A shared focus on user needs acts as a bridge between departments, cultivating a more collaborative work environment.
5. Competitive advantage
This is one of the top priorities of every company and the reason why they need technology leaders (regardless of the industry). But it comes with, sometimes, overwhelming expectations – the boards simply expect their CTOs to provide them with that competitive advantage.
An ace in your sleeve these days is user-centricity. It enables you to develop products and services that resonate with users, leading to increased customer satisfaction, loyalty and, ultimately, a competitive edge.
Real-world Examples of Tech Companies That Have Used Design Thinking to Achieve Success.
In its early days, Airbnb struggled to attract users. So they conducted user research and discovered that potential hosts were hesitant due to concerns about security and trust. This led to the development of features like verified profiles, reviews and secure payment systems, ultimately transforming Airbnb into the hospitality giant it is today.
Another successful example is Intuit.
Now, as we all know, tax preparation software can be notoriously complex. Intuit used design thinking to revamp their flagship product, TurboTax. They simply placed focus on user needs and frustrations. The result was a simplified interface, step-by-step guidance and incorporated helpful educational resources. The outcome was a more user-friendly experience and a surge in customer satisfaction.
A similar approach was utilised by Nest Labs. Using design thinking, Nest focused on understanding user behaviour patterns related to energy consumption. After extensive research and analyses, they created a visually appealing and intuitive thermostat that learns user preferences and automatically adjusts temperature settings. This enabled homeowners to enjoy a more comfortable home environment with increased energy efficiency.
But what to do if you want to expand your taxi services to food delivery? Do you lean on traditional leadership models or do you utilise some hard-core design thinking like Uber Eats did a few years back?
“We constantly immerse ourselves in the places where our customers live, work, and eat”, says Paul Clayton Smith from Uber Eats’ design team. “Sitting in our offices in San Francisco or New York, we can’t truly understand the experiences of a person on the streets of Bangkok or London. We need to go there, move about the city, experience the food culture and watch how people use the things we’ve designed”.
Uber Eats has implemented a series of protocols and practices like The Walkabout Program, Order shadowing, and Fireside chats to truly understand the pain points of their market. And, according to Paul, they iterate a lot, “Our business is a marketplace that needs to quickly reach critical mass to provide value to each of our different customers…Swift iteration allows us to move fast and ensure we get the design just right”.
This immersion, iteration and rapid innovation is what powers the Uber Eats design team. It is a design-thinking approach that allows them to solve complex logistical challenges with new technology that resonates with their customers.
Now that we have successfully elaborated on the advantages, let’s dig deeper into our subject.
What is Design Thinking?
Design thinking is a human-centred problem-solving methodology that emphasises empathy, user-centricity, iteration and prototyping. It’s a cyclical, non-linear process that allows us to deeply understand user needs, challenge assumptions and ultimately create innovative solutions.
There are four core principles:
Empathy
User-Centricity
Iteration
Prototyping
The Process
There are, typically, five key stages (due to the iterative nature of design thinking, these stages can sometimes overlap or be revisited):
Empathising or focusing on understanding the user (ie, gathering information about user needs, behaviours and pain points through research methods like interviews, surveys and observations).
Defining the problem based on the research (ie, forming a clear problem statement after synthesising the information).
Ideating (ie, brainstorming a wide range of solutions to the defined problem where wild ideas are encouraged and no suggestion is off-limits).
Prototyping (ie, developing low-fidelity, tangible representations of your most promising ideas to get something in front of users quickly to gather feedback).
Testing (ie, presenting prototypes to users and observing their interactions while gathering feedback to refine and iterate on your ideas).
Differences Between Traditional and Design-Thinking Problem-Solving Methods in Technology
How to Integrate Design Thinking into Your Leadership Style
1. Build a Design Thinking Culture
Lead by example. Demonstrate the commitment to design thinking principles by participating in workshops, advocating for user research and creating a culture of empathy within your team.
Shift the mindset by encouraging a focus on user needs and problem-solving over solely technical solutions.
Promote open communication and collaboration across teams.
Invest in training your teams.
2. Create a Collaborative Space
Kill silos to thrive on collaboration. Engineers, designers, product managers and other stakeholders must work together.
Conduct user research workshops (eg, interviewing potential users and analysing data).
Establish design thinking leaders by identifying individuals passionate about design thinking. Empower them to act as internal advocates and facilitators within the team.
3. Promote Experimentation and Iteration
Allocate resources for rapid prototyping (ie, low-fidelity representations of ideas for user testing, not polished final products).
Embrace failure as learning to encourage a culture where experimentation and iteration are seen as valuable learning opportunities. Keep in mind that failure provides valuable insights for refining ideas.
Encourage user feedback (ie, encourage your team to actively solicit user input).
4. Integrate Design Thinking into Existing Processes
Enhance instead of replace because design thinking is not meant to replace existing development processes. It enhances them by incorporating user-centricity and iterative feedback loops.
Identify integration points (eg, user research can be incorporated into the early stages of product development; prototyping can be used to validate assumptions, etc.).
Track progress and measure impact.
The takeaway is simple: a tech leader who embraces a culture of design thinking, quickly positions as the one who drives innovation and delivers solutions that create competitive advantage.
Conclusion
Design thinking equips CTOs with a deep understanding of user needs. By prioritising user-centricity throughout the development process, CTOs deliver solutions that resonate with their target audience. This translates to:
Increased customer satisfaction
Reduced churn
Enhanced brand reputation
Improved market differentiation
Hence, the advice: start exploring design thinking resources, participate in workshops and begin integrating its principles into your approach. Become a future leader who shapes the tech landscape.
Resources for Further Learning
Articles:
Harvard Business Review: Look for articles on design thinking in business and technology leadership.
Fast Company:Articles on design thinking for innovation and creative problem-solving.
IDEO Blog: IDEO is a renowned design thinking firm. Their blog features insightful articles on applying design thinking to various industries, including technology.
Remember, this is just a starting point. As you delve deeper into design thinking, you’ll discover a wealth of resources available online and through professional development opportunities.
“Leadership is the capacity to translate vision into reality”
Warren G. Benis
Visionary leaders possess an innate ability to predict trends, envision revolutionary products, or foresee shifts in consumer behaviour long before they become apparent to others.
They challenge the status quo, daring to think differently and inspire their teams to turn bold ideas into tangible innovations. We can think of some obvious tech visionaries.
Whether you view yourself as or have the potential to be a visionary, what’s clear is that as a senior technology leader, it’s incumbent on you to create a sufficiently compelling image of an achievable future that will help to encourage and inspire those around you.
You do need to have a vision about the direction of travel and be able to communicate that with sufficient clarity to those you will need to help turn it into a reality.
But vision is only part of the equation because, without judgment, it’s likely to be unfulfilled.
Your job, therefore, is not just about knowing new technologies but also about how they’re going to be used and whether they can take your organisation to the next level or whether they pose a threat, perhaps an existential one.
The primary request for any senior tech leadership role is leading a strong team that consistently delivers groundbreaking innovations and achieves measurable results. That means you don’t merely manage a tech team; you must have the vision to lead it.
Why vision instead of just management?
Strong leaders provide a compelling vision and roadmap, improving team focus and motivation. Combined with a culture of trust and open communication, it creates a high level of psychological safety for the team. In turn, such a team is more open to risk-taking, innovation and honest discussion of challenges.
Why is this important to your organisation and, more importantly, you?
Technology leadership is essentially about aligning tech with business goals, unlike other senior leadership roles. When technical initiatives are converged with broader business objectives, they drive innovation and bottom-line results. In other words, perfect alignment gives a company a competitive advantage and subsequent long-term growth.
The other reason why organisations require effective leadership is because it lowers risks, resolves conflicts and helps teams anticipate challenges, increasing the likelihood of delivering projects on time and within budget.
Finally, let’s not forget that talented tech professionals want to work for inspiring leaders in thriving environments (ie, attraction and retention of talent – check!).
But what’s in it for you?
Career advancement for a starter. As a rule of thumb, tech leaders command higher salaries due to greater responsibility. This translates into more influence within the organisation.
Also, moving from managing tasks to leading people and driving impactful projects creates a greater sense of purpose and achievement.
Effective tech leaders gain visibility and often interact with high-level stakeholders across the business, expanding their professional network.
However, it all begins with building high-performance tech teams because, at the end of the day, leaders are only as good as their teams.
Building and Managing High-Performance Tech Teams: A Quick Guide
High-performance tech teams are the key to unlocking innovation, achieving project goals and staying ahead of the curve. Here’s how to build one from scratch:
1. Hire for Skills and Cultural Fit
Go beyond technical skills. Granted, technical expertise is a must, but don’t neglect soft skills like communication, collaboration and problem-solving. Also, consider hiring for future skills (when you see the potential in a candidate).
Assess cultural fit. In other words, look for individuals who align with your company values, are team players and are most likely to thrive in your work environment.
Diversity matters;therefore, build a team with diverse perspectives, backgrounds and experiences. This leads to richer discussions, more creative solutions and a stronger team dynamic.
2. Prioritise Continuous Learning
Invest in team development. Provide opportunities to expand their skill sets through workshops, online courses, conferences or hackathons. Encourage knowledge sharing within the team.
Embrace a growth mindset. It is a culture that values learning from mistakes and adapting to new technologies.
Lead by example. In other words, demonstrate your commitment to ongoing learning by actively seeking new knowledge and skills.
3. Foster Open Communication and Collaboration
Create safe spaces for feedback. This means making team members comfortable about expressing ideas, concerns and, more importantly, constructive criticism because where everybody thinks the same, nobody’s thinking.
Use collaboration platforms to facilitate communication, knowledge sharing and project updates, but minimise silos and 1:1 conversations. Consider implementing a dedicated ticket policy (provides a precise historical overview!).
Celebrate team wins and acknowledge the collective effort.
4. Empowerment and Ownership
Delegate meaningful work that allows team members to utilise their strengths and learn new skills.
Give team members the freedom to make decisions and push them outside their comfort zones within defined parameters.
Recognise and reward ownership (ie, acknowledge individuals who take ownership of their work and go that extra mile).
5. Conflict Resolution and Psychological Safety
Address conflict constructively by developing clear processes for addressing disagreements and resolving conflicts fairly and respectfully.
Focus on solutions, not blame.
Create a dynamic work environment where team members feel safe to take risks, experiment and admit mistakes without fear of retribution.
Publicly acknowledge outstanding work and offer individual praise for effort and achievements.
Tailor rewards to preferences. Here, you need to understand individual needs and offer rewards beyond just financial incentives (eg, flexible work arrangements, learning opportunities…).
Building a high-performance tech team is an ongoing process, not a one-time event. That process includes continuous learning, open communication and empowerment. In time, you’ll create an environment where talented individuals can thrive.
Remember, a motivated and engaged team is the cornerstone of any successful tech venture. And such a team is your engine through an array of different roles.
Key Roles of Senior Tech Leaders
Setting technology strategy
Communicating with the senior leadership team and stakeholders
Managing technology budgets
Overseeing technology projects
Building and developing strong teams
Innovation management
Change management
(For a detailed insight into the roles and responsibilities of Chief Technology Officers in different business sizes, read this guide.)
As you can imagine, these roles require a unique blend of technical knowledge, business acumen, leadership skills and a commitment to ongoing learning.
Which brings us back to one of the key roles of tech leadership: setting technology strategy to align tech with the company’s mission and objectives.
While technical prowess is important in this process, several core leadership skills truly propel you forward.
Core Tech Leadership Skills
1. Strategic Thinking
Or, in other words, seeing the big picture, understanding long-term trends and aligning technology investments with the organisation’s overall mission and goals. This prevents short-sighted tech decisions that waste resources or don’t contribute to overall success.
Proper strategic thinking avoids reactive tech and ensures solutions serve an overarching purpose (eg, a CTO who aligns an AI initiative with improving customer service, not just for the sake of cutting-edge tech).
2. Problem-Solving
Since tech is full of unexpected roadblocks, as a tech leader, you must create structured approaches to identify root causes, generate creative solutions and make well-informed decisions.
A good example is a project manager who facilitates a root cause analysis instead of just blaming developers for a delay.
3. Communication
To be able to articulate often complex technical concepts in clear, accessible language for both technical and non-technical stakeholders, you’ll need to switch from just listening to active listening and adapt your communication styles.
Clear communication is essential for fostering collaboration, avoiding misunderstandings, inspiring teams and building trust in a leader’s vision.
4. Team Building
Tech is made by people, and the best ideas arise with a strong team dynamic. For a tech leader, this means attracting top talent, creating an inclusive culture, fostering collaboration, resolving conflicts and motivating individuals to work towards a common goal.
Strong teams simply produce better results, are more resilient to challenges and are more likely to innovate.
5. Adaptability
Tech environments are rarely static. Leaders must often adjust plans, learn new skills and guide their teams through uncertain terrain. Because, at any moment, the company strategy can change (eg, a Black Swan event) and as a leader, you are expected to pivot these strategies while remaining agile.
6. Ethical and Data-Driven Decision-Making
Take a moment to answer these three questions:
What are the broader societal implications of our technology?
Are we prioritising fairness, transparency, privacy concerns and user well-being alongside business goals?
Is my recent decision based on accurately interpreted data or gut feeling?
Ethical decision-making builds trust with consumers and employees, avoids potential harm and positions the organisation as a responsible leader in the industry.
Of course, these are just the most prominent from the list of skills technology leaders must possess to do their jobs effectively. Our free tech leadership book, “90 Things You Need to Know to Become a CTO” expands on critical areas of tech leadership through 9 logical sections. It is a rich resource that will come extremely handy on your journey so take a moment and download it before you continue.
It’s simple and requires nothing but objective self-assessment.
STEP 1: Write down the core skills we explained and rank yourself (1-5) on each skill.
STEP 2: Objectively reflect on strengths and areas with the most growth potential.
STEP 3: Self-discussion
Which of these skills do you believe are the toughest to master?
Are there any we haven’t mentioned that you think are vital?
If there are, what are they (write them down under the ones we explained)?
STEP 4: Challenge
Pick one ‘growth’ skill and commit to one specific action to improve it in the next month.
To gauge and benchmark your current strengths and weaknesses against the hundreds of global tech leaders who’ve already completed the process, complete our Skills Assessment.
Natural talent is a start, but deliberate growth is key.
Common sense tells us that continuous development (personal and professional) is one of the key components of technological leadership in business.
But what are the most effective strategies considering our busy daily schedules? We can’t exactly commit to traditional university programs, can we? So what’s the optimal approach to this problem?
Before we lay down the strategies, think about this: we cannot improve what we do not acknowledge.
Let that soak for a moment…
Continuous Development Strategies
Peer Mentorship that includes peer sessions and development.
Seeking out challenging experiences and deliberate practice in weaker skill areas.
The Dynamic Leader Principle
These skills compound – it’s about the interplay between them that leads to exceptional leadership outcomes.
The analogy is a well-tuned orchestra. Each instrument, no matter how good it sounds on its own, is nowhere near as effective as when it plays its part at just the right moment with the rest of the orchestra. When perfectly combined, the outcome is pure excellence.
However, it is, essentially, a conductor that transforms this collection of instruments into a well-tuned orchestra. That’s why you need someone with experience by your side, especially at the beginning of your CTO career. We are talking about structured programs, Q&As with field experts and CTO shadowing.
“One of the best parts was getting to meet and talk with other people in the course. Whether it was networking sessions or just group discussions, it was comforting to see that others face similar challenges. Sharing ideas and experiences with a diverse group really broadened my perspective and was incredibly valuable.”
The path Dallas and over 440 tech leaders have taken so far leads you through all 9 areas of your future career:
Leadership and Teambuilding
Business Fundamentals
Technology Strategy and Business Goals
Personal Development
Product Development
Information Management
Finance and Funding
Data Science and Analytics
Digital Trends and Innovation
The outcome here is gaining the tools to a) lead with confidence, b) make optimal strategic tech decisions and c) inspire your teams to achieve their best. And if you briefly check here, you’ll quickly realise the promise is delivered.
This was a quick introduction to tech leadership where we covered the fundamentals – the what and the why. What comes next is exciting, empowering and, most importantly, educating because it explains the how of everything. You will get the necessary knowledge and tools to put your leadership skills into action.
( of course it will depend of the severity and context of the problem also )
One response to “Enhancing Collaboration with a Principal Engineer at TechGlobal”
Given it is not a clear case of a “brilliant jerk”, that has been covered already in the comments – it is basically a coaching topic. The step from senior to Staff/PrincipalArchitect usually implies a significant shift in role expectations – is this clear to the person? Is it stated in a role/level description and properly discussed and reviewed in 1:1s?
Imho it helps to find out together where the ineffective behavior comes from? Is it that they are feeling like an imposter, defensive, overwhelmed? Or rather bored by the same problems, same questions, mistakes, arrogance of more junior engineers or managers for decade(s)?
Different coaching strategies can be developed based on this self-reflection by the PE and 1:1s or 360s.
A few tools I have used or seen working include: 1) re-framing it as a problem to solve – not a character flaw or soft skill to get better at – here is the problem: we shall lift the quality, flow, avoid risk: how do you do that w/o you doing it?
2) Succession planning: for managers it is more common to make succession planning an explicit part of someone’s goals. Apply the same to senior technical leads and ask them to identify, support, coach and make sure that the next generation of principal engineers is growing (and seniors ..)
3) Write things down – it is OK to be opinionated and define guardrails, standards for many aspects, but then write them down and be accountable; help PEs to do so in an inclusive, open way