Tech Lead Role

Rationale

Why does this document exist? Simply put, so you know what is expected of you when performing the role of Tech Lead.

Tech Lead is an important role at Infinity Works and carries a lot of responsibility so everyone who is in this role must be aware of the responsibilities they are signing up to. This document defines those responsibilities.

Similarly, because it is such a critical role we must share some techniques and advice for how to succeed in the role, and this document lists some of them too.

Some background

Team leadership activities

Team leadership involves a mix of activities. The balance of time required for each will depend on the scale of the engagement, the client culture and the range of stakeholders, but a typical mix might look like this:

These activities may all be done by a single person, especially on smaller teams and on simpler engagements. Since most of our teams have technical deliveries, this single person will need to provide technical as well as other forms of leadership and we call this role "Tech Lead". Other times these activities will be shared between several people. For example, if the requirements gathering and analysis are more involved then a dedicated Business Analyst may do the bulk of this work, or where there is a need to invest considerable time and energy into interacting with non-technical stakeholders or producing reports then a dedicated Account Lead or Delivery Lead may share these activities.

The important thing is that these things are covered by someone. If sharing responsibilities, have a clear agreement of who has primary responsibility for each thing and work closely together to avoid things falling between the cracks or duplicating effort.

What is a Tech Lead?

The Tech Lead role is not a point on the ladder, but a set of responsibilities that any engineer may take on once they reach a senior level. Tech Leads are strong technical leaders and use their skills to ensure engagements are successful, the team improves and clients are happy. Whatever the organisation of the team on an engagement, the tech lead is expected to provide mentoring, guidance and support to other members of the team.

The tech lead needs to be good at seeing the big picture, able to make an effective plan to deliver results and able to work to maximum effect by delegating work and empowering others. They focus on the whole team's productivity and strive to increase the whole team's effectiveness. They are empowered to make important decisions for the team and handle difficult leadership situations where necessary such as dealing with stakeholders, client staff and conflicts of priority. They also lead the charge in partnering effectively with other parts of our business and the client team.

Is being a Tech Lead all about tech?

Frankly, no. To be a good Tech Lead you undoubtedly must have good technical skills. You will be expected to help move projects forward with your hands-on skills. Solid technical skills and the ability to practically help the team let you establish credibility and also ensure you can lend a hand when things get tough. The other vital element of being a Tech Lead is solid people skills. You simply cannot lead without engaging with other people. Some of these people will be fellow Infinity Works engineers, some will be Infinity Works staff from other roles. Some of these people will be client staff and many of them will not be technical. They will be relying on you to translate technical issues into a language they can understand.

The art of being a tech lead

The real trick to being a good Tech Lead is all about balance. You won't just be hands-on engineering every day. You will have to split your time between your personal technical commitments, what the team need from you to be the best they can be and what the client needs from you to make sure they are happy that things are going the right way. This does mean you'll wear many hats, but you'll also get a much clearer view of the bigger picture and much more autonomy in deciding what work gets done and how it gets done.

Responsibilities

The role of Technical Lead carries a broad set of responsibilities. On smaller teams or accounts, the Tech Lead is likely to be directly responsible for all these factors, while in other cases they may be shared with other people such as a separate Account Lead, Delivery Lead or Business Analyst.

Basics

This role is usually carried out by those at career level CL8 Senior Consultant and above.

Tech Lead specifics

Ensure the team is working to a plan with defined goals which the team believes is achievable and the client understands and agrees with.

You'll need to identify what the project is trying to achieve, why things need to change, how they need to change and what critical features need to be delivered for the project to be a success. Knowing how to build things is useless if you can't decide what are the right things to build. Knowing the right things to build is useless if you can't evaluate if it should even be built at all. (If something doesn't meet the business' needs, why build it at all?)

The goal here is to provide some structure for basing estimates and ordering work. You don't need to identify all the elements of a project in exquisite detail, but there is a lot of value in identifying and thinking about the external dependencies and issues that might affect your work.

The skill of being able to break a large piece of work down into rough deliverables is essential. Finding ways to break work into meaningful chunks that made sense technically is a real skill. The objective is often to parallelise work and prioritise so that the important things are delivered efficiently. To do this effectively you need an understanding of the business as well as the technical constraints. Often, you'll need to collaborate with domain experts and other specialists outside your team to gather all the right inputs.

• Ensure the team has tickets to work on which are ready for implementation.

Ensure the technical design of the system. Others may contribute but you remain ultimately responsible.

Being a Tech Lead often means you have to listen to a range of points of view, make a reasoned decision, communicate that decision, and if needs be, defend it. The team will look to you for clarity and certainty.

• Ensure the team delivers to an appropriate quality.

Establish the team culture.

A big part of being a Tech Lead is the 'Lead' part. You need to lead by example and model the behaviour, attitude and standards — technical and personal — you expect to see from your team.

Act as a primary client contact and Infinity Works representative.

In many engagements, you'll be the most senior Infinity Works person that a client sees. We pride ourselves on our honest, no-nonsense approach. This can often mean having difficult conversations with clients and learning to navigate the politics that exist in any business. This is made more difficult by the interaction between Infinity Works staff and client staff at all levels.

• Ensure the system performs as required in production and is maintainable.
• Ensure appropriate documentation and traceability are in place to avoid later disagreements.
• Overall, ensure the client is happy with the engagement.

Advanced

What Infinity Works core skills are required?

• Building great relationships - Level 4
• Figuring stuff out - Level 4
• Leading the Infinity Works way - Level 4
• Developing Infinity Works - Level 3
• Embracing change and ambiguity - Level 4
• Thinking differently - Level 3

Tech Lead specifics

Ensure the team is working effectively and team members are happy.

This often means going the extra mile to help your team stay motivated, positive, and feel like they can achieve. This can mean helping them technically when they are stumped, teaching them new skills and giving them new opportunities — to make mistakes and learn from them if needs be!

You need to support them when the going gets tough, pick them up when they are down and correct them when they do the wrong thing.

Ensure the team delivers fast enough and with appropriate discipline and rigour.

You will need to be the person that makes sure everyone else meets their commitments. If they can't get things done on time then it's over to you to fill the gaps. This often means multi-tasking and chasing up lots of little details. Often you are peddling like crazy just to make things look graceful.

Resolve blockers caused by factors outside the team.

Initially, client staff are rarely keen to see us. With hard work and honesty, this often changes to a positive relationship but always requires careful management. Sometimes you'll need to push stakeholders and client staff to achieve your objectives. It may not be comfortable at first, but it is necessary.

• Resolve blockers caused by issues within the team such as lack of skills or knowledge or lack of appropriate tools.
• Support and develop team members.

Bonus

• Protect the team from unreasonable client demands.
• Resolve any interpersonal or performance issues which arise.

Techniques

Business value

Understand the business goals or problem. Don't start without that knowledge

Before thinking about the technical design, understand the problem statement and expected business value. What are the client's goals? Do they aim to increase market share or tap into a new market, make cost savings, or something else?

Use: Elevator pitch, product box

Ask yourself, is radical or traditional right for the client?

When approaching technical design, consider the business drivers. Sometimes they will be best served by choosing technologies and architectures which challenge the status quo and inject new thinking, but other times simpler, more established or better-understood approaches may be better.

Use: Innovation budget, skills matrix

Keep the design grounded in business value

(Respectfully and politely) challenge designs which prioritise perceived architectural purity over business value or aim to meet functional or non-functional requirements which are more than what is needed, especially scalability or extensibility.

Use: Epic estimation, options comparisons

Product and planning

Take responsibility for the plan, have a roadmap

Invest time in building and maintaining the product and technology roadmap. Especially if the team has no dedicated BA, or when working with a client BA who needs support, this will require you to lead the team to identify and estimate Epics, identify dependencies and break Epics down into Stories.

Use: Goals and milestones, epic roadmap, backlog refinement, three amigos

Track risks and dependencies

Clearly record and communicate risks and dependencies to the client, especially where they are outside the team's control. Work proactively to resolve the risks rather than just track them and find ways to remove the dependencies or make them less problematic.

Use: Risk log with regular reviews along with client

Understand the Infinity Works / Client relationship, commercial model and contract [Advanced]

Be aware of the client's commercial agreement and model. Identify key delivery dates and whether the client is more driven by fixed date or fixed scope. But be careful how you have these conversations and ensure the client is engaged with the process, especially if planning shows that there is too much work to fit the time and hard decisions need to be made.

Use: Goals and milestones, epic roadmap, backlog refinement, three amigos

Build situational awareness [Advanced]

Spend plenty of time speaking with client stakeholders and influencers, especially if the account lead is not involved day to day. Understand their wider vision and plans and what else is being worked on. These conversations often uncover dependencies or assumptions which will affect the work the team is doing, and they may lead to opportunities to widen our involvement.

Use: Org chart, stakeholder map, programme plan

Technical design

Focus on non-functionals

Have a broad understanding of the key areas which need to be considered when designing systems, paying particular attention to non-functional requirements such as integrity, security, performance, capacity, scalability, resilience, availability, recoverability and maintainability.

Use: High-level approach, high-level design, low-level design, non-functional requirements

Keep it simple

Design systems which are as simple as possible to help with maintainability, operability and integrity. Consider alternative designs to remove complexity when it creeps in. Be mindful of the operational overhead of systems with many moving parts, interactions and dependencies.

Use: Play through scenarios to uncover hidden costs, options comparisons

Aim for harmony

The parts of a system should fit together and follow a standard approach unless there is good reason to deviate. Favour the "least astonishing solution".

Use: High-level approach, high-level design, define and document code/naming standards and patterns

Establish the technical direction but don't design everything up front

Don't try to design every detail up front, but also be aware of the need to set a clear technical direction and strategy. When decisions are made too early they may turn out to be irrelevant due to changing understanding and requirements, so don't invest too much time in them. But if the team don't have a shared understanding of which way they are heading the work will be unaligned and the system will lose coherence. Identify key risks and assumptions and at the appropriate time do lightweight PoCs, spikes or research to guide the design.

Use: Epic roadmap with T-shirt size and risk/uncertainty rating, PoCs/spikes

The "right" technical design depends on the client's context [Advanced]

Be aware of the client context. Take the client's skills and background into account. Consider and communicate ways to incrementally work toward what you think is the ideal solution rather than assuming you will be able to jump straight there.

Use: Current, interim and target architecture, innovation budget, skills matrix

Client relationships

Speak to others outside your project

Work to build relationships with key client stakeholders including product/project/programme managers, delivery/engineering managers, architects, operations teams, DBAs and change/release management. Identify those who could have a significant influence on the real or perceived success of the team and build trust and rapport with them.

Use: Make time for a chat, engineer situations to encourage ad hoc conversations, and regular reviews with key stakeholders

Justify your thinking

Present ideas to the client as intentions rather than decisions which are a done deal. Justify decisions based on the effect they will have on the team's ability to deliver the desired outcomes. Where decisions may be controversial, present alternatives and explain why you favour your chosen option. Be aware of the client's context and background: decisions which seem obvious to you may still need to be justified to the client.

Use: Options comparisons, play devil's advocate for your ideas, be balanced, don't rubbish ideas

Cooperate with everyone

Work toward achieving a positive outcome, even if the client's thinking or processes seem cumbersome or old-fashioned. Sometimes we can influence these, but this needs to be handled carefully and it is usually best to avoid appearing to challenge them head-on. Try to understand what experience or fear is motivating their thinking and try to find alternative ways to make them comfortable rather than discounting their thinking out of hand.

Use: Take the emotion out of decision-making, and be inquisitive about motivations

The client is in charge

While taking a lead on decision-making, remember that the client needs to feel that they are in charge. Choose your battles and don't sour the relationship over unimportant differences of opinion. But where you feel they are making a significant mistake, calmly explain why in terms of business risk or cost.

Use: Options comparisons, epic roadmap

Get clear agreement

Record decisions, including the date and which client stakeholders agreed to them

Use: Decision log

What if the client doesn't agree

Where the client argues against your proposals remember that ultimately it is their right to have the final say and we are there to advise, not dictate. If your recommendations are not followed then document this using plain factual language and avoiding inflammatory wording. If you feel that decisions which don't go your way are going to significantly hamper the team's ability to deliver then seek guidance from the local board.

Use: Risk log, regular reviews with key stakeholders

Know when you need help and ask for it

Know when to ask for help, especially with client stakeholder management.

Use: Engage with other tech leads, local board etc

Protect the team, filter out noise [Advanced]

Try to insulate the team from unnecessary distractions and unreasonable demands from the client. Take responsibility for managing client expectations and the messaging to client and team.

Use: Epic roadmap, sprint plan, channel communications via defined stakeholders if needed

Focus on operations

Have an operational model

From the outset, think of what you are building as a system preparing for production. Get used to working as you will once it is live. Build the tools which will be needed in production and get used to using them before go-live.

Use: Operations epics and stories, with internal users such as support engineers as the persona

Be ready for incidents [Advanced]

Establish and rehearse the procedures which will help you respond to incidents. The team may need to be on call. Lead by example and be part of the on-call rota.

Use: Role playing, chaos engineering

Technical delivery

Change your mind when it is demonstrated that you're wrong

Don't stick with decisions if experience gained through delivery shows them to be wrong. Important indicators that designs and decisions may need to be changed are often only clearly visible by experiencing the impact of these decisions during implementation.

Use: Retrospectives, pairing

Help with tricky technical problems

Don't be too fickle. Sometimes the team needs to push through a tricky problem rather than change course. Be aware of the potential impacts on team and client perception and reputation of sticking with or changing decisions.

Use: Pairing, spikes, options comparisons

Spend some time hands on [Advanced]

Be involved in the low-level implementation as well as the high-level designing. This will allow you to guide the implementation and ensure the team is working toward a shared vision and implementing to an appropriate standard.

Use: Pair program, pick up simple tickets, do spikes / PoCs

Quality

Establish a culture of quality

Quality delivery comes from setting clear expectations and establishing a team culture where individuals hold themselves and each other to account. Lead the team in defining appropriate quality standards and processes. Lead by example, diligently following the processes you've agreed to.

Use: Definition of done, test strategy, code standards, stand-ups, end of sprint reviews, retros

Cover the basics

Focus on the basics like issue tracking, source control, pairing, peer review and CI/CD. Invest time in defining the test strategy. Ensure appropriate documentation is produced as part of delivery and tools and processes are in place to make onboarding easy.

Use: Issue tracker and/or physical board up to date, branching policy, definition of done

Avoid perfection, don't nitpick

Don't seek perfection. Give team members space and when the solution they produce is good enough don't criticise minor details unnecessarily.

Team

Build the team culture, keep people motivated

Build a good team atmosphere where individuals feel empowered and engaged. Be approachable and always make time for colleagues. Be aware of relationships within the team and work to resolve clashes. Ensure new team members are appropriately on-boarded and have the tools they need to do the job.

Use: Delegate but support, retros, create time for socialising, regular feedback sessions

Team output beats individual output

Don't be a hero. Focus on team delivery over your individual contribution. Prioritise helping others deliver their tickets rather than delivering yours.

Encourage challenges from both your team and client

Take a lead on making decisions while keeping others informed and making them feel like they have been involved in the process. The team need to be bought in or they will not work toward a common goal. Delegate and involve others in decision-making where appropriate and give them space to do so, while providing the appropriate support. But don't let the decision-making end up as "design by committee": take a lead or direct others to take the lead where necessary.

Use: Options comparisons, spikes, clear owners for decisions, three amigos

Be expert in some areas and competent in all

Don't try to be the expert in everything, but also don't delegate so much you can't have meaningful involvement in decision-making. While maintaining a broad understanding across the whole system, do work to provide expert guidance in at least some areas — ideally the areas where the team are weakest.

Use the team

Don't let yourself be a design bottleneck — make use of the team. Work as part of the team rather than in isolation and don't work too far ahead of the team. Enable the team.

Give constructive feedback, seek constructive feedback. Coach your team [Advanced]

Give regular constructive feedback to team members, and seek feedback from them. Be aware of team members' performance. Coach when possible, but also escalate to the local board promptly when needed and contribute to the resolution process.

Use: Regular feedback sessions (1:1 and peer-to-peer), pairing

ISO

You'll carry out your role in accordance with the requirements of ISO9001 and ISO27001 as reflected in the Company's policies and procedures and the ISO9001 and ISO27001 organisational structure charts.