The Leadership skills you know you don’t have.

Previously I posted this on leadership skills and while I was recently reading it again, I realized that I now disagreed with something I had said earlier:

I have come to realize that some are leaders in one function (Project), others may be a mix in two (Functional and Technical); In my opinion (and conclusion), one must continue to grow their leadership by improving skills in other areas/domains that are not on-par with the rest.

People (followers) expect their (great) leaders to roll up their sleeves and get their hands dirty, so great leadership is well rounded and should be able to tackle any problem.

I now disagree and think that great leadership is not always well rounded; while its important to continue growing; there are going to be areas that one might just completely sucks at. it’s important to realize that and know what your weaknesses are and plan for them; ideally by putting others in place that can help cover them……….. or by learning how to suck less at them.

Have a plan, bring on and place great people… that’s what really counts.

The kitten and the mouse.

There was a kitten and there was a mouse.

Every evening the kitten would cry at the mouse. “Come out and play”

But the mouse would not come to play.

Yet, every night the kitten cried for it to come play.

After a long time, the mouse finally decided to come out to play – and the kitten, now a cat, killed it.

That is the reality of the cat – and the fate of the mouse

Innovating the Physicians Inbox

Remember Gmail back in 2004? How about Yahoo mail back in 1997 or Hotmail in 1996? Regardless of what you are using for email, its evolved & improved (you may or may not agree) – it has changed.

From tags, to filters, to conversation grouping (my favorite) to other tricks and hacks… all to make email more – manageable.

I entered the Healthcare industry a few years ago (I am no doctor), and while my medical and healthcare knowledge is minimal, I can certainly say that there is ample opportunity to innovate.

So why the mention about email? For me, it was interesting to see and learn that in a clinical environment there is “so much going on” and that physicians want a “systems that can give them information without overloading them”. There are definitely challenges in doing that, because what you decide to leave out for the sake of simplicity might actually be needed, by someone, somewhere.

It all starts with the “Inbox”; that’s where all their results, orders, alerts, etc show up regarding all the things going on around them: Have a look at some of the interfaces they currently use, reminds me of outlook express and outlook 2000.

cerner

google searched source | Demo Video |GE’s system

Some have tried to replace the entire Inbox, but why would you want to replace such a core functionality in the first place? The ones who use these systems day in-day out know exactly where to look for what they want, yes there is a lot of information and it can get cluttered., so why not build complimentary products that help deliver a smaller snapshot of the big picture – it’s like searching for something on google, you get a general idea of what the page might contain in the return results and you can then decide if you actually want to dig deeper.

It would be neat if you could take all this information, and funnel it into some sort of relative context that “tells you a bit about everything” and then you can funnel down to a “tell me everything relative to this one thing”… Someone must have surely done this already, maybe not for physicians/healthcare, but for some other “busy” information context; hasn’t anyone done this???

If you followed this blog post through twitter, then you are already on a platform that does just this. If you used twitter on the iPad, then you are already using a design that I used as inspiration for my idea for what a Physicians Inbox (Providers Inbox) could look like.

phybox

This is still a rough idea, there are several things to consider but it would definitely be fun to change the way physicians interact with their inbox.

eCommerce tooling: Build vs Buy

When you can’t quite find something that fits the need, don’t give in and accept “almost” or “good enough”; don’t settle.

Blank Label needed an eCommerce platform that supported several custom parameters (shirts are complicated). Several were looked at but they didn’t fit; we built our own.

We needed a user experience that allowed dynamic visual updates – theres lots of crap out there, we custom built our own.

We needed to account for manufacturing and our fulfillment, we built our own.

Analytical – several great products out there, we did not build our own 🙂

Email that went out in mass volumes – Thank you sendgrid.

We tried several customer engagement/referral reward solutions, coupon management, gift certificate generation, sales commission – stuff. They didn’t work, we built our own.

We’ve built a lot of stuff – and perfected it. We’ve also learnt a lot about our customers and the way they like to shop and be engaged. We also learnt when to buy and when to build.

There are some exciting things in the pipeline for the stuff we’ve had to build and what we would like to do with all of it.

Stay tuned!

Failure: Learn to fail – successfully

For a week or so, my son has been failing, he constantly fails, every day, every hour but he is so adamant that he won’t give up; he tries and tries again – and fails for the unknown-th time (yes he has failed that much); He has spent majority of his life failing; almost all 11 months of it.

To him, it’s not failure, to him, he is learning how to walk, or eat, or talk.. just like his sister did, and my better half, myself and almost everyone I’ve known.

At any given point there are thousands of seminars going on about “Success” and how you can learn “how to succeed”; some will teach you how to be successful at flipping houses, investing, growing a business, setting up an eCommerce shop that takes a few hours per week where you can set your own hours and “like Bob, make $10,000 per month” with the disclaimer that these results are not typical….

….But what about failure? Who teaches you how to fail successfully?

While there are lessons to be learnt from others in being successful; these lessons are based on other people’s failures and what they learnt from them – they learnt to fail, successfully.

We are born with a “learn by trying” and “learn from failure” behavior but at some point many of us lose it because we are taught that failure is bad.

While “success” is the end-result or the goal that we wish to attain, we really should tell ourselves that “it’s okay to fail” (avoiding obvious failure paths and not self-inflicting intentional failure) and we should be trying to figure out how to fail successfully; “I failed, I’m now going to get up and try a different approach” – you have to be okay with failing.

Unless we try and push our limits and drive towards the point of “possible failure” we wont discover our potential.

In leadership, failing successfully is important as it tells your followers that you too are human; that its okay to be wrong, and that you learn from it; that its okay to try something different and experiment. I don’t have all the answers for my teams and I try various different things to find answers that work – I end up with a lot of failures before I end up with success.

You have failed successfully when you have failed, learnt from that failure and have gotten back up to try again.

Keep failing.

Work hard – Play hard – When fun becomes a performance issue

In my pursuit of becoming a better leader I sometimes forget to look at my the lessons life has taught me much earlier on in life (as a child), its interactions with people that ask interesting questions that help dig out those lessons – this is one of those.

I grew up in Dubai – back then it wasn’t all the glitter and glamour it is today, things have changed dramatically. One thing that has not changed though, is the summer heat.

I am not sure what you may have heard, but Dubai has two seasons, “”hot” and “very hot”. So, growing up in Dubai and school being out over the summer heat pretty much meant that we were mostly indoors.

Being stuck at home gave us just a few options: watch TV (not much to watch), play games, read books. The games were fun for a while, but they were the same games, TV kinda sucked…. the only thing that changed, or was new was “reading books”. Junior school on-wards at the end of the school year, my parents would buy the books needed for next school year and being bored, we would study them over summer. This turned out to be a great thing to do because once the school year started, I was already familiar with the material, had already done the required readings and most of the homework – I could mess around in class and do what I wanted, and since it was no longer summer, I could go out and play after school – it was a lot of fun.

I was performing, my homework was done, I already knew everything and I could do whatever I wanted; there was no harm that I could have been doing by having fun…. right? well. I was wrong.

Eventually (think it was grade 9) a teacher called my parents in and together they explained to me that while it was great that I was on top of my game, my “fun” was becoming a distraction for others because the other students were unable to concentrate and get work done. Since the others had not already gone through the material, someone like me should be helping them get their homework done and leading by example rather than distracting them with fun alternatives.

We all have different motivations for pushing hard and getting things “done”, i.e. “I just want to push through he last few minutes of this workout and complete this 1000 meter row so that I can sit down and take a break”, or “I just want to finish coding this feature so that I can get back to learning about Node.js”, or “I just want to finish my work so that I can have fun..”… (who really wants to be rewarded for finishing early with more work?) working hard and having fun is great – there should be a healthy balance. Top players work hard and take a deserved break; However, most of us do not know or even think about how our actions may negatively impact others by creating distractions, or may impact ourselves and stop us from growing or delivering to our full potential; when the fun does negatively impact others/ourselves, it is important to recognize and address it. In the event that you do end up in a situation where someones “fun” is negatively impacting others, or themselves: do what my teacher did and have a conversation explaining the impacts. In my opinion (and experience), explaining the impact (of an observed issue) can make a world of a difference and often solves the issue.

At the end of the day, its the culture you build as a leader that dictates how people “have fun” and what work means to them.

Do not focus on making a team perform better

At a meet-up earlier today I was asked “how can one make a team perform better”; I believe this question can be answered in many different ways and I would like to share my opinion(s):

Would you rather have a team that reluctantly does as you ask or would you rather have a team that does what you need it to do before you ask?

16406976

Culture has a large role in Leadership; in order to lead, you need to push a culture that people want to be a part of (follow).

There are several areas you can focus on and below are four (of many) things that I like to keep in mind when I am building “Culture”:

  • Build and foster an environment that drives ideas bottom up as this increases engagement and hunger for solving challenges. The people on the front line(s) have valuable feedback that they want to communicate but do not know how – build communication and engagement.
  • Actively recognize and reward, be humble, chose to publicly provide positive feedback and privately mentor with constructive criticism – build appreciation and mentorship
  • Be as transparent as possible, over communicate, share road maps, expectations, perceptions, feedback, motivation – build trust
  • Build and implement a collaborative environment, have people tie in with each other, be open, honest, humble, we spend majority our of day together and should want to be together – build a family

The focus should not be on “making a team perform better”, it should be on improving “culture” – Improve culture and your team will automatically perform, better.

Taking just these four points into account: when you focus and improve culture, your people will be more engaged, have trust in you, want to grow and have the desire to help others be successful around them (imagine the care bears); these type of teams happily give it all they got and even go above and beyond to ensure success.

office-space-copier

The leadership skills you dont have

There are four areas/domains of leadership skills: Product, Technical, Functional and Project.

Product leadership skills

  • Customer: Know/Understand the customer’s needs; focused on customer
  • Road-map: Know/Define what to deliver when
  • Marketing: Know the business market/sales models and trends

Technical Leadership skills

  • Architecture/Development oversight
  • Technical Road-map: what fits where and how to best build it.

Functional Leadership skills

  • On-board/Distribute Knowledge: Bring on new hires, knowledge sharing
  • Grow People/Push to potential: Drive engagement, innovation
  • Resolve Conflicts/Define culture: unblock, collaborate, act on feedback.

Project Leadership skills

  • Track progress
  • Schedule work/resources

There are other leadership skills that can be added to the list above and there are skills that may be shared by leaders (such as process optimization, motivation,  domain knowledge, etc.) that I did not explicitly define; I limited to the top 2-3 that came to mind.

I recently asked myself, “what makes someone a great leader, and how does this differ from team to team?”; I have come to realize that some are leaders in one function (Project), others may be a mix in two (Functional and Technical); In my opinion (and conclusion), one must continue to grow their leadership by improving skills in other areas/domains that are not on-par with the rest.

People (followers) expect their (great) leaders to roll up their sleeves and get their hands dirty, so great leadership is well rounded and should be able to tackle any problem.

RAPID Agile: Customer Focus – Defect Management

Before we dive back into defining an approach that mixes Product and Custom focus, we should probably ask “How does one focus on the customer?”

In an ideal world there are no defects; but since there are, and customers expect them to be resolved, an ideal approach balances itself between being proactive and reactive; proactively resolve reported/discovered defects and appropriately manage escalations. On the surface, one focuses on the customer by making sure that the defects are fixed before a customer reports them and if a customer reports them, they are addressed promptly (top priority of course) and the customer is satisfied – below the surface, defect management and prioritization play an important role towards our customer focus as this tells us how soon we can (and will) actually resolve defects.

The list below doesn’t capture all possible approaches in resolving defects; it captures approaches that I have had some experience with (I recommend that you certainly do not try the first one):

  1. Don’t resolve them
  2. Push the defect to the original developer, or the developer most familiar with the functionality for resolution.
  3. Allocate time for the first available developer to pull a defect in and resolve.
  4. Have a defect duty rotation where a person (or team) resolves only defects for a time period
  5. Have a dedicated team for defect resolution.
  6. … Some other create ways to resolve reported defects..

Always push to most familiar
Pushing the defect to the most familiar sounds like a great idea and in many cases it is because the one most familiar would be able to resolve quickest and positively impacts customer experience. The issue with this approach is that the most familiar person might be involved with something that has a higher priority than this defect, or is out on PTO and would not be able to resolve for another 2 weeks. Let’s say it takes someone familiar with the code to resolve in 1 hour but takes someone not familiar with the code 6 hours. If the defect goes to the person currently tied up and is most familiar, the customer will have to wait a minimum of 2 weeks + 1 hour; however, if it goes to the person not currently tied up and is least familiar, the customer will have to wait a minimum of 6 hours. Being collaborative and available for the team may improve the turnaround time on average, but a hard coded “always send to the one who created it” may not be the best approach.

Allocate time to pull
Allocating time towards the end of an iteration, development or whatever, towards “defect resolution” allows the team to first get the scheduled work out of the way, and “if” there is time, someone may pick something up from the backlog of defects. The issue with this approach is that if the development cycles are fully booked (maybe there is a hard date) and there is any risk or complexity that might lead to developers putting in all they have to meet the delivery; defect resolution gets thrown on the back burner. In most cases where the approach is “allocate time to pull defects”, the unspoken rule is that new products come first, defects second – unless; where the “unless” is for escalations and chaos/fire-fighting instances. For agile teams, if the time allocated towards defect resolution does not change from sprint to sprint, then there is no impact to velocity; however, if the time allocation is not fixed the velocity can get impacted depending on how much time is spent on defect resolutions (usually hours) vs. features (SP’s)…. You could estimate defects in story-points but this can lead to additional issues that will need to be worked out… i.e. do you really want to hold a sprint back? etc..

Defect resolution duty rotation
For a given time (usually the span of a sprint) a developer within a team, or a whole team themselves will be on defect resolution duty; once the time span is over, someone else (or a different team) takes on defect resolution duty and so on. This helps cross-train and helps make everyone familiar with the code base. It can also help improving code quality since everyone is learning from everyone’s mistakes and provides a great collaboration platform; while it does have some great benefits it does introduce some challenges. A significant issue is that developers and teams lose traction as they switch focus from “new product” to “old product”; the interruption can cause a delay since the developer(s) will need to get back to where they were after the rotation is over. For organizations that have many teams or larger teams this may be less of a concern since the rotation might happen every few months; but even then, when it does happen it does have a negative impact.

Dedicated team for defect resolution
The thought on this one is that if there is one team solely focused on supporting “released software” (defect/engineering sustaining team) and other team(s) focused on creating “new software” (Feature teams) that you end up with a two-tiered development approach where both the product and the customer can be focused on. The feature (new software) team is rarely impacted by defects from the “live” world and they can always focus on delivering new product; the defect/engineering sustaining team is dedicated to resolving defects and is not tied up with new features. The issue with this approach is that no one aspires to be a “defect fixer”, developers want to “develop” new and innovative “features” (or at least I did); It is possible to make this work if more attention is given to down-time cross-training, root cause analysis, collaboration, role rotations, etc… (I have seen teams evolve this approach into a “defect resolution duty rotation” approach)

In addition to the above, there can also be hybrid approaches that mix various approaches, i.e. defect resolution duty rotation with an added “pager duty” where someone (not on defect duty) is on-call but in general there is no “incorrect approach”; however:

Any approach can become incorrect when developers are forced to accept an approach that they do not agree with (or understand).

Any approach that is going to be implemented should be discussed with the teams that will be implementing it, focus on and explain the “why”. When an approach does not work, try to adjust it or try something else!

“if the code repository is an “elephant” and new code is peanuts being fed to this elephant by the other guys, then I am always cleaning up after the elephant; who wants to be a shit cleaner forever?”.