This document outlines my philosophy on technical leadership. Its purpose is twofold:
- Establish a methodology I use for technical leadership (why it is written).
- Establish accountability for my technical leadership (why it is public).
Principles
Acceptance
Not everything is always perfect. It's entirely okay for not all aspects of the project to be constantly perfect. Priorities are set in collaboration with stakeholders, and aspects of the project that do not directly align with key objectives should be accepted or validated against the priorities.
Case: Instability:
Problem: The platform is unstable.
Business Objectives: Feature velocity.
Approach: Initially, it must be accepted that the platform is not stable. However, it should constantly be validated whether the instability hinders business objectives of feature velocity. If so, the platform stability should be adjusted to a state where it no longer obstructs the objective, but no more than that.
Stakeholder Alignment: We don't have a stable solution as long as this is not prioritized. It can be prioritized, but it will affect other objectives or require more resources.
Direction
Leading a project is about setting direction. For example, if there are inappropriate constructions in the code, more suitable patterns should be devised. The new patterns should be documented, disseminated, and integrated.
Case: Component Properties
Problem: Bugs often occur because properties are not set on components. Our data model allows a lot of data to be optional, and a decision was previously made to accept optional properties on components deeper in the hierarchy.
Approach: Find a pattern that eliminates the error vector inherent in having optionality. This can be done by creating a sum type that either takes the optional value or a "value does not exist" value.
Stakeholder Alignment: Co-developers should know that this is the construction we will use in the future. It should be clear that if a property on an object is not optional, this pattern should be used.
Compassion
Software development is a journey. Decisions have previously been made consciously or not, and oftentimes we see the effects later when the decision has had severe impacts. However, it is important to understand the grounds for the decisions that have been made. This should be done in a way that evokes no defense. It is important to be conscious and compassionate about the situation and open-minded about the reasons.
Ownership
Each team member generally own their own code. This is something to be proud of and something to be responsible for.
Anti-Dogmatism
Not all projects should be led in the same way. A significant part of managing a project is identifying gaps and filling them. In particular, these gaps are highly dependent on the resources available to a project and the objectives of the projects.
Methods
The landscape of methodology is large. Some work well in certain teams and contexts. I have had success using the following methods:
Use proposals and RFCs
...to work on ideas from inception to buy-in.
- Proposals provide agency to each individual team member as a tool to participate in a debate that transcends development.
- Proposals are more flexible than stories/epics and allow recording of less condensed ideas.
- Proposals are particularly well-suited for remote situations where they record information that is mostly just discussed.
Have Code Guidelines
Writing code is like playing the piano. A pianist does not consider each individual key strokes but rely on practiced chord progressions.
In software development team, nobody gets to be Beethoven. Instead we share and maintain a list on what good chord progressions are - the code guidelines.
When writing software the importance of rule-adherence is as the following:
- Type safety: Important, non negotiable.
- Linting rules: Can be circumvented when they obstruct a better way to write code.
- Code guidelines: Lists out preferred way to deal with situations in an abstract way.
Code guidelines take into account that there might be certain circumstances where this does not make sense.
I work with code guidelines are demonstrated in my sample code guidelines for a typescript project.