This document discusses best practices for managing product releases and software engineering teams. It provides the following recommendations: 1) Establish clear processes for releases, including regular intervals, versioning, distribution, and metrics to measure success. Ensure everyone understands their role in the release cycle. 2) Use the Dreyfus model of skill acquisition to balance team skills and experience levels. Recruit for "smart and get things done" attitudes. Apply practices according to where the team stands. 3) Automate aspects like releases, reporting, and testing when possible, but also retain some manual processes to aid understanding of what to automate. Team learning takes time.

1. Dancing for a product
release
lcerveau@nephorider.com

2. • From general (over) simplistic things to practical
tricks
• Mix of big company and startup experiences
• From inside (direct management) and outside
(consulting)

3. • Idea of creating one identified entity
• With a name, possibly a brand
• That has multiple releases with different
importances
• And where each release is infused by the
personality of its creator team
Product??

4. • The team has to deliver it
• The team has to evolve
So that a product lives

5. Put the Team in place

6. Years of cultural organization (Europe, East Coast…)
Tester
Dev
Product
Marketing
BOSS
High level glorious thinker
Low level manual stinker
Add the Project Manager as mid level wannabee parasite
Inside
Outside

7. Impact of the 201X Startup paradigm
• Let’s pretend this does not exist because there
are not enough people in the company and
everyone is multitasked
• Let’s not hide anymore the engineering geek
and make it a selling argument
• Let’s pretend a product/app is a common work
But it takes more to fight your reptilian/cultural/religious brain

8. Change your mental schema
Tester DevProductMarketing
Dictatorial Boss
Project Manager —> Engineering Project Manager
EPM

9. Engineering Project Manager
• Duty to make reporting and have a rigorous no lie/
no bullshit attitude
• Must have no favorite partner among the other
core team group
• Must anticipate (and do) the work that other do
not want to do : bug triage, reporting
• Should be number one product knowledge source

10. Technical or not?
• Decide from the start if you are a technological
company
• If yes make sure that you can show your technical
assets at any time
• If not think if having a technical team is a good
thing
• If not Keep a QA instead of an engineer

11. About QA
• It always come at last. Whatever you announce.
• QA people are always considered as “not good
enough to be an engineer”
• They are always right
• They must feed the machine (bug), especially to
do what automation can’t

12. Don’t break the cycle
Especially at day 1

13. Develop
Release Use/Test

14. Versioning
• When you repeat yourself change the
version each time. Reporting is essential.
• Build version versus marketing version (iOS
has agvtool - set up your project).
• Version all components, make the version
easy to find
Question most heard in product life cycle. Save
20% of useless talk

15. Release
• If there is one automated piece in your
system this is the release tool
• The boss should be able to make a build
• Release at regular and fixed intervals. Do
not wait for engineers/designer to complete
their fixes
• EPM should make sure everyone knows
what’s new there. Track history

16. Distribute (especially mobile)
• Use third party tools for mobile applications
(Testflight)
• Make sure everyone is over-notified of a new
build
• If you worry about who is on your distribution
list, do not put her/him there. Remove people
who do not install
• Use distribution to validate a development. This
is NOT final release

17. Measure
• A bug system is a metric system. It provides
cold facts.
• If you argue philosophically about what is a
bug (or not), a feature (or not), then stop
doing this job and do cocktails
• Make sure it can integrate at all level of the
workflow (gathering of bugs)
• The best tool for your team is the one people
use

18. The cycle is for everyone
• Product designer could be ask to provide 10
variations of one design
• Product launch is not done with talk : text to
write, translation to make, videos to prepare
• The EPM must gather all elements

19. Process or not?
• Process is a mean not a goal but “Without
process there is no product” .
• Do not make process or tools a topic of
discussion inside your company.
• Once a process decision is here, stick to it…
until you change it
• If it is not adopted try again later
Yaka, Fokon happens here

20. Tech management

21. Landscape
• Software Engineers are the kings of today
• ….but statistically this can’t be
• And everyone like to think they are in the late
part of the Gaussian curve
me = fXXXing genius

22. 2 books to read

23. Dreyfus model of skill acquisition
• Developed by two (Stuart and Hubert)
brothers in the 1980
• Model of skill acquisition and mastering
• 5 levels from Novice to Expert: they see the
world in different ways
• Per skill model but….

24. Dreyfus model
Expert Expert work from intuition
Proficient Proficient practitioners can self correct
Competent Competent can troubleshoot
Advanced
Beginners
Advanced beginners don’t want the big
picture
Novices Novices needs recipes

25. Build your team
• Decide how to balance the skills and levels:
e.g one architect (expert), one debugger
(expert), 3 monkeys coders (Beginners)
Skills
Level

26. Some management experience
• Startup does not give you legitimacy. This is a
constant fight.
• Recruiting is the entry point: “Smart and get things
done”
• Applying “best practices” should be done
according to where the team stands in the Dreyfus
model
• No concession should be made on the company
code identity. If it looks good and coherent it
probably is.

27. Make a set of common knowledge
• Everey engineer should know this
• Some examples
- Stop and start the infrastructure
- Know an HTTP API
- Know the database model
- Measure performance of a system

28. Technology choice
• There is no technology fundamentally better
than an other. Just different paths to the
same point
Tech A
Tech B

29. So where are the differences?
• Someone who deadly wants to prove a
technology is better will be better
• Depending on what are the company goal the
technical target goal should be adapted,as
long as you are conscious about it
• In the end the quality will come from coming
back to what has been done. It takes one year
to write a piece of code

30. The signs to fire an engineer/consultant
• “We need to redo everything”
• “This is not in my code”
• “We should change to this new library”

31. Product evolution technical impact
• Ways to upgrade between versions. Be
forward and backward compatible
• Have a way to notice that there is
maintenance
• Make a version obsolete with a nice feedback
• Be as much crash prone in your data
technology
From day 1 have in your product

32. Stay manual

33. • You can not go so much faster than the
speed of team
• But you must always try to do it
Team learning can be slow process

34. • Release tool
• Automatic Bug reporting
• Automatic test
• Monitoring and notification of problems
Automation is useful

35. But sometimes keep it manual
• Automation is good only if someone read the
reports
• Understanding what needs automated need
manual try