There’s a lot of resources explaining more in details many roles in IT, but one in particular I think it’s not well defined or explained. The Feature Lead.
I have an overall idea of what this role should do and which behaviors or skills people on this role will have to develop or show in order to make the most out of it and really create an impact.
In order to share these thoughts I’m drafting an e-book that will bring a more detailed perspective on this subject. See below an excerpt of the first chapter.
What is a Feature Lead?
The Feature Lead is a role – a set of responsibilities – that can be deployed inside software development teams as a mean to empower people to take ownership and make decisions regarding the development of new features, creating a more fertile environment for growing self-managed teams as well as a culture of experimentation and learning.
The feature lead is the equivalent of a product owner on the technical side of things. That means that the Feature Lead will be responsible for taking care of all the technical issues that involves the development and especially the delivery of a new feature end-to-end.
Did you know?
The definition of what a “feature” is, as we know it nowadays in software development, was described by Peter Toad in 1997 in his process for software engineering called The Coad Method, that later evolved to become the Feature Driven Development process. The core of the Coad process was an artifact, created during the analysis phase, called “a feature”. It was similar to a requirement, except by the fact that it was written using a domain language which the project sponsors could understand. The main concept is that a “feature” should be written in a way that the sponsor could agree that the feature had meaning and was required in the system . Doesn’t this sound like an old relative of User Stories?
- It’s a role and not a job title.
- A feature lead is responsible for feature delivery.
Did you like it? See below the outline of the e-book: