Your leadership provides the what; you should own the conversation of the how.
Your engineering organization must be able to prioritize and help deliver the ingredients that are relevant to achieving your comfort towards creating the product. Removing obstacles to delivery – both tangible and intangible – is a key ingredient to maintaining a healthy engineering culture.
Ingredients that you can clearly itemize, justify and deliver towards timely delivery of a quality product, are management's responsibility to support and provide.
Provided that you and your leadership want:
- A stable product
- An effective and low maintenance developer experience
- Timely delivery of priority features that delight the customer
- Quality guarantees via pragmatic testing methods
- Seamless and predictable deployments and integrations
- Quick turnaround times on reporting and resolving production issues
- Early identification of bugs and security concerns
- End to end visibility of your infrastructure and application
You and your colleagues should be in a position to
- Clearly itemize the ingredients you need to get the job done
- Estimate the level of effort to deliver
- Acquire any necessary new skills and competencies
- Advocate for the time and resources necessary to your immediate supervisors
The following grid is a tool to design and define the guardrails and quality gates for building a software product:
| Planning | Development | Pre-push | Pre-merge | Post-merge | <more quality gates here | |
|---|---|---|---|---|---|---|
| People | ||||||
| Processes | ||||||
| Tools |
This can easily be represented either as a real-life or virtual whiteboard. With this board, individuals or teams can define
- People: define the specific people or activities involving human roles that can be applied at a specific stage of the engineering journey
- Processes: define the processes that should be applied at specific points in the progression from raw material to finished software product
- Tools: identify tools that can be applied to the product as it moves along the assembly line of software engineering.
The idea is to provide a visual, structured approach that will help with the timely identification of opportunities to improve the process of developing the product. It’s also particularly useful for collaborative purposes, where any number of devs can contribute their ideas in a structured manner.
- Expect that your BMD grid could be reused by other departments in your organization
- Prioritize mitigating risk to the product, as well as your own comfort in building and supporting it
Having this structure, guardrails and quality gates:
- Collect yourselves into pods (or guilds)
- Prepare to define specific tasks that can be collected into coherent milestones.
- Work with your steering group to maintain alignment with strategic initiatives and objectives.
Otherwise known as guilds in various parts of the industry. A pod is a group of subject-matter interested individuals in the organization. For example, a Front-End pod will be composed of individuals that are either experts or interested in the matters concerning the front-end components of the product; a Security pod will be composed of individuals interested in security matters affecting the product.
- A pod will cross the boundaries of functional teams, or other traditional reporting structures.
- A pod will bring together like-minded individuals across the engineering organization, to collaborate in tight-knit groups that are passionate about a specific subject matter. No management or authority figures should participate in these pods.
- A pod will meet on a regular basis to deliberate and ideate on how to address De-risking and Engineering Comfort, as it concerns their subject matter. No management or authority figures should participate in these sessions.
- A pod should use the BMD grid or similar structure to clearly outline their ideas and plans as they concern the subject matter.
- A pod should self-designate Points-of-Contact. The PoCs will serve as an interface to the pod for management, and other pods. These aren’t individuals with authority over anyone else in the pod; they’re simply representatives of the pods they participate in.
- A pod should be empowered to define work they deem necessary to further the objectives of De-risking and Engineering Comfort. The work should be well-defined and estimated by the pod, for level of effort and resources.
- Work output from the pods should remain clearly aligned with any strategic objectives of the larger engineering organization.
Pods provide a structure for engineers to freely ideate, experiment and coalesce around efforts that can be linked to strategic objectives.
They are an avenue for engineers to provide bottom-up leadership to their supervisors.
The tasks that engineers deem necessary as pods should be grouped together and organized under milestones. Milestones are coherent, measurable and time-bound goals that the smaller units of work build up to. Milestones should be demonstrably linked to any larger strategic initiatives, if they exist. A milestone serves as an uplink to strategic targets and initiatives, from the work the pods are doing. This way, non-management folk have some ownership and stake in the strategic goals of senior management
With these structures in place, we arrive at a process where
- Pods ideate and craft milestones they’re interested in picking up
- They work with the steering group to allocate time and resources to the milestones
- Continuously deliver milestones based on needs they’ve identified, under the guidance of their steering group.
Ownership comes with responsibility. You're still accountable to management for results. Milestones still need to be strategically aligned somehow.
Your ownership of the way the product is built must be able to answer specific questions as to how exactly you're owning the way the product is built.
Sometimes, the values of your ownership will conflict and there will need to be trade-offs e.g. Making something easy to deploy may make it difficult to upgrade; making it easy to develop may make it difficult to test.
Understand these trade-offs you're making and be ready to lay out the case to your leadership when called upon