Last ~2 Years

• PDFer
  • continued from Jeff Decker
  • worked solo for ~2 months
  • custom fork temporarily of Chromium in order to solve a problem (buffer overflow)
  • full rest API with workers using SQS that I managed solo and before the days of Terraform
  • 15 minutes per unit (tops) * number of units * incremental edits = 10,000 hours total or something we came up with
  • this was crucial for getting contract for NYC that is one of the major reasons science is pushing us close towards the positive EBITDA next year or so
• Curriculum component/ES6
  • built on Thomas Lahr's work (which helped us immensely later)
• Edition/language matrix
  • frontend JS wrapper around server side rendered HTML
• Worked with J Priest for authoring app speedup
  • dipped into Java args and page caching
• NGINX proxy layer and OpenResty
  • custom naming for S3 items
  • CORS solutions
  • in place of more slow microservices
• first isomorphic NodeJS library "amp-content"
  • used on backend for PDFer and frontend in Curriculum app
• Docker build system
  • to free up dependencies on Astrotools
  • custom versions of any linux package
    • Ruby
    • NodeJS
    • Java
    • etc
• Grand Central
  • Angular 1.x and React on the same DOM/window

struct Amplify

My perception

• Aaron Harnly (CTO)
• Nathan Potter (SVP of Engineering)
• ?
  • Mike Z ↔ Mike L
  • Me?

Or more specifically on science, we have

• a product owner (Eve Silberman)
• an engineering directer/manager (Michael Zawadzki)
• a team of engineers with
  • 1 "team lead" that only handles admin and organization (Jesse Vogel)
  • 1 "tech lead" that isn't necessarily officially named (me, Christian Battaglia)

Product engineering

"[After the] product foundations, you need devs who engage with the 'why', actively."

What is it?

Engineers who have:

• the thirst for using technologies to leapfrog human/user problems
• empathy to reach for magical experiences

"Great product engineers know that minimum lovable products need the right depth to be considered during the build phase"

Traits

• proactive with product ideas/opinions
  • "They think about other ideas and approach the product manager with these. They often challenge existing specifications, suggesting alternative product approaches, that might work better"
• interest in the business, user behavior and data on this
  • empathetic about how the product makes users feel and how those users benefit from using this product
• Curiosity and a keen interest in "why?"
  • "Why build this feature for the product, why not the other one? Why ship this first milestone, instead of choosing another one, that's a lot simpler to build? How will things be measured - why don't we choose a more thorough way to measure things?"
• Strong communicators and great relationships with non-engineers
  • "talking with people outside engineering, learning about what and why they do"
  • grabbing coffee, lunch, or doing a hallway chat with non-engineers
• Offering product/engineering tradeoffs upfront
  • scoping the effort to build the product, the engineering effort to build a key feature might be significant
  • go back to the product manager, suggesting a completely different feature to be built, given the product impact would be similar, but the engineering effort vastly smaller
• Pragmatic handling of edge cases
  • "For example, if one in a thousand users might be hit by an error, they will consider the effort to fix it and think about what happens if they don't do anything. Can customer support help the person in this case, during validation? Can the user just retry and succeed the next time? Can the product be slightly modified, so this edge case won't occur?"
• Quick product validation cycles
  • "how can we validate that people will use this feature, the way we think they will?"
  • pubnub test
• End-to-end product feature ownership
  • "When a feature performs worse than expected, they are curious to understand where the mismatch was. They are just as interested in finding the root cause between the product plan and the real world result, as they are to debug a hard-to-reproduce bug in the codebase. They'll often spend a good amount of time debating hypothesizes and learnings with the product manager and data scientists."
• Strong product instincts through repeated cycles of learning

Takeaways

• Understand how and why your company is successful
• Build a strong relationship with your product manager
• Engage in user research, customer support
• Bring well-backed product suggestions to the table
• Offer product/engineering tradeoffs
• Ask for frequent feedback from your product manager

this is fundamentally based on the belief that if you empower others with the context they can move faster, make better decisions, be engaged and help you scale the product craft across your organisation.

Amplify Product Engineering 2020+

• Strong opinions, loosely held
  • ability to talk openly and candidly with product
  • PEs will often come to POs/PMs with an opinion on a particular item they’d like to flesh out more
• Quickly build intuition
  • direct exposure to customers
• Bring healthy conflict
  • “healthy” conflict by considering different aspects of a decision and encouraging healthy debates and challenging the status quo
  • questioning the work, not the people
• Identifying (and minimizing work) on edge-cases
  • elevate the discussion to focus on the majority use case
  • spend all their efforts on the ideal journey — the path most taken
  • spend their time on the most valuable thing
• Cup of quick wins
  • not content with doing the same task more than once
  • understand the value, and second, you need to know what is low hanging engineering work
• Seek early feedback
  • validate a concept, gather feedback and do a build-measure-learn loop
  • take as many shortcuts as possible to ensure the problem your solving has met its goals before entering a hardening phase
• Communicator
  • build a community and staff engineer the workspace in a "Amplify learning" kind of way
• Take decisions and own their backlogs
  • take the time to write the tickets and report issues in other areas of the product even if not in the specific lane

Laws (Earth from the sun's perspective)

1. Technology is, first and foremost, a people problem
2. Can't force people; tempt them
3. New must be better than the old

Diamond cheaper than glass because carbon cheaper than silicon (Niel Stevenson)

What mindset?

• configurability = hardware/software convergence
• magic in computing
  • software doesn't do computing but software is computing
  • book becomes a piano (we can do this!)
• Crapiano vs Garage Band
• !(product == technology && liberal arts)
• technology is Greek (art U science)
  • techno = art, skill, craft
  • logia = science, theory, study
  • definition is redundant and recursive
• people
  • real world assum the best but in product engineering assume the worst
  • people employ product to make lives easier
  • people are not stupid but don't have the domain specific knowledge so pretend
  • not impatient but don't have the time
  • selfish
  • not ignorant and apathetic but don't know or care about your company
• sharpen your focus
  • remove 1 feature or line of code will render it useless
  • engineering elegance
• great products are boring with little layer of revolutionary
  • first iPod (nothing)
  • solved problem simply and well
• no million dollar idea
  • if you do all the work we can give you half the money
  • dime a dozen?
    • no dime for 12
  • thousand dollars to listen to your ideas
  • originality is not the most important thing
• hell-a-vator (evil elevator)
  • unhappy and confused people
• platform is culture
• most important thing is building a team
  • n+1 teams for n platforms
• build the product the user expects
• disprove to yourself that it doesn't work
  • test like your arch-nemesis
  • hate your products
• plan + design = ship on time
• cut features don't cut quality
• don't ship your rough draft
  • out the door and into the waiting arms of the person who's opinion does not matter
  • don't use your customers to test
  • stuck with the first impression
    • color?
  • never get second chance to make a first impression
  • adds up Microsoft Kinnect
  • don't dig a hole for yourself
• when is it ready?
  • mariachi? crazy?
  • the hook is the thing that makes your product stick in the mind

Questions

• As far as you currently know of me and my role, am I fulfilling my duties/job description as an engineer?
• What more is there for me at Amplify?
• Could something like a product engineer fit at Amplify?
• How might I get a stake in helping make or being at least hyper aware of infrastructure decisions?
• What is the right balance of technical problem solving and innovation at Amplify as we balance out and start to venture into positive EBITDA?
• Is there room for technical leadership in place of or beside management?

Terms

• Product engineering
• EBITDA
  • earnings before interest, taxes, depreciation, and amortization
  • net income plus interest, taxes, depreciation and amortization

Resources:

• The Product-Minded Software Engineer
• Product engineers - Sherif Mansour - Medium
• Product Engineering