Earlier this month, I visited our Brazilian offices to run some internal training, called Tech Lead Skills for Developers. The trip felt a bit full circle as I had visited Brazil several years ago for the same reason and needed to develop the material. Instead of the handful of people I coached, I ran two full classes with a mix of people currently playing the Tech Lead role and those who might be stepping into the role.
The course I run uses a mix of training styles (short presentations, lots of time for story sharing, discussions, interactive exercises, brainstorm and lots of time for question time). In general I’m really happy with the overall result with a good balance of covering lots of material, making it personalised and relevant, and giving people an opportunity to practice, gather feedback and have a go at applying it. The feedback for the course was quite consistent with those in the past, telling me that the balance was just about right.
One of the great opportunities I have had, running this course in different places is seeing some of the cultural implications and differences between continents. I learned, for example, that Brazil (traditionally) has a higher Power Distance Index (PDI on the Hofstede Dimensions), which means that, at least compared to the United Kingdom or America, authority is viewed a bit more strictly. In practice, this meant that a lot of the developers, working in more collaborative environments seemed to almost take an extreme anti-leadership position, where any mark of authority was viewed poorly, or that there was a reluctance to be seen taking on a title.
I also discovered that the word delegate in Portuguese had a negative association. As we discussed how effective leaders scale themselves through effective delegation, it was almost interpreted as a manager telling people to take care of the bad tasks – which, of course, wasn’t the intent! In the end, I tried to express effective delegation as a way of ensuring that all important responsibilities were being taken care of.
I am running this course again later this year in both Thailand and Singapore and look forward to seeing some more of the cultural differences that emerge during the discussions.
I wanted to respond earlier, but tweets were too restrictive. Here’s my response.
The argument against Tech Leads
The article rebuts the necessity for a Tech Lead with the following points (emphasis author’s, not mine):
Well functioning teams in which people share responsibilities are not rare.
When a team is not functioning well, assigning a tech lead can potentially make it worse.
There are many great points in the article. Some of the points I support such as how sharing responsibilities (also known as effective delegation). Distributing responsibilities can be one way effective teams work. Other points lack essential context such as the title (it depends), while other points lack concrete answers such as how to turn a dysfunctional team into a highly performing team.
Are well-functioning teams rare?
I’ve worked with at least 30 organisations over my career as a consultant, and countless teams, both as a team member (sometimes Tech Lead) and as an observer. I have seen the whole spectrum – from teams who function like a single person/unit to teams with people who simply tolerate sitting next to each other, and where one can’t miss the passive-aggressive behaviours or snide remarks.
The article claims:
that the “tech lead is a workaround – not a root cause solution
Tech leads could alleviate the consequences only
Unfortunately the article doesn’t explain how or why the tech lead is a workaround, nor how tech leads alleviate just the consequences.
The article gathered some discussion on Hackernews, and I found some comments particularly interesting.
Let’s take a sample:
(gohrt) Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
(vidhar) …we live in reality where lots of teams are not well-functioning some or all of the time, and we still need to get things done even when we don’t have the time, resources or influence to fix the team composition then and there.
(ep103) If I had an entire team of my great engineers, my job would be easy. I’d simply delegate my duties to everyone else, and we’d all be nearly equal. I’m jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.
(shandor) My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (EDIT: i.e. tech lead responsibilities)
(doctor_fact) I have worked on teams of highly competent developers where there was no tech lead. They failed badly…
(mattsmith321) It’s been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions.
(jt2190) I’ve been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted… These teams (if they can be called that) produced software that had little to no overall design.
Do these sound like well-functioning teams to you? They don’t to me.
Well-functioning teams do exist. However it is clear that not all teams are well-functioning. In my experience, I would even say that really well-functioning teams are less common than dysfunctional, or just functioning teams. For me, the comments are proof enough that well-functioning teams are not everywhere.
It is actually irrelevant if well-performing teams are rare – there are teams that definitely need help! Which leads to the question…
Does assigning a tech lead to a poorly functioning team make it worse?
In my talk, What I wish I knew as a first time Tech Lead, I explain how acts of leadership are amplifiers (can be good or bad). Therefore assigning a bad tech lead to a poorly functioning team will probably make it worse. However I don’t think organisations set out to give teams bad tech leads.
If a team is poorly functioning, what do organisations do? Simply leave the team to stew in its own juices until things are resolved? That’s one option. Doing nothing is a gamble – you depend on someone in the team to take an act of leadership but the question is will they? I’ve seen many teams never resolve the very issues that make them poorly functioning without some form external intervention or assistance.
Most organisations try to solve this by introducing a role who has some authority. It doesn’t necessarily need to be a Tech Lead, but when the core issues are technical in nature, a good Tech Lead can help. A good leader will seek out the core issues that prevent good teamwork, and use their role to find ways to move them towards a well-functioning team. Sometimes this may mean calling meetings, even if the team do not want to have meetings to reach an agreement about how the team handles certain situations, tasks or responsibilities. A good outcome might be an agreed Team Charter or some clarity about who in the team is responsible for what. A team may end up with a model that looks like they do not need a Tech Lead, but it takes an act of leadership to to make that happen.
The wrong analysis?
The article suggests that a full-time Tech Lead introduces risks such as a lack of collective code ownership, decision-making bottlenecks, a single point bus factor, and (reduced) impact on motivation. I have seen teams with and without Tech Leads both suffering from these issues. In my experience, teams without a Tech Lead tend to have more issues with knowledge silos, no cohesive view and less collective code ownership because there is little motivation to optimise for the group and individuals end up optimising for themselves.
The issue is not caused by whether or not teams have a Tech Lead. Rather, these issues are caused by a lack of a technical leadership (behaviour). The Tech Lead role is not a prerequisite for having technical leadership. I have seen teams where strong, passionate individuals will speak up, bring the team together and address these issues – which are acts of leadership. I have also seen dysfunctional teams sit on their hands because individual (job) safety is an issue and these issues go unaddressed.
The article misses the subtle but important point of good technical leadership. A good leader and Tech Lead is not trying to own all of the responsibilities – they are there to make sure they happen. There is nothing worse than expecting everyone is responsible for a task, only to find that no one is responsible for it.
“The greatest leader is not necessarily the one who does the greatest things. (They) are the one that gets the people to do the greatest things.” – Ronald Reagan
The extent to how much individuals in a team can own these responsibilities is a function of the individuals’ interests, skills and experience. It depends!
Asking whether or not teams need a Tech Lead is the wrong question. Better questions to ask include what’s the best way to make sure all of the Tech Lead responsibilities are fulfilled, and what style of leadership does this team need right now.
Good software architects understand that their role as a leader is not necessarily telling developers what to do. Rather, good architects act like a guide, shepherding a team of developers towards the same technical vision drawing upon leadership skills such as story-telling, influencing, navigating conflict and building trust with individuals to turn their architectural vision into reality.
A good leader, and thus, a good architect, will listen carefully to the opinions of each contributor, fine-tuning their vision with feedback from the team. This leads well onto the next point.
Being a developer
Making good architectural choices is a function of balancing an ideal target architectural state with the current state of a software system. As an example, there is no sense in adding a document database to a system if the problem domain is better suited for a relational database, even if that’s boring. An architect may feel tempted to impose technologies or architectural choices without considering the fit for the problem space – AKA behaviours of the “ivory tower architect.”
The best way an architect can mitigate this is by spending time with developers and time in the code. Understanding how the system has been built up, and the constraints of the system as it stands today will give the architect more information about the right choices for today’s environment.
Having a systems focus
Seasoned developers know that code is only one aspect to working software. To make code run, a seasoned developer understands there are other important quality attributes necessary for code to run well in its production environment. They consider aspects like deployment processes, automated testing, performance, security, and supportability. Where developers may approach these quality attributes ad hoc, an architect will focus on understanding not just the code but also the quality attributes necessary to meet the many needs of different stakeholders such as support, security, and operations staff.
The good architect focuses on finding solutions that can satisfy as many of these different stakeholder needs instead of choosing a tool or approach optimised for the preferences or style of a single contributor.
Thinking like an entrepreneur
All technology choices have costs and benefits, and a good architect will consider new technology choices from both perspectives. Successful entrepreneurs are willing to take risks, but seek ways to learn quickly and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short- and long-term costs and the likely benefits they will realise.
A good example is when the architect avoids committing to a new tool based on reading a new article, or having heard about it at a conference. Instead they seek to understand how relevant the tool is in their environment by running an architectural spike to gather more information. They don’t pick a tool based on how good the sales pitch is, but what value it offers, given what they need for their system. They also look for the hidden costs of tools such as how well is a tool supported (e.g. level of documentation, community adoption), how much lock-in the tool brings or the extra risks it introduces over the long-term.
Balancing strategic with tactical thinking
A lot of teams build their software reactively with individual developers choosing tools and technologies that they are most comfortable with, or have the most experience with.
The good architect keeps an eye out for what newer technologies, tools or approaches might be useful but does not necessarily draw upon them immediately. Technology adoption requires a considered approach looking at a long-term horizon. Architects will seek for a good balance between agility (allowing the team to move fast) and alignment (keeping enough consistency) at both a team and organisational level.
Architects know that effective communication is a key skill for building trust and influencing people outside of the team. They know that different groups of people use different vocabulary and that using the technical terms and descriptions with business people makes communication more difficult. Instead of talking about patterns, tools and programming concepts, the architect uses words their audience will be familiar with. Communicating technical choices to business people with words like risk, return, costs, and benefits will serve an architect better than the words they use with their development team.
An architect also realises that communicating within the team is just as important as outside, and will use diagrams and group discussions to establish and refine the technical vision, and use a written log like an Architectural Decision Log or a wiki to provide a historical trail for future generations.
Doing the job of a well-rounded architect is not easy. There are so many elements to focus us, each drawing upon many skills that a developer often doesn’t focus on practicing. What is most important is not necessarily the ability an architect has, but that they have enough expertise in each of these different areas to be effective. An architect who is skillful in only one of these six areas described above will not be as effective as an architect who has a good level of expertise in all of them.
I recently moderated a panel in our London ThoughtWorks office aimed at developers leading technnical teams as a follow up from the Lead Developer conference.
Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.
This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.
Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.
The panelists shared their experiences around situations like:
Having a tough conversation with a team member or customer;
Sharing how they have dealt with overtime (weekends, later work);
How they resolved a technical disagreement within a team; and
Handling a particularly aggressive person, or being aggressively threatened;
The audience also threw in a few questions like:
Dealing with office politics;
Finding access to key influencers/stakeholders;
Where you draw the line with a person on a team; and
Dealing with a technical stakeholder who is too involved, because they seem to have too much time;
We also had some great sound bites in relation to the topics being discussed.
I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.
Earlier this week, I ran a workshop at the first ever Agile Europe conference organised by the Agile Alliance in Gdansk, Poland. As described in the abstract:
Architects and architecture are often considered dirty words in the agile world, yet the Architect role and architectural thinking are essential amplifiers for technical excellence, which enable software agility.
In this workshop, we will explore different ways that teams achieve Technical Excellence and explore different tools and approaches that Architects use to successfully influence Technical Excellence.
During the workshop, the participants explored:
What are some examples of Technical Excellence?
How does one define Technical Excellence?
Explored the role of the Architect in agile environments
Understood the broader responsibilities of an Architect working in agile environments
Focused on specific behaviours and responsibilities of an Architect that help/hinder Technical Excellence
What follows are the results of the collective experiences of the workshop participants during Agile Europe 2016.
A set of coding conventions & standards that are shared, discussed, abided by by the team
Introducing more formal code reviews worked wonders, code quality enabled by code reviews, user testing and coding standards, Peer code review process
Software modeling with UML
First time we’ve used in memory search index to solve severe performance RDBMS problems
If scrum is used, a good technical Definition of Done (DoD) is visible and applied
Shared APIs for internal and external consumers
Introducing ‘no estimates’ approach and delivering software/features well enough to be allowed to continue with it
Microservice architecture with docker
Listening to others (not! my idea is the best)
Keeping a project/software alive and used in prod through excellence customer support (most exclusively)
“The art must not suffer” as attitude in the team
Dev engineering into requirements
Problems clearly and explicitly reported (e.g. Toyota)
Using most recent libraries and ability to upgrade
Right tools for the job
Frequent availability of “something” working (like a daily build that may be incomplete functionality, but in principle works)
Specification by example
Setting up technical environment for new software, new team members quickly introduced to the project (clean, straightforward set up)
Conscious pursuit of Technical Excellence by the team through this being discussed in retros and elsewhere
Driver for a device executed on the device
Continuous learning (discover new tech), methodologies
Automatic deployment, DevOps tools use CI, CD, UT with TDD methodology, First implementation of CD in 2011 in the project I worked on, Multi-layered CI grid, CI env for all services, Continuous Integration and Delivery (daily use tools to support them), Continuous Integration, great CI
Measure quality (static analysis, test coverage), static code analysis integrated into IDE
Fail fast approach, feedback loop
Shader stats (statistical approach to compiler efficiency)
Lock less multithreaded scheduling algorithm
Heuristic algorithm for multi threaded attributes deduction
It is easy to extend the product without modifying everything, modularity of codebase
Learn how to use something complex (in depth)
Reuse over reinvention/reengineering
Ability to predict how a given solution will work/consequences
Good work with small effort (efficiency)
Simple design over all in one, it’s simple to understand what that technology really does, architecture of the product fits on whiteboard 🙂
Systems’ architecture matches team/org structure
Ideally separated tests, Automated performance testing, automatic front end functional testing with selenium, unit testing done for the first time 10 years ago, constructing new performance testing cases takes minutes, after refactoring unit tests are passing (majority of them – hopefully all!)
Constant curiosity for new technologies/approaches
Good knowledge of software patterns (when to use and when not)
Learn from mistakes
Definition of Technical Excellence
(Technical) Excellence is an attitude to be better than yesterday
Technical Excellence is the holy grail that inspires teams to stay on the path of continued improvement
Technical Excellence is a process that continuously improves product design and the development team. Examples: Automation, knowledge sharing, culture. Synonyms: Dream
Technical Excellence is an ability to consciously apply tools and practices to solve and continuously improve over complex problems in a sustainable way and within constraints (e.g. time and money). Examples: Continuous Delivery
Activities of an architect
Able to choose the right solution amongst many possibilities (awareness of consequences and limitations)
Being able to justify technical decisions made
Thinking (find time to think about the product, structure, technologies used, etc)
Helps resolve interdependencies, helps to identify/minimise external noise (i.e. technical dependency change with negative impact), co-ordination of integration with other teams working on the same project
Start and moderate discussions on design, longer term consequences of decisions, etc
Requirements definition, making sure ‘nothing’ is omitted during analysis/design
Questions decisions to encourage thinking about wider picture amongst developers, asks questions (non obvious especially), Asking difficult questions about work being done
Listens to others
Encourage people to bring ideas, encourage idea sharing
Setup backlog for achieving technical excellence
Challenge old decisions
Business decision support (IT, 3rd party)
Make sure we don’t bite more than we can chew – incrementally/iterative
Ensure architecture is visible, understood and accessible to the team, keep the technical cohesion, helps team consider the bigger picture and interdependencies, helps team define the system and diagram it
Detailed knowledge of technologies/protocols used
Proposes solutions to complex problems
Wide view of situation/projects, look what other teams are building for things to reuse or interface to
“Main” test scenarios definition
Definition of components structure and interactions
Guard technical vision (dialogue with stakeholders)
Focus on project goal
Verification of current design vs planned use
Ad hoc just in time consulting to feature teams when things get complex
Teaching teams, sharing technical knowledge (and expertise) with the team
Coaches team. Gets buy-in from the team for change they are about to trigger, coaches dev team
Identifies technical skillset gaps in the team
Mitigates the risks
Out of box ideas
Research for solution, helps team identify areas for experimenting, exploring new territories
Creating proof of concept (POC)
Learns new things, research and try new tools, ideas, technologies, etc
Gains an in-depth understanding of a system before attempting to change it
Reviews teams’ system design, performs code reviews and coding standard support, reviews code
Behaviours that support Technical Excellence
Gives team rapid and timely feedback
Patiently explaining all the tiny details responding to simple questions
Be there whenever needed
be the safety net whenever devs need you
Set communication for knowledge sharing
Explain the reasons behind the design
Raising the visibility of good developers
Do pair programming, works with the team
Explain technical excellence value for business
Encourage team to think and work towards Technical Excellence
Growing people, mentoring developers to improve tech skills, training the team, educate actively – organise coding dojos, etc
Set up backlog for achieving Technical Excellence
Raising the team spirit and motivation
Waking up with 3am to connect with a team on a daily basis (for a distributed team)
Discussing discovered problems with the team
Sat down with the team to teach and record architecture training for future use
Keeping an eye on new things on the market and bringing them to the team
Staying current in technologies, tools, concepts, etc.
Being a visible role model in terms of pursuing Technical Excellence
Support team in collaboration with other teams
Helps team identify blindspots
ability to change contexts between projects
Lets the team make decisions
Take a step back and make room for technical advancements of the whole team
Not doing stuff from actively discourage column
Team makes decisions
Behaviours that discourage Technical Excellence
Dictatorship, have to do it my way, will to control (every small detail)
Blaming and shaming
Making arbitrary decisions, especially without explaining the reasoning behind it
Rejecting too complex C++ code
Using ambiguous, complex, uncertain English vocabulary
Shutting down emergent ideas from the team
Discouraging ideas “I couldn’t care less about your sophisticated C++ SPT initialisation”
Created ugly prototype for a demo and forced team to clean up afterwards
Imposing BDUF (Big Design Up Front) over the development team
Created non-viable design (i.e. could not be implemented with current constraints)
Enforcing old known technologies, etc out of inertia/ignorance, sticking to the “old ways”
Doing too many activities to follow through – not focused on any (and no time to encourage Technical Excellence)
One of the key responsibilities of a tech lead or architect is to ensure there is a shared understanding of where the team is heading. A clear Technical Vision is really important so that everyone on the team pulls together in the same direction instead of moving in potentially different ways, or worse, pulling against each other. What follows are three tips I think about when focused on building a Technical Vision.
1. Use a visual
Although developers will often joke about the “whitebord architect”, I find diagrams are a powerful way of articulating ideas that cannot be succinctly expressed in code or words alone. I highly recommend Simon Brown’sThe Art of Visualising Software Architecture which provides concrete advice to make your diagrams better.
Your first step in building a Technical Vision is to make sure you use some sort of visual model. Using words alone leads to unintentional misinterpretations or misunderstandings. Diagrams offer different perspectives and a shared model between two people. Use a number of visuals to model different perspectives but identify first what perspective you find adds the most to shared understanding.
TOGAF list a number of potential perspectives you might visualise. Remember however that more models does not lead to a better understanding. Diagrams are only a tool to aid communication, not to replace it. This leads nicely onto our second tip.
2. Discuss as a team
Successful architects and tech leads build a shared understanding of the Technical Vision by involving the entire team in its creation. Whiteboards are your best tool here to allow for real-time collaborative creation. A model is best built block by block with the same shared context and story.
Building a visual together is a much more effective way than printing off a PDF or asking people to view a static copy on a wiki. Beware your human sunk cost fallacy cognitive bias which my colleague Neal Ford calls the Irrational Artefact Attachment. Try not to invest too much time in any models or diagrams, or you’ll find yourself (irrationally) defending or preventing change to the model which leads us to the third and final tip.
3. Iterate – reflect and review
A real Technical Vision must incorporate feedback. Unlike the once-off architecture models written by true ivory tower architects, the Technical Vision should be revisited as the system evolves and as the team learn more about the domain and constraints of their environment.
Look to review the shared Technical Vision as a team on a frequent basis (once every three months is a good guideline for a long-lived system) to ensure the shared understanding is the same.
In some of the Tech Lead courses I have held, we sometimes talk about leadership styles and whether or not the Tech Lead role is essential. During these discussions, one of the biggest influences on both style and necessity is the style of teams.
This article represents my current classification of teams I have seen over my years in industry.
One man army
A lonely developer working on a project by themselves. Most likely they are working on multiple projects and consequently multi-tasking, because that’s the way the organisation works. Often seen in organisations that are siloed. Technically not a team but treated as a part of a team.
Distributed teams come in many shapes and sizes. Although distributed teams are similar to Off-Shore teams (see below), distributed teams tend to be a team spanning several locations. GitHub are an example of a distributed team (and organisation). Often seen with start-ups who are seeking talent not easily found in the same location.
A distributed team typically spans several timezone, making an “all-hands” meeting more difficult. Relies on asynchronous tooling such as chat software (e.g. IRC, Slack) and virtual task boards.
An Off-Shore team is a distributed team in mainly two locations. Often used by many IT organisations as a “cost-cutting” tactic trading communication effectiveness. Sometimes an off-shore team is a historical artifact (company acquisition or expansion) and necessary to keep essential knowledge alive.
Off-shore teams often have better overlap with time zones that fully distributed teams, but often results in an us-and-them mentality.
The “Pod” shaped team
The “Pod” shaped team is a co-located team who that has most of the skills they need to deliver a project. The team often includes a PM, developers, analysts, testers and sometimes operation and support people. They are all working towards the same project at the same time. This reduces co-ordination and communication lag and makes software delivery more effective.
They are called a “pod” because they are kept to a certain size (typically less than 12 people) to keep communication overhead minimised.
Functional silos are not representative of effective teams because people are grouped managerially and physically by skillset instead of by goal. Each group is managed by a separate person and in larger company, decision making and authority reaches several layers much higher into the organisational hierarchy. Collaborating and changing the way that a team working on the same project across functional silos becomes very difficult to change.
Typical functional silos often seen: PM (and their PMO), Analysis, Developers, QA, DBA, System Administrators, Network and Support.
A couple of weeks ago I had a last minute invite via James Lewis to speak at at Away Day for some people from GDS. I only had a couple of days notice and was going to give a talk around being a Tech Lead but thought I would adapt some of my talks to the broader audience that would include developers, web operations, delivery managers, tech leads and architects.
I have been thoroughly impressed by the work and innovation that the GDS team have made along the way and my goal was for everyone to come away, feeling like they could demonstrate Technical Leadership without requiring a title of a “Tech Lead” or “Architect.”
The GDS Away Day was held at Fish Island Labs, a new digital hub set up by the Barbican group and located on the river Lea with a nice spacious set of rooms for conferences and co-working and a very functional bar down stairs.
I held my talk as the closing keynote before I joined everyone in the pub downstairs and had some great feedback about how relevant the message was, and that many people came away inspired, which I was particularly happy with given it was the first time I held this talk and the little time I had to prepare for it.
With a one-time only opportunity this year, I am running a course for Architects and Tech Leads on 22-23 October at the ThoughtWorks Sydney offices. After interviewing over 35 Tech Leads for the Talking with Tech Leads book, I recognised there is a gap about teaching developers the special leadership skills a successful Architect and Tech Lead demands. The class size is really limited, so reserve yourself a place while you can.
In this very hands-on and discussion-based course, participants will cover a wide breadth of topics including understanding what a Tech Lead is responsible for, the technical aspects a developers rarely experiences and is not accountable for, and the difficult people-oriented side to the role including influencing, relationship building and tools for better understanding your team.
This is a two-day course that will quickly pay back dividends in accelerating you on your path or further developing your Tech Lead skills as developers. Register here on eventbrite for the course 22-23 October.