TeamLead Conf · April 29–30, 2021
The SOLID Team Lead
Management fundamentals for engineers
/ The SOLID Team Lead · TeamLead Conf 2021
Management fundamentals for engineers
Management fundamentals for engineers
Who this talk is for
You are a strong engineer
You are new to management
You already lead a team, or are about to
You want to succeed in the new role
Who carries an idea through to a result
A modern cross-functional development team
Roles: Analyst, Data Scientist, System Engineer
…QA engineer, Developer, Infosec engineer
Loop: idea → requirements → design → development
…deploy → operations → financial results
The customer's ideal team
The business customer brings an idea
In return they expect financial results
Between them sits one «development team»
Making that team excellent is the team lead's job
OOP principles
Abstraction — only what matters from the outside
Encapsulation — details stay hidden inside
Inheritance — a shared shape gets reused
Polymorphism — one interface, many implementations
The same four words applied to a team
Abstraction: the customer sees a team, not six roles
Encapsulation: the team lead stands between them
Inheritance: the same team shape for every idea
Polymorphism: three teams, three implementations
The same four words applied to a role
Abstraction: requirements → duties
Encapsulation: the result matters, not the keystrokes
Inheritance: Junior → Middle → Senior
Polymorphism: substitutability within a level
Five principles — and five management practices
First for code, then for the team
Example: from one shared IT team to feature teams
In code: a class has a single purpose
In a team: one goal, and its resources are inside
Before: one shared IT team with shared prioritisation
After: a feature team per customer plus platform teams
Example: the QA competency matrix
In code: open for extension, closed for modification
In a team: this is about competency matrices
Base duties are fixed at the junior level
Every level above only extends the contract
Example: an architect reached by two ladders
In code: a derived class stands in for its parent
In a team: everyone is substitutable, starting with the lead
Problem: development and analysis both lead to Architect
Solution: Software Architect and Solution Architect
Example: segregated interfaces and meeting notes
In code: many narrow interfaces beat one broad one
In a team: one interface is exposed outward — the lead
Do not route every activity through that one person
Spread the work across the roles inside the team
Example: micromanagement vs management that works
In code: depend on abstractions
IoC matters more: the framework drives the flow
Micromanagement: the lead re-explains every step
The healthy version: principles first, then the task
What to take with you
The management half of SOLID
S: a team has one goal and every resource for it inside
O: a competency matrix fixes the base and extends the contract
L: clear level requirements produce substitutability
I: the team lead is the interface, not the only channel
D: principles instead of micromanagement
«Essentially, all models are wrong, but some are useful» — George Box
The knowledge sources from the talk's closing slide
Article «The SOLID team lead, or management basics for engineers»
Article «SRP and IoC principles in software development management»
Article «Orchestration and choreography in development management»
Talks «Modern approaches to building software» and «How we make architecture decisions»
polomodov.tech
All slides and links — in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube