Random Thoughts On….Product Engineering

For the past 5.5 years, I've been a part of the product engineering leadership at a couple of organizations. While I'm not sure if these ideas translate to client services, I know that they have all been valuable to me as I work long term building products and brands.

  • It's important to periodically reevaluate your tooling and process. Iterating on the process can be just as important as iterating on features. As a team, you are able to take all that you have learned about how you work and try to improve upon it.  It's important to not do this too often though, otherwise, you are spending your time chasing something shiny rather than building something that solves problems. 
  • Users over business requirements. Users over short-term wins. Users over everything. If you aren't building for people, your motivations are wrong and you need to rethink what you are doing. Always think about users. If you are discussing working on anything and no one has asked how it benefits users, ask that question. 
  • Implementors need to have control over either the schedule or the scope of a project. Giving up both leads to burn out and/or low quality work. Implementors mean everyone actively contributing, and not just the engineers. 
  • Design is more important than you think. Design is not done at a specific point. Designers need to be involved in everything. Yes, even the most underhood back-end project. Design thinking is undervalued. I've yet to see it be overvalued.
  • Share your work and ideas internally early and often. Even when they are half-baked or you don't think they are very good. 
  • It's important to understand that what is a high priority for you, isn't always a high priority for the team. That said, every member of the team should have at least one personal priority accomplished on a regular basis.
  • At least once a quarter, you should do a sprint focused on developer experience, refactoring, and bug features. Keeping the code easy to work with shouldn't be forgotten.
  • Do things that don't scale, but make them scale if you keep doing them.
  • There are a lot of things you can optimize for and deciding what you want to optimize for is a challenge. Sometimes you need to optimize for Time To Launch, others you want to optimize to make it easier to iterate on the UI. Figure out what's important on a project by project basis.
  • Don't forget any of Akin's Laws of Spacecraft Design, especially number 1.
  • At the end of the day the rules for success are 1) keep the site up 2) faster is better than slower 3) experiment with everything else

Akin’s Laws of Spacecraft Design Modified for Websites

I have long been a believer that as creators and creatives working on websites, we can learn a lot of other fields.  One that I am constantly looking at for inspiration is spacecraft and astrophysics. Akin's Laws of Spacecraft Design are a collection of axioms collected and maintained by David Akin, a professor at the University of Maryland.  Here they are, lightly edited for websites. 

1. Engineering is done with numbers. Analysis without numbers is only an opinion.

2. To design a website right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong.

3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

5. (Miller's Law) Three points determine a curve.

6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.

8. In adtech, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.

10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.

11. Sometimes, the fastest way to get to the end is to throw everything out and start over.

12. There is never a single right solution. There are always multiple wrong ones, though.

13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

14. (Edison's Law) "Better" is the enemy of "good".

15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.

17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct.

18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your page speed is one nanosecond, you may have invented HTTP/3, but the chances are a lot better that you've screwed up.

20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

21. (Larrabee's Law) Half of everything you hear at meetups and conferences is crap. Education is figuring out which half is which.

22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)

23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

25. (Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along.

26. (Montemerlo's Law) Don't do nuthin' dumb.

27. (Varsi's Law) Schedules only move in one direction.

28. (Ranger's Law) There ain't no such thing as a free launch.

29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new website, learn to draw. Engineers always wind up building the website to look like the initial artist's concept.

31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.

32. (Atkin's Law of Demonstrations) When the website is working perfectly, the really important visitors don't show up.

33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.

35. (de Saint-Exupery's Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

36. Any run-of-the-mill engineer can build a website which is elegant. A good engineer builds systems to be efficient. A great engineer designs them to be effective.

37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.

38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

39. Any feature launch which "just happens" to include a new design is, de facto, a redesign.

39. (alternate formulation) The three keys to keeping a new feature launch affordable and on schedule:
       1)  No new designs.
       2)  No new designs.
       3)  Whatever you do, don't redesign the website.

40. (McBryan's Law) You can't make it better until you make it work.

41. The Internet is a completely unforgiving environment. If you screw up the engineering, somebody loses money (and there's no partial credit because most of the analysis was right…)

Getting Involved and Giving Back As A Beginner – Lisa Yoder – Ela Conf 2016 

“We are all cereal beginners. It’s not to say you are not an expert, but if we are not all trying new things we kind of stagnate and get boring”

I listened to this talk while painting, where I am a beginner and fee like it often.  I makes me want to figure out how to find a community for painting and give back to it.

hat tip to Lauren Pittenger for recommending the Ela Conf talks.

OK, But There Are Two Rules

“OK, but there are two rules:  1. You can’t change the recipe.   2.  You can’t do anything that anyone else has done before.”

With those two options off the table, the only alternative was to invent something completely new, or do nothing at all.  Long story short….the distiller got to thinking, invented an entirely new process at the end of the aging cycle, and now they have a new product, Makers Mark 46.

Read the rest of the Makers mark story: Andy Swan » “OK, but there are two rules…”

Problems aren’t solved best when there are 80 different solutions on the table.  Problems are solved when there are zero solutions on the table. It is why we need to embrace constraint.