Learning to Lead: Motivating People To Solve a Problem

In my previous post in the Learning to Lead series I talked about how being able to facilitate a conversation is an important leadership quality. In this post I'd like to talk about motivation and how the ability to motivate sets great leaders apart from the rest of the pack.

Many people's first reaction to motivation is to think about compensation. While compensation is an important motivator, it's not the ultimate motivator. If you haven't already, go watch the surprising truth about what motivates us. It debunks the myth that money is the ultimate motivator and is a great introduction to the type of things that will motivate once money isn't a worry any more.

I truly believe that the ability to motivate is one of the things that truly sets great leaders apart. Being a good motivator is not about being a cheerleader or always being positive and perky. While those things are occasionally required, motivation is about so much more than your attitude or presentation. Motivation is about being able to call others to action. In the tech industry this is especially important because lack of motivation has a direct correlation to loss of productivity, slipped schedules, and quality code (i.e. buggy and/or unmaintainable).

In my experience as both a software development engineer and as an engineering manager, there are three key areas to focus on when trying to motivate individuals or a team.

Impact

Engineers should understand the impact of what they're working on. This comes in the form of understanding the short term, mid-term, and long term benefits to their customers and their team. They should have enough information to understand why their work is important and to empathize with those that need it to be completed. Most engineers thrive on knowing that their work is being used by other people. It's much the same as an musician being motivated by knowing that others are listening to their songs. Or an author being motivated by knowing that someone is lost in their narrative.

Interesting

This may sound obvious but the work that's being done should be interesting. If your engineers feel that what they're doing is busy work, repetitive, or monotonous they're not going to be motivated to complete it. In this case you need to learn to correlate the current work they're doing with something that is of interest to them. Often I've seen lack of interest when a team is in bug fixing mode or just about to ship a product. In this case it's important to emphasize how what they're working on now enables them to work on the next big thing.

Another way to help make the work interesting is to find a tie between it and their career development. Maybe it gives them exposure to a broader set of skills or technologies. Maybe it allows them to check a box on their career goals or will help prepare them for being promoted to the next level.

Relate

The engineer needs to personally relate to the problem in some way. The best way I've found to help engineers relate is by dogfooding their own software. Using their software everyday in their personal lives will help them see what others are experiencing. It will help them want to fix the pain points that otherwise wouldn't be important to them.

Learning to Lead: facilitating conversation

In my previous post in the Learning to Lead series I talked about how earned trust is the cornerstone to leadership. In this post I'd like to look at another aspect of a good leader; facilitating conversation. Being able to facilitate a conversation may not be at the forefront of the qualities you attribute to good leadership, but I think it should be. Being able to facilitate a conversation shows a level of maturity that's needed in order to lead people successfully.

Ensuring the purpose is known 

Every conversation has a purpose and I'm still surprised at how often I've seen two people arguing with each other simply on the basis of not having a shared understanding on what the purpose of the conversation is. A good conversation facilitator will be able to articulate in a meaningful way the purpose of the conversation. Often this can be accomplished by stating what the desire outcome is right at the beginning. For example, "Today we're here to talk about FOO and make a decision about BAR with regards to FOO."

Getting people to participate

One of the keys to being a good conversation facilitator is getting people to participate in the conversation. This can often be difficult for a variety of reasons like people being uncomfortable talking in large groups, not wanting to speak up, having a lack of confidence, being intimidated by their peers, and etc. A good leader is able to encourage participation in the conversation without it being awkward.

Some tips for conversation facilitation:

• Ask open ended questions. This discourages one word responses and encourages meaningful conversation.
• Don't be afraid to let the room be silent. Often people trying to facilitate conversation will talk and talk and talk so as to avoid silence. Not everyone is an off the cuff thinker. Silence allows people to process what they've just heard and formulate a response. The key is figuring out when it's been silent long enough the the conversation needs help.
• Recap. This is useful at the beginning of the conversation as well as the end. At the beginning of the conversation it's often helpful to recap what the goals of the conversation are. For example, "when we finish today we should have a plan of record for...". At the end of the conversation a recap is useful to make sure everyone heard the same thing.
• If you know someone is passionate about a particular topic but not eager to put forth their opinion, you can try to gently guide them into the conversation. This can be as simple as saying "Tom, you and I were talking about something similar the other day which makes me believe this is something of interest to you. I'd love to hear your opinion on ..."
• Be direct and ask someone else to respond to a particular comment or statement. This can be especially useful when someone is steam rolling the conversation. For example, "Harriet, what are your thoughts on what Bill just said? Do you agree or disagree that..."

Avoiding derailment

Tangents are unavoidable, especially if you've got any "talkers" in the group. But tangents don't have to derail the conversation. A good facilitator is able to keep the conversation on topic. One common reason a conversation gets derailed is if someone else has an agenda that's not part of the purpose of the conversation. A good facilitator is not afraid to steer the conversation back on topic. This can often be accomplished by saying "Jess, that's a great point but I'm not sure that this is the correct venue for it. Let's set aside some time specifically to talk about that so we can use this time to talk about ..."

Another way conversations can get derailed is if you've got someone that rambles. What I've often found is best is to tackle a rambler head on. You can do this by jumping in and saying "That's a great point Sue, I'm curious to hear what other people think about the topic as well." Occasionally you have to be blunt and say something like "Greg, the latter part of what you're saying isn't really pertinent to the conversation at hand, let's stick to this topic now and we can get back to the latter part of what you're saying at another time."

Learning to Lead: It Starts With Trust

In my previous post on being a Senior Software Engineer I talked about one of the characteristics that defines the role is being able to get people to want to follow you. At it's heart the problem is one of trust. People don't want to follow someone they don't trust. What does it take to gain trust? Fully answering that question would probably take a novel. But at a high level I believe there are five key aspects to earning the trust of others.

Honesty

Any conversation about trust needs to start with honesty. At it's core honesty is about NOT deceiving others. As a software engineer that means you're able to:

• Say I don't know when you don't have the answer.
• Remove personal bias when evaluating a solution. When you can't remove the bias, it means communicating that bias clearly.
• Give credit where it is due (i.e. don't take credit for others achievements).
• Publicly recognize the achievements of your team.
• Provide clear, constructive criticism when someone is not doing something well.

Integrity

Being a leader means having a known set of guiding principles that you hold yourself and others to. The key is that you hold yourself to them FIRST. It's also important that the value of these principles is understood by others. It helps if others agree with these principles, but even if they don't knowing that you're holding yourself to your own standard helps earns trust.

Respect

The key to gaining the respect of your peers is to start with respecting them. In the technology industry this means valuing others skills and abilities. Not just the skills and abilities that you find value in, but also the skills and abilities that THEY find value in. Respect involves holding others achievements in high esteem.

Transparency

In my opinion transparency as a leader in the technology industry is not about making sure everyone knows everything you know. That can actually be detrimental to the team. It can add unneeded stress on those that don't have the context or the maturity to deal with the information.

Instead transparency as a leader is about making your motivations known. Help people to understand why. Why you're asking them to do something, Why something is the correct priority. Why somethings not the right direction for the team or project.

Fallibility

The last key aspect to earning trust is being able to admit when you're wrong. Everyone is human and humans make mistakes. Being able to admit when you're wrong sets the tone that it's okay to acknowledge your humanity. Once you're able to admit you're wrong you can start to correct the problem.

Senior Software Engineer

One thing I've noticed throughout my career that's been pretty consistent is the desire of software engineers to be given the title Senior Software Engineer. I've seen many people claim the title without truly understanding what it means or what the role entails.

The Misnomer

Often I've seen people given the title or claim the title based on the number of years of experience they have or based on the fact that they have more technical chops than their peers. Being a senior software engineer doesn't have anything to do with years of experience, but instead is about maturity as an engineer. While the two may be correlated (highly so in many cases) there is not a causation relationship. I've seen just as many tenured developers who were no more senior than their counterparts fresh out of college. It's also not only about your technical ability (while that is a large part).

If years of experience don't define a senior engineer and being the most technical person doesn't then what does? In my opinion a senior engineer is someone who manifests most, if not all, of the following characteristics.

Language/Platform Agnostic

A senior software engineer may have language or platform preferences but they're able to deliver on any platform. This is because they understand system metaphors, abstractions, and compositions well enough to know how to learn what they don't know quickly. They identify the correct metaphors, abstractions, and compositions needed to be successful and realize that the syntax and libraries are just implementation details.  

Able to identify and articulate trade-offs

Building software is always about trade-offs. They are able to take schedule and scope into account when building a solution. They understand and are able to clearly articulate risks. For example, a senior engineer knows that with a fixed schedule scope must be variable. They're able to identify and clearly articulate what the proper scope is and what features are at risk.

They're about shipping software

First and foremost, a senior software engineer is able to deliver software. They deliver software in large volumes. This is largely to do with their ability to understand and quickly get through boilerplate code in order to focus on the real problems. They understand that unshipped software isn't making the business better.

Able to get people to want to follow them

Solving complex and ambiguous problems is a requirement of being a senior software engineer. But being able to solve those problems isn't sufficient for the title. A senior software engineer is able to successfully lead a team. They're able to motivate people to solve a problem, hold people accountable to solving the right problem, and get down to the level of other less experienced developers in order to stretch them and help them achieve goals that are beyond their current abilities. 

Able to simplify a complex problem

Senior software engineers are able to see through complex problems and break them down into smaller, easier to solve, problems.

Understand the correct amount of engineering required to solve the problem

Senior engineers don't over engineer solutions and likewise they don't under engineer solutions. They understand that software is meant to solve a particular set of problems while needing to stay maintainable in order to increase the lifespan and usefulness of the product. They recognize that the elegant solution is not always the correct solution. They also have the ability to take a complex problem and identify the potentially fragile portions of a solution and design around them without over generalizing a solution or making the solution less useful in solving the problem at hand.

They recognize that everything doesn't have to be "built here"

This one is pretty straight forward but difficult in practice. Senior engineers recognize when a particular problem is not part of the groups core competencies and look for external solutions. While a particular problem may be interesting, unique, or fun a senior software engineer is able to recognize when solving that problem in house doesn't add any business value or add burdensome tech debt. 

Does your job define who you are?

I've been thinking a lot lately about how intertwined our jobs are in our lives and our identities. For some, a job is simply a way to pay the bills. For others, their job is as much a part of their identity as their education, their hobbies, or even their families. The thing I've been wrestling with is whether your job defines who you are.

What your job says about you

It's interesting when you really sit down to think about it because you can actually deduce a lot about a person just by their job. For instance it can tell people or at least be an indicator of

• Your relative education level
• Your relative intelligence level
• Your interests
• Your hobbies
• How motivated you are to succeed

For example, if you meet someone who's job is software engineer you can be pretty confident that they've got at least a bachelors degree (most likely a bachelors of science) and could have a masters degree (which is more common these days).

Knowing their employer can possibly tell you even more. For instance someone who has been at their job for at least a year at Google, Amazon, Apple, Facebook, or Microsoft will tell you that the person is probably slightly competitive, most likely always excelled amongst their peer group, and wants to work on problems that affect a large user base.

What your job doesn't say about you

With the exception of a few job categories, your job likely doesn't say

• Whether you are interesting or not
• Whether you have social skills
• Whether you are emotionally mature
• Whether you are kind or cold
• Whether you are empathetic or apathetic
• Whether you are selfish or selfless
• Whether you prioritize your family first

To know these things, you have to actually know the person.

Does your job define who you are?

Now we're back to the original question that started this post. Given the above, I think that your job says a lot about you and it can describe your attributes well. But it cannot define you.

Redefining federated identity and authentication

Recently I've been thinking a lot about Federated Identify. In the technology industry it feels like we're always on the constant hunt for the perfect solution when it's been sitting under our noses the whole time.

The Problem Space

At it's heart there are two things that are being solved for. First, how do I authenticate that you are who you are? Second, how do I share basic information in a secure way across multiple systems.

The first problem is a somewhat straightforward problem to solve. While in recent years we've seen advancements in bio-metric authentication, largely authentication is achieved in the form of some sort of username and password combination.

The second problem is not as straightforward to solve. There are a lot of systems that we use everyday ranging from social media to more crucial services like banks and utilities that need a variety of information about us on top of the typical authentication that we are who we say we are. Social networks need to know who your contacts are, what your calendar data entails, who you converse with and when you're available. Banks and utilities need to know more basic information about you such as your mailing address and phone number.

Having a single canonical source for all this data sounds like a great idea doesn't it?

The Problems With The Problem Space

Federated identity and authentication come with the promise of managing your authentication and personal information in one place. In theory that's achievable, but it practice it's a lie. Users still have the burden of managing multiple profiles, duplicating information across sites, and figuring out each sites different privacy policies, what they do with your information and what information they share (or sell) to others.

Again, if there were one true canonical source for this information this wouldn't be a problem, but history has shown that there isn't going to be one canonical source. In fact history has shown that we've made the problem worse. Instead of having one place to manage data we've got a dozen. To make matters worse, most of those places do not stay in sync and we're forced to either deal with inaccurate/out of date data or to spend a lot of time keeping all our data up to date.

Still aren't convinced, how many of these federated identity and authentication sites do you have an account with?

• Microsoft
• Google
• Yahoo!
• Twitter
• LinkedIn
• PayPal
• Foursquare
• Mozilla
• Amazon

My guess is that you have an account on at least half of those, if not all of them. That data point in and of itself is proof that federated identity doesn't solve for the you're only going to have to manage your data in one place problem.

Redefining The Problem

I'd like to propose that we redefine the problem in such a way that

1. We allow users to store their personal data wherever they want
2. We make that data accessible and 100% in the control of the users
3. We authenticate users in such a way that they only have one username/password combination to remember and changes to their password are instantaneous across all sites they authenticate with.

The Solution

Solving this problem isn't actually all that difficult. It can largely be done with existing technologies and open standards.

Authenticate users using their existing email service provider

If every email provider exposed an OAuth provider that was built on top of SMTP Authentication then we'd have this service today. The user would be redirected to their email provider and asked to authenticate. They'd give their email provider their username/password combo and then it would issue an OAuth token to the service.

The users email/password combination are never shared and users don't have to remember multiple usernames/passwords. It comes with the added benefit that when they change their email password it's instantaneously reflected in any service they use.

Again this could be built into every existing service now using existing standards.

Allow users to store data wherever they want

As a user I should be able to store my data in the service of choice. I should be able to store my data in Facebook, Microsoft, Apple, Google, Amazon, or <insert your favorite cloud provider here> service. If I want to use another service then I should be able to point it at where I store my data and it should be able to read or modify it as I choose.

This also could be done today using existing standards and protocols. If each cloud provider did the following we'd liberate our data and ourselves from having to choose how and where we store data.

1. Expose CalDav, CardDav, and WebDav APIs to read/write contact, calendar, and file data.
2. Provide a mechanism that allowed users to grant access (OAuth anyone?) to their data from another service.

Example of how this would work in the real world

Let's say I decide that I want to use GMail as my email provider. I go sign up and GMail creates an account for me and exposes an OAuth provider for anyone that wants to integrate with my GMail account.

Later, I get an iPhone and want to use iCloud and Apple's calendar. When I sign into my iPhone I tell Apple that I use GMail for email and it also authenticates me using GMail and OAuth and creates an account for me. Part of what I get is a calendar, contact management, and file storage.

I then decide I want to join Facebook. I go to Facebook and instead of creating a new account, I tell Facebook to authenticate me using my GMail email address. When it authenticates me I tell GMail to give it access to my calendar, contacts, and file storage. Facebook creates a new user for me, identified by my email address. Facebook then asks if I have a calendar and contacts and I point it at Apple, who has exposed a CalDav and CardDav server. Since Facebook has been approved for those services Apple is able to validate I am who I say I am and Facebook now has access to my contacts and calendar. In fact Facebook could also use my file storage as the primary place it stores photos and videos I upload.

As a user I get to control my data AND still get access to all the great services I've come to enjoy. We all win.

Smartwatch Manifesto

As I mentioned in my previous post I've owned a Pebble Time for a few weeks now which basically makes me an expert on all things smartwatch related (please note the sarcasm). But seriously I do think I have a much better understanding now of what a smartwatch is and should be for. So here's my Smartwatch Manifesto.

A Smartwatch is a companion not the star of the show

What I mean by this is that a smartwatch should help you with some other task, unrelated and uninitiated by the watch (with the one exception of telling time). To prove this I present a simple test. While standing up straight, hold your arm out parallel to the floor for 3 minutes without putting it down. Go do it now. Sucks doesn't it?....

You're obviously not going to be interacting with your watch in that position but that test is to show you that it is unnatural for you to not have your arms at your side or in a sort of resting position. When you initiate doing stuff with your watch it makes you do something unnatural.

The goal of a Smartwatch app should be to get you in and out as quickly as possible

This rule is a direct result of rule #1. The ways that a smartwatch app can enable you to get in and out as quickly as possible are:

• Present the minimal amount of information on the screen as needed to fulfill the task.
• Be context aware, and use that context to decrease interaction.
• For example, if you know the user is running or biking, default to voice control rather than button or touch input.
• Allow voice interaction to both initiate activities as well as respond to notification.
• When using voice dictation, validate using audio.
• You already know audio is okay since I initiated the interaction with voice.
• It prevents me from having to focus on my watch instead of my primary activity.
• It helps me get the context someone else will hear/read my statement in.

A Smartwatch needs to enhances communication

Society today communicates via voice, touch, and text. We use different means of communication in different contexts. A smartwatch should enhance communication in the context the user is in. For example; when I'm out and about I will primarily want to respond to things using voice commands as it's easier than having to pay attention to the screen.

For each primary means of communication that the smartwatch enhances the wearer should be able to initiate the communication, see current meta-data about the communication, and respond to or interact with the communication.

Primary means of communication that a smartwatch should enhance include:

• Phone calls
• SMS
• Email
• Calendar

A Smartwatch allows you to get a glance at meta-data

Minimization of data should the the smartwatch apps goal. The watch has a smaller screen and different input. Therefore it should initially present meta-data and not full data. Allow the user to dig in where appropriate but make that the exception to the rule and not the rule itself.

For example, email meta data should be from, subject, and first line or two. I know the date since it came from a notification, and it was to me or I wouldn't be reading it (even if I was BCC'd the primary purpose is that I read it, and thus it is to me). I should be able to decide from the meta-data whether I want to dig deeper into the full data.

A Smartwatch is context aware

Watch wearers typically wear their watches all the time. The watch should be able to determine the wearers current activity and respond in kind. If I'm moving the watch should be able to determine the difference between walking, running, biking, or traveling by car or plane. If I'm still the watch should be able to determine (using enviornmental and other factors like my calendar) whether I'm asleep, in a meeting, on the couch, or at a movie.

Watch app makers should be able to ask what the context of the user is so that the user is able to interact with the watch in the most appropriate fashion for their current activity. For instance, if I'm biking I should be interacting with the watch primarily through voice and audio playback.

A Smartwatch has a long battery life and is water proof

Watches are cumbersome to put on and take off. Therefore a smartwatch should optimize for not being taken off. This means that it needs to have a long enough battery life that having to charge it is the exception to the rule and not the rule itself. This also means that the watch needs to be waterproof in order to allow me to take a shower or go swimming.

A Smartwatch enables fitness tracking

For a smartwatch to enable fitness tracking it needs to be able to determine the following:

• Current Activity (walking biking running swimming)
• stair counts
• step counts
• elevation gain/loss
• heart rate
• calorie count
• pace
• sleep tracking