The Manager's Path

A Guide for Tech Leaders Navigating Growth and Change

The three types of managers to avoid :

• Neglegt : he/she does not meet expectations, never gives feedback and avoid meetings.
• Micromanaging : questions every details and refuses to let you make decisions.
• Abusive : ignores you until they want to yell at you.

The following includes my own notes about what I want to remember and the role that I’m interested in.

Essential features of a good relationship

1. Recurrent 1-2-1 meetings, scheduled (or at least with some predictability). Meetings should come from both sides, with an agenda. These meetings create a extra human connection[^1] and create opportunity to speak privately about whatever needs being discussed. To prepare them, thinkg about topics to be discussed - for boring subjects, emails are just as good.
2. Feedback : at one time or another, you will screw something. A quick feedback is essential, otherwise it will be uncomfortable. The only thing worse than getting a behavioral feedback is not getting one at all, or getting it several months later.
3. Finding trainings or conferences, providing resources for career growth, getting you a promotion or advocating to get one.

How to be managed

Whether you are brand new or have 20 yeards into your career, the charge of figuring out what you want to do, what you want to learn and what makes you happy rest on your shoulders.

• You are responsible for yourself : ask for projects you want to work on. Advocate for yourself.
• Seek for feedback : take it graciously when it comes to you.
• Give your managers a break : it’s only a job to do the best for the company and the team. He/she is not a psychologist. The only person you can change is yourself.

Mentoring

Mentoring is the first step on the ladder to being a manager. It gives you the opportunity to learn in a fairly safe way about management and being responsible for another person. Mentoring can be about internships or new hires.

Internships

When dealing with internships, sit with the person as much as possible on the first day, and try to listen, communicate and adjust responses as much as possible :

• Listening is the most basic skill for managing, and the precursor to empathy. People are not good at saying precisely what they mean in a way that others can understand. You will need to translate questions and (really) pay attention to body language.
• Be careful, as the intern might not ask question, though he/she should.
• Communicate clearly what needs to happen, if he/she should do researches on its/her own before asking questions, explaining pieces of code, point to documents, … All of these will learn something about its/her potential. Give him/her milestones and break projects into smaller parts.
• Calibrate responses and frequencies of interviews.

As a summary :

• Prepare for his arrival,
• Have a project for him to work on,
• Plan to have him present his work at the end of the program.

New hires

New hires are a bit different from interns, as they should have a little more experience. To prepare his start :

1. Plan to have pair-programming, to learn the code base,
2. Point to a glossary, because they are many bits of process, culture and second nature jargon - that you might not realize, but these are completely foreign for a newcomer.

Good team have good onboarding documents they provide to newcomers : step-by-step guides, how to set up a ne dev environment, how to familizarize with tools, … These documents should constantly evolve : make new hires to complete these kinds of documents as their first task.

Tech Lead

The tech lead should be :

• Good at communication,
• Give good presentations without melting down,
• Good at talking to different teams and roles,
• Good at prioritization,
• Pragmatic at urgency,
• Do not dive into details.

He/she continues to write code, but with the extra responsibilities to represent the team to the management. Altough the tech lead is not managing (at least, directly), he/she is still expected to provide mentorship and guidance to the members of the team :

• Influence without authority,
• Need to slow down in ordre to go fast in a near future,
• Focus on the team rather than on the code, to tackle technical debt and focus on operations.

The objective is to reduce the number of (critical) paging alerts and to double the number of deploys.

As a tech lead, you have to act as :

• A software developer,
• A system architect,
• A business analyst,
• A team leader.

Managing a project

To manage a project, you have to :

1. Break the work down into smaller pieces.
2. Push through the details and the unknowns. Do not stop when you’re tired, and keep pushing past those points of irritation. Quit when you think there is no added value in spending time on it.
3. Run the project and adjust the plan as you go. The value of the planning is to help you knwo approximatively how far the project has gone and how much it is left to accomplish. As things will slip (and they always do), keep everyone informed.
4. Use the insights gained in the planning process to manage requirements changes.
5. Revisit the details as you come close to completion. “What is missing ?” and run a “premortem” (= everything that could fail during the project).

Understand the architecture

Connections, interfaces and visualizations… It’s almost impossible to lead a project well if you don’t understand the architecture you are changing.

Team player

… and do your part on boring parts of the code.

Lead technical decisions

… but do not take them alone, without sollications of the team.

Communicate

• Write well,
• Read carefully,
• Get up in front of people and speak,
• Pay attention in meetings,
• Test the limits.

Write design documents, get feedbacks from other speakers and do not forget to listen.

Principle of the Agile Manifesto

• Individuals and interactions over processes and tools,
• Working softwares over comprehensive documentation, Customer collaboration over contract negotiation,
• Responding to change over following a plan.

It’s a waste of time to play “rules cop”, as automation can make the rules more obvious.

Managing people

You should :

• Establish standards for the code and for the systems,
• Share (transparently) knowledge,
• Create a culture of continuous feedback.

People

Know your people. What are their strenghts and weaknesses, how should they improve ?

Observe them : you can’t give feedback if you are not paying attention. Adopt a habit of positive recognition. Provide light and regular feedback. Provide coaching. Avoid big surprises.

If every case, as much for the interviews as for letting someone leave, you will need “files” : either because the people is boring, either because she is not meeting excpectations or tasks that she is being assigned. In both cases, it will be easier to have an history of feedbacks, than trying to build everything up from your memory.

Start giving feedback as early and often, and keep tracks of records you’ve been delivering.

• The product manager is responsible for the roadmap,
• The tech lead is responsible for technical details,
• The manager is responsible for team’s progress through each of these elements.

Analyse dysfunctionalities

• Not shipping : the reasons for not shipping could be technical debt, poor tooling, heavy manual testing, … Analyse how to break down work in smaller pieces.
• Shield : The goal of a manager is to make the team focus on what they need to do without being distracted.

Prioritization

You should distinguish what matters. A task can be urgent (or not) and important (or not) :

• ⚠️ Important and not urgent : strategic ! Make time for this kind of task.
• ‼️ Important and urgent : Obvious work
• 🙄 Not importand and not urgent : Obvious avoid
• 😶‍🌫️ Not important and urgent : Tempting distraction.

Ask for the agenda upfront meetings. We should have a clean procedure and expected outcomes.

“No by default” ➡️ “Yes, and …” means to respond with positivity, while still articulating the boundaries of reality. If you need to say “no”, say it quickly, and if you say “Not right now”, you will need to be sure that “later” can actually happen.

Signals

The frequence of code releases, of code checkins and the infrequence of incidents are signals for a healthy team.

You should standardize releases process, how long does it take, what did go wrong and how to make a roll-back.

The number of incidents should be confronted to the stability and number of features. It is important to have insights about incidents, but trying to prevent everything is just pure loss of time.

Bootstrapping a culture

Culture is how things get done, without people having to think about it.

– Frédéric Laloux - Reinventing Organizations

Structure and processes

Structure and processes are seen as pointless, see harmful. But :

• Without any process, your team will struggle to scale.
• With the wrong process, they will be slown down.

In politics, a “good political idea” is one that works well in half-baked form. It should be the same in engineering : processes should have value even when they are not followed properly.

Processes are necessary. To avoid scaring people, you should rather speak about :

• Learning (instead of structure),
• Transparency and sharing (rather than processes).

What matters

You should see what’s important for your colleagues, how they do manage uncertainty and risks, which kind of solutions they would choose by default (the perfect one, the ideal one or one “that works” ?).

Standards

Code

The code review (process) is a fail-safe for something we might have forgotten, that acts as transparency about applied changes, but it’s also a socialization process.

The only problem is that this process takes time, and everyone should not be onboarded right at the beginning.

For the general layout, a simple Linter can be used (pylint, prettier, …).

Linters aren’t in your way. They’re on your side.

– https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/

Post-mortem

No finger-pointing !

Post-mortem should be a safe process and if someone is responsible for triggering the wrong button, we (as a whole) should be responsible to make that not happen again.

The circomstances of the incident should be analyzed and measures should be taken to avoid the cause to be repeated again. The actual situation should be made better.

In every case : be realistic ! All problems cannot be addressed immediately.

Risks

WHat kinds of risks concern our team ? Our institution ? How could we mitigate those risks without adding a lot of new totally useless processes or adding unwanted bureaucraty.

Conclusions

Stay curious !