lead from front

[AmitKumarDas]

// questions
//
// is it gated?
// is it a self-service deployment model?
// is it a self-service release model?
// is it auditable?
// is it repeatable?
// is it reliable?
// is it less overhead?

// versus
//
// number of machines outnumber the humans
// cost of downtime vs cost of quality gates
// pre-production vs in-production checks 

// feedback framework
//
// Perception - i see/notice/observe
// Reaction - emotions (concerned, upset, angry, annoyed)
// Impulse - i wish/ i ask for/ i would like to discuss

[AmitKumarDas]

// reduce cognitive load & let teams focus on business / logic
// enable teams to transition from features to outcomes
// pair testing / debugging

[AmitKumarDas]

// Knowledge silos lead to project roadblocks and team frustrations.
//
// Structuring engineering orgs based on function can be a practical solution, 
// especially in large tech teams. But in many cases, it creates silos that exacerbate
// skill gaps and lead to roadblocks, friction between teams, and a culture of 
// dependency.
//
// In this panel, engineering leaders discuss the methods they’ve used to share
// knowledge and collaborate across teams. They cover how you can identify 
// silos, recognize when they are a problem, and take practical steps to break 
// down barriers between teams.
//
// Key Takeaways
//
// - Identify when restrictive silos appear in your engineering teams
// - Learn how to make the most of engineering specialisms without compromising team performance
// - Improve problem-solving and team cooperation
// - Build a cross-functional and autonomous engineering culture
//
// refer - LeadDev Broadcasts

[AmitKumarDas]

https://leaddev.com/culture-engagement-motivation/learnings-placing-engineering-heart-innovation

- placing engg at the heart of innovation
-- what makes an org innovative
-- creativity of engineers is stifled due to limited method of task assignment
-- assign teams problems instead of predefined work
-- perpetually disempowered
-- leading to stagnation of product development
-- unlock creativity & innovation with an experimentation mindset
-- malleable planning instead of fixed plan

- maximize developer's impact
-- embrace the engineers' natural flow
-- engineers push themselves into new areas of professional growth, 
-- when this is supported engineers can keep up with the pace of the ever evolving 
-- disempowered teams lead to feature factory orgs

- job autonomy & understanding the purpose
-- unlock unseen motivation & people's full potential
-- participatory decision making

- Instead of compelling missions or initiatives, teams deal in feature and project assignments. 
-- Chronic multitasking and over-utilization
-- delivered features vs. delivered outcomes

- acknowledge failures & scrapped work
-- roadmaps show a list of features & not areas of focus &/ outcomes
-- No staff retrospectives, PM retrospectives 
-- No retrospectives on the quality of their product decisions 
-- Developers have “passing tests”, but product managers do not
-- Product managers view velocity and output as their key performance indicator

- "front loaded process" in place to "get ahead of the work" so that items are ready for engineering
-- alternatively known as "culture of handoffs"
-- team is not directly involved in research, problem exploration, or experimentation & validation
-- once shipped team has little contact with support, sales, customer success

- features are not delivered incrementally
-- You might still work in sprints 
-- but nothing new is reaching customers at the conclusion of each sprint

- chasing upfront revenue
-- Features are implemented to close new deals
-- While not inherently wrong, the economic justifications are often flimsy (at best), 
-- and fail to account for the non-linear increase in product complexity 
-- (you make the quarter, but you pay for it many times over later). 
-- Again, this reinforces the idea that features are the unit of value measurement.
-- Product decisions lack a sound economic grounding

[AmitKumarDas]

https://amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later

// Should small group” (three amigos: design, engineering, and product) 
// to figure things out in advance before landing the effort on “the team”?
//
// One big learning is that even with the best intentions, 
// it is common for these “small groups” to land prescriptive work on teams 
// without detailing the bet, and the expected benefit.

[AmitKumarDas]

// https://cutle.fish/blog/dear-product-managers#.mij4797cz
//
// Is any of our hard work really paying off for our customers and business? 
// Is it moving the needle? 
//
// Guessing without reflecting is not fine. 
// We’ll never learn that way. 
//
// The team is measured (officially or otherwise) every day: 
// uptime, defect counts, story point velocity, test coverage, 
// hours spent programming, acceptance criteria met, and
// stories and features shipped. 
//
// But none of these things indicate customer outcomes. 
// Feature-bloat adds complexity, and complexity slows us down. 
// Keeping us busy is not the goal. 
// Delivering outcomes is the goal.

[AmitKumarDas]

// testing
//
// refer - https://www.datadoghq.com/blog/test-creation-best-practices/
//
// historically tests have been notorious to create and maintain
// take considerable time to implement -- more than coding the logic
// configurations for executing tests become more complex as your infrastructure grows

[AmitKumarDas]

// make simple things effortless
// make complicated things possible
// demonstrated faith to pick one from available options

[AmitKumarDas]

// The Doominator from Modus Right Workshop
//
// Put your tickets or features somewhere in the axes

               Eternity
                 /|\
                  |
                  |
  Doom <----------------------> No Impact
                  |
                  |
                 \|/
                Today