Posted on

Motivation & Accomplishing Goals

Life goals, they’re hard to achieve.. Right?

Everyone has goals. It could be improving health, buying a new house, getting that promotion, or starting a business. Goals and change carry a stigma of being difficult. Many struggle and fail to accomplish their goals. Many more fail to even start towards them.

I am personally very goal oriented. I’ve used my mentality to succeed at my job, expand my future potential, cease using tobacco products, lose substantial weight, start a regular exercise program, buy a home, etc. These all are completely unrelated things, except in the sense that they are goals and I attack all of these different goals with the same mindset.

These are some of the things I tell myself to keep myself on track.

“Media is a reward.” – Information overload. There’s so much content out there to consume between all of the different media channels, it can be hard to get enough of it! So much so that I routinely see people risking their lives messing around on their smart phones while hurdling down the highway at 80mph. That’s right, people love to consume media so much that it’s apparently worth risking life & limb for. Media is designed to be addicting, and it works.

One strategy I use to keep myself on track is simple — I don’t allow myself to consume more than I produce. If I want to spend an hour or two reading a book, watching a movie, or playing a game, I first make sure I put in at-least that amount of time up front on a proactive and productive activity. This has helped me procrastinate substantially less and has also cleared my thinking that is now more focused on achieving my goals and less focused on viewing others’ accomplishments.

“Don’t multitask.” – Multitasking skills can be valuable when you’re executing on the daily routine. Being able to cook while talking on the phone or fill out forms while waiting for a file to transfer is a useful skill to have, except when you’re trying to break the day to day. Accomplishing a goal means making meaningful life change, and that requires devoted attention. The goal is new, and any other existing activities that you try to pair with the goal in a multitasking fashion will be more appetizing to your brain than the (difficult) goal. Basically, stay focused!

“You’re overthinking it.” – Just do the thing. Whatever it is, just do it, and nothing more. It can be easy to get distracted by potentials that may never happen and other rabbit holes along the way, but what’s important is that you keep the goal simple. Don’t allow additional scope to creep into the goal. Scope creates doubt. You can always set additional goals to improve further after accomplishing what’s at hand, but trying to make something bigger than it needs to be will spawn a relentless cycle towards failure.

I’m in software, so my goals tend to be product oriented. When building anything, software especially, it’s very easy to play the ‘what if’ game. What if it did this, and had that, and could interact with this other app, etc. All of that is well and good, but if you never stand the basics up, there’s nothing to what-if about. You can always iterate, but you first must accomplish something.

“You’ve got this.” – The most important thing to tell yourself is that you’re capable. It can be easy to let doubt sink in when the challenges seem unsurpassable, but you just have to forge onward. I’m in the midst of watching my mother open her second restaurant. When I was a kid, I never thought I would see her doing what she’s currently accomplishing and has accomplished already. The amount of challenges that she’s faced along the way would have crushed most people, but she has the tenacity to keep the ball moving and that is the driver to her success.

In all, the important thing is just to keep a clear head. Limit your consumption of others’ accomplishments so you can focus on yours. Stay on track and don’t allow added scope to creep in. Most importantly, believe in yourself. Pair self-belief with dedicated time and success in your goals will follow suit.

Posted on

4 Keys to Building Software With Soul

User experience matters. Great functionality wrapped in a poor experience is useless.

When Steve Jobs passed away, fans of Apple and all of its offerings reacted as though they had lost a member of their own family. You could not turn on the news or glance at social media without seeing countless public displays of mourning. The interesting thing though, is the overwhelming majority of these people whose despair was so real and so evident had never met the man.

Why did they care so much?

Why did everyone care so much about a man that they had never met? Corollary to that, why do you see many less Apple bumper stickers now than you did ten years ago? In answering that, I thoroughly recommend watching some of the documentaries out there on Netflix and otherwise regarding Steve Jobs. Man in the Machine is quite good, but there are others and all are worth watching. One thing you’ll notice as you dig into the topic are opinions that Steve Jobs was not as beloved amongst those that knew him closely as he was amongst the Apple fanbase. There are plenty of stories out there. I don’t want to recap things that I wasn’t present for second-hand, as plenty of other people have.

But why society cry for this man’s death?

What Apple created under his watch had so much soul and so much elegance to it that people formed what they felt were tangible bonds with the products that they paid top dollar for. He formed these bonds by achieving a level of understanding of the art of user experience that I’m not even sure Don Norman — author of the Design of Everyday Things which is widely considered the user experience bible — can claim. Unboxing an iPod felt like you were part of a special club. The devices just seemed to work, and always seemed to somehow know what you were trying to do, as if the designers had thought of every single person and every single possibility.

We all use software. Whether it’s the dashboard on your car, the email app on your phone, or the enterprise system you use at work, software is everywhere. The vast majority of software is clunky and hard to use, but very functional. Very rarely will you encounter a product that works so well that it inspires true positive emotion. The fact is, people want the software to get them where they’re going without too much thought or effort, and if you boil everything down to that simple fact, the decisions on how to structure the software start making themselves.

(1) Users Aren’t to Blame

User blaming is effectively blaming the victim of bad design. If a user does something that you consider unintelligent, it’s important to remember that the user should not be expected to be an expert and should not be expected to be a software engineer. Software is a tool, it’s made to improve the quality of life in some way, shape, or form. It’s not meant to be an academic experience – users should not require PHDs in your product.

Software engineers are notorious for blaming the user. In the past, I was the worst offender of it. “Well why did they do that?” I would lament.

They did that because your software didn’t stop them or warn them of the consequences. It’s not something to get defensive about, it’s just something to fix. Bad design should be treated like any other software defect. That starts with the admission that if people can’t figure out how to appropriately use your software, that is your fault. Having good documentation is helpful, but what’s much better is a self-documenting user interface that doesn’t require the user to take so many extra minutes reading documentation. It’s important to have good, detailed documentation, as long as you understand that nobody really wants to read it. It’s just the best option they have for solving their current problem – similar to the manual that arrives with your new toaster.

Don Norman frequently tells a story regarding 3 Mile Island. The idea is that the control room in the nuclear facility was about as complicated as it could possibly be. When it’s so difficult to quickly gather critical information from your user interface, it’s surprising that a disaster hadn’t happened sooner. All of the information can be readily available, but it has to be in a format that a human being could reasonably be expected to operate with. Luckily, when most of us are designing interfaces there aren’t lives on the line, but if you design your product with the mindset that usability and approachability is life-and-death then the improved experience will resonate with your users.

(2) Reduce, Reuse, Recycle
 

The main problem with the vast majority of software packages is the learning curve. This makes complete sense, as those developing the product work with it every day and therefore build up strong muscle memory regarding the basic flow and operations within. In this sense, it’s important to remember that every person using your product will have used it for the first time at one point. As the old saying goes, you most certainly do not get a second chance at a first impression.

Consistency in experience is key. A product developed without standards will inevitably become very hard to use. It’s not an if, it’s a when. The most important standard that can be imposed is limiting the overall number of design elements present in the product. One person or small team should be responsible for the design of these overarching elements, and those building the product should be restricted to using only those elements. Engineers should be encouraged to make suggestions or requests, but should never make executive choices without approval. It’s a challenge to do this without stifling creativity, however if done correctly a balance of innovation and usability can be struck.

Too many software products with great functionality suffer because there is no consistency from area to area. This is typical when every engineer is making differing decisions about how to solve the similar problems. Taking an example software product, one form may have tabs across the top and buttons on the bottom left, while another may have tabs down the left and buttons across the top. Differing fonts, colors, input sizes, behaviors of buttons, etc. All of this makes for a very disjointed user experience.

At work (Deacom), we have a very controlled set of objects. Every entry field in the system is the same size and has the same behavior. Every function, from formulation to order entry, has the same flow. Every editing form has the same standard buttons and functionality — same with every on-screen report. Even though we have almost 1,000 forms / screens in the system, users (internal and external) know what to expect no matter where they land in the system and developers know what to expect when they’re building it.
 

(3) Key Performance Indicators (KPIs)

Value needs to be placed on every single detail of a product in order to drive the type of experience that can take the success of a product to the next level. It’s easy to cut costs on things like Research & Development and Quality Assurance up front, but when those decisions are made, the people making those decisions are setting a ceiling for success. If you want to reach anything close to iPod / iPhone levels of adoration, however, a higher level of effort, engagement, and yes — cost, is required. Take some time to use your product. Really use it, and ask yourself measurable questions every step of the way. Additionally, put your product in front of some people who have never used it and ask them the same questions. The answers to these questions will form your usability KPIs.

Some of the questions I ask are:

  • How many interactions did that process take to navigate?
  • How many seconds did it take to load or execute?
  • What percentage of the interactive objects present can you describe the purpose of?
  • Scale of 1 to 10 — Does this look objectively good?


Take the time to ask these and other, more tailored questions of your product while also asking them of other products you use. Look for industry trends. Figure out what you like and don’t like in everything you use. Use those measurements and observations to determine clear goals, on a monthly or quarterly basis, to iterate towards a better product.
 

(4) Encourage Feedback

With any service, and software is no different, customer feedback should be encouraged. Organizations that repress or don’t prioritize proper feedback loops with their users will fail to recognize critical shortcomings and ultimately be surpassed by their competition. We live in a Yelp day and age, where reputations and stories are available at a keystroke. It’s critical to address negative customer experiences before they end up as negative stories that can ruin your reputation.

Responding to feedback can be difficult because it doesn’t always fit in with where the product is currently going; however, it’s important to understand what the customer is trying to do something that is important to them and to keep an open mind regarding potential solutions to the problem. Many of the best ideas that arise when designing a product originate from grass roots customer experience stories rather than traditional R&D.

If the feedback is a simple misunderstanding, the ability to communicate this clearly back to the user is key. It can’t stop there, however. If a customer misunderstood how to use the product, there is a root cause in the design of the product that must be addressed, otherwise this flaw will continue to spawn additional bad feedback in the future. Bad feedback that can easily be considered sunk labor cost and sunk opportunity cost alike.

I’m not sure if or when a product will captivate people the way the iOS devices in the 2000s did. Tesla has had a pretty strong following at times in recent years. I’m personally a huge fan of some of the things happening at Microsoft currently under Satya Nadella. Who knows? When the audience of a product is so bought in that they openly mourn when its creator is gone, that’s something incredibly special. It may never happen in the same way again.

Posted on

My Take on Management

I’ve been managing business professionals for several years now. At the start, I managed the boots on the ground. Over time, as we’ve (Deacom) grown as a company, many more layers have been added. With few exceptions, I am now several layers of management removed from the boots on the ground — which I honestly have mixed feelings about at times. Either way, I’m not here to say that what I do is right or that everyone else should lead and advance the same way I have. I am merely here to share some of my approach that has worked well for me in recent years, and if that helps anyone, then fantastic.

(1) Be a Human

People want to be managed by someone they respect as a person and as a leader. People want to look up the chain and respect what they see. This means being empathetic, being a good support system, and yes — rewarding people the way you would expect to be rewarded for your efforts.

Years ago, when I was first managing a few software developers, I had a reputation as a bit of a hothead. I was trying to make a name for myself in a new role. I was the young guy in charge and wanted everyone to respect me. Unfortunately, this led me into the starkly common trap that many managers run into.

Barking orders and talking down does not earn respect, even if people (begrudgingly) do what you tell them to do.

My management style started to change when I got my first two weeks’ notice. I had been very rough on a senior developer. We had an aspect of our product that didn’t work and was causing issues for our customers, and this developer was responsible for that segment of the application at the time. Was I right to be upset? Absolutely. Was the right answer to vent my frustration to the guy in email form on his day off? Absolutely not. I wouldn’t appreciate it and neither did he. Granted, you have to make mistakes and learn from them to get better, I still look back on many of my early mistakes with regret.

So, how do you avoid the trap? Easy.. Just be the person you would like to report to.

This can mean:

  • Asking how you can help your employees reach their goals. My go-to in interviews is “interview me.” My go-to in performance reviews is “what more do you need out of me.” Management is a support role, never forget that.
     
  • Rewarding and recognizing, not just financially, but also through simple gestures: with a hand written note, a bottle of wine, a public announcement, whatever it takes to make sure people understand that they are valued.
     
  • Empathizing with an employee’s current work load and overall life situation.

Overall, just put yourself in the shoes of others and remember that your fancy title doesn’t make you better than anyone. An organization needs everyone bought in and marching forwards to be successful. That is.. Unless you want to do all of the work yourself rather than with a team.
 

(2) Replace Yourself

As I’ve moved from managing doers, to managing managers of doers, to managing managers of managers, I’ve noticed some trends. One interested tidbit that sort of amazed me at first but now makes glaring sense is: someone that is an effective manager of doers is not necessarily an effective manager of managers. The two roles require different skills.

I’ve always sought to replace myself. I’m generally lazy and I like variety in life, so I need new challenges to solve in order to keep things interesting. Therefore, I need managers that are good at managing managers as well as doers.

Here’s how I constantly replace myself by growing managers:

  • (2.1) Coach, Don’t Solve – Managing doers is quite a bit easier than managing managers. When you’re managing the boots on the ground, you need to come up with the plan and make sure the plan is executed on time using least cost resources. When you’re managing managers, you need to teach people to come up with the plan. Not just any plan — the right plan. No open book tests can be allowed when a manager comes to you looking for an answer.

    I tell my management team, “Don’t bring me a problem that you haven’t attempted to solve.” It’s actually quite similar to what I used to tell my developers — “If you’re going to ask for help on a coding problem, I need to see Google/StackOverflow up when I walk over.” Managers need to be able to come up with a plan in a pressure situation. Being that person is half the battle, the other half being a good talent developer. While it might make you feel like the bigshot-genius to always have the answers, solving rather than coaching will limit the growth and development of your direct reports and therefore limit your ceiling.
     
  • (2.2) Give “Dual Feedback” – Remember, most people that you give feedback to have a job they’re doing now and a job they want to do later. For some of them, that job they want later is your job — and you should hope that they earn it. The biggest mistake here can be seeing your employees as competition and therefore holding them back by not giving them the keys they need for success.

    I coach people with “Dual Feedback.” This means, you need to give people feedback for the job they do now. You also need to give them feedback that relates what they’re doing now to what they would need to improve on to handle the job they want. Everyone has hopes and dreams, and only giving feedback predicated on what people are doing today will keep them in their current spot and potentially cause long term negative turnover.
     
  • (2.3) Get Peoples’ “Take” – I like to get peoples’ opinion on decisions I’m making, emails I’m sending, or whatever else I’m doing on an average day. Usually, I feel as though I already have it figured out. The exercise sometimes nets some useful feedback, sure, but that’s not primarily why you do it. The goal is three-fold: 1) you get someone involved — helping improve buy in and your approach-ability, 2) you get to see how someone would handle a situation in your shoes which can be a valuable coaching opportunity, and finally 3) you might get some useful feedback that alters your plan. Either way, with the exception of a little lost time now, soliciting the opinion of your team on decisions you are making is a no-lose move.

Don’t be greedy with your role and responsibilities, don’t job-hoard. If you want to do more in the future, you need to stop what you’re doing now, and that means coaching so you can replace yourself long term.
 

(3) Constant Feedback

If you’re currently a manager, how long has it been since you’ve talked to each of your direct reports? Of your last conversations, how many concerned their work and what they need to do to move forward in their career?

If the answer to these questions is longer than a week or two, you’ve got a problem. Your problem is either too many direct reports (we could have a whole different dialog on the rule of sevens and the overly-flat org chart) or too much of a hands-off management style.

Having conversations with employees about their performance is hard, which is why it can be easy to simply budget twice a year to have these chats: mid-year and year end. The problem is, while it’s easy in the short term, it’s harder in the long run. Not addressing performance immediately is unfair to the employee, it’s unfair to you, and it’s unfair to the company.

Why?

  • Employee – Employees need and expect to understand where they stand. They’ll take no news as good news, and if there’s no feedback (good or bad) they will keep doing what they’re doing and potentially get complacent. Surprising an employee during the year end process is uncomfortable and unfair. Surprising an employee with a termination process can actually be the catalyst for something that’s already awful being much, much worse for all involved. Employees should never be surprised, and if you’re doing your job as a manager, every move will be expected and understood.
     
  • Yourself / Your Company – Your goal is probably to make your employees better so you can advance further. See: “Replace Yourself” above. That’s not going to happen without the right feedback at the right time. Also, from a company standpoint, your job is to maximize the performance of your employees for the overall efficiency of the business. Businesses that need to overstaff to keep up due to inefficient employees cannot compensate the way that they would (probably) like to. This can create an endless cycle of turnover and malcontent that can destroy a business culturally from within.

Overall, if you want to be a good manager it’s really not that hard. Act with authority but compassion. Think about what your superiors see in you, but also what those on your team think of your leadership. Figure out how to grow people, replace yourself, and then teach those people how to grow people as well.

Posted on

Learning to Think by Learning to Code

You know, besides the essential actions such as eating and breathing, I can’t think of many things I’ve done for the vast majority of my life. One of those activities is computer programming. I don’t write code nearly as often as I used to. Rather than 40 hours / week, I now just dabble at work and with small projects on the occasional weekend. Most recently, I wrote a simple tool that scrapes the internet for news about our customers merging with or being acquired by other companies, so we can stay in the know. The skill that I do use constantly that I learned from programming is thinking.

Thinking? Yes. Programming teaches you how to think.

I can imagine a standard, and probably quite reasonable, reaction to that statement from someone who has never had to break instructions down to something so simple that a machine can understand the message. “What, you’re telling me I don’t know how to think?” No.. I’m being purposefully extreme with my statements. I am, however, telling you that your ability to process information and come up with a proactive plan would be improved if you wrote some code from time to time.

Virtually everyone has given some instruction or ask at some point in time. Even an inquiry as simple as “Hey, grab me a water would ya?” is an instruction to another person which will be met with a response. Think about what happens what you ask someone to grab you a water. That person instantly knows what you want. They know to get a “water” which could be a bottle of water, a cup from the tap, etc. They know how to get it. They know where you are and what it means to properly bring it to you without making a mess of things. Hands down, there is much more ambiguity in our average dialog than most people consider. The difference is, when you’re communicating with other humans, there’s another human brain on the other end to interpret the message, fill the gaps, and make decisions.

This is not the case with a computer, I don’t care how far machine learning has come. For machine learning to solve this problem, you first have to teach the machine to learn and then put it through years of “learning.” Substantially harder than just teaching it to get water.

So how would this work with a computer? Well.. Think about how your brain processes how to go and get water from the kitchen. Not at the “I need to get water” level.. No.. let’s get closer to the “bend my knee, move my foot, plant it on the ground, repeat for the other leg” level. A machine needs step by step instructions. It needs to know how to move, how to recognize water, how to retrieve the water, how to deliver it to you. It’s actually quite intensive.

Seven words, the initial inquiry was seven words, because a human already has all of the ability. By the time you’ve accounted for controlling motors, balance stabilization, object recognition, task management, ability to grasp / hold objects, you’re into the tens of billions of lines of code. Alas, I’m using a very over-the-top example to make my point, but that is, in fact, what it is like to spell things out for a computer. That is also why you should generally triple any timeline that a software developer gives you. It’s so easy for a human to envision how the pieces fit at a high level, but when you get down to it the devils are in the details.

The point is, since a computer cannot make choices or recognize patterns the same way that a person can, you have to spell things out at a level that most people are not accustomed to thinking. When you force your body to do something it’s not accustomed to, as with any exercising, it becomes stronger in that area. We take ours and others ability to process information the way we do for granted. It really is an amazing thing, something that we’ve been trying to recreate artificially for a while and are still just scratching the surface of.

So, let’s take a more realistic example. Let’s take a simple chat app that allows two people to chat with each other. What’s funny is, writing the “happy path” for this app really wouldn’t be too bad. You need some sort of user system, some sort of database for storing chat history, and some sort of basic interface which is basically a large text field (current chat text) above a small text field (what you want to send). It would take a few hours to stand all of the infrastructure up (should probably triple that timeline..), but it wouldn’t be too complicated. Before you knew it the computer would know how to facilitate chat with others.

The complexity with even the most simple app comes in the exceptions that usually don’t happen in design or controlled testing. There’s actually a whole other topic here I’d love to get into regarding designing for exceptions rather than use cases, but we can leave that for another day.

The gist revolves around asking questions like:

  • What happens if a user loses connection mid chat?
  • What happens if a user sends a message that’s too long for the server to process?
  • How do we handle non printable characters such as 0-NULL or 8-BACKSPACE?
  • What if two people try to chat with the same person at the same time?
  • How are times handled in the chat database for differing time zones?
  • et al

Each case needs to be handled, or the user experience will be laden with bugs.

Point being, if you want to be better at solving things, learn to teach a computer how to solve. It doesn’t know how to do anything. It has less solving ability than even the smallest child, and therefore, teaching it how to solve teaches you how to think at the most basic of levels. Applying this extremely detailed level of step-by-step thinking to bigger picture problems is a whole different story, but at least it gives a solid foundation.

Thanks for reading! Still trying to figure out if this whole blog thing is going to stick with me, but this was very enjoyable to write. Constructive feedback is certainly welcome.