The Long Slow Path to E-Commerce

I’ve had Badgly open for about 2 months now.  Traffic is slowly building, but as is typical in Shopify stores bootstrapping themselves and coming from nowhere, I haven’t made a sale, yet.  I’m actually completely fine with that for the moment, since it allows me to understand what is going on before I feel I am risking customers.

My understanding of the who e-commerce growth aspect goes something along the lines of…

  1. Have a product that people want to buy
  2. Have a website that organically ranks for people looking to buy.
  3. Invest in social media to grow a following
  4. Invest in advertising to get more people

That, of course, sounds very simple.  Now particularly with drop shipping, there are many thousands of stores that throw a nice face on a product using stock photography, market the hell out of it and as orders come in pass them off to a wholesaler who does shipping and other logistics.  In theory a nice little opportunity for some relatively passive income.

I’m not in it for that.

Based on some experiences previously, I’m creating pins, badges, and magnets using full color 3d printing, finishing by hand.  These are more or less in direct competition with enamel pins, but I’ll get onto that later.  So let’s pull apart my assumptions above and see where the lead.

So next post… the product…

This is a post that is part of me documenting my experience building the Badgly store.  All the articles are grouped together under the Badgly Category.

Advertisement

Learnings from an Online Store

I’ve recently opened an online store for Pins, Badges, and Magnets using 3D Printing technology.  The store is called Badgly and is at https://badgly.com/ go there, the link to the left has a 10% off discount applied. They are mostly equivalent to Enamel Pins, but don’t have the high upfront costs of creating the die and manufacturing them.

As part of this journey, I’ll be documenting my experiences with Shopify, Adwords and building an online presence.  I’m not going to guarantee that my assumptions will be 100% correct, but I hope that my experiences will help others going through the same process.

All the postings will be under the Badgly category.  Feel free to post comments, corrections or insights below.  Some of these posts will be cross-posted to Badgly, depending on the contents – on use-cases.org, I’ll be a lot more open about the frustrations, machinations, and pain that goes into building an online presence.

Meltdown and Spectre Computer Vulnerability Cubicle Magnets

When something bad happens, like Meltdown or Spectre, or Heartbleed, your engineers end up having late nights,  grueling daily update meetings.  At the end of the day when the dust settles, we don’t get a Service Ribbon that shows your involvement in those days of battle.

With the security industry creating well-recognized brands and logos some of the bigger vulnerabilities, we might have those opportunities to make sure those that join the firefight get the tech equivalent to the service ribbon.

At Badgly, we’ve created some cubicle magnets that allow for a commemoration of those days when you lots lunches, nights and weekends to solve some of your companies biggest and burning issues.  We’ve got a set of Vulnerability badges for Meltdown, Spectre, and Heartbleed.  We’ll update this post with images when they get back from the printers.  Some sample renderings are below.

For geekiness points, all the vulnerability badges will be golden-ratio rectangles.  Is there a vulnerability that you’d like to see memorialized?  Post comments below.

 

 

The Evil Genius of the Amazon Six Page Narrative

One of the leadership tools that Amazon uses internally is the Six Page Narrative. This is where a decision that needs to be made is presented as a narrative document, restricted to six pages, with appendixes. The outcome of the narrative is a go/no-go on the subject. The meetings that discuss the narratives are typically 15 minutes of silent reading/note taking followed by 30-45 minutes of deep dive questions and clarifications. The best possible outcome is 5-10 minutes of discussion and then a “Good narrative, I agree, go do it!”. A bad outcome is “I now have more questions than I started with, let’s stop the meeting now and meet again in two weeks.

The narrative is actually fairly evil in its construction. The six pages and the structure of the document itself are ultimately fairly arbitrary. It is the forced revision/improvement/validation that is forced to fit into six pages that is critical. As many a good orator has mentioned conveying detailed content concisely takes longer to prepare than long form.

The six pages is a hard limit for the narrative (and no, you should drop to 6 point font with 0.25 inch margins, that defeats the point). By forcing a limited set of pages it forces the author (or authors) to go through numerous drafts to reshape the document, polishing it by ejecting, rewriting abstracting and summarizing as you go along. This forces a reasonable taxonomy and structure of information within the subsections and a good ordering of information. This repeated revision to fit takes the mental work that the reader must undertake to correlate and rationalize the information. If the document takes the reader is taken through a clear path where the questions are almost immediately answered, it shows clarity of thought and understanding, increasing confidence in the author far more than a set of bullet points on a powerpoint.

One final part that is overlooked in the six-page structure is the appendixes. The appendixes carry the data, the validation, the information that feeds into the narrative that isn’t needed to support the narrative, but is needed for completeness and cross-reference. You can say “our data supports this information as follows”, the appendix allows the reader to dive deeper into the data to ensure that they would draw the same conclusion, but assuming that the data presented in the narrative can be taken as interpreted correctly, then the narrative can still hold it’s own.

This approach is common when needing to write a concise 1 or 2 paragraph email. You write what you want, re-work, re-work, re-work. Placing a sometimes arbitrary boundary on an output forces a deeper consideration than would otherwise be delivered.

Other Amazonian documents have a similar templated structure that to some extent is inviolable structure. The 1 pager, the working back document, the root cause analysis, all structured to force the presenter to think, structure and organize their thoughts. For communicating business information, I don’t think I’ve seen it necessary to present a Powerpoint for quite some time.

The narrative form still has some risks. To stick with the narrative form, authors are sometimes tempted to inline what is better communicated with tables a) option a – 15, b) option y – 25, c) option z – 10. By its nature, this information is tabular in form. A small structured table can carry a lot more information and take considerable cognitive load away from a reader. The narrative author must balance the use of prose with other information dense methods of presenting information.

What other documents does your organization use to communicate ideas? Are the powerpoint templates still the ruler of your domain?

I’ve also added a deeper dive into part of six page narrative with a discussion of cognitive engagement.

This is a Quora crosspost from this answer. I’m reposting my popular answers here for posterity. Obviously in a different context it has been modified slightly primarily putting context inline

Towards a Skate-Dad (Day 1)

So this Christmas, we bought our 10-year-old a skateboard.  As part of ensuring there is a bit of extra commitment, I’m joining them in learning to skate.  So let’s put it into context here…  43 years old, 225 lbs, mostly sedentary lifestyle tech geek…  so that probably paints the picture.

So why am I doing learning to skateboard?  The first part is to do the whole role model thing.  I have reasonably high expectations for my kids to be resilient through adversity, to put in the time to practice to get good at things.  If I expect them to get up after hitting the pavement, I can expect them to…  They are a hell of a lot less fragile than I am and should be able to get up and move after a fall that would wipe me out.  I’m also doing this as part of a general effort to get fit and ensure that can learn new physical skills.

What’s my end point?  Realistically, I currently have little interest in doing tricks, I’ll probably declare personal victory when I can push, tic-tac and pump on a half pipe and turn…  We’ll see how much further it goes from there.

This part of this blog will give periodic updates on my quest to get to the endpoint.   Today is day 1…  My kit is an 8.5″ board, 54mm wheels, from the local Skateworks shop.  I’m a bit of an analytical geek, so I’ll also be writing up some of my thoughts, most likely ill-founded, for others to pick on.

So Day 1…  Practicing pushing, very simple tic-tacs… Becoming kind of comfortable.  Of course, day 1 something has to happen.  If my memory serves me right, my front foot wasn’t in the right spot, I tried to do a push, and it all went downhill from there.  I ended up rolling my left ankle and landing on my right hip.  No bruising on the hip, but the ankle is now strapped.   We’ll see how the healing goes, but I’m eager to help the kids out on the park again before the new year break finishes.

Fortunately, or maybe not so, fortunately, it took a few hours before the pain from the rolled ankle to kick in, so I got about another hour of practice at the skatepark.

ng-Whatever

We’ve all done it, sat around a table dissing the previous generation of our product.  The previous set of engineers had no idea, made some stupid fundamental mistakes that we obviously wouldn’t have made.  They suck, we’re awesome.  You know what, in 3 or 5 years time, the next generation of stewards of the system you are creating or replacing now will be saying the same thing – of you are your awesome system that you are slaving over now.

So what changes?  Is the previous generation always wrong?  Are they always buffoons who had no idea about how to write software.  Unlikely.  They were just like you at a different time, with a different set of contexts and a different set of immediate requirements and priorities.

Understanding Context

The context that a system is created is the first critical ingredient for a system. Look to understand the priorities, the tradeoffs and the decisions that had to be made when the system was first created.  Were there constraints that you no longer have in place, were they restricted by infrastructure, memory, performance?  Were there other criteria that were driving success at that stage, was it ship the product, manage technical debt or were there gaps in the organization that were being made up for?  What was the preferred type of system back then?

Understanding these items allow you to empathize with system creator and understand some of the shortcuts they may have made.  Most engineers will attempt to do their best based on their understanding of the requirements, their competing priorities and their understanding of the best systems that can be implemented in the time given.  Almost every one of these constraints forces some level of shortcut to be taken in the delivering of a system.

Seek first to understand the context before making the decision that the previous team made mistakes.  When you hear yourself making comments about a previous team, a peer team or other group not doing things in the way that you would like to see it, look for the possible reasons.  I’ve seen junior teams making rookie mistakes, teams focused on backend architectures making front-end mistakes, device teams making simple mistakes in back-end systems.   In each of these contexts, it is fairly obvious why the mistakes would be made.  Usually, it will be within your power to identify the shortcoming, determine a possible root cause by understanding the context and shore up the effort or the team to help smooth things over and result in a better outcome.

Constraining Your ng-Whatever

When faced with frustration on a previous system, consider carefully a full re-write into a ng-whatever system, or incremental changes with some fundamental breakpoints that evolve, refactor and replace parts of the system.

It is almost guaranteed that the moment a system gets a “ng-Whatever” moniker attached to it, it becomes a panacea for all things wrong with the old system and begins to accrete not only the glorious fixes for the old system, it will also pick up a persona of its own.   This persona will appear as “When we get the ng-whatever done, we won’t have this problem..”.

These oversized expectations begin to add more and more implicit requirements to the system.  Very few of these will be expectations will be actually fulfilled, leaving a perception of a less valuable ng-Whatever.

Common Defect Density

I’m going to come out and say that most engineering teams, no matter how much of a “Illusory Superiority” bias they may have are going to be at best incrementally better than the previous team.  With that said, their likelihood to have defects in their requirements, design or implementation will be more or less even (depending on how the software is being written this time around).

The impact will typically be that the business will be trading a piece of potentially battle hardened software with known intractable deficiences, with a new piece of software that will both have bugs that will be only be ironed out in the face of production.  Even worse, there will always be a set of intractable deficiencies that are now unknown – only to be discovered when the new software is in production.

When the original system was created, it is highly unlikely that the engineering team baked in a set of annoying deficiencies.  Likewise, the new system will, to the best of your teams understanding,  not baking any deficiencies into the system.  You need to make a conscious decision to take the risk that the new issues will be less painful than the old issues are.  If you can’t make that call, then sometimes refactoring and re-working parts of the system might be a better solution.

 

What have your experiences been with ng-Whatevers?  Have you found that your team can reliably replace an older system with a new system, and see that in a few years time the new system is held with a higher level of esteem than the original system?  Follow this blog for more posts, or post comments below on this topic.

 

Planner Printable – Monthly Habit Tracker

One of my ongoing demons that I have always had to deal with is consistency in some tasks.  Making consistent behaviors and habits is something that I have managed to make through most of my life in someways by the skin of my teeth – well maybe not that dramatic, but I generally do well under pressure and so procrastination works well for my type of personality where the time pressure focuses me.    However, not avoiding the pressure comes from habits and predictability, and that is what this planner printable is intended to do.

This particular printable is a monthly habit tracker.  The intent is to manage consistency and provide incrementable improvements over months.  The main intent is to focus on a baseline habit with a bit of consistency, and then improve/balance over subsequent months.

Monthly Habit Tracker

To use this printable, name your tasks and your target (either per week or per month).  Each of up to 31 days is included so you can mark off your task completion on a daily basis.  At the end of the month, you can compare your target against your total.  Your next month should ideally be modified by your relative success in delivering a particular frequency of the habit.

I find this structure useful because it will keep items that I need to do visible, and will allow me to see what different habits go well together, ideally simplifying the habits in to habit clusters.

Here is a PDF printable for A5 planners (or half Letter) – Monthly Habit Tracker.

Do you have any habit trackers that work for you, try this one out and provide suggestions on how this tracker can be improved.

Planner Printable – Full Year Calendar

As part of my new series of planner printables, I’m going through my set of custom planner pages that have worked for me, and some that haven’t worked too well.  All these planners are designed to fit into either a half letter/statement/memo or an A5 planner.  I personally use an A5 planner, and so these printables can be cut at the 5 1/2″ point.

This printable is a full year calendar, aligned for weekdays.  This is designed to be inserted landscape in the planner, allowing easy lookup of where days in the calendar sit.

Screen Shot 2017-12-27 at 12.07.52 AM

Here is a downloadable printable (Full Year Calendar) targetted for Letter only, please email for A5 size.  Once print, you should be able to cut the page in half, add your hole punches and enjoy.

What printables are your favorites, any tweaks or changes you’d recommend to this one?

Moving to a Planner

Part of my 2016 ‘make myself better’ effort involved using a planner.  There were a few reasons for an attempt to move back to pen and paper.  It’s been over 18 months since I started with a Planner, and now is a time to share the pages I’ve created and the give an update on what works for me.

71v5zzy2brgl-_sl1500_61fo80ljkfl-_sl1500_The first planner I purchased was a relatively cheap import from Amazon.  Even though it was a relatively cheaply made planner, its leatherette feel was okay, and it has stood up to 18 months of regular use fairly well. For a pen for the planner, after playing with a few cheaper pens, I went for the (moderately) more expensive Cross Tech 3+. This is a nice two color (red/black) pen, with a mechanical pencil and a touch screen top.  I’ve never had an issue with the pen and it holds really nicely.

For 2018, I’ve splurged on a Filofax Finsbury planner81qldvqlmyl-_sl1500_.  This will allow me to split my day job from my personal/side projects into a different planner.  I’ll still take both with me to work, but I’ll be able to pull out the appropriate one when needed.  My first opinion on the Filofax Finsbury is that the pockets are nearly not as functional (pockets, etc) as my first cheap one.  Since it is real leather, it will likely soften and become more convenient.

The form factor that I have a strong preference for is the A5 size.  A5 (5.8 x 8.3 in) is almost the same size as Half Letter/Statement/Memo (5.5 x 8.5 in).  So it allows me to use either formal A5 or generate cut a letter page in half.  This has opened up a range of custom options that for generating pages.  In coming posts, I’ll be highlighting those pages and making them available.

Onboarding, Technical Debt and The Future Self

Any organizational leader is always challenged by the ability to quickly get new engineers active and effective as they join the company.  This is commonly called “onboarding”.  Common approaches include

  • Boot Camps similar to Facebook,
  • Intern style mini-projects
  • The dreaded fix-a-few-bugs in the first week
  •  The sink or swim, here is your desk, hit the ground running

All of these approaches (except the last one) attempt to

  • Familiarize a developer with the code base
  • Do generally low-risk changes and get the code into mainline or production
  • Start to understand the systems and tools that the team uses

Generally, the stated intent of on-boarding an engineer is to bring them up to speed and be productive.  In this post, I’d like to turn this on it’s head and ask the industry to not look at the onboarding process as a way to get an engineer started, but rather a way that the existing engineering team showcases the code, the architecture, the behavioral norms and the vibe of the engineering team.

I’ll lean on the analogy of an rich elderly aunt visiting from out of town throughout this post.  The onboarding process is like that awkward first few minutes where you walk through the house showing the washroom, kitchen, where they are sleeping and other items that are needed to make the stay welcoming.  However that five minute tour is usually at the end of a few days of frantic cleaning, scrubbing, removing trash, setting rules for how the kids should act, and so on.  After all your familial reputation is on the line here.  Who want’s an awkward Thanksgiving or Christmas where there are the little comments, the glances and whispering from the aunt who has formed her opinion of  how you operate as a family.

When a new engineer arrives at a company, the deepest scrubbing we usually do is to make sure their desk is clean and the computer is there.  It leads to an awkward recruiting moments when the reputation of the company is passed on to other engineers as the new engineer is asked ‘How’s the new Job’.  In the same way the elderly aunt is associated, but not vested with you. So is the the new employee who hasn’t quite felt part of the team.

Inverting Onboarding

Turning the onboarding process on it’s head also has some material impact on the way the engineering team see’s itself.   When you have a visiting relative, you want to show that you are a the good part of the family, and have your things in order.  Use the onboarding experience as a way to ensure that the team presents a real demonstration of how the team is awesome.  You can’t fake awesome for very long.

Make your leaders of the organization accountable for how the team is presented to the new hire.  Make those leaders ensure that the 2-4 week honeymoon period for the new hire sets the basis for a long term relationship.    The discussion shouldn’t be whether an engineer is now productive for the company, it should be whether the company has made an engineer productive.

That inversion goes a long way to extend that honeymoon from a few weeks to a few year.  That inversion helps engender an organization that fosters growth and development during an engineer’s tenure.  That inversion changes the way the organizational leaders look at how they run the organization.

Make Your Leaders Accountable for Onboarding

The critical part of this inverted view of onboarding is making the leaders of your engineering team responsible and accountable for the onboarding of the engineering team.  Some indicators of issues to consider when examining the onboarding  process.

  • Can the new engineer checkout and build with no major hiccups?  Typically there is a verbal tradition that carries engineers from the written references to being productive.  (“Oh yeah, you need to this or that, we should update that”).
  • Does the new engineer need to talk to other engineers for a basic bootstrap of their environment?
  • Does the new engineer need things explained on a whiteboard?

Realistically, the new engineer doesn’t have the ability to influence how quickly they come up to speed.  There will be an intrinsic ability that the new hire carries, but the largest influence of how the new hire onboards is carried by the organization.

By making the hiring manager and their lead engineers responsible for the effectiveness of the new engineer, it forces introspection on the team about how they manage their development how much of the way the team operates is transparent, captured, and communicable and how much is opaque and a form of verbal tradition.

Some measures that I push my teams to meet for a new dev are:

  • After the initial orientation and first login, be able to sync the code and start a build within 1 hour.  (This forces the hiring manager to ensure the permission groups, environments and access is all done before the hire starts.)
  • Have the engineer be involved in a code review within the first day, but before their first change. (This sets the bar for how the code reviews operate and the expected conduct for the engineers on the team).
  • Have a problem or proving task able to be resolved and pushed to a staging environment, device, into a build within the first day. (This drives an understanding of the way the development goes from the developer to production).
  • Have a debrief after the first day and the first week about the questions, points of confusion, suggestions and best practices that the new hire misses.  (This helps drive introspection for the team for the next round of hires).

Equivalence to Technical Debt

A lot of these negative indicators and the difficulty in achieving the measures are driven by the technical debt that an organization is carrying either consciously or subconsciously.  Finding opportunities to spot the technical debt that is causing friction within an organization are golden.

Technical debt in a development team is most visible to a new hire.  They walk headlong into it with open eyes and an inquiring mind.

Helping the Future Self

The future self concept covers the lack of familiarity that an engineer will have with some code or a system that you are currently working at some point in the future when you need to go back to it.  Over time, poorly written code – even written by yourself, becomes that code written by the clueless engineer a few years back.

Technical debt is usually correlated with old crappy code.  However while the engineers are writing the code, there is not the assumption that the code that is going in is crappy.

A new engineer being onboarded to a new system is in exactly the same place that a future self or a new transfer into the team will be seeing.    They don’t have the history and so it will always be more jarring to them.  Future selves and new transfers will have enough history that they will orient themselves back to familiarity very quickly.  Warts and all.

Learn From the New Engineer’s Honeymoon Period

Engineering leaders, should look closely at the questions, feedback, and interactions that a new hire has with their new code, systems, and team.  They don’t have the history or familiarity with the code that helps them skip the opaque or confusing bits of how you do development.  This will help not only with onboarding new hires, but also the engineer’s future selves, and people switching into the team.

Those first few weeks of a new engineer are extremely valuable, use it as a barometer for how effectively the team is managing technical debt and creating maintainable code and systems.

Don’t squander those first few weeks.  Also, keep your house in a state that your elderly aunt would like.

As always, vehemently opposed positions are encouraged in the comments, you can also connect with me on twitter @tippettm, connect with me on LinkedIn via matthewtippett, and finally +Matthew Tippett on google+.  You can also follow me on Quora, or simply follow this blog.

%d bloggers like this: