Here's a contrarian opinion, but when practicing product development, I don't think you should be using requirements documents at all.
This may provoke a reaction and you may be asking, "But how will your align a team, prevent miscommunication, and work to a common understanding?"
I'm not advocating for a lack of documentation (although I prefer to keep things light), but I am advocating that you use the term "feature specification" instead of "requirements".
The reason why, is that "requirements" carries a strong connotation to it, that if you meet the requirements, you'll have done a good job. This may be fair if you're working to a contract, but in product development, the goal should be product success, not contract fulfillment. There's a term used to illustrate the point, called "achieving failure". It's when you build everything, exactly as intended, and it turns out to be a giant flop. The "requirements" may have been met, but it's not what the market or the customer wanted or needed at all.
That's why I prefer the term "feature spec". It's what you're agreeing to build. Hopefully, nobody's requiring you to do anything and you're here of your own free will.
To dive a little deeper, my mental model associates "requirements" with a traditional waterfall development model: requirements --> design --> implementation --> test / integration --> deployment.
I far prefer a "discovery/delivery" model of development that starts with a problem. Then the team, through a process of exploration and lightweight testing, figures out what features they bet will solve the problem. So I'm not opposed to documentation along the way, I just prefer to use terms like "problem framing", or "one pager", or "one paragraph description of what you're trying to do that even the sales team could understand", and then collaboratively figure out what we need to do to arrive at a feature spec.
The "figuring it out" portion is where you use UX mocks, prototypes, simulations, and all sorts of other tools to try to reduce risk in what you're going to build, before making a feature spec that will commit serious engineering resources.
And yes, for my readers who are hardware engineers, there is a heavy bias to an Agile style of software development in what I just wrote. For a lot of hardware, the "figuring out the features" portion of the project has to be done early, in the prototyping phase, and you get fewer chances to tinker and explore. Hardware bets are a little bigger. "Hardware is hard" is the saying.
So the next time you find yourself using the term "requirements", take a step back, and ask if that's what you really mean. Feature spec is much friendlier.
cheers!
Sam
aka THE Awkward Engineer
p.s. I have no objection to the terms "regulatory requirements" or "legal requirements". Those really are requirements :-).
]]>Today's post is a bit on the nerdy side, but with the dry winter air in New England, I'm reminded of some old on-the-job training I received on electrostatic discharge. (ESD)
ESD is the fancy word for the zap of static electricity you may get when you walk across a carpet and touch a metal doorknob.
Most of the on-the-job training was about how to prevent it. It's very easy to build up a charge of several hundred volts, just walking around a carpeted room, and an actual zap of static electricity is in the low thousands of volts, enough to ionize the air. The current, and hence the total power, is relatively low, but it can easily damage some electronic components.
The typical strategy for prevention is to use special clothing, desk and flooring materials, shoe covers, and grounding straps to dissipate electrical charges. Rather than building up and rapidly discharging, the charge slowly bleeds through the material until the electric potential has equalized.
One team in the lab was working with some unusually sensitive components and the typical strategies weren't enough. They developed a procedure where two assembly technicians would need to connect wrist straps and shake hands in a particular sequence to equalize electrical potentials prior to passing physical parts or tools between them. They called it the "grounding dance".
Fast forward many years later, and one day, after kissing my wife and giving her a resounding electrical shock on the lips, I told her about the grounding procedure.
So if you ever see us get in the car together, lean in for a kiss, then abruptly pause, you'll know what we're doing. The next step is to paw at the air until our hands meet and then proceed once the electrical potential has equalized. It's the grounding dance.
best regards,
Sam Feller
aka THE Awkward Engineer
Short post today. I want to introduce a term I call "buyer's delight".
Buyer's delight is simply the opposite of buyer's remorse.
I find I tend to agonize over purchase decisions, think carefully before I buy something, and sometimes deliberately wait several months to see if I still really want a thing before deciding to get it.
So buyer's delight is the payoff when you repeatedly use a thing and continue to get satisfaction out of it. Buyer's delight is more than just satisfaction though, it's actually a little smile that I make to myself.
I find that buyer's delight occurs for me mostly with kitchen items, one particular pair of slippers that keeps me cozy, and a few select articles of winter clothing...
I hope the term helps you take a moment and enjoy the little things.
best regards,
Sam
aka THE Awkward Engineer
In a previous post, I wrote about how my best ideas were often killed in their nascent state. Typically, I'll brief the chairperson of my executive advisory board, who then uses the awesome power of their seat to issue what can only be described as the "spousal veto." Thus, the idea is nixed.
Necessity, as ever, remains the mother of invention, and I continue to generate ideas. I won't go as far as to say that it's the slings and arrows of outrageous fortune that I'm taking arms against, but they're at the very least... inconveniences, where I find inspiration.
Here are some of the more recent ideas to encounter the spousal veto.
The television remote seems to mysteriously disappear from time to time. Fortunately, the the world of assembly line ergonomics and efficiency has the perfect solution to keeping tools just within arms reach, and yet, out of the way when not needed.
The Tool Balancer is a spring loaded, retractable device, used for suspending a tool from an overhead position, where it's easy to grab when needed, yet doesn't take up space on the work area.
My idea was to hang the remote from the ceiling, right within arms reach of the couch. Voila! No more lost remote! Unfortunately, this one didn't make it past review with the executive advisory board.
Pill a day boxes use a great combination of visual reminder / status and prep work to help stay on top of medical regimens. I thought the technology could be repurposed and applied to a daily flossing routine.
With small hooks to hang the floss for each day of the week, every SMTWHFS would show whether you'd flossed or not. Naturally, you'd hang it from suction cups, adhered to the bathroom mirror.
This one received a "hard no" in committee review.
I really like cats and dogs. This also received a spousal veto.
I really like ice cream. It turns out, commercial grade soft serve ice cream machines can be purchased at the low end of the market for under $1200. That's not an impulse purchase for me, but I've definitely thought more than once about it. I've also thought about running an extension cord from the driveway to the street and just making people around the neighborhood happy.
This isn't a hard no, but the spousal veto isn't getting lifted until I find a space for a new appliance with a 20" x 30" footprint.
We needed some new décor for the office video call backdrop, but veto power was invoked instantly on this one. Never had a chance to bring it home.
best regards
Sam Feller
aka THE Awkward Engineer
Today's post shares some management ideas I'd like to try (if only anyone would let me). I don't have any pressing needs or problems which would drives impetus for change, but I'm curious if these ideas reflect better ways of working.
I'm not talking about a compressed work week, with 40 hours in 4 days, I'm talking about a true, 4 day work week. The upsides for workers are obvious (more free time!), but would productivity really go up? I'm not sure, or even how productivity for knowledge workers can be precisely measured.
I know that personally, my brain is never really "off", and that extra time is really spent processing ideas in the back of my head. I've often said that my most productive time (in terms of value creation), is when I go for a regular daily walk and do nothing except let my mind wonder. I'll also compose the outlines and entire paragraphs of my blog posts before sitting down to write while on my walks, so in a way, it's like I have "processing" modes and "execution" modes.
I'd be willing to believe that the extra day and free time would improve the quality of the mind wondering/pondering/processing modes, which would make the 4 days of "execution" mode more productive. I think this could work for me and I'd love to be in a place that's willing to try.
Pair programming is the practice of two software engineers sitting together (physically or remotely) working on the same piece of code. I'm told it takes a little while to get used to, with "driver" and "passenger" roles. I've also heard that it's excellent for junior engineers to get mentorship from senior engineers. Other benefits include improved knowledge of the code base.
What's wild to me, is that placing 2 engineers on the same piece of code doesn't cut productivity in half, and in some places, actually increases productivity. This is because reviews go faster, code is higher quality, and less likely to have bugs.
I also think there's a psychological effect going on, that working in a pair like this makes it easier to focus and stay on task. This is jan effect exploited by "work with me" youtube channels, livestreams, and organizations like Caveday.
I've also heard that the focus and social interaction of pair programming can be exhausting, senior engineers don't benefit from being paired with other senior engineers, and of course, it can be affected by interpersonal dynamics, and the idea can be an uphill sell and take some getting used to.
I've also heard you can get a lot of the benefits (mentorship, shared knowledge) from pairing for only a couple hours per week, and I'd be really curious to see it tried outside of software development, for example, with mechanical CAD modeling, or electrical schematic capture.
I've ranted about email (a to-do list made by other people) before and the importance of deep work. In short, the idea is that while email is easy to send, it places a burden on the receiver. It creates a sort of locally optimal, globally suboptimal behavior. You may think that dashing off an email, or quickly pinging someone for an answer on chat improves productivity if you're stuck waiting for an answer, but globally, it means everyone gets interrupted all the time.
Now personally, I don't mind the chit chat of Slack, and I've done some reflecting on why.
This is where I've landed
So in my view, there should either be short chat messages, or longer documents that exist outside email, where collaborative written editing/commenting/discussion is possible. So I'd like to try working at a place that in practice no longer uses email for any internal communications.
But what if we really did want to abolish chat? It means that people couldn't get answers right away, which is locally sub-optimal, but it would encourage lots of deep work.
In my experience, most things can wait half a day, or a day, and you can find something else to do while waiting for an answer.
To avoid email or chat, I'd have scheduled synchronous working time. This is slightly different than a daily standup, or a meeting. In some of the earlier hyper-growth days of Youtube, and then at Coda, they have a practice to do this called "Bullpen". The idea is that for about an hour, you have to be available and sitting on a video call (or in person). So if someone needs you, or a serendipitous conversation or group starts to form in a breakout session, they can get you right away if needed. If you're not needed, you still need to be there, but you're allowed to work on your own stuff.
This preserves deep work time, eliminates the need for chat (if you can wait a day for an answer), encourages some spontaneity and serendipity, and precludes the need to coordinate meeting schedules, because Bullpen time is universal across everyone's schedule. Again, I have no first hand experience with this, but I'd sure like to try.
Shape Up is an alternative to more typical Scrum/Kanban processes. The idea is that people are better at budgeting and shaping/scoping what can fit in a 6 week time chunk, than estimating how long a given, well defined piece of work will take. Ideas are shaped at a "fat sharpie" level of resolution, which means you can't get too into the details. Then, a small team of 2-3 designer/engineers are given free reign to execute on the idea in the 6 week window.
Supposedly, there's a lot less time spent defining the work, the individual contributors experience a lot less micromanagement and are given more creative freedom, and it's less stressful, overall. Definitely sounds worth trying, to me.
Anyway, these ideas are in the realm of "hmmm... that sounds interesting" for me right now. If you've had experience with them, I'd love to hear about it!
best regards
Sam Feller
Today's post is an update to my cooking cheat sheet. This revision was inspired by a colleague, who told me she had a list of 40 or 50 meals she could cook. The idea was that she could pick from the list when she needed inspiration for dinner and she could go at least a month or so without repeating herself.
The first page is mostly notes and techniques from the previous version, the second and third pages are generally organized by heat source and cooking vessel, whether it's a pan, pot, instant pot, oven, etc.
Maybe it's the engineer in me, but I definitely enjoy my cooking gadgets.
Again, it's a cheat sheet, and notes that I can follow, but the full pdf is available here.
And yes, this may be a ploy to send your favorite recipes.
best regards!
Sam
aka THE Awkward Engineer
]]>
Hi all!
Today's post is seeking like minded Gmail/Hacker News/NY Times readers (3 of my top 4 most frequented websites. I'm still working on Reddit.) that are willing to test my Chrome extension.
For those following along at home, ever since I came back from an off the grid vacation, I've been really interested in tools to limit / manage my internet usage. The Chrome extension I made is testing a theory that eliminating the "variable reward" of internet use will make it easier to manage.
In short, the Chrome extension makes it so that I can visit Gmail, Hacker News, and the NY Times as often as I like, but when I do, there's nothing new there. It limits updates to once a day.
I'm experimenting on myself and so therefore incredibly biased, but I think it's helping me. The biggest change I've observed was an old habit of leaving items as "to-do's" in my inbox, checking Gmail out of boredom, then realizing it was the perfect time to do the "to-do's" and then actually getting to inbox zero. Which was satisfying.
If you'd like to try the extension, click here!
best regards
Sam Feller
aka THE Awkward Engineer
Today's post is about an estimation technique that I like. I'm not sure this particularly variation has a name, so I'll call it Wideband Delphi with bounded estimates. It uses some "Planning Poker" style wisdom of the crowds techniques to estimate both the "likely" and "pessimistic" durations for an activity. In practice, I find that it's fast, engineers are comfortable with it, and the bounded estimates that it generates lead to good discussions over the nature of schedule risk. (And the estimates, in my limited, anecdotal experience, have been pretty good.) I'll share up front how to put it in to practice, then talk about why it works.
Here's how the process works.
And that's it! I've found that groups can converge quite quickly, even on difficult questions. For example, I've seen teams estimate things like Linux kernel updates, where they all agree that the likely case is 1-2 weeks, but even if things go very, very, wrong, it won't be worse than 8 weeks. And that's just on the first round of estimation.
The power of this technique comes from chaining together multiple estimates and developing an understanding of the uncertainty in a project, which in turn leads to discussions of how to drive that uncertainty out. Those conversations are incredibly important for stakeholder management.
Of course, sometimes people like having hard dates, but this can help pick that hard date with an understanding of where you are between the low and high bound estimates. Pushing for an earlier date comes with the risk of outright slipping it, or needing to put in a lot of extra hours to make it happen. But now you can make some of those risk based decisions up front, with a data informed discussion, rather than arbitrary "gut feel".
I think one of the reasons this works so well, is that Notoriously Squirrely Engineers are much more comfortable providing likely and pessimistic estimates than giving a single hard number. There are strange incentives when putting together single number estimates, either to pad the date to create wiggle room, or to lowball it to make a particular path look easier and less costly.
The real world is much messier than "how long will this take", and the bounded estimate creates room for that, while also acknowledging the practicality of needing dates to be able to make good decisions and track progress.
I think the best model to capture that messiness is called the log-normal distribution. Most people have heard of the bell curve. Well, if you do some math, take the logarithm of the bell curve (or the normal distribution), you get the log-normal distribution. What's neat, is that on the left side, it's bounded to zero, which corresponds well to real world events that can't happen faster than no time at all. In the middle is the "likely" case, and towards the right is the long tail of things that seemingly come out of nowhere and take forever.
Physical things like trip durations, height/weight distributions, and yes, task durations, tend to fit a log-normal curve better than a bell curve.
The idea here is to try and capture the 50th percentile "likely" case, and the 90th percentile "pessimistic" case with the two estimate bounds. You don't need to capture it perfectly, you just need to get close enough to have an informed discussion.
I'll be repeating internet myths if I explain exactly how the Oracle of Delphi technique was first developed, but the idea is that the averaged wisdom of the crowds tends to be more accurate than any one individual. The Planning Poker style of simultaneously revealing estimates allows for quick estimation without letting any one individual bias the crowd ahead of time.
Even when final dates haven't been important, I've found Planning Poker and estimation valuable for driving out misunderstanding when two estimators wildly diverge, i.e. "what do you mean, that's an 8, i thought that was a 2?" - "well, you said it needed feature Z, if we only did X and Y, then yeah, it's a 2" - "oh, I didn't know Z was that hard, let's scrap it, then."
I won't get too in depth in this blog post, but there are Critical Chain planning techniques that use the low bound estimates to create a schedule, then use the high bound estimates to create a buffer. The schedule tends to always slip, which is expected, because it's built against the "things going well" likely estimates. What's cool, is that if you use too much schedule buffer too soon, it creates an early signal if the project is running late, which tends to eliminate "we'll make it up later" mentalities.
Calculating what the buffer should be and how the "pessimistic" cases blend together (after all, not everything will go wrong), is the next level of applying this technique. If you're really fancy, you can do some monte carlo simulation, or if you're less fancy, like me, you can use root sum of squares (RSS). Again, the idea here is to drive good discussions.
There are a few proprietary software packages used by consultants that do this sort of modeling, I've made do with spreadsheets for the calculations and sort of hacked together more common tools like Jira/Asana/ClickUp etc... using the low bound estimates, sliding the schedule manually when slip happens, and keeping a placeholder buffer that doesn't move as a separate line item. I don't know why these tools aren't built into current products... maybe they're more common to manufacturing operations and less well known, or maybe they're just too complicated to add.
That's all for today!
Best regards
Sam Feller
aka THE Awkward Engineer
In my previous post, I shared some of the things I've learned talking to people about their struggles with internet and phone use. In this post, I'll share how I think about the problem and why things like Apple Screentime limits fail. Rather than blocking or limiting access to the internet, my idea is to modify websites/apps so that they are less rewarding, which will make it easier for me to control my usage to a more reasonable level.
I think it's fairly common knowledge at this point that phone apps are designed to get you addicted. App makers might not use that word, but when you see book titles like Hooked: How to Build Habit-Forming Products, you know it's true.
I'm a big fan of Atomic Habits, who uses a model of cue --> craving --> action --> reward. The faster and more frequently you get around the loop, and the more satisfying the reward, the stronger the habit becomes. Phones are a perfect storm for this. The cue (app notification? moment of boredom? ) leads to a desire to open the app, which leads to taking the phone out, which leads to stimulation from use. It is so fast and so easy. Especially if the thing lives in your pocket.
Strategies for reinforcing or breaking habits involve adding/removing friction. For me, for example, physically seeing an iPad makes me want to browse the internet, so putting the device away is my strategy. (Which fails if my kid leaves it out after playing or watching something. It's a slippery slope. )
I still think deleting or eliminating apps and devices is the best outright method (seriously, people, just delete TikTok), but if you can't or won't, the technology limitation strategies used by Apple Screentime, Android Digital Wellness, Chrome plugins, and others all work using a similar mechanism. They attack the gap between having a craving and actual use. Sometimes it's a 10 second delay before opening the app, sometimes it daily budget or time limit.
Installing these apps, or turning on Screentime, is very easy. But so is turning it off.
So while the blocking and limiting strategies do work for some people, most people, myself included, often have a moment of weakness, disable the blocker, and they're back to where they started.
I mentioned earlier that my idea was to attack the "reward" portion of the loop. It turns out that variable rewards are much more stimulating than consistent rewards, which makes sense. (Search for BF Skinner and his experiments with lab mice.) I mean, consistency is boring, but the possibility of occasionally hitting a jackpot is exciting.
This is another way that email/internet/phone apps are just a perfect storm of stimulation. Every time you're on it, there's potentially something new, exciting, and cool, and you're never quite sure exactly what will be there when you open it up. It's a random stimulus, available on short notice. Of course people struggle to manage it.
So in my instance, with email, my idea isn't to block it or restrict access to email, but rather, to limit the stimulation from checking it.
I need email, personally, professionally, for bills, etc... but I don't need to check it 7 times a day and get a little does of stimulation and newness every time I do. So my idea is to limit delivery of my email to once a day. I can check it as often as I want, but there just won't be anything new there.
My theory is that over time, my brain will learn that email isn't so stimulating, the compulsive checking will stop, and I'll just check it once a day, which seems alright with me. And because I won't hit a jarring or unnatural time limit or wall, this should be gentle, and won't tempt me to disable the blocker.
I thought this would involve all sorts of tinkering and hacking (with ChatGPT!) and mucking about with Gmail's API. Turns out, there's a simpler workaround. Gmail has a search feature that filters by date.
I wrote a Chrome browser plugin that detects when I go to gmail, then redirects me, also to gmail, but with query parameters that only show email from before midnight on the current day. So effectively, my email is being delivered once a day. If there's an urgent message, like a password reset (which I know to look for), I can just search directly for it.
This is very nearly what I want, except if I click on the inbox link, the inbox flickers on the screen for a split second before the url redirect kicks in. I'm pretty sure I can fix that with a little more tinkering. I'll keep you posted!
best regards,
Sam
aka THE AwkwardEngineer
This post is about developing my UX research skills and how I've practiced those skills to learn about internet/phone addiction. In short, I'm blown away by the things people will tell you if you just ask them the right way. (Although Asking the Right Questions has maybe been a theme for me.)
I'll talk about past mistakes, my current model for interviewing, and some insights shared from these interviews. The punchline: people have deeply personal motivations for changing their behavior, often triggered by some sort of life event (birthday causing reflection, a breakup, death of a relative). Their specific habit is different (YouTube, TikTok, email, video games, Insta), but there are common themes.
I've been working to develop my UX research skills, ever since finding out (the hard way) that I'd heavily biased my research when I was working on Interrobang. Oddly enough, being able to bias people that way is a great sales skill, but when you're trying to do research, it leads you to fall in love with your own ideas and just reinforces confirmation bias. After all, look at all these people who agree with you!
The mistake I made with Interrobang was to ask forward looking and opinion based questions when I was talking to users. I've learned from The Mom Test and other books that there is real data in past behavior and real data in live reactions. (There is also real evidence in people actually paying and using for things, but the whole point of good research is to figure out what those things will be prior to actually spending the time to build them. Even if you don't nail it, good research will at least move you in a better direction where you can build less, learn, and iterate.)
So if you ask a question like "Would you use this?" or "Do you like this?", human nature just makes it very unlikely to get a valid answer. In the worst case situation, which I learned the hard way, they'll say "of course I want this" and you'll run off thinking you already have a win.
So for a super quick, basic interview, you'll ask a question like "how often do you..." or "when's the last time you...?". I asked a few people, "when's the last time you tried to manage your internet/phone use" and people would say they tried the Screentime setting on their iPhone, got frustrated with it after a little while, just turned it off, and they were back to where they were. That's the whole interview and it takes maybe 2 minutes or less.
I'm a big fan of "jobs-to-be-done" theory. There are a lot of people developing the concept, and you'll see different definitions and approaches, but they all sort of revolve around the idea that people are trying to do things, and they'll "hire" whatever product helps them get the job done best. It's hard to design a product to do the job best without knowing what the job is, and understanding and characterizing that job is the goal of the research.
The specific technique I'm trying for deeper interviewing is something called the "switch interview." The idea is to recreate the timeline of events (all past behaviors!) around a customer action. What happened when they "hired" a different product to do a "job"? And why did they swtich? I'm still asking about the last time they took steps to manage their internet/phone use, but I'm going a lot deeper, and asking for more detail. I'm also asking what lead to slipping back to their bad habits.
Now, most people haven't formed a neat little linear narrative of what happened, so much of the interview is asking for specifics. There are all sorts of techniques to get people to build up these timelines, like asking them to move sticky notes, having them draw it, intentionally misstating things so they'll correct you, etc...
As I'm building up these narrative timelines, I'm looking and listening for four things: 1) the "push" that's causing them to take action 2) the "pull" that's telling them which action to take 3) "friction" that makes it hard to do something new, and 4) "inertia" that makes it hard to stop something old. This will reveal a lot of information about what's important to them in getting their "job" done.
Putting this into practice is as fast and easy as getting coffee in the morning. I printed up an 8.5" x 11" sheet of paper that said "Have you tried to manage your internet/phone use? I'll buy you coffee to talk to me about it for 30min." and then I went and I got coffee. It doesn't take long at all to find someone, and usually they decline the offer to pay.
Here's an example from one session: Interviewee is a documentary film maker. She had sought out an ADHD therapist/coach the day before (note: evidence of willingness to pay to solve a problem.) We refocused the interview on the previous incident of behavior. She'd been struggling with focusing to hit a client deadline (that's the push!), and installed chrome plug-ins on her laptop and used Screentime on her iPhone to block Youtube. (that's the pull, it's not hard to know about or be aware of these tools. In the case of the iPhone, they're built in already. Chrome install and Screentime use are relatively low friction.) She uses Youtube for her job as a filmmaker, and the temptation is constant, so she can't give up Youtube entirely (inertia!). Eventually, she'll "treat" herself to celebrate finishing a milestone, turn the time limit off, and then slip into her old bad habits. In her own words "this is negatively affecting my life."
So, the common themes across a few interviews:
Other notes:
So it's possible to develop my UX skills and get a lot of really rich, deep, insightful information, just getting coffee in the morning, which I already do. And there's something about the human connection and the humanity of what people are sharing that I find moving.
I have a lot of thoughts on how to solve these problems, but that's a post for another day. Whatever the answer is, there's plenty of "push", but I think there are bigger challenges to overcome the inertia of not want to give up a connection to friends/family, and then the "pull" towards a specific solution means the solution needs to work and be marketable. (Cold turkey may be most effective for quitting TikTok, but you can see situations where cold turkey doesn't work for everyone.) I'm also curious if there's an adjacent space to research, but specifically around RSS and feed readers.
As for my little newspaper project, I'm now automatically sending Trello screenshots to the printer and my next steps are figuring out how to get a daily Gmail set added to the mix.
best regards,
Sam Feller
aka THE Awkward Engineer
Today's post is to share some previously developed training material about working collaboratively with product management, design, and engineering to break down user stories.
At the core, I truly believe that good process and good technique results in better outcomes, with less stress. I've seen multiple teams benefit, including previous teams I've worked with and with past clients. People have been nice enough to say things like "Sam is an engineering whisperer" and "With Sam, I can't tell where the product/design process ends and where the engineering process begins."
Mostly, I've just connected dots from the work of others. User Story Mapping, by Jeff Patton, is phenomenal, but I've been able to incorporate ideas from all sorts of other places and my own experiences as both a Program Manager and Product Manager.
This talk is aimed mostly at software teams, but the content has value for back end software teams too, and has nuggets that hardware teams will find valuable, if not directly relevant.
I suppose if there's one, maybe two big ideas, it's this: First, I'm picky about language, because there's a big difference between a user story and a feature, which in turn is different then an engineering task. Second, I use techniques like asking for "good, better, best" versions of things to facilitate discussions, and make room to talk about options and tradeoffs. Which is all part of making good decisions.
So really this talk is about taking a high level user story about say, building a shopping list app, and breaking that down to the nitty gritty details. (Should it be sortable? Alphabetically? By aisle at the store? By price?). Because at the end of the day, nitty gritty details are what's being built. And some details are probably worth building before others. Figuring out how to do that collaboratively in a high functioning team takes work, but it's also really fun when it gels, and leads to building awesome stuff.
Finally, I'll say that this content doesn't say anything about identifying customer problems, or knowing that a problem is worth solving. That's a topic for another day.
I'm not sure how well the material stands without me talking through it, but I've added my notes, where I thought it made sense. Anyway, the slide deck is online and available here.
Happy to discuss, debate, and take questions!
best regards!
Sam Feller
Today's post is a mini update on the mini-newspaper and then a book report.
After writing about staying offline last week, I made some progress executing on my mini-newspaper idea. I have a short little script that successfully goes to the Trello website, types in my username and password, and grabs a screenshot of my board - all things I was doing manually before. The next step is figuring out how to send that to the printer.
ChatGPT certainly makes things easier when looking up commands, but it's not flawless, by any means. I still 100% consider it a useful productivity tool. (I also find myself trying Bard and Llama2.ai, and wonder if I'll find one more useful than the others, but haven't settled on a winner yet.)
Of course, a little script like what I've built so far is very "brittle", meaning that if any little thing changes in the Trello login sequence, or with the printer, the whole thing could fail entirely. It makes me think about integration points and things that would need to be built if others were to ever use this, but right now, it's good enough for me.
I think there's a lot of fluff around the concept of "strategy" and I wanted to read more about what other thinkers had written on the topic. These two books were recommended and I would endorse the recommendation if you're curious on the topic.
7 Powers: The Foundations of Business Strategy
I find org design to be a somewhat nebulous concept, but I think it's best to think of it as a systems design activity where you're trying to define roles, processes, incentives, and structures, then aligning that with your people, with the intent of best delivering value for customer. As a design activity, there's no single "best" or "right" answer, but there are some tools for going about the process.
Honestly, I can't recommend any of these books unless you're in the field and it's critical to your knowledge base, and event then, I'd be hesitant. None of them are written well.
Data Driven Org Design - This is the best of the bunch, but has entire chapters(!) devoted to the idea that data can come from spreadsheets and other business systems, too. Makes clear that there are roles, positions, and people, and to think about all of them as unique components.
Mastering the Cube - Quick and simple list of org design mistakes, like designing orgs around the needs or desires of individuals, rather than the needs of the business.
Designing your Organization: Using the Star Model to solve 5 Critical Design Challenges - Good for the examples it provides, but honestly, just not a good read.
Department of Speculation - A series of vignettes following a woman's life. I loved the brief, punchy little scenes.
Gates of Fire - Violent. It's about the Spartan lifestyle and the 300 Spartans who battled at Thermopylae. Fun read if you like historical fiction and action.
Maus: A Survivors Tale - I read this one because it was being banned in places. It's a graphic novel, and the author's choice to portray characters as different species of animal (all the Jews are mice, the Germans are cats) really worked well artistically. The book is about the Holocaust and doesn't pull any punches about the true horror of the experience. The intensity of the content doesn't make it an easy read, but I think it's important to bear witness. Highly recommend.
Empowered - I read this is as a follow up to Inspired. This book focuses more on the management of product teams and product managers, rather than product management itself. The biggest takeaway is that autonomous teams don't need less management because of their autonomy, the management they need is more about alignment and coaching.
That's all for now!
Best regards,
Sam Feller
aka THE Awkward Engineer
Today's post revisits ideas around my Receipt Printer, my Physical Trello board, and Staying Offline. I'm interested in a new iteration, where I effectively print a personal newspaper automatically each morning, with my calendar, my Trello, select filtered email messages, and maybe some news and weather.
More than that, though, I'm also interested in tying together several different threads of thought, including ChatGPT, habit forming/addiction treatment, and UX research into how people manage their internet use.
Full disclosure, I just came back from a week-long vacation in Colorado. I had no cell service and wi-fi was only available in one particular cabin where we were staying. I found myself sitting in a chair, listening to the birds and the flow of water in a nearby stream, feeling the sun and the breeze, and I'd sit and do... nothing... and it was glorious. I didn't feel any pull to use the internet, and I didn't slip into using the internet accidentally, either.
So I did mention that there was wi-fi in one cabin and I checked my personal email once a day. The truth is... there really wasn't really anything in my email that needed an urgent response. Same thing with the news. Once a day, or even every other day, or even every three days would probably be way more than enough. (Or heck, it could really probably go a week).
So I've known from past experience that putting devices away and staying off the internet has been good for me mentally. And yet... I always find myself sliding back into old habits.
My take is that because so much of my work is done on a computer, (and in many ways part of my job), it's always going to be challenging. Atomic Habits talks about cycles of cues, triggering cravings, leading to actions, leading to rewards. I think a lot of apps that put limits around device or email usage target placing limits on the action/reward portion of the cycle, but I'm really curious about preventing the cue in the first place.
In other words, how can I get the benefits of what I use the internet for (email, calendar, to-do list, weather, news) without using the internet.
I know that personally, I do well productivity wise when I print up my physical Trello board, and I enjoyed using my receipt printer to show the weather and a comic strip. But there are flaws.
The receipt printer actually used some shell scripts that leveraged some command line tools to access Trello. That in turn used If This Than That to create Trello cards with the weather. So the whole thing is really a flimsy, hacked together kluge. And then Trello doesn't format things nicely if you try to send them directly to the printer, so for the physical Trello board, I actually take screenshots manually and then send the screenshots to the printer.
So, I know conceptually that setting up something that pulls in data from various sources, formats it, and creates a pdf, then sends it to the printer is quite feasible, technically. The devil, as always, is in the details. For example, Google Calendar has an API, (or maybeI should use Zapier’s interface to the Google Calendar API or the dozens of Zapier competitors that have popped up), but now you need to register accounts with Google, get developer keys, a whole rigmarole. It's all possible, but it means reading endless, often poorly written documents. It's one of those things that might take 20 minutes for someone who knows what they're doing, but could take me a day.
I like to think that ChatGPT is really useful for this stuff. For example, I know that there are tools for running browsers in "headless" mode (meaning without a screen) as part of various testing and automation suites. I had an idea to stand up a little webpage, load it in a headless browser, take a screenshot, and send that to the printer. I asked ChatGPT and it suggested using Pupeteer.js and provided the code to do it.
So part of this idea is also to scratch an itch around playing with ChatGPT.
One of the things that I've learned the hard way is that you can't just go and ask people what they think of a mini-newspaper idea. You can ask if they would commit to trying it, or ask them to pay for it via some kickstarter-like presale, but that's not particularly useful at this point.
What you can do is ask about past behaviors. (Testing live reactions is something we can try later.) At this point the research is along the lines of "When was the last time you tried to manage your internet usage? What did you try? Did you spend any money on it? What happened? These are questions where we can get unbiased answers about motivations and pain points. The newspaper solution may or may not solve these problems, there's just no way of knowing yet, but we can get information to help tailor what the solution might be, and help craft something that adds some "pull" to the existing "push" of people looking for internet management solutions.
Ok. This is a pretty tangled web, but there are few more thoughts to weave into this story.
Almost a decade ago, the Little Berg printer launched, which was essentially a mini-newspaper driven by a receipt printer. The product was adorable, but eventually it shut down when the cloud service that powered it couldn't be supported any more. Someone else revived it a few years after the original servers shut down, which is pretty cool. Regardless, I'm really interested in speaking to the founder and the revivor to see if they have lessons to share.
Also, I've participated in the past in a group called CaveDay, which I think essentially uses some peer pressure and group psychology to join a video chat, turn off your phone, promise not to check email, and just do deep, focused work. Everyone else is working hard, so, ummm... something happens where it makes it easier for you to focus and tune out distractions too. It may sound weird, but it has a cult following.
Finally, I know there are experts out there who specialize in addition treatments, and I'm sure internet addition falls in that category. I'm curious what their take is on this too.
This post was really about getting some ideas out. I'm really interested in flexing some dev skills and making something for myself. I also acknowledge that I'm weird and into odd little ideas like this, but I'm curious... when was the last time you, dear reader, tried to manage your internet usage? What happened?
best regards
Sam Feller
Today's post is about Goals, and partly for my own benefit, attempts to consolidate and summarize what I've learned from personal experiences and from various books. I'll touch on ideas from Christina Wadtke's Radical Focus, John Doerr's Measure What Matters, Josh Seiden's Outcomes Over Outputs, and Bill Carr and Colin Bryar's Working Backwards, and Marty Cagan's Inspired (as well as others).
Implementing effective goals or OKRs (objectives and key results), in my view, is really about building effective feedback driven control loops and establishing those control loops at the proper position in what Seiden refers to as a "results chain". (Inputs --> Activities --> Outputs --> Outcomes --> Impacts)
When people mess up goals, I think it's most often because they fail to set goals at the right point in the chain, or they fail to implement a feedback loop, and never look at the goal again until it's too late.
The short version of all this is that I believe a good product goal (as opposed to an engineering goal) is defined as an outcome that's within a team's control to achieve, and that the goal needs to be reported against every 1 or 2 weeks.
Of course, there's a lot of to unpack in that one sentence, which is what this blog post is about. I'll describe the results chain in more detail, use the results chain as a framework for talking about different types of goals, and then try to tie some ideas together from the various books.
Let's dive in.
First, we need to start with some common language and mental models, because engineering outcomes, product outcomes, and business outcomes can all be mixed up.
My favorite model, that I learned about in Outcomes Over Outputs, is something referred to as a "results chain", and it's a framework often used for measuring some very challenging, tricky to define, humanitarian problems.
Inputs --> Activities --> Outputs --> Outcomes --> Impact
Here's a great example taken https://winderl.net/result-chain-a-beginners-guide,
The country of Smokistan wants to reduce smoking.
The desired impact is that less people die of smoke-related illnesses within five years.
The planned outcome is that fewer people smoke fewer cigarettes.
Smokistan plans to achieve that by increasing taxes on cigarettes and making smoking more difficult in public spaces – these are the outputs.
This requires several activities: for example drafting and passing a new anti-smoking law or funding and implementing smoke-free public zones, etc.
These activities require additional time and money – the inputs.
Outputs are tangible deliverables generated by projects. Documents, product features, software executables, parts, components, reports, etc... these are all outputs.
Outcomes, in particular, are given a very specific definition. For the purposes of product management, they are defined as "measurable changes in human behavior". (Or, for purposes of engineering teams, an outcome may be a "measurable performance improvement.")
Outcomes in turn, lead to impacts. Impact is usually something valuable or worthwhile, or a proxy measure for those things. The example above counts deaths from smoking related illnesses, but things like revenue, Net Promoter Score (NPS), star rating, and other trailing measures would all be considered "impacts".
Seiden advocates specifically for defining product goals in terms of outcomes. In general, I agree, but it's at odds with some of the advice in the other books. Here's how I make sense of it.
It makes sense to set an activity based goal if that activity is hard, and the goals serves as a reminder to keep doing the right thing. For example, "Make 3 outbound sales calls per week" is a reminder that sales can be a numbers game, and that sometimes it takes some hustle.
"Go to the gym twice a week" is another form of activity based goal. In the results chain for this one, we're assuming the activity will lead to a net negative calorie expenditure (the measurable outcome), that will lead to weight loss (the impact).
The caveat with activity based goals, is that they create some lock in and take away some creativity . For example, we could get to a net negative calorie expenditure through diet, and while a dramatic choice, we could also get to the desired weight loss through surgery. Taking a goal on an activity creates focus, which is often a good thing, but understand that setting goals further upstream in the results chain takes away options.
I don't mind output goals when the output is quantifiable, but too often, an output is reduced to building a feature or completing a project, and that's where I object. I'll provide examples of both in a moment.
I'm also of the belief that when goals are quantifiable, it's possible to set a wildly ambitious goal to inspire people, and still realize positive outcomes when the quantifiable output falls short of the target. Many outputs, on the other hand, like features or projects, are binary; they're done or they're not.
In Working Backwards, an output goal was set against the number of product pages on Amazon.com with in-stock items, the idea being that more items (the output), would lead to more customers finding something they like and making a purchase (the human behavior that defines the outcome), which would lead in turn to business impact. Here's a case where falling 10% short of an ambitious output goal (say, 750,000 products in stock) is still pretty awesome.
On the other hand, I see so many teams takes goals like "Launch this new feature." I object to these types of goals because they lock the team into building the feature and they let the team off the hook if the feature doesn't have the intended outcome with customers.
Maybe it's semantics, but I view projects as a things where people work to reduce risk and are expected to predictably execute. Which isn't to say that projects shouldn't be tracked and reported against, they should, its just that calling them goals, is in my view, a disservice.
Perhaps the lone exception to my "project as goal" objection is when achieving the output isn't guaranteed from the get go. This is the canonical moonshot: "...this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth."
Setting goals on outcomes is the model advocated for in Outcomes over Outputs, where an outcome is specifically defined as a human behavior. Some human behaviors lead others. For example, increasing new user signups is a behavior that might lead returning visits, which may in turn lead more behaviors like making a purchase, which will lead to business impact.
One of the things that I really like about this model is that focusing on human behavior, is I think, at the core of good design, and human behaviors make defining measurements somewhat simpler and less subjective.
Setting a goal on outcomes also creates a feedback loop at an interesting point in the results chain. It's not so far upstream that it locks you into a plan, and it's not so too far downstream to get timely feedback, or where other confounding variables may be getting mixed in the signal.
Setting goals on outcomes gives a product team a lot more creative freedom to figure out how to drive the outcome they want, but with a short enough leash to hold them accountable.
I think the real challenge here is figuring out which product outcomes you think will lead to business impact. It takes time and customer research to make that happen, so you can't necessarily jump to goal setting right away. It might take a quarter of research to figure out what outcome you think will drive the desired impact.
Finally, it's possible to set straightforward goals on impact, for example "increase revenue by 10%." These give the most freedom and latitude, sometime too much, because it can be beyond the scope of a single team to control. For example, marketing, sales, and product can all influence revenue together. Holding a single team accountable for goals like this can be tricky.
So I mentioned earlier the importance of creating feedback driven control loops, and that I believe that means reporting at a cadence of every 1 to 2 weeks.
The intent here, is to force teams to regularly ask themselves "where are we going, where are we now, and what are we doing to close the gap?" When I've seen teams try grading OKRs on a quarterly or 6 week (half quarterly) cadence, the goals just don't stay top of mind.
On the other hand, I've seen teams asked to report an accuracy target (an example of a performance metric, or an engineering outcome), only to realize in the first reporting sessions that they had no idea how to measure the accuracy. Two weeks later, they came back to it with a hand calculated measurement and we argued over the definition of what accuracy meant, than two weeks later, we had automated the measurement, and then over the course of several months, the metric slowly increased as we improved the product.
There are a few points to take away. First, the initial goal language was not perfect. Second, coming back to the goal every 2 weeks forced us to pay attention to it. We refined our definition of what the goal was, how to measure it, and how to improve it.
So in other words, if you're spending more than 2 weeks defining goals, you're taking away some of the power of feedback loops to correct the goal and your definition of it. Define the goal quickly. It's ok to refine it over time. The point is to come back to it repeatedly. Keep asking "Where are we going, where are we now, and what are we doing to close the gap?""
What if the goal can't be measured until the end of the quarter?
Some goals are hard to measure on a continuous basis, or aren't worth measuring until after a project is completed. In this case, Wodtke suggests reporting a confidence score on achieving the goal. Clearly, a direct measurement would be preferable, but at the very least, the feedback loops and mechanisms to drive focus are in place.
Where do mission and vision fit on the results chain?
This is one where I'm still thinking through things. I think shorter term objectives, the larger vision, and the long term mission all fit within the category of down stream impacts.
What is the overlap between the results chain framework above and Objectives and Key Results?
Well, there's a lot that's been written about OKRs, much of which conflicts. John Doore's book, which I don't recommend, often uses a format that I think is more akin to user stories and acceptance criteria, i.e. "achieve this goal, by which we mean that we agree completing these projects means the goal is met." Again, I don't like projects, because I think they take teams off the hook for projects that don't deliver intended results.
Christina Wodtke's book fits much more closely with the framework above, but doesn't write about it quite as clearly, or as a formally. In her book, it's a more pragmatic "how would we know quantitatively that we've achieved our objective?" with less formal definitions of what each of the steps of the chain means..
What about pragmatic situations when you just need to launch something, like a restaurant?
Wodtke would say to quantify the launch. How would you know a restaurant opening is successful? Is it the number of customers? Yelp reviews? Writeups from restaurant critics? Followers on instagram? Service times and food quality? This is all to help you focus. Why is your confidence score an 8 that we'll have a line of customers out the door on opening night? What are you doing to make that a 10?
Notes on Quantity/Quality pairs
Wodtke and others talk about the importance of balanced goals. For example, balancing goals on quantity with goals on quality. It's great that's there's an engineering performance target to produce 20% more widgets an hour. You can't be spitting out garbage parts though, to get there.
Notes on Trade Spaces:
I've seen some goals that give teams freedom my making tradespaces explicit. For example, engineering performance goals on airplane parts could trade a pound of weight and make their part heavier, but only if it also saved $10,000. This sets a lot of context and gives the team to pursue better choices.
I hold it as a truth that Crayola brand crayons are the best and all other brands of crayon are inferior. Other crayons just aren't as smooth and don't put down color as well. I've known this since I was in kindergarten and it remains true to this day.
Rant aside, my kids had all their crayons in a giant bucket, which I thought made it hard to find the right color. After Googling for crayons holder CAD models, I decided I didn't like what was out there, and made my own.
The design was made using onshape.com, you can view the model here.
As expected, initial creation lead to an uptick in crayon based drawing. Less expected, the kids actually would put the crayons back in the holder on their own initiative.
best regards!
Sam Feller
aka THE Awkward Engineer
Today's blog post is about game changers. These are the books that literally changed my game, meaning they changed my approach to problem solving, design, project management, product management, and personnel management.
I've chosen these books for impact. There are certainly lots of great books out there and more that I'd recommend. But these books divide the world into how I viewed it before reading these books and how I viewed it afterwards.
Where I found other books that were worthwhile, but not necessarily "game changers", I've made notes with recommended follow up in the specific order that I recommend reading them.
The New One Minute Manager - At its core, getting the best out of people is about setting expectations, providing corrective feedback when necessary, and reinforcing good behaviors with positive feedback. That's it.
Follow up books: High Output Management, How to Talk So Little Kids Will Listen, Radical Candor, Making of a Manager, Never Split the Difference,
Traction: Get a Grip On Your Business - A clear, succinct guide to basic habits and guides for running a team or business.
Follow ups: Radical Focus, Built to Last, Turn the Ship Around
The Goal - A remarkable illustration of lean manufacturing principles. It completely turned my view of efficiency in manufacturing upside down, and refined my understanding of lean as applied to product development.
Follow ups: Lean Startup, Toyota Production System
The Non-Designer's Design Book - Once you learn basic graphic design principles, you can't unsee them. There's no summarizing this book, the examples and lessons need to be seen and practiced.
Refactoring UI - Understanding the basics only took me so far. Refactoring UI leveled up my skills for understanding color palettes, type systems, design systems, and UI patterns.
The Mom Test - Past behavior contains real evidence and hypothetical predictions can be dangerously misleading. This book teaches quick and dirty UX research and interview skills that can be utilized immediately.
Rocket Surgery Made Easy - Opinions and feedback can also be dangerously misleading, but live reactions contain real data. This book is a great complement to the Mom Test and leveled up my skills for product testing.
Follow ups - Continuous Discovery Habits, Inspired
User Story Mapping - I already believed in the power of user journey mapping (which I very much muddle up with service blueprint design) as an organizational framework. This book helped me refine and polish these ideas and effectively upped my game for working with software engineers.
Follow ups - Scrum: The Art of Doing Twice the Work In Half the Time, Product Development Flow, Building a Project Work Breakdown Structure
Atomic Habits - I remember reading an 8 or 9 page handout from Amazon on mechanism design, or how to build systems to ensure things get done, rather than wishfully hoping they will. This book is better, with a deeper understanding of the psychology, and better guide on how to successfully build habits. Total game changer.
Follow ups - Hooked, Deep Work
Start with Why - I actually recommend people watch the 20 minute TED talk, rather than read the book.
Spin Selling, Inside the Tornado - Two books about marketing through all the stages of the adoption life cycle.
When Coffee and Kale Compete - The best book about "Jobs to be Done" theory.
That's all for now! As I read more, I will add them to the list!
best regards
Sam
aka THE Awkward Engineer
Today's post is about advancing the state of the art in mouse trap driven catapult design. We'll meander for a bit and talk about the backstory and motivation, but the punchline is that I have a design for a mass producible, injection moldable catapult. It features a snap-on throwing arm that fits over the kill bar of a traditional "snap trap", and then the trap itself snaps into a plastic frame which controls the throwing angle and keeps fingers safe. It'll throw a marshmallow about 6-8 ft. Oh, and my favorite design feature, is that the mouse trap's trigger mechanism is kept intact.
The story starts several months ago with the discovery of a mouse in the house. I mean, we found evidence of droppings, and some mouse sized holes in an instant ramen packet and a box of Cheerios, and then one day I actually saw one scamper across the kitchen.
My wife has a true, stomach churning phobia of mice, so we hired a service that came and filled up all the air gaps around the house and left around 60 or 70 traps in every nook and cranny.
To their credit, it's been several months, and nary a mouse has been seen, live or dead, but from my point of view, these mouse traps are now being underutilized. So I started thinking about what I could make with them.
Mouse trap powered cars were a thought, but catapults just seemed more fun.
This is a total tangent, but when interviewing engineers, I often asked a question about keeping a chicken egg warm and incubated until it hatched. The question starts with a scenario where it's necessary to hack something together with materials from around the house, then progresses to more and more sophisticated builds. Once the chicken egg is safe, I start asking the candidate to start thinking longer term, and maybe not having an ugly recycled cardboard box and a heating pad in my living room.
This question certainly weeds out bad engineers, and most mechanical engineers can start talking through what would be necessary for a more repeatable, scalable, durable, attractive build.
The best answer by far though, went something like this.
"So the chicken egg is safe for a little while, and I have a few days to come up with something nicer?"
"Yes."
"Well, chicken incubators sound like a thing that already exists. I'd look on Amazon to see if I could just buy one."
The lesson here is not to engineer things when you can just buy them for a lot less time and trouble.
So I turned to the internet and did an initial search for mouse trap catapults. I was disappointed with what I found. Clunky CAD models. Popsicle sticks, spoons, and duct tape. And none of the designs used the trigger mechanism of the trap, which in my view, is half the fun! Nothing available on the internet, either for sale, or for download, would suffice! So I could tell myself I was fully justified in spending the effort on this. There was no buying what I wanted on Amazon. Time to design my own!
I've done a ton of work lately in program and product manager roles, and haven't done much heavy lifting on my own, but deep down, I tell people that there is still a mechanical engineer in there somewhere, so maybe I was just looking for an excuse to spin some CAD to make sure the skills hadn't fully atrophied and also play with my 3d printer.
Here's the process:
Initial steps started with some sketching and some tinkering with popsicle sticks and duct tape to get a rough sense of proportions.
From there, I can get into rough CAD. The purpose of the first build was to start checking critical dimensions.
And as it turns out, I goofed on the first build... I tried to have the flat bar hit perfectly against a flat surface on the frame, and frankly, that's never gonna happen. I redesigned the surface with a curve, so that I would always have a flat on curve interface, which is much better from a wear point of view. I took a couple iterations to get the locations of all the necessary critical surfaces to locate the trap and the throwing stop.
At this point, I started playing with the throwing arm. The first one fit, but it had a habit of slipping off with repeated firings.
An iteration or two later and I had the throwing arm getting into shape. Eventually I tried to address wall thickness and make something manufacturable. I could certainly tweak this a bit more to eliminate the need for side actions, but it's close enough for my purposes and I wanted to put more time into the main body.
There were a couple false starts at making something manufacturable for the main frame. I really wanted a simple, two part mold, and wanted to avoid side actions or anything that would add cost to the part.
Because of the frame geometry, you need some access holes so the mold can "reach" to the underside of the part. I ended up in some places where I didn't like the aesthetics, so decided to start again from scratch.
Actually being able to hold the part, instead of spinning the 3d model, made me rethink a few things. In particular, I realized how much material was just being covered up by the mouse trap. This lead to another iteration.
Also, I thought that ribs on the top of the part, where the "stops" were might look OK, but when I saw the build I changed my mind. I took another crack at it. The build below was really getting somewhere!
]]>Today's post is about working with scientists and finding appropriate ways to report status and drive communication in larger groups. I've done this work with engineers before, but working with scientists in this way is new to me.
The problem is that my traditional project manager approach of asking "What do I get and when do I get it?" doesn't quite work, because the scientists are often tasked with problems that are so open ended as "Can you look and see if there is a 'there' there?". The answer to my PM is question is therefore "I don't know and I don't know." Not exactly an insightful update.
Anyway, to cut to the chase, I'm experimenting with some new questions, "What have you learned and what are you still curious about?" and finding some success.
The rest of this post is details about how I picked those questions and how it's working out so far.
I've written about status reporting before and I remain convinced that few people have been taught how to do it well, and in my experience, it's not taught in schools at all. The first failure mode is to ask for status with no further prompting, which often results in too little information, no information, or way too much. The other failure mode I've seen is the "what have you done recently and what are you doing next?" format which suffers because it becomes monotonous and boring.
Engineers are allergic to drudgery, paperwork, and status reporting, and if anything, scientists are even more so. Their typical stance is to say, "just talk to me", rather than asking for a report, but the problem is that that can be inefficient and it doesn't scale well.
The ideal status meeting for the scientists then, would be to efficiently convey information and avoid monotony. One of the outcomes I'm looking for is also engagement from the team, meaning cross team collaboration, information sharing, and knowledge flow, as evidenced by further questions and dialog in response to a status update.
This wasn't going to happen if the meeting was dull and if people tuned out during a status meeting. My challenge was to find good prompts that would hone in on the most important information and encourage good replies.
This is a bit of a detour to the startup world, but bare with me for a moment. One analogy I've heard to describe early stage startups is that they're high speed learning machines, or at least, they're supposed to be high speed learning machines, or they'll run out of money and die before they find product market fit (and their next round of funding). Speed of iteration, and how quickly a startup and can figure out what doesn't work and get on to a path of finding something that does is what's important. So progress at a very early stage startup isn't measured by profit (after all, there is none), progress is measured by learning.
In a similar sense, we don't pay scientists to do research, we pay for the output of that research, which is learning. (And for the record, learning the 9,999 ways to not make a lightbulb is still a valuable outcome, and par for the course.)
Regardless, the insight here is that when I ran engineering projects, I didn't care about the work you did (although, deep down, on a personal level, I'm an engineer, and I do care), I cared about what I was supposed to get and when. In a similar fashion, for scientists, I don't care about the research approach, I care about what they learned.
It turns out that if you ask "What have you learned?", there's a lot pf valuable information in the answer, even if the scientists haven't learned anything yet, because you can ask why they haven't learned anything yet. It could be they're still running experiments, or cleaning up data sets, or waiting for additional input. That information is often actionable, and when people have learned something, it's often interesting, and worth sharing with the team.
So we're distilling the status update down to the most useful pieces of information! This is good stuff!
The follow up question to "What have you learned?" is then "What are you still curious about?". I like this question, because it's an open invitation to the rest of the team to think about what questions the previous round of learning raised for them, which a great driver for engagement and collaboration, in my book.
I also like the question, because it's a measure of appetite and sense of whether it's worth continuing to research in a very open ended problem space. Sometimes you learn something that makes you scratch your head and ask more questions, sometimes you learn that there's no signal in the noise, and you're running out of ideas for how to filter it, and your instincts and (lack of) curiosity are telling you to stop digging.
I'll admit that I'm fairly early into this, but so far, I'm happy with how it's going. If any of my readers have worked in scientific organizations and had to run a team meeting, please share your thoughts!
Best regards,
Sam Feller
aka THE Awkward Engineer
I've long been fascinated with calendar visualizations, particularly ones that make it easier to correlate physical distance with temporal distance.
I drew a lot of inspiration from this Kickstarter for a wall calendar. In particular, I liked how it chunked the year into two week time blocks. My criticisms were that I didn't like the lack of boundaries around each date, I felt the white space around the borders was too empty and unbalanced and I didn't love the treatment of quarters and month designators on the left hand side.
Also, when i realized I could get large format printouts made at my local UPS store for 49 cents per square foot and a large wall chart would cost $3, my willingness to design my own went up exponentially.
Here's my calendar for 2023. You can download a .pdf here.
Best regards,
Sam Feller
aka THE Awkward Engineer
Today's post is about Systems Thinking, and a systems diagram that resonated with me on a personal level, after reading a book called The Fifth Discipline. (The book covers a much broader set of topics and I'm not ready to give it my full endorsement yet, but it certainly had some worthwhile nuggets inside it).
System thinking, in a nutshell, is about taking a step back and looking at the larger patterns of behavior at work. In broad strokes, it views the world as interacting sets of feedback loops and the feedback loops often include a time delay.
Systems tend to fall into a set of "archetypes", and you're probably familiar with many of them, like escalating cycles of violence, the tragedy of the commons, and virtuous cycles where success leads to more success, and various other patterns.
One particular pattern is called "Eroding Goals." I use a gym analogy to explain it, say a goal to do ten pullups. So you start practicing pullups, and find that it takes time to get that strong, and you can't do ten pullups right away. Falling short of your goals doesn't feel good, so maybe you tell yourself, you should change the goal, and you're satisfied with the number of pullups you can do today. There's no longer a gap between your goal and your current state, so balance is restored.
The book showed a diagram that looked a lot like this.
Something about that diagram really resonated with me, because it made me realize I've given up on things without giving myself the time to get through the delay portion of the loop, or giving myself time to learn, or build metaphorical muscle. (Marketing is one of those things. Marketing is hard.)
I decided that I liked the diagram so much that I wanted to turn it into a poster and put it on my wall, but I wanted something nicer than the sketch above.
This is the poster.
Hang in there! It takes time to build muscle!
best regards
Sam Feller
aka THE Awkward Engineer
Lots of odds and ends in today's post.
Within my personal network, I've had a good handful of people I know that were laid off recently or are actively looking. They're good people, located in the Boston area, including a
Reach out to me with any job posting you think may be relevant and I'm happy to make a connection.
No, I'm not 3d printing the full house. My seven year old wanted to make a model. I showed him how to use the line tool, trace over some images, and extrude shapes.
Some of his observations "The dining room went way faster than the kitchen!" My reply: "Guess which one costs a lot more to build, too?"
We were doing about a room an evening before the guide bushings literally fell out of the print head assembly. It was an old printer, where they used 3d printers to print parts for the 3d printer. It was one of the first sub-$1000 machines to hit the market over a decade ago and I think it's time for an upgrade. Whatever it is, I don't want to tinker with it, I just want the parts that come out of it.
The circuit board assemblies from the Voltmeter Clock Auction are back and they work! We were all set to start assembly today, when we found that the 3mm Phillips head screws we ordered were not what were shipped. Minor hiccup, but they'll be out the door within the next 1-2 weeks.
I'm speaking at the next Boston Hardware Meetup, where I'll be giving a talk about my philosophies and approach to hardware project management. I'm also giving a lecture at Babson in December to about how I break down software user stories and help Product Managers, Designers, and Engineers work together.
I have some follow up blog posts to pair with the approach to user story breakdown, I started tinkering a little with the circuit from a few weeks ago, and a few art projects.
best regards!
Sam Feller
aka THE Awkward Engineer
p.s. Looking for a job? Looking for good people? I want to help. The AwkEng email list is over 1000 readers and has a pretty targeted audience. Let me know who or what you're looking for!
]]>The pre-programmed microchips I wrote about last week arrived. I took a live, working Clock on my desk from a previous batch and that became the test bed. I de-soldered the old microchip, dropped a new one in, and voila, it worked. There's something amazing to me that I can reach out to a vendor, say "gimme the same thing you gave me last time" and, even though it was a few years later, get exactly that.
I also have a renewed appreciation for production quality systems where you can trust that what's on the BOM is good. I had a pretty hacked together system and folder structure, but I could still find my BOM and my old PO's, and the firmware image is for sure a trackable line item. It's part number AWK-105-0047RevA.hex, and it comes with corresponding revision controlled fuse and lock bit settings.
So the microchips are on there way to the assembly house and I'm one step closer to a new batch of Clocks.
On a separate tangent, I recorded an episode for the Pick Place Podcast a while ago. It came out just recently, and one of the things we talked about was a technician I worked with who had phenomenal skills at making surface mount electrical prototypes, with intricate little traces made out of copper tape, and beautifully laid out little jumper wires.
This is something I've had in the back of my mind for a while and I've been thinking about things to prototype to practice those surface mount hacking skills.
I may have an idea.
When I was a kid (this was in the 90's), I had a DIY hobby kit that I soldered together. It was called the TS-4 "Tickle-Stik" from Ramsey Electronics and it turned 3 volts DC into about 85 volts AC, which is enough to feel a buzz. In retrospect, I'm surprised this was ever sold to the public, but hey, nobody got hurt and it was fun. You might even say, electrifying. (I'll show myself out.)
Anyway, I found it in my basement, it's no longer functioning, but I thought, maybe I can reverse engineer it and then use this as inspiration to build a prototype.
Then I thought, the internet never forgets and maybe I can find the manual for this thing, along with the schematic and save the reverse engineering step.
Well, the internet has delivered in spades. I'm not sure Ramsey Electronics sells hobby kits any more, but I did find an archive with a pdf of the manual and I have an email out to Ramsey's sales team to say hello and see if the original owner/inventor is still around.
Anyway, the whole point of this post is that I'm scratching my head a little over the schematic and while I play an electrical engineer for fun sometimes, I'm mostly a mechanical engineer on the inside.
The circuit is an example of a blocking oscillator. When the circuit and the transistor turns on, feedback from the transformer secondary "blocks" the signal that turned on the transistor in the first place, which in turn kills the current to the transformer primary, which leads to a current drop in the secondary, unblocking the transistor to turn on again, and leading to oscillations.
Or so I think.
I keep scratching my head, because I think the polarity on the transformer is backwards. Part of me thinks that I might have theory of operation slightly off, and it's overshoot and ringing in the RLC portion of the secondary that creates a negative voltage and turns the transistor off, but again, I'm not sure.
Anyway, if you're an EE and willing to talk me through it, drop me a line!
]]>We're back today with an update on Voltmeter Clocks and a brief foray into supply chain. The Vickrey auction is over, we've collected funds (see footnote* at end of this post) and now we're placing component orders.
In true Awkward Engineer style, I gave myself a minor panic attack checking through supply chain on chips. Everything's ok and stock is available (plus I hold limited stock in my basement, just not as much as I'd like for a small board run), but here's a jargon-y detour you may enjoy.
The Voltmeter Clock was originally designed around the ATtiny24/44/84 family of microchips. It's very closely related to the ATmega328 family, which is what powers the more widely known Arduino Uno hobby board.
In comparison to the ATmega328, the ATtiny24/44/84 family has less memory, reduced power consumption (important for a battery operated device!), a smaller footprint, and costs a few dollars less. Retrospectively, the difference in cost was probably silly to quibble over, but engineers love to optimize things, and that's what I was doing.
Anyway, going one level deeper, the ATtiny24/44/84 also has an "A" variant and a "V" variant. The "A" and "V" variants both run at lower voltages than the base variant, which is functionally critical, because the Clock power supply circuit was designed to take input power (nominally a 1.5V AA battery, but optionally a 5V USB power supply) and run at 2.0V. Regardless of input voltage, the "A" variant just consumes less power than the other variants, which again, is critical for a battery powered device.
So if you're following along, that means that the "A" variant is preferred, but in a pinch, the "V" variant could be used with a USB power supply. The board was designed to support both options, so there would be no board changes or firmware changes.
Still with me?
Ok. So, differences still remain between the 24, 44, and 84 variants of the ATtiny, namely the amount of memory. They each have 2K, 4K, and 8K of ROM, respectively. (Yes, that's K for kilobytes. Welcome to the world of super cheap microcontrollers!). The firmware for the original clock took up 2046 bytes, fitting in the 2048 bytes of memory available on the ATtiny24. When I rewrote the firmware for the Alarm clock version, it only fit on the ATtiny84. The Alarm clock firmware was clever enough to detect what components were on the circuit board though, and so the same chip/firmware combination could be used for either the Clock version, or the Alarm version.
So that means there are still more options. The ATtiny84A chips are clearly preferred, because they can be used for Clocks or Alarm Clocks, but if needed we can order a Clock only batch.
Finally, there's one more level to the rabbit hole. All those chips above come in different physical packages, meaning the physical shape of the chip, with names like DIP (dual inline package), SOIC (small outline integrated circuit), QFN (quad flat no-lead), and so on. I wanted the SOIC version, but in an absolute emergency situation, I could keep the same circuit board schematic, but redesign the physical layout of the board to support a different package.
Ok, so there's one more small wrinkle. Namely, the distributor. As a little guy, I don't buy anything directly from the factory. I go to one of their distributors to buy everything, and some of them are nice enough to program the microcontrollers at their facility, so that I don't have to do it myself. So on Friday morning, my preferred distributor was out of the chip variant that I wanted, but an alternate distributor had it.
That alternate distributor just happens to be one of my least favorite distributors. It's impossible to get anyone on the phone who knows what's going on and they don't respond to emails in a timely fashion. I wasn't super happy about it, but there were options, plans, and backup plans, and backup plans for the backup plans, and I was ready to move forward.
Then, in a stroke of good luck, my preferred vendor had the exact part I wanted back in stock by Friday afternoon, they responded to an RFQ for custom programming and returned it over the weekend. On monday morning, it looked like a few hundred has been sold, and while I was filling out the paperwork for a custom programming order, a few thousand more had been sold, leaving only about 1200 pieces in stock.
It means someone probably had a standing order, waiting to buy up that inventory when it became available over the weekend.
I called to make sure they held some stock for me and my order, the paperwork is in, and we're good to go.
So the next small scale batch is underway!
best regards
Sam
aka THE Awkward Engineer
* Footnote on the Vickrey auction. One of the risks of running the auction was that people would not make good on their bids, which would throw the whole process off. Everyone delivered funds in a timely manner, so thank you, you guys are awesome.
I also found it really interesting how the bids were distributed for the Clocks. As promised, everyone paid less than what they bid, but because the distribution was relatively smooth, nobody received a particularly outsize discount. This seems like an indicator of success for achieving some sort of bidding optimum, but I'm just happy that I can sell Clocks and provide them at a discount to the respective individuals.
]]>Every now and then, someone points out that I'm not *that* awkward, and then they ask me how I picked the Awkward Engineer name. First, I usually question their judgement and also respond that they've never seen the single, unmarried version of Sam try to talk to women and find a girlfriend.
But here's the official story of where the name comes from:
At some point in my mid twenties, I had a friend who, no joke, picked up a CO2 tank and a pressure vessel off the side of the road somewhere in Cambridge, MA. Given the number of universities, laboratories, and home brewers in the area, this wasn't that eyebrow raising, but I digress.
This friend then went about carbonating anything and everything she could put in the pressure vessel. Beverages, fruit, vegetables, jello, yogurt, etc... Anything with some water content will absorb some CO2 and get a bit of the fizzy 'soda' feeling when you eat it. We even tried carbonating marshmallows. (As I recall, they sort of collapse under the pressure of the CO2, then re-inflate when the pressure is released, and retain a bit of fizz.)
The carbonation was really becoming obsessive, but another friend said something along the lines of "Oh, it's just a phase, it will pass."
And in that moment, something clicked in my brain, and I realized that all my quirks, twitches, odd habits, dating foibles, and misadventures with trying to talk to women weren't just a phase. I was in my mid twenties. I wasn't going to grow out of it.
This was just who I was.
I decided I might as well roll with it, so Awkward Engineer became the name of my blog. Fast forward several years, and I'm very lucky that my now wife basically clubbed me over the head and instructed me to ask her out. But that's another story for another time.
Best regards,
Sam
aka THE Awkward Engineer
Hi all!
Today's post is about software backlogs, why they often turn into quagmires, how to fix them, and better yet, how to prevent quagmires in the first place. Also we'll dunk a little on JIRA, you know, because we can. (Every word of ifuckinghatejira.com is true.) The most important tip is that I try to do as much story writing, collaborating, and revising in a shared online document before the stories are stable enough to load into a ticketing tool, heading off a mess, but there's more to it, so read on!
In almost every book on agile I've ever read, they describe a beautiful flow of work through the backlog. Large, partially formed pieces are at the bottom of the list, then they get refined and broken down, and finally, the small pieces that are ready for engineering float to the top, where they can be loaded into a Sprint for engineers to work on.
Periodically sorting and cleaning the backlog (often called Grooming) is meant to keep the backlog in a nice, neat, prioritized state, with the highest priority, most important work always at top.
Engineering is often the most expensive, labor intensive bottleneck in a product team, so keeping a steady supply of the highest priority work ready for the engineers is meant to ensure the team is working on the optimal thing.
In theory, this sounds lovely, but then real life happens, and you get a mess.
When I say mess, the problem that I've repeatedly seen is software teams with hundreds and even thousands of items in their backlogs. Nobody can hold that much stuff in their head, and I'm betting that the "prioritization" in the backlogs just means that the most recent items with the most attention end up at the top of the list. The queue starts to form from the front, and the rest of the backlog is dead. It's hard to having meaningful grooming discussions over what's important.
Having better knowledge of story writing and a good process for breaking down stories certainly helps, but let's be clear here: most PM tools set you up to shoot yourself in the foot.
The first thing that happens, is that the act of writing down the story into a ticket in any one of these tools makes it inflexible. Creating tickets, naming them, filling in fields, - all these acts create user friction that makes it slow to split, change, or modify a story later on. (JIRA, somehow, even marks it hard to delete a ticket, rather than archiving it or progressing it through the usual workflow.)
The other thing that happens is that the text field of the ticket itself is a terrible text editor for collaborative work. Any comments on the ticket are placed as footnotes, rather than inline, and any of the features of a modern, collaborative online editor are lost.
So what happens, is that the stories, once created, end up looking something like the picture below, and they never get refined.
Some classic symptoms of this failure mode are stories that take forever to close, lots of work happening outside the ticket system entirely, and piled up and abandoned stories that were no longer relevant after they were written.
The other place I've seen tools lead people astray is by creating the illusion that work is being smoothly broken down, providing ticket types like epics, stories, and tasks. (And in the case of JIRA, also sub-tasks. Again, please see ifuckinghatejira.com)
So in theory, you should be able to create epics, then break those down into user stories, than in turn, detail the direct work or "tasks" that go into each user story. (Others may use different pieces of terminology, I prefer epics, stories, and tasks).
Once again, real life happens, and the shortcomings of the tools become apparent. JIRA in particular, has UI quirks around how it implements sub-tasks and if they even appear in a backlog or on a scrum board. (Trello, Asana, Clickup, and others all handle subtasks much better.) JIRA quirks aside, the tools now fail in a handful of ways. Either all stories are visible in the backlog, regardless of refinement level, or the backlog is limited to a single epic, regardless of whether the team has multiple epics open.
When stories from multiple epics coexist in the backlog, I usually say we've gone from "apples to oranges" comparisons, to comparing "apples, oranges, raisins, walnuts, and bananas." It just doesn't work. Prioritization needs to happen at a higher level.
The solution is to two part. First, maintain separate backlogs at multiple resolutions. Second, keep the fine resolution refinements in a collaborative document and out of the ticketing system for as long as possible.
Typically, this means I'll write out user stories and acceptance criteria in a Google Doc where they can be commented on, debated, easily rewritten, or split. When the stories are stabilized, and we're to the point of understand the work tasks, I'll load the stories into JIRA, where they're ready to be estimated, prioritized, and scheduled into Sprints.
Finally, for the fine resolution backlog, build filters so that only the very top of the "coarse" resolution backlog appears in the fine grained backlog.
What this ends up looking like in JIRA is a scrum board for Epics and a scrum board for Stories, with some filtering to determine which epics are allowed to appear on the story board.
I'm shocked at how few tools support flows like this, and in particular, how tricky it is to implement in JIRA. For my money, shortcut.com is probably the best "out of the box" tool I've seen for software.
There's also no substitute for having a good sense for what a "story" is, as useful, functioning piece of software. (I still high recommend User Story Mapping) and a process for designerings and engineers to break down stories together, but that's a topic for another blog post.
If your team could use help getting your backlog in order, I'd love to help. Just email me!
best regards
Sam Feller
aka THE Awkward Engineer
Another mini book report for you! As per usual, they are listed in the general order of how much I recommend them and/or how much I enjoyed them.
Totally unrelated, I keep telling myself I'm going to finally pull the trigger on putting up the Vickrey auction for Voltmeter Clocks. Next week is the week, I tell myself. Stay tuned. In the meantime, back to the book report.
Radical Focus - I highly recommend this book about OKRs. It mirrors some knowledge I've learned the hard way and expands on it. Basically, the objective should be qualitative and inspiring (often using superlatives!), while Key Results are numeric, and - this is important - are reviewed frequently, as often as every 1-2 weeks. Quarterly or bi-quarterly is not often enough. Here are some additional lessons learned
SPIN Selling - This is a landmark sales book that's remained popular for at least the last 30+ years. It dispenses with the "Always Be Closing" philosophy of high pressure sales in favor of understanding customer problems, using Implication questions to really hone in on the pain (almost the opposite of The Mom Test), and matching benefits to customer needs.
Big takeaways for me
Build - Highly recommend Tony Fadell's book on his career experiences and everything that lead to the iPad, iPhone, and Nest Thermostat and Nest Protect. He covers topics as diverse as team building, operational cadence, defining "good enough" (hint, write a mock press release first to know what "good enough" looks like), organizational growth breakpoints, hiring/firing, managing boards, branding/marketing, and more. Tony learned some painful lessons the hard way early in his career, and seeing the path he followed is inspiring.
Big takeaways for me:
Decisive - Fascinating book about the psychology of decision making. I read this on a a recommendation from Continuous Discovery Habits. Basically, the author shares a few techniques for avoiding some common traps and biases that make it hard to make good decisions. Some of the highlights are
Why Buddhism is True - The author takes concepts in neuroscience and makes connections to Buddhist teachings. In short, the human brain evolved special "subsystems" for dealing with personal safety, food drive, reproductive drive, family care, and broader community and social interaction. These systems worked well for hunter-gatherers, but aren't necessarily well adapted to modern life. (The canonical example is ruminating over embarrassing yourself in front of a stranger. Staying on good terms with your hunter-gatherer tribe is critically important, so your brain should worry about how other people think of you, but strangers you'll never see again probably aren't worth the time worrying.)
In a similar fashion, the human tendency to become ungrateful for the status quo and hunger for more, is again, probably more useful for hunter-gathers than for modern life.
The key to quieting the subsystems that drive internal thought processes and vie for attention in the conscious brain is breaking the feedback loops that say paying attention to those neural circuits is working.
This aligns with the author's experience with Buddhist teachings and meditation practices, to recognize those thoughts as cravings or desires that will ultimately lead to dissatisfaction, and rather than trying to fight them, just acknowledge them, until you grow bored with them, and they subside.
There's more to the book that I'm glossing over, and the author gets into more abstract ideas and concepts of self and Nothingness, and arbitrariness of drawing a line between yourself and the world around you ultimately, it's just signals to the brain. This book isn't for everyone, but if you're interested in meditation, Buddhism, or neuroscience, this is worth reading.
Influence - The book identifies seven quirks of human behavior where people act in seemingly illogical or arbitrary fashion. For example, the principle of Reciprocity means that if someone invites us to dinner, or makes a kind gesture, we feel obligated to later return the favor. Social Proof (everyone else is doing it), FOMO (or scarcity), Consistency (stubbornly staying the course, rather than changing your mind, just to appear consistent, or to avoid the appearance of having been wrong in your original assessment.) Honestly, this is one where you could probably just Google for a summary.
Pencil Me In - A cute book with different ideas for making visual notes. It won't magically make your drawing better, (for that, you'll need to practice), but it does contain great sources of inspiration for developing a visual language for business sketching.
Buddhism Without Beliefs - I read this as a follow up to Why Buddhism is True. It focuses more on the practice of Buddhism and the teachings of the Buddha, and why these ideas are still valid, without needing to subscribe to Buddhist ideas of reincarnation or achieve Nirvana.
UX for Lean Startups - Just skip this one. My friend's review was "I give this book to people who don't know what UX is but should know about it, like CEOs. It's not for learning UX."
This Book Will Make You Kinder - This came from the "return to shelves" cart at the library, which means someone from my neighborhood thought this book was worth checking out. That person was wrong. Let me save you some trouble and I'll summarize it for you - "The more you know about other people, the nicer you'll be to them." Boom. I just saved you several hours.
I've mentioned briefly in a few previous blog posts that I work with a personal assistant. Some readers expressed curiosity about this, so today's post is about my experiences and advice on finding an assistant and how we work together.
The whole reason for hiring an assistant is to leverage your time. I hired an assistant a few years ago when I had an hour plus drive to and from work. That was two hours or more lost a day when I couldn't work as usual, but I could talk on the phone, dictate things, and answer questions. Working with an assistant was my attempt to claw the time back.
Basically, if it can be done with a cell phone and the internet, it can be delegated to my assistant. The bulk of what my assistant handles involves running my CRM, following up on calls, and scheduling. It's something I know I would drop on my own, but my assistant helps keep me on track. In a way, its a form of an accountability mechanism, sort of like hiring a personal trainer to make sure you go to the gym.
Aside from the CRM, my assistant also handle a lot of tasks that are heavy on "follow up". For example, I organized an ice cream tasting event several weeks ago that involved calling 4 ice cream shops in Somerville, getting pricing for tasting sized servings, and confirming they were ready the weekend of the event. It sucks up a lot of mental space, especially if a shop is only open at certain times, or the manager is only in on certain shifts. Tasks like that (calling venues for birthday party package rates, calling architects to see if they're taking on new clients, rescheduling the dentist, etc), are perfect for an assistant.
My assistant also handles a number of small research projects. For instance, working with the Veteran's Administration to find the WWII service records for my grandfather.
Finally, I review the status of some of my own personal tasks with my assistant, which keeps me honest and on top of things.
Typically, I do a 10 minute phone call in the morning with my assistant, either while commuting to work, or during the pandemic times, while doing chores around the house. The typical routine is to check items we've snoozed to see if they've come up again. If the ball is in someone else's court, we'll check if it's due yet for a volley back and will ping it if needed, then we run through active projects, then quickly run through dictation on anything in the CRM system.
My assistant has access permission on my calendar, my blog, and a few other systems, usually managed through regular account permissions whenever possible, or otherwise through a password vault. I've set up permissions for an email alias, so messages can look like they came from my assistant, or they're can be made to look like they came up from me. (Note, this doesn't grant broader email read access).
When Interrobang was running full steam ahead, we'd have a call every morning, but now we typically check only two mornings a week (hint: she has capacity for additional clients!). I actually looked back at the meeting load for Interrobang, and I think my assistant helped me set up 132 meetings or video calls over the span of several months.
I went through a few assistants before I found one I've worked with for the last few years. Here are some of the options for finding one:
Starting in maybe 2018-ish, "AI" powered assistants were really trendy. Turns out, it was a giant "wizard of Oz" demo, where they had real people behind the curtain pretending to be the AI while the engineers frantically tried to use that behavior as a ground truth for a data set so they could learn and automate everything to reduce costs. Those didn't work so well and most of those are shut down. Not a recommended option, but those are out there.
Another option is to work with an agency. They typically have lump packages for a fixed number of hours of work each week, they'll assign an assistant to you, which means they'll take care of the vetting/hiring/etc. I tried this for a period of time, but the assistant assigned to me quit with the agency, so I went looking again.
Finally, you can find an assistant via a freelance site, like Upwork.com. This ranges from $3-5/hr call center employees in the Philippines, to $10/hr assistants in Latin america, or US based assistants at $30-90/hr. ($90/hr is for executive assistants for big company CEOs). In my experience, you get what you pay for, and the most important thing I was looking for was evidence for good soft skills. And yes, this means you'll need to put up a job post and screen resumes. This is my recommended route.
I had an assistant out of Jamaica for a little while (only the mildest hint of an accent), but her experience was mostly working in help support call centers, and she lacked some of the soft skills to anticipate needs and tone when following up on tasks. My current assistant was formerly a paralegal (strong indicator for soft office skills), is US based and in my time zone, and has been awesome. So you it might take a little while before you find someone you like working with.
When I look back and ask if the time with an assistant is worthwhile, it's less a question of "did I feel like it was working" and more like "would I have gotten X done at all?" In terms of the CRM, which has gotten me my last several jobs, I know for a fact that I'd let it drop when I got busy or stressed.
I'm a big believer in systems, and working with an assistant is part of my system for making sure certain things absolutely get done.
best regards!
Sam
aka THE Awkward Engineer
Today's post is about serendipity and discovering a better way to pop popcorn. It could be this is just common popcorn knowledge, but I did some low key Googling, and feel like I might have something new here, so I'll share. The punchline is that by tipping a flat bottomed wok at an angle, you create a pool where the oil collects in the corner of the pan. Kernels tend to roll back into the oil pool, while popped corns tend to explode out of the pool and to the cooler parts of the wok. The result is fewer unpopped kernels and lower likelihood of burning the popcorn.
Of course, the popcorn problem is well known: How to get all the popcorn kernels to pop, while also avoiding burnt kernels. (And yes, I'm keeping microwave popcorn out of the mix here. I have nothing against it, I just have a full jar of popcorn kernels in my house to work with. Waste not.) I've seen various tricks and techniques on the internet, including using different types of oil, mixtures of oil and butter, different amounts of oil, different shaking techniques, different temperatures, and use of sacrificial kernels to test the oil temperature. Regardless, my 4 year old issued the statement that "Mommy's popcorn is better than daddy's popcorn, 'cause daddy's popcorn tastes burnt."
Well then.
The gauntlet had been thrown.
It turns out, the solution had been under my nose for a while, but the string of events that lead to it is what I find interesting.
It started at the library, where I normally request books online (thank you Minuteman Library Network!) and then do a quick pickup when they arrive. The whole experience is fantastic, and in my view, totally superior to buying books on Amazon, not to mention much more free. The downside, like any online experience, is that browsing and discovery isn't quite the same.
This is where the "return to shelves" cart comes in. Here, in effect, was a curated list of what people from my community actually thought was worth reading, waiting for restocking. Rather than browse all the aisles, this is where I do a quick check to see if anything catches my eye.
And indeed, something caught my eye. J. Kenji López-Alt had a new cookbook out called simply, "The Wok", and true to it's title, it was about cooking with a wok.
Quick aside, the cookbook is fantastic, and I learned how to use cornstarch to "velvet" meat, which is a game changer.
Anyway, the book had a recipe for a fried egg which involved tilting the wok to create a deeper pool of oil, which didn't click right away, but was lingering in my brain somewhere.
So after reading The Wok, I was super excited to cook anything I could in it. Naturally, you can use it to stir fry on high heat, but the steep walls of the wok add some versality, and it's still a metal pan, so you can saute, sear, braise, stew, steam, and deep fry as well. Part of my "cook anything and everything in the wok" phase including popcorn, which admittedly including a few burnt batches.
After rigging up a steam basket for dumplings with a wire rack one day, I wondered if I could figure out some sort of arrangement with a cooling rack, similar to what I'd seen at a fairground kettlecorn popcorn stalls. Basically, the exploding kernel passes upwards through a net, but the fully expanded kernel can't pass back through and down into the kettle.
After some puttering about trying to fit a square peg into a round hole with a rectangular cooling rack in the round wok, leaving the wok somewhat askew, it occurred to me to try tipping the wok at an angle.
The angled wok worked wonders! All the kernels rolled into the pool of oil, and the explosions of popping popcorn would jostle them and keep them moving. The popped popcorn would either stay out of the pool, or get blown out by the next kernel. And any kernels that got knocked out of the pool just rolled back in. It was the best batch of home cooked popcorn I had ever made! No burning, with just a single unpopped kernel left!
Finally, for the bonus: salting the popcorn and giving it a stir-fry tossing motion in the wok is incredibly satisfying. Highly recommend.
Best regards!
Sam
aka THE Awkward Engineer