SOLID Engineering Leadership
Tranistioning from Engineer to Engineering Leader is a process full of opportunity. Opportunity to learn, grow, and to expand your knowledge base into domains you only scratched the surface of. It's also a process ready and willing to teach a few hard lessons. One such lesson I learned was the application of Dependency Inversion as it pertains to leading a team of engineers.
There are several flavors, variations and interpretations of the Dependency Inversion Principle (DIP). The one I find most applicable here is
- High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces).
- Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions
How is that relevant?
Sounds quite technical, doesn't it? This is clearly only applicable with my head down jamming out code and drinking Monster, right? Nope turns out this might be one of the most important principles you can apply to leadership.
The whole point of this principle is to avoid a tight coupling between implementation details and the value they yield. Between the value forming business logic and underlying technical concerns.
Viewed from a leadership perspective, our value building business logic lies with the product and/or feature we're trying to deliver. That's the critical idea the business wants to bring into being. The driver of this idea is the Product Owner/Manager, while its creation lies with the Engineer.
Product Ownership
That nascent idea has intrinsic value outside of any technical implementation. It may well be implemented with an Archimedes' screw if that gets the job done.
Engineering Rigor
As Software Engineers we implement the business logic with rigor and pragmatism. Software Engineers are 100% coupled to the details of the implementation and know its every nuance.
Lesson Learned #207
And this is the lesson I learned: The responsibility of Engineering Leadership is providing that abstraction between two concerns. The deep in the weeds, detail oriented Engineering implementation and that value driving, idea realizing Product Ownership. Each side of the coin depends on an abstraction of the other.
Living this Dependency Inversion means the leader is simultaneously
- Driven by the higher level Product Initiative
- Provides the space and freedom to the engineering team to deliver
These complimentary perspectives yield the compound title Engineering Leader. Lesson learned, maybe next time it'll be Liskov substitution principle
