Is technical leadership important? Even in a modern, agile / lean / software craf company? My experience says it is not only important but the key to the improved performance of developers. Whether we’re talking about a team technical lead, a software architect, a CTO, or an informal leader, I often see the need to understand their leadership role better.
I have my own story with technical leadership. I’ll be sharing it in this article, and try to extract my key learnings. I’ve applied them for 15 years and they stood the test of time; I trust you’ll find value in them as well.
Project X
It was 2001 when I got involved in a defining project for my career. I will codename it ‘project X’. It was a zero-administration C++ Business Intelligence application; or, in modern terms: a big data application using a NoSql database, running on the local network. Except no NoSql database engine existed at that point fit for the project’s needs, so we had to build our own engine. I was appointed to the project almost as a desperate solution; the company was not doing well due to the dot com bust, I had just returned from Paris, and the client was kicking out developers from the team because they weren’t delivering high enough quality.
Development Process
It’s easy to say now that that project was a great learning opportunity. The first few months were very intense and, while it felt good to learn, I was also unhappy at times. To understand why I need to tell you more about our way of working.
First, we had to we had to know the coding and design guidelines by heart – very well written, ~2 pages living documents containing must-know information. Then, we had to study two core C++ books, “Effective C++” and “More Effective C++”. They contained a list of good code constructs applicable in specific contexts. Think of it like the tips and tricks for Javascript that you find today online, only compiled in two books and about 200 of them. We wrote our own unit testing library because back then there was none for C++.
Developing a feature would go like this: you would get a short requirements document for a small piece of a new feature. You were then supposed to create a design diagram and have an informal design review meeting. Then, you would write the tests and the code. When you were done, an informal code review meeting took place where both production code and unit test code has thoroughly reviewed the guidelines and the books mentioned above. Sometimes, the review took place on email instead of face to face. It was made very clear from the beginning that quality was very important. In our context, this meant at least three things: simple code, simple design, and high performance.
Feedback
The reason for unhappiness in the first months is that I would often get emails pointing out my mistakes in design or code. Thinking back, I realize it’s easy to take such emails personally, especially when you’ve never been subject to real feedback before. I know now they weren’t about me, but about my work. Like most programmers, I had a difficult time to distance myself from my code and from my ideas. So I’ll admit they resulted in some swearing. But when the logic prevailed I understood the feedback was correct. It’s always a difficult time when you realize that you aren’t good enough. If you manage to put your ego aside and get over it, you learn more than from any book, conference or internet website. And, although I’m not programming full-time C++ anymore, I’m still using a lot of the lessons learned during that period.
Lots More
There’s more to say about this project. It was my first experience as a technical lead, my first experience with unit testing (a practice I kept improving, understanding and teaching since), my first experience with elements of XP (small iterations, code review, unit testing, direct connection with client etc.) and much more small things. In hindsight, it also had issues in certain areas: writing tests after the code and too much control from the technical lead was slowing us down, lack of visibility on the whole project created awkward situations etc.
But the real lessons learned are about technical leadership, specifically, the practices and ideas that were defined in the project, how they were explained to me and how they helped me while I was still only a developer. I still use these ideas today, as CTO of MozaicLabs and as a consultant for tens of companies looking for technical improvements.
1. Be clear in what you require from developers
Hands up if you’ve heard this phrase before:
Our developers have to work at the highest quality …
Keep your hands up if everyone from the company is too busy maintaining an existing mess that slows down development to the point where survival is uncertain.
I cringe when I hear the ‘Q’ word, especially when it has ‘highest’ in front. Software quality is a very fluid concept. For me, highest quality means:
- zero bugs found by users
- the speed of adding features is constant throughout the whole lifetime of the product
- the application is fast enough for what it’s doing (and you need to detail what ‘fast’ means in your context)
- security measures are appropriate for the type of data you’re storing and type of service you’re offering (and you need to detail what ‘secure’ means in your context)
- feature requests and other updates are delivered in a timely fashion (and you need to detail what ‘timely’ means in your context)
- the application behaves appropriately under higher loads (and you need to detail what ‘loads’ you are supporting in your context)
- never lose customer data
- the application’s availability is within acceptable limits (and you need to detail what ‘acceptable availability limits’ means in your context)
This doesn’t have to be your definition of ‘highest quality’. For most companies I work with, it isn’t. And I’m not going to bash those companies because all projects have constraints.
A good technical lead knows the constraints and knows how to do the best work possible within those constraints.
But because the definition of ‘quality’ is so different, it’s very important to clearly define what you mean by ‘good quality’. It may be “deploy quickly, let the users test it”, or “simple code, simple design and high performance”, or “zero bugs, fast response and high security”, or “only cutting edge technologies and algorithms and innovative implementation ideas”. Write it down, post it on walls, send it in emails and slack channels, remind developers about it over and over again.
Quality is only an example. Another source of issues is configuration management, as in “when do we branch? when do we merge? how do we mark staging and releases? etc”. Yet another one is the testing strategy, as in “what do we test? when do we test? who tests?”. These are fairly easy to solve (we know, we helped customers before with testing strategy and configuration management).
Ask yourself: what is unclear? Talk to your developers. Talk to your customers. Talk to your managers. Then clarify it.
A good technical lead removes uncertainty and creates clarity with every opportunity possible.
2. Advocate the practices, processes, and tools that help developers deliver what you require
The best CTO I knew came to Mozaic Works with a very clear plan. Briefly, it stated:
- As a company, we are now at point A and we need in point B
- To support this, we need: clean code, better designs, BDD and continuous integration
- We do not need continuous deployment
- To go there, we need a training program as follows: 6 months of clean code workshop and practice sessions, 6 months of design patterns workshop and practice sessions, 6 months of SOLID principles and practice sessions, 6 months of BDD workshop and practice sessions etc.
Some of my friends have disputed this plan, saying “but continuous deployment is very important”. To this day, I still trust this person because he knew exactly the constraints of the company, and the plan was clear, well organized and predictable. That’s more than I can say about any other CTO I’ve met.
We also knew this wasn’t an easy job for him. To get to this plan, he had to spend months traveling between sites around Europe and UK, discussing with developers and leaders in the local organizations, explaining the same things over and over again and probably listening to the same worries over and over again.
This is a job for a good technical leader. As a CTO, you supervise the practices, processes, and tools for the whole company. But there are other types of technical leaders, with smaller scope and more constraints. At the product level, we have architects who have a word to say not only about the higher level structure of the code, but also about the organization; for example, microservices are not merely an architectural concept but equally so an organizational one. At the team level, we have technical leads who can advocate things like code style, team practices and so on.
One of the defining characteristics of Project X was that every tool and practice aligned with the ‘simple code, simple design and high performance’ goal. Design reviews helped us simplify the design. Code reviews helped us find issues and simplify the code. Unit tests clarified the features, allowed us to build on solid ground and found problems early. Source control was helping us collaborate at a time when it wasn’t necessarily popular.
You might say we were lucky, and that many of you work with tools imposed by the company and there’s nothing you can do about it. Well, there are a few things you might try. Your company might be using an awful source control system; nothing stops you from using git on your local computer to make small changes or even local branches and push to the company source control when done. I’ve done this with all customers who weren’t using git. Creative solutions exist, and it’s your responsibility as a technical lead to advocate them.
Maybe you know where you want to go, but you don’t know how. In that case, our famous free 42 minutes consultation might help.
3. Teach and mentor your developers to deliver what you require
What do you think would have happened in Project X if someone handed me a feature and then started to criticize my code and design, without any support whatsoever? I think I would have lost my faith, started brooding and maybe even quit the company.
Good technical leads do a push-pull move: they push developers to better results, more learning and practice and pull them towards learning resources and practice sessions.
Once you ask things, you need to offer support to obtain those things. Here’s where it gets complicated because not all people need the same kind of support. Some need to read books. Some need to write pet applications. Some like a social environment (coding dojo, code retreat, pair programming), others like to be more secluded. As a mentor, you need to adapt to their needs instead of imposing your own true way.
Still, there’s a push-pull move with learning as well. I push developers towards more feedback and more social ways of learning because they are more effective for the organization. But when I see they are not comfortable, I pull them back into the comfort zone (usually with jokes, designing a safe environment, being nice or, in extreme situations, suspending temporarily the sessions).
In Project X, we were required to write code in a very specific way that we had never used before. Although difficult, we always had the right amount of support: books, documents, colleagues and, ultimately, the technical lead.
Summary
This sums up the basic things I’ve learned about technical leadership from a defining project in my career. To summarize:
- Take into account the organization’s constraints:
Understand them, challenge those who aren’t helpful, but take them into account nonetheless
- Clarify everything:
What is quality
Configuration management
Testing strategy
… and any other sources of confusion
- Clearly define practices, processes, and tools that help your team(s)
Advocate and experiment (when possible) with better ones, but make sure they are clear and helpful
- Provide all necessary resources for developers to deliver what is required
Do the ‘push-pull’ move: push towards better results, practices etc, pull towards learning resources that support the results you want
Do you agree? Do you disagree? Let us know in the comments.
For more on breaking barriers between technical and leadership, check out Alex’s book “Usable Software Design”, about mixing UX practices with software design since the developer is the user of software design.
