In IT services, we’re consultants at all times — not just to clients, but also to the project team, peers and delivery operations. This means that we’re often juggling many things at once – managing expectations of internal and external stakeholders, supporting teams as well as making decisions across technology, design, architecture and business solutions.
On the other hand, there are also operational challenges. How hands-on should you be and how much should you delegate? Should you protect your team or let them fail and learn? How should you balance customer delight vs. team health? How should you measure growth?
In our experience as consultants, technologists, managers and leaders, we’ve learned a thing or two about this. In this article, we share our lessons.
Three hats of a technology leader
In our view, to influence people and decisions from the ground up, leaders often wear one of the following three hats — enabler, influencer and ambassador. Let’s look at them one by one.
Enabler
Get your hands dirty. Enable the delivery team to get stuff done. Do, show and tell.
Enabler is the persona you assume when working with the delivery team on the ground. As a technology expert wearing this hat, you would be coding, writing tests, pairing, building infrastructure, setting up pipelines, fixing and firefighting. The goal of an enabler is to create an environment that enables quality, shows best practices, sensible defaults and the right way of doing things. Here, you will set an example that others can follow. If you aren’t skilled enough in a specific area, you will plan/staff to get the desired skill on to your team.
For instance, at one of our projects, team members were struggling to follow eXtreme Programming (XP) engineering practices such as TDD, pair programming, refactoring, clean code etc. As enablers, we first helped the team understand the benefits of following these practices — building and delivering better software faster. To do this, we used brown bag sessions, mob coding and group refactoring sessions and paired on complex stories. The enabler in these cases is hands-on, sitting with the team and working alongside them to lead by example.
Influencer
Influence delivery team to take action. Show the path further along. Facilitate and direct.
This is the hat you wear while stretching the team towards excellence. You will pose creative questions to improve quality, design interesting technical problems to solve, challenge the team to make space for innovations in processes, inculcate a sense of curiosity and facilitate tough discussions. As an influencer, you guide the team to be better than yesterday.
One of the biggest responsibilities while wearing the influencer hat is to prioritize work (user stories) that clear technical debts. This will help build better quality software and eventually deliver faster in the long run — like paying now for a better tomorrow.
Ambassador
Bridge business value articulation. Be the voice. Build opportunities.
An ambassador is also an influencer, but here, you’ll use your influence to bridge the gap between the delivery team and the client. More often than not, all that is needed is a voice. So, as a consultant, you will use your relationships and position to advocate for building high quality software and better software architecture. Irrespective of whether you are the enabler or influencer, while wearing this hat, you are an ambassador for ideas that help improve the environment, holding customer-centric values at the core.
Let us tell you an exemplary story. In one of our projects, the client wasn’t used to agile XP practices of continuous and early feedback on quality. They were concerned with testing efficiency because not enough defects were getting logged in. Our project lead — wearing the hat of an ambassador — stepped in to explain the importance of preventing defects rather than finding them. They showed the business value of automation and effective dev box testing versus logging every defect in JIRA. After this conversation, the client could see the value of testing clearly and delivery became smoother.
I'd recommend mob programming to showcase TDD.
Add structured logging to support the insights for performance testing.
Apply a blacklisting strategy to the JWT token for expired or stolen access.
Architecture Decision Records (ADRs) should be in 'definition of done' for a user story.
Lets prioritize tech debt stories along with related user stories in same iteration.
Lets build testable solutions.
Every commit should be production ready. Lets follow trunk based development with feature toggles.
User story is complete only when it is ready from end-to-end. Do not split stories as frontend or backend.
Show how following XP practices helped with better quality software.
Will containerization make it more scalable?
Can more tests be shifted to being unit tests? How about less functional tests?
I stand by XP practices. Let’s talk!
Have you heard of the cloud native application using 12 factor apps?
Efficiency should be defects prevented, not detected.
Let's measure what matters and focus on the outcome (what we deliver to production) vs. just focusing on developer productivity (as story points).
Security needs an upfront investment and we will invest in DevSecOps.
Not all leaders know when and how to switch hats. That’s natural. It takes experience, opportunities and deliberate effort to build these competencies. Here are the skills you can build to ‘effectively wear all three hats' –
Influencing and persuading
Whichever hat you’re wearing, you should be able to influence teams, colleagues, peers, managers, etc. Understand when you need to influence and as much as possible leave it to others ‘to enable’ or figure out HOW.
While focusing only on the WHY and WHAT may be possible at some times, at others, you will need to ‘influence and enable’ – be hands-on. Ideally, growing as a leader means you will focus more on influencing and less on enabling over time.
Stakeholder management
As they say, all management is people management. Understanding client/stakeholder needs is essential as a technology leader. Pair with stakeholders to align technology with business needs. Learn to articulate business value. Practice influencing business decisions by exploring it from each stakeholder’s perspective. Develop empathy.
Building a high performing team
If you want to be a successful leader, you should aim to lead a team which is self-organizing, has consistent collaboration, outperforms equivalent teams and has a collective ownership of results. Such a team does not exist on its own, but needs to be built and nurtured. Hold yourself and peer leaders accountable for giving the right guidance. Set clear goals. Build trust. Encourage healthy conflicts. Work towards a team which will be able to support you in taking your leadership to the next level.
Effective delegation
Effective delegation is needed, not only to create an environment where the team owns various areas of work, but also to enable others in their leadership journey. It helps people in your team to understand the responsibilities of a project better and hence commit to the shared cause. Delegation is often misunderstood as a way of distributing work and micro management. Instead, bring a balance of directions and participation. Create a space of shared understanding in the team, working towards collective goals.
In everyday practice, these three hats might look very similar. In fact, on some days, you’ll be changing them so fast, they might all seem to be floating in the air. But remember that, as leaders, we serve our customers, stakeholders and team. Each one of them has a different need. Your job is to always have these three hats handy and know when to use which.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
