Categories
Uncategorized

Respect the Journey

Frodo shows up in Mordor and flips the ring into the molten core of Mount Doom. He has no scars. His clothes are clean. There has been no suffering. Sam has plenty of elvish bread for the return home and it’s back to the Shire in a day or so. This is a completely different story than the one we know. It has the same outcome, but it’s entirely devoid the hard lessons of the journey that preceded it.

When we are new to a situation, it’s not always clear what journey the characters involved have been on. We can try to rally them to our cause, but if they have just gone through hell and back, the response to our pleas will certainly be different than if the team has been doing well.

There is nothing more annoying than to experience a great amount of toil and trouble, only to suffer fools at the end of the journey wondering “what took you so long” or “why the frown?” So, be empathetic to those who’ve just achieved something. It may be that it took every ounce of their strength and willpower.

It may be their Mordor.

Categories
Uncategorized

Trust

I’m trying to trust more, but it’s hard. I see the failures around me as evidence that I continue to need to work to help others achieve success.

But the reality is, I fail as much as anyone. More often than I’d like to admit, the failings I observe are as much the result of my actions as those around me! What I need to do instead is to build trust. Or rather, I need to grant trust to those I love at home and to those I work among.

I can remember, when I was just 16 years old working at a local hardware store, the sporting goods clerk was trusted with the gun case. He was the elder clerk and was so heavily trusted to do his job and to care for the revolvers, pistols, and rifles, that he has been in that role for nearly a decade before I started working there.

Do you know what he did one night before going home for the night? He let me clean and clear the gun cases and put them in the safe for the night. Me, a 16 year old who had never shot a pistol. This was not supposed to happen for just anyone. You needed training. You needed to be older. To have experience. You needed…trust. Did I do anything to earn this trust? Not likely. But there I was doing my best to put these machines away without a single nick or knock and being more careful than the most ardent gun owner.

Trust can liberate. Affording trust can, ironically, be the trigger causing the trusted to actually be deserving of it.

I will strive to trust more and in so doing, to respect the intelligence and abilities of those around me.

Categories
Personal

Plano 6303

When I was about eight years old, I was given my very own tackle box; a classic Plano three-tray box in a nice two-tone, dirt-inspired brown — Model 6303. At the time, I remember thinking that it was extravagant; too much perhaps for one young man to have at his disposal. The fish wouldn’t stand a chance! With three rows of compartments for lures, hooks, weights and bobbers, it seemed I would never grow out of the utility of this product.

And you know what? I never did…it’s in my garage to this day!

Made of thick plastic and a few brass pins and latches, the box has stood the test of time better than many other things in my life. The first thing I did was put my full name and home phone number on the underside of the box, which you can read to this day (Sharpie being, evidently, something else that stands the test of time). Whenever I see it now, I can remember the countless times I’ve hauled that box to local ponds in search of bluegill, streams full of crawdads and carp, and most famously to a family friend’s private lake containing big mouth bass capable of consuming small birds.

Here’s to the great things in life and the memories they enable.

Categories
Uncategorized

All Stars

My son recently participated in an All Star tournament for his Little League. Watching him through the tournament, the confidence he built throughout the regular season was clearly abandoned for feelings of alienation and a general lack of passion.

When we feel the pressure of highly capable people around us, it can affect our mindset. We strive to be great in our given discipline yet when we achieve greatness and are subsequently thrust to the stage, we sometimes wither into our former selves.

Every game has an important, elevated “next level” stage like an All Star game in Little League or an executive leadership meeting for a new Director. It’s in these situations that you’ll inevitably notice that some of the players are not shaken by the heightened pressure but instead thrive on it. When others crumble as the game intensifies, these individuals exude a calmness under pressure which, when it becomes contagious enough, can spur on the team’s ability to succeed in spite of their nerves.

What, I wonder, causes some of us to break under pressure versus see the pressure as just another game to be played? Perhaps the only way to build this mindset is to have played those high pressure games enough to not be fazed by them.

Perhaps it’s on the leaders of great teams, then, to practice high pressure situations on the fields of greatness (real or simulated), in order to build comfort and coolness under pressure. If we can do that, maybe our entire team can be All Stars.

Categories
Uncategorized

Five Ways UX Designers Can Build More Acceptance of Their Work

Have you ever attended a design review meeting — perhaps to review the results of a design sprint (see Jake Knapp) — where the team seemed to love the work, appreciated the research that went into the design decisions, and yet ultimately decided not to move forward with the proposed design? How frustrating. Don’t they know what this means to you!!!

I believe there a few key reasons why this happens and can offer a few tips and tricks that can help avoid this scenario.

1. Emphasize How the Deliverable Solves a Problem

Many creatives spend so much time focused on the results of their efforts that they forget to reiterate what the design actually does to solve a problem, capture an opportunity, or otherwise improve a product. When presenting your creative work, remember that your audience must first agree that the design was necessary in the first place so you have to make additional effort to remind them.

Put yourself in the shoes of the stakeholders who care deeply about the problem being solved (e.g. product managers, founders, customer advocates, etc.). If your presentation doesn’t resonate with a very real issue they can relate back to the customer, you will struggle to keep their attention much less get their approval or constructive feedback.

2. Demonstrate How the Design (and it’s Hypothesis) Has Been Validated by Actual Users

Research shows that people make decisions based on something called “ambiguity avoidance,” wherein the decision maker prefers an option having known and quantifiable risks over options with unknown or incalculable odds (see Ellsberg Paradox).

If a problem or improvement is hurtled through an idea-to-solution assembly line without being validated along the way — either by potential or actual users — then you have created a potential for stakeholders to choose a more quantifiable risk. In other words, they will prefer a solution to the problem having fewer unknown risks and which will very likely (and unfortunately) be a meager iteration of an existing solution.

If your design truly has the stuff your users’ dreams are made of, make it clear to everyone how you snatched those dreams from their minds and delivered it in your work. Show those A/B test results, the user research, the heatmaps of prototypes, and so on. It’s really, really critical to build trust and clarify that there are risks in this design, but that they are known.

3. Align the Design to the Long Term Strategy

There has perhaps never been a more strategically focused design effort than what is happening in 2018 with Tesla Motors. I would wager that the internal reaction at Tesla to the notion of an electric semi truck was less than exuberant. But consider this excerpt from the now famous Master Plan blog post:

The strategy of Tesla is to enter at the high end of the market, where customers are prepared to pay a premium, and then drive down market as fast as possible to higher unit volume and lower prices with each successive model.

When applying the strategy above, it’s clear that the Tesla Semi announcement was strategically brilliant. It is an expensive, premium product design in a niche area of their existing area of expertise: electric vehicles.

When you pitch your next design, consider how it aligns to the most broad and ambitious goals of your organization. You may find that it inspires commitment at the very highest levels of the organization.

4. Make it Easy to Enthusiastically Sell

Some design work is easy to love, but hard to sell with passion. The design may pluck all the right chords for the existing market, the test users, and even the overall strategy but if it’s absolute nightmare to talk about, build relationships from, and illustrate the vision, then you have failed.

So, how do you make your designs easier to sell? You need to anticipate what your sales prospects will ask the salesperson immediately after demoing your software. Imagine questions like:

  • This looks good, but what if we want to change the colors to more closely match the other apps we use?
  • How do I connect it to [application X] where most of my data is?
  • We have users who are remote a lot, can you show me the design on a phone…can I pull it up on my phone right now?
  • What if we only want [Feature A] and [Feature B], will you give me a price for not having [Feature C]?

If your design is not flexible, it will not give your sales team the enthusiasm they need to present it well. And remember…

“For every sale you miss because you’re too enthusiastic, you will miss a hundred because you’re not enthusiastic enough.”
 — Zig Ziglar

So remember: an enthusiastic salesperson is the ambitious designer’s best friend.

5. Consider How it Can Be Efficiently Built

Last but certainly not least, you must consider the complexity to build the design you are communicating. If your work is beautiful, but proposes an entirely new UX pattern set or uses untraditional metaphors, the engineers will struggle to scope, plan, and execute your work in a timely manner.

Since your design needs to be iterated on in the market (you know that, right?), it’s in your best interest to produce an artifact that can be built quickly without a lot of prodigious back and forth between product, design, and engineering.

A popular and emerging technique to achieve this is to design using existing HTML and CSS, in code, so that you can be certain that engineers can quickly pull from their grab bag of already built components. Do this and you will get amazing collaboration from the engineering team.

I hope you find this helpful in preparing you for that big demo, presentation, or design review. You have chance to make a great impression and get buy-in so don’t waste it!

Categories
Uncategorized

Entrepreneurship = Taking Risks

entrepreneur |ˌäntrəprəˈnər| noun
a person who organizes and operates a business or businesses, taking on greater than normal financial risks in order to do so.

I am not an entrepreneur, but I know one when I see one — the risks they take define who they are.

Entrepreneurs have no other choice but to take their vision to the world. They invest everything they have into their ideas and the businesses they build to turn them into value. They bore their friends at dinner parties and exhaust their energy (and that of their families) to provide great service to their customers. They use their garages for product development because they can’t afford an office or lab.

Most of all, entrepreneurs take abnormal risks at the hope of outsize personal or social gains.

Before their ideas take hold, they are betting the proverbial farm on it’s success. If the idea fails, it’s back to square one, often without a plan B.

So, entrepreneurs must connect to people who can help them, burn the midnight oil researching their target market, and obsessively test the core hypotheses of their ideas. If it they didn’t do it, no one will.

I had a lunch recently with a local entrepreneur who personifies this definition. If his idea takes hold, it will potentially impact every small and medium business who cares about employee engagement. He has initial customers and is getting great feedback, but I can tell the business is a huge financial risk for him. It’s all consuming and all or nothing.

Conversely, I’ve also mentored individuals with tons of ideas but who are taking no risks to realize them. With these founders, in place of desperation and risk, there is a safety blanket of a 9–5 job. In place of a firm commitment to a vision there is an unproven belief that their idea is unique and original.

And a total lack of risk.

I want these founders to GET REAL. I want them to feel the urge to burn the candle at both ends in pursuit of their vision…and if the current vision isn’t good enough then I want them to pursue a vision that is. I want them to stick out their necks, borrow money from a wealthy Aunt, or somehow just put more skin in the game.

I get it. I was recently not willing to risk my own job security, cushy day job, and free time to build an AI-based stock recommendation platform with some casual business buddies. Without the same risk taking as my fellow founders, I didn’t have equal skin in the game and was not the team member I could be. My involvement started to look less and less like an entrepreneur — as defined above — and more like an advisor/employee.

So, if you are truly all-in on your business, then I suggest you take whatever risks you need to match what you expect to get out of the business. This tells everyone — most importantly yourself — that you are not messing around.

That you would risk it all.

Categories
Uncategorized

What’s the Problem, Again?

4 Simple Rules for Avoiding Death Spiral Projects

At times in my career, I’ve found myself working on projects that I would describe as “going through the motions.” While these efforts often began with the best of intentions — “make the customer happy”, “rewrite our client/server software for the Web”, and so on — over time they became death spirals for one primary reason: I lost sight of the problem I was solving.

Wait, what was I working on?

By following a few simple rules about What, How, Why and When to solve a given problem, you can avoid the same fate.

What: Make Sure There’s a Problem

There is one fail-proof antidote to the poison of death-spiral projects. Do not let a day go by without asking yourself…

“What is the problem I’m working on?”

It seems obvious, but in my experience it’s rare for an entrepreneur or creative person to stop what she is doing and do a self check-in on what exactly is the problem being solved.

After coming up with an answer to this question, decide if the overall problem is big enough to justify continuing to put effort into solving it. Sometimes a problem can be solved with a quick and dirty approach rather than the big project you have planned on the horizon.

How: Make the Overall Problem Smaller

Now that you’ve got an important and large problem to solve, ironically, you need make it smaller by breaking it into chunks. Creative people often avoid taking the time to break down a problem into it’s sub-parts, favoring just getting started #mvp #hustle #killyourself.

But if you break a problem down, your mind can consider a more focused and doable solution from day to day, without having to consider massive boil-the-ocean solutions that are beyond your reach. I like to do this by just using indented bullet points in a text editor. Example:


Once you have a break down, choose the smallest and most achievable part of the problem to attack today. I love the feeling of solving a tiny little piece of what I know to be a larger problem every day. This is hard if you allow yourself to just jump into the big problem solving without following this rule.

Why: Make the Problem Matter to You

To me, solving problems with software or design is a personal matter. I get very immersed in a problem and always look to solve it very deeply. However, if the subject of the problem or the potential benefit don’t ultimately matter to me, I will allow the core issues to linger and my solution will be half-hearted.

Like Sisyphus rolling his stone up a hill, solutions provided by people who don’t care about the problems they solve are bound to roll back down the proverbial hill of needing to be solved again.

This guy is on the The Struggle Bus

The only consistent way I’ve found to avoid this scenario is to surround yourself in problem “sets” that speak to your skills and passions. For me, these are problems relating to building solid, scalable digital products efficiently. So, I surround myself with challenging businesses, customers, and engineers in the software space. I imagine that, while I might be good at solving problems as a nurse or a pilot or a teacher or a food critic, it is not what I am ultimately motivated to do and I would not excel.

When: Is the Problem Actually Solved? If So, STOP and Find Another One

Another strange observation I have made is that teams and creative individuals never seem to be satisfied with their solution. The recent emphasis on iterating on a solution over and over again has caused many to get stuck in a rut of perfecting a single problem, which they believe needs to be solved more accurately, efficiently, and with greater value generation.

Sure, iteration can be good, but in many cases there is too little time and too much competition to justify whiling away on a single problem. Just identify it, make a solution work, and move on!

With some simple rules in your mind as you go through the day, you’ll find your problem solving abilities will expand as you make more effective and efficient choices in what, how, why and when to solve the problems you are best suited for. Best of luck!

Categories
Management Uncategorized

Advice for the New Engineering Manager

When I first started leading software development teams, I was extremely naive about what it meant to be a manager. My father was a small businessman and lead his company and its employees with an unmistakable authority and command-and-control style. I was naturally influenced by this approach early in my career and applied it to some of my first teams. What a disaster! I’ve since learned this and many other lessons about what it means to lead engineers, developers, and product managers in their day-to-day work.

So, here are some opinions on engineering management I think could help the newly promoted.

Let Go, But Stay Current (or, Know Your Strengths)

There is a lot of content on the subject of whether engineering leads or managers should continue coding, architecting, and being an individual contributor. It’s very tempting for the new manager to believe she can continue to code. After all the source code is right there, still just one git commit -m 'Fixed typo' away from being improved upon. While I think the answer can vary based on the company, the team, and the product, I would argue it’s better to get out of the code for the most part.

I was never a particularly strong developer; often leaving tasks to the last minute, under-scoping work, struggling in the pre-Stack Overflow days to understand harder concepts, and so on. But I did learn that the most effective engineers are commonly on the most effective teams and so I instead began gravitating toward making sure teams around me were healthy. This often meant negotiating time to reduce technical debt (often of my own creation¯\_(ツ)_/¯), upgrading development systems and IDEs, and automating tasks like builds and releases. This became a strength overcoming any weaknesses in my coding ability and I began to take satisfaction in a team’s increased ability to perform without my direct contribution to the code.

So, while I believe the first thing to get right in your new role is to focus on the team’s health, I also believe it’s important to stay current on technology and programming methodologies being deployed by your team. As a manager, you will be asked to break ties all the time (or just shepherd conversations in one direction or another) and it’s best to know a thing or two about the current issues being considered. Don’t be the manager who defers tough decisions by bringing up the good ole’ days when you wrote that CORBA interface that made the company so much money in 2003. It’s irrelevant today and, anyway, your code probably had to be thrown out at some point.

Manage Your Team’s Mindset

Today’s workplace can be a stressful place. We seek to stay productive throughout the day, ever seeking the elusive “flow state.” Meanwhile, a successful software team is often an endless fountain of distraction. The more users adore your software, it seems, the faster and louder are their complaints about a bug you just shipped or how a feature misses the mark. What a catch 22! How can we achieve high levels of productivity when doing so causes more chances to be distracted?!?!?

My strategy: maximize mindfulness. The software team that can consistently drown out distractions, face urgent “fires” without slipping into endless firefighting, and find peace standing in the front of the mountain of work called “the backlog” is the team that has the correct mindset. Fostering a team’s healthy mindset is now a primary job for you as the engineering manager. They cannot do it on their own.

To encourage a healthy mindset on an engineering team:

  • Assure the team that there is always time to do things correctly, even if it has be a little later than today for the sake of shipping the current solution.
  • Foster a sense of reasonable compromise and give-and-take, even in the face of seemingly intractable trade-offs resulting from the first point.
  • Let engineers pick their own tools or build new ones if necessary.
  • Listen to their needs and observe #allthefeels. Effective engineers will solve problems right up to and including the point of exhaustion, frustration, and even rage. Don’t let it happen.
  • Coach engineers to strive for high quality on every line of code, but ensure they are comfortable shipping things before perfectionism kicks in.

A healthy mindset in an engineer is a precious gift, freeing up the manager to focus on the company’s goals, customer needs, and recruiting new engineers to the team.

Master The Ability to Connect The Work to the Mission, Vision, and Roadmap

This lesson applies to pretty much every role in a technology company, but the impact to an engineering team is compounded many times over. Specifically, the engineering manager must master connecting the company mission, vision, product strategy, and feature roadmap to his or her team’s day-to-day engineering efforts. When a team doesn’t understand why they’re working on something, it breeds conflict, distraction, busywork, and analysis paralysis.

“We all know that these functions must work together toward a common set of goals that involve a satisfied customer and a money-making product. The roadmap is a critical opportunity — frequently missed — to articulate those goals and rally everyone around them. Before you can establish specific goals, you need a vision, a product vision in particular that guides the direction, not only for the goal setting but also for all activity on the product.”

from Product Roadmapping by Evan Ryan; Michael Connors; Bruce McCarthy; C. Todd Lombardo

Like the crew of a ship in the middle of the ocean, a team constantly looks to the captain to tell them where they’re sailing and why. Like a remote island with the promise of treasure chests full of gold, a finished and successful software project should be something each team member desperately wants to attain. So, the engineering manager has to clarify what is so great about the software to be built, the brilliance of the roadmap, what a feature’s purpose is in the world, and how amazing it will be to finish the project.

There is a lot of overlap here with the Product Manager role, so common in startup technology companies. But I believe the engineering manager has a responsibility to make sure these connections are made whether the PM is succeeding in doing so or not.

Meetings Suck. You Will Now Create Them. So, You Suck. But It’s OK.

Dear New Engineering Manager,

Sorry, but your calendar is now officially f*cked.

Best,
The Gods of Management

Remember the days when you had long, uninterrupted blocks of time to just think about a software problem, design a solution, implement it, write tests first and iterate on the final solution? Yeah, those days are gone. But don’t make the mistake of thinking that your whole team has to suffer your newfound lack of whitespace on your calendar. Their time to dedicate to such things should be high, even as yours dwindles to zero.

For more useful and meaningful insights on this topic, just see Chapter 5 of Managing Humans by Michael Lopp. In fact, just read the whole book.

There are many different lessons that can be learned in the span of a management career, but perhaps the biggest thing to remember is that your new goal is really to build better engineers. By removing impediments like meetings, paying for expensive conferences, and coaching individuals through tough architectural challenges, you are not just helping them build a better software product, but also a better self.

“Management is the opportunity to help people become better people. Practiced that way, it’s a magnificent profession.”
– Clayton Christensen

So, welcome to management and soak in the inevitable fatigue, the constant stress, and, if you’re lucky, the chance to build a team that will do the greatest work of their lives.

Categories
Product Management

Evolving Storytelling in Product Development

Imagine you’ve observed a problem that many people around you experience. Like how, for instance, meaningful home automation is still extremely hard for the everyday home owner to achieve. So, being a smart product manager / programmer / entrepreneur / hacker / designer / innovation-generating-machine, you set out to solve this problem once and for all!

Assume, for a moment, we are going to deploy a software solution to this home automation problem. Some time ago, two major schools of thought emerged for solving software problems:

  1. Big design up front (BDUF) – Deep analysis of the problem, use cases, conditions, acceptance criteria, functional requirements, user interface flows, interaction diagrams, and so on with the ultimate deliverable of a massive, beautiful product requirements document (PRD)
  2. Extreme programming (XP) – Immediately start to develop a solution that kind of solves the problem, but without really knowing why, what, and for whom. Put off any robust architectural designs in favor of highly tested, peer reviewed, and simplified code. The deliverable: working software that did some stuff we were asked to do, with lots of passing unit tests

The BDUF approach leads to massive budgets, expensive research, wasteful over-specification, and bloated software which often doesn’t even meet the real needs, which may never have been discovered. The XP approach suffers from constant churn in the code as requirements begin to shift over time requiring architectural design changes and massive refactors to the implementation and UI design, leaving customers clinging to product roadmaps in the hopes their needs will eventually show up there.

What are we to do? How can we describe the home automation problem we want to solve to our engineers, without massive amounts of analysis paralysis or wasteful hacking together a solution as we go?

Our Savior, the User Story

Enter the user story, the venerated artifact of the Agile Manifesto, Scrum, and all things Silicon Valley circa 2010, where we value responsiveness to change over adherence to a plan, iteration and MVPs over big releases and customer sign-offs, and epic ping pong while enjoying Topo Chico over late nights in server rooms.

As a home owner, I want to be able to automatically turn off my lights when I go to bed so that I can avoid spending time turning off a bunch of light switches in every room.

We are hopeful that this short, contextual narrative slices through the process overhead of BDUF and the lack of functional clarity of XP. Business analyst-types, inclined to define the complete set of use cases using the Rational Unified Process (🤢), are instead inclined to write stories that leave off massive functional detail in favor of “let the team decide.” Extreme programmers who just want to build cool shit, must now sit in (gasp) meetings, trying to decipher what the hell words like “automatically” mean and how to scope the level of effort.

But the ambiguity, lack of definition, and risk of misinterpretation in user stories is HUGE. So, we evolved techniques for story estimation, story points regimes (e.g. Fibonacci, primarily), story break downs to reduce scope, reprioritization, refinement, reflection, playbacks and demos, design reviews, stakeholder reviews, customer playbacks, feature toggles, and on and on and on. All in an attempt to simultaneously de-risk building the wrong product and but maintain velocity in delivery.

And still, we build the wrong things, overdue and over budget. All. The. Time.

Milkshakes For Hire

So, along comes Clay Christensen with his ideas about disruptive innovation and customer segmentation around “jobs to be done” (or JTBD). I won’t go into depth on this research here, but if you’re not familiar it is well summarized with the following analogy: a person is not shopping for a 1/2″ drill bit, she is in search of a 1/2″ hole in the wall, the drill bit is merely hired for the job of making the hole (for more see this).

In our history of storytelling to describe software solutions, many now try to apply this type of thinking to agile stories. A popular technique is the job story (explained here), where the focus is shifted away from a persona and more on the trigger of a given scenario giving rise to the need to hire something to do a job.

The JTBD-centered version of our home automation story becomes:

When I am tired and ready to go to bed at night, I want all the lights to go out automatically so I can go to bed without worrying about leaving lights on.

Hmm. Alright. We can identify some of the obvious benefits of this format:

  • Removes the abstraction of “home owner” which is redundant, irrelevant, and incorrect in some cases (e.g. Airbnb guest)
  • Describes the trigger for the action of the lights needing to be off (“tired and I go to bed”)
  • When it occurs (at night)
  • Less about something an abstract “home owner” wants and is more direct that the lights should just go out automatically

So the way we describe what we should build keeps evolving. Both the structure and context of the “job story” focuses, it would seem, on adherence to a few specific rules for finding product-market fit, including:

  • If a product is good at meeting a need, then the need can be expressed as a job that the product is hired for
  • A job to be done emerges when the right conditions occur, which is ultimately more important to specify than the persona to whom it is occurring
  • Customer motivations, then, are necessarily as much about their need to “hire” something to do a job as it is about their preferences, biases, or membership in a persona like “single female” or “student”, commonly used in the “As a ____” user story template
  • Finally, to find product-market fit, one should bias toward first understanding the jobs to be done for your hypothetical target market, then aligning a product as the best possible “hire” for that job

Another Possibility: Empathetic Stories

But can’t we go further than just pointing out a user story as relating to a “job” that someone needs done? What if the ideal scenario is that the job to be done never existed in the first place? Christensen’s theory has several flaws in this regard, most obvious being that the solution provider (e.g. the milkshake restaurant in the canonical research example) is constrained to their existing industry.

Maybe we can do better, with empathy. Empathy–defined as the ability to understand and share the feelings of another–might be something we can employ, when specifying product requirements, to better illustrate the purpose of a given solution. I believe an empathetic mindset causes story narratives to abandon the constraints of existing solutions, markets, and industry norms in a very productive way.

So, our empathetic home automation story would go something like this:

Janice, a mother of two young boys, has just finished paying the bills and loading dishes from dinner into the dishwasher. Her husband, Frank, is in bed already, reading a book as he usually does until long after she’s asleep. Time for bed. As she strolls out of the room, Janice leans back toward the kitchen and says, “Good night,” which causes the kitchen, living room, family room, dining and front bathroom lights to immediately go out. The hall bathroom does not go out immediately as it normally would, since Jake, her youngest son, is in there getting a late night drink of water. The hall light remains on for 20 seconds before fading out, just as an exhausted Janice arrives in her bedroom to find Frank reading, as expected, by the light of the beside lamp, which has stayed on. She enters the bathroom, where a light has flicked on automatically, where Janice brushes her teeth, and washes her face before turning out the light and going to bed.

Here, we learn a vast amount more about the scenario we must design and implement into our solution:

  • The software probably needs to “know” this is Janice, so that the sequence is specific to her. One of her kids telling the house good night two hours earlier should probably not result in the same events unfolding.
  • A “good night” sequence needs to be programmed to be able to automatically turn off, dim over a time period, and turn on simultaneously
  • Some lights should not be turned out, even if “all lights” would typically be turned all at once otherwise
  • We probably should have presence indication in the bathrooms so we don’t turn the light out on anyone

So, you can see the scope of our story has positively exploded, but so has the degree of purpose, clarity, and potential value of the solution. We have a rich and contextual example in which the home automation solution can apply in the real world. Gone is the generic categorization of “home owner,” the myopic specification that lights only go out when saying “good night,” and ambiguous terms like “automatic”.

Perhaps most importantly, this story sounds like the script of a Super Bowl commercial! I would wager that the average salesperson or customer success manager would greatly prefer seeing the empathetic version in a release note over either of the previous stories.

Do we all have the imagination and creative writing skill to specify our products in this manner?

I think we must, if we are to deliver products that we love designing, building, and supporting.

Categories
Mentorship

Saying Goodbye to Bob

Bob Montgomery was a coworker, friend, and cherished family member to so many of us. But for me, he was also a mentor. He and Janie were responsible for the success of my internship at AMD in the Summer and Fall of 1998 and, as a result, much of my career in software that followed. I don’t think I ever told them what that meant to me. I’ll try now, if it’s worth something.

As I look back on my career over the past 20 years, I’m struck by how much of it was not really a personal choice of mine. Rather, it began with Bob’s decision to bring someone into his work life, to live in his home for six months, and to deliver on a promise to his coworkers that a young business student from CSU Chico could add value to the AMD team. My mentor, it seems, chose me.

Bob came into my life through my wife’s sister, Amanda. In late 1997, Amanda had been working as an usher for the immensely popular Chico Heat baseball team here in Chico. Her skill in serving beers to the premium section caught the eye of the Heat’s closer, Josh Montgomery. One thing led to another and I suddenly had a connection to Advanced Micro Devices (AMD), through Josh’s father Bob. This series of events occurred, as can happen in close-knit families, without me even asking or prodding Bob for an internship. My mother-in-law Lorna probably spoke to Amanda, who asked Janie, who likely mentioned it to Bob and so on. I don’t know the story, because I selfishly never asked.  Being twenty-one has it’s downsides.

So, Bob decided that I could use his help and vouched for me at AMD. He decided his input, experience, and guidance was worth passing on to me. What I didn’t know at the time, was that Bob and Janie were to become a huge part of who I am today.

As the summer of 1998 approached, I prepared for an internship at 1 AMD Place, Sunnyvale, CA. Having agreed to take me into their home for an extended six month period, Bob and Janie received me and all of my worldly possessions–predominantly stereo equipment and a gaming computer–to their beautiful home tucked into the forest surrounding Felton, CA. Soon after the Spring semester ended, I began work at AMD.

Fast forward to January. After a busy and stress-filled internship–there was this thing called Y2K that everyone was all freaked out about–I returned to Chico in the Winter to finish up my degree. And in the process, Bob and Janie had become my friends and my family; my Felton Mom and Dad.

I want to thank you, Janie, for all that you did for me. I am so sorry for your loss.

In the short time I was under Bob’s informal mentorship, here are a few things I learned:

  • How to treat your coworkers with respect and to earn their respect in return
  • How authority figures are people too and can even be friends, as were so many to Bob at AMD
  • How to consider, deeply, what others might be thinking as they go through change in a workplace or in life
  • The value of rising early and exercising (I’m still struggling with this one). You’ve never seen someone improvise in a gym like Bob. 7 reps of bench presses, 23 lunges, some time on the bike…you never knew what to expect!
  • How walking Labradors along the beach in Santa Cruz can feed your soul
  • How to make small talk in the car, even during the white-knuckled gauntlet of the Highway 17 morning commute
  • The difference between drinking alcohol to get drunk–a well-honed skill of mine up to that point–and drinking to complement a meal, smooth out a conversation, and make the stress of the day just a bit less sharp
  • How to treat your wife, whom I observed he loved more than life itself (still working on this one too, honey)
  • How to laugh at life
  • And many more

Recently, I have been working as a mentor with ChicoStart, a local startup incubator, to help energize and grow the tech and entrepreneurial community here in Chico. We talk a lot about what mentors can do to better energize and serve startups in the area. One of the recent efforts has been to formalize what makes a healthy mentor/mentee relationship; how does an entrepreneur choose a mentor and so on. This is a challenging topic for us, as we witness promising young minds making the same mistakes we made years ago. Lately, though, I have been thinking: I just need to be more like Bob. To just give and expect nothing in return. To listen, thoughtfully. To help others consider the weight of their decisions and actions. Bob was so effortlessly good at this.

I hope Bob knew, through the years, that my later career progress could all be traced back to these lessons he passed on to me in those six months in Felton. I believe now, in hindsight, that they are my secret weapons.

He was for me, then, the mentor and friend I didn’t know I needed, but without whom I would not be who I am today. I feel lucky to have known him and will miss him greatly.

Thank you.