Category: Leadership and Management
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.
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?
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.
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):
Don’t resolve them- Push the defect to the original developer, or the developer most familiar with the functionality for resolution.
- Allocate time for the first available developer to pull a defect in and resolve.
- Have a defect duty rotation where a person (or team) resolves only defects for a time period
- Have a dedicated team for defect resolution.
- … 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?”.
RAPID Agile: Focus on Product and Customer by mixing Scrum and Kanban – ScrumBan
We are usually torn between building more “product” or satisfying the “customer”.
Prioritize Customer (maintaining product)
Fix and release to save the world
Prioritize Product (building more product)
Plan and build to a schedule
When you focus on product, you have a certain “amount” of product that needs to be built within a sprint (time box); you can plan for fixes by leaving some room for the defect backlog, but features come first – then come fixes, and the work is usually fixed where people know what they are working on for the sprint. In this scenario most will usually package after the sprint is over (test and release)
When you focus on customer, you have to fix and get the fix out the door ASAP. Priority is given to the most critical fix and/or customer and things will be packaged (test and release) as soon as appropriate and/or possible.
Some solve this by having a sustaining engineering team, but who really wants to only fix defects?; others use a mix of cross-functional or functional teams and adjust as needed, but this can be disruptive.
If you chose to “adjust as needed” (be agile) you will introduce some chaos every now and then but this can be minimized by having “plan of action”. How you adjust as needed and what type of “plan of action” you need also depends on what type of process you follow and what your focus is; is your culture focused on product? or is your culture focused on the customer? Depending on whom you ask (their role) within an organization, you may get different answers.
If you follow “Scrum” then your work queue is mostly “push” defined, where work is planned and pushed into a sprint/iteration before its worked on.
If you follow “Kanban” then your work queue is mostly “pull” defined, where work is pulled and worked on.
In an ideal world, one would have a process that allows the focus on both, the product and the customer. A process that allows you to “build what you say you will build” but also allow you to focus on “what is important right now”; such a process would mix Scrum and Kanban, giving you, ScumBan. The idea of a Scrumban is not new; there are books and many talks/posts regarding this. How Scrum and Kanban are merged together depend on the person who is cross-breeding the processes and what problem(s) they are trying to solve; I named my implementation “RAPID” for “Real-time Actionable Prioritized Individual Delivery”.
In my next post around RAPID, I will go over some examples that helped define the how and why behind RAPID and how it would be used in a team that wants to focus on both, the product and the customer.
Leadership lessons learnt at Crossfit
Challenge – The WOD’s are different, will require effort and will challenge you, you will burn out – it should not be easy.
Teamwork – It doesn’t matter if you finish first or last – your team will encourage and cheer you on till the end; the class is only over when everyone is done or when you run out of time 🙂
Tolerance – You run into people who work differently than you do, might have behaviors that turn you off, you get to know them, you encourage them and/or they encourage you; you build tolerance and figure out how to workout together.
Accountability – No one is counting your reps or sets, making sure that you did actually finish the WOD or micro-managing you; you hold yourself accountable and make sure you finish your WOD
Motivation – While there is a coach motivating everyone by saying things like “great job” or providing tips; you also have others going through the workout saying things like “great job everyone, were almost there”. You realize that a culture of encouragement that involves encouragement from peers in addition to encouragement from the top helps motivate you and the team more than one single person can.
Respect – You learn to respect other peoples space, limitations, accomplishments and drive. You learn from them as they respect you as a new-comer and help you be better.
Maturing from a StartUp to a StartedUp culture – Series Part 5
People growth – Old blood vs New blood
I wrote my first post here on Jan 23 2011 and that post was titled “Startups – importance of your team“; Its been a little over 2 years since I wrote that post.
Most of us work 5 days a week, putting in about 8 or so hours a day (we will stick to the average/norm here). We come back home in the evening to spend anywhere from 1 to 4 hours with our family/friends.
When friends and/or acquaintances form a startup, the long hours and the close working relationship build on existing relationships and everyone at the startup works as a “family”; but what happens when there are no existing relationships? or what happens when you already have a family and someone new tries to come in? Wouldn’t it be awkward if you were out with your family/friends and a stranger joined your group and just hung out? would you be your self? most wouldn’t.
So how do you take an existing family (a started up culture) and add newer members to it? How do you mix the two so that you do not end up with friend circles?
I have 4 simple attitudes/behaviors that I build my base on:
“We are not that different”.
The new member see’s a whole new planet, different people, cultures, processes, jargon, etc. The first step should be to look for similarities between what they know and what they should know. For my teams I use a buddy system and its usually the previous newest member who buddies up with the new member. They go over materials, documenting anything new that might come up, go for lunch, talk about process, go through the who’s-who, engage the new person in conversations with the other team(s); they try to get to know this person as if they were dating each other.
“We got this, lets work on it together”.
How do you start work? where do you start? who do you ask? Scary questions for someone looking under the hood of something they do not understand. Here is where the buddy comes in again; during stand ups and sprint planning the buddy might offer “we can work on this together”, or someone else on the team might say “hey this is a good problem for me to show you how xyz works, and we can solve it”… they get the knowledge, they figure out how to start, they experience the process and they know how to close it. Build trust and accountability.
“Your team mentioned that you are catching on so quick, what can we improve?”
Over communicate reinforcement of team acceptance, ask for ideas on what can be improved, engage the new member; engaged employees have ideas and feedback that they want to share, things they have questions about.
“You are doing great, let me share my vision on how you play an important role to the team”
Setup a growth plan that’s challenging and communicate that it may be challenging and track to it. I like to plan for the 1, 3, 9, 12 and beyond and use data obtained directly or through peer feedback to gauge fit; if there is going to be tissue rejection, you need to act fast and figure out what you need to do to make it work successfully.
These 4 steps get you on track but you will still need to build additional on-boarding processes (around material and core knowledge ) that will grow the employees product knowledge. Its also important to keep your existing members in mind when you optimize culture as you want to grow the existing employees as well and not just the new ones.
At the end of the day it helps if we recognize that the teams we work with are more than just “Random people”; they are people we spend several hours with, they are friends, people we trust, can openly collaborate with and people we want to continue to work with.
When one finds a team they can work with for the rest of their life and can call family, its no longer “work”…it’s just a large friends & family gathering where they just happen to be working on something together and having fun.
We should all build and be part of such teams.
Maturing from a StartUp to a StartedUp culture – Series Intermission
People?
Yes!
Product?
Hell Yes!!!
Process?
Boooooooo!
Is that what comes to your mind when someone mentions “process”? For many that’s a “Yes!”… “We don’t need no stinkin process; we just want to work”
“Process is just a book definition of something”, “its boring stuff”, or “Theory that doesn’t apply to the real world” are some of the phrases I have heard people use in disgust to define what process is; and in a past life someone used a “process is something that doesn’t apply to a startup or startup culture” on me….
“We care about people”
“We care about product”
“We only care about people and product”
..but what about process? why does process not get any love? What is it about process that makes people cringe? If process is evil, why is it that many methodologies (based on research and metrics) focus on the importance of all three (“People”, “Product” and “Process“)?
Process is everything that people and product are not.
Process:
- is culture and a shared understanding,
- it’s how your teams work and collaborate.
- it’s how you measure performance,
- its how you innovate, grow, plan and deliver product,
- it’s how you engage and grow people,
- Its more than ISO certification…
- its a lot more than this
Life is a process that’s filled with people and products
(among other things)
Dilbert – Scott Adams Inc.
Zeeshan Sheikh 