Are you leading or managing?

“The key to successful leadership today is influence, not authority” – Kenneth Blanchard

I have been thinking about this a lot lately. I am well-read in the aspects of leadership and agile principles, consuming as much as I can to fill not only ways to do my job better but as a personal fulfillment of exploring ideas. One thing on my mind lately has been surrounding where leadership lies and what it should be focused on as opposed to those people in which you have doing the work or helping management the work.

In my opinion, the cornerstones of leadership, agile or otherwise, is to create that compelling end goal and vision for the unit/group/organization, make it transparent, effectively communicate the needs from others that you have within your role, hold them accountable to the work being done, coach and guide as needed and get out of their way to accomplish what needs to be done. I believe this. It is core to who I am.

But as leaders, we often cannot get out of our own way. Many of us have come to our role through amazingly successful careers within the technical industry and are still deeply attached to that. The idea of solving people’s problems through smart solutions probably lit a spark for each and every one of us. However, even as much as we shed this past, I observe so much of it being held onto for various reasons. Organizational pressure, people issues, want to “be involved” or a perception of ultimate responsibility.

Lyft or Uber?

In the area in which I work, these crowd sourced car services are very popular and people use them for short trips for errands to leaving work and returning from an appointment or for safe rides after the bar crawl they undertook with their friends.

But when you secure one of these services, do you feel the need to take the wheel? Guide the trip? Watch out for every pothole, distraction or provide constant directional guidance to get to your destination? I doubt it. I imagine (as I will admit I have never used these services) that you provide a destination and you trust in the exchange of service for money that the driver will get you to that destination. If you are doing all of things I mentioned above, I have to ask; why didn’t you just drive yourself?

But as leaders, we can often find ourselves being that “jerk” of a passenger that distrusts the person we have hired and we have to lay hands to the wheel ourselves.

Do you trust the people you hired?

Have you hired well? Do you have the skills you need today with the capacity to think about where you are going tomorrow? Maybe you have people in place to manage daily operations, are these people that understand what you needs are and coach and hold accountable the people doing the work meet the clarified end goals and needs? If not, are you directly involved as a result? Do you distrust the people you hired to actually do the work? Then, my agile friends, you have a people problem. If you hired the right people, provide them coaching, guidance and freedom to meet the goals with accountability; they just might amaze you.

And on a side note, stop carrying dead weight if they are not the right people. If you have people that are not meeting the expectations (that are being clearly communicated) you have two options, coach them up or coach them out. Putting your head in the sand or allowing higher performing to make up for the lack of effort or skill in others breeds nothing more than resentment to your leadership and a unhealthy culture.

If as a leader, you communicate the things you need to support your role clearly, are available for any refinement or feedback and hold accountable those people you hire to achieve these goals, haven’t you done what you need to do? Are you supporting them when they hit unknowns by coaching them through ways to solve s problem when they hit an impediment and empowering them to try and find solutions? You’re off to a good start here in my humble opinion.

But if you cannot trust the people you hire to design the mechanisms to do the work or managers of daily operations context to ensure that the work is being addressed, why did you hire them? If you have to be personally involved in the deep woods of solving the how of every need, perhaps you need a role in doing, not leading.

Assuming this posture is hard

Being a leader who steps back and empowers the lowest reasonable level to design how the work gets accomplished and holding accountability to this being done is difficult. The pang of fear of “ultimate responsibility” creeps into your head. But guess what? If you are clear on expectations and accountability for that work, the team will design the system in which to meet that need without you and you can hold them accountable to do so and also accountable to provide the information in a transparent manner so that you can provide it upwardly or maybe just get out of the way and make it transparent to everyone and gain deeper insight into areas that you see as problematic based on the things you feel are important to keep a pulse on.

It’s easy to say “yeah I trust my people” or “they’re smart and they can figure this out” and then your actions demonstrate the contrary. Things like “I need to be in that meeting” or “I will do this small thing that actually another role should be doing” are examples of you saying the words but not demonstrating your stance to let people use the power they have in the role you hired them to do (as empowering people is a myth; they already have power) sends a poor overall message.

But what if they screw it all up?

Let me answer that question with a question to consider … “do you want a sustainable organization that knows how to take in problem, organize the work and act to deliver end solutions”? If you do, how will they ever learn to do that if they never start doing that? Yep, they may screw up. And it could be bad and you could get your ass handed to you by leadership above you as a result. But you can take that beating, pull them together, make them aware of the issue and ask them to solve the problem then hold them accountable for that solution. Because, if you have not learned this in business yet, you can believe 3 truths:

  1. Things will sometimes screw-up. You try and mitigate that or have a plan of restoration for those things you know about.
  2. People will screw-up. People are fallible. Utilize these situations to recover and learn. Keep things transparent and visible and hopefully you’ll see them coming more easily.
  3. You will get you backside chewed for something you are not responsible for sometime in your business career. If it’s a routine thing, you might think about a new organization But when you are responsible, you are responsible. You take the hit and do not pass the beating forward. Communicate effectively the issue and work to get people to solve the problem and set accountability. Do not take it personally or become embarrassed and mettle as a result. Shoulder the burden of being a leader.

I have worked places where there have been more than one screw-up within the company doing the work (see coach up or out statement above) . I have never seen these people so invisible nor so powerful to bankrupt a company or close it’s doors alone.

If people screw-up, allow the operations level folks to address the problem once you communicate the problem effectively. Don’t just solve it for them.

Demonstrate and hand over ownership

If as a leader you have a young or growing organization that need something more than being provided a direction and vision at first, this is ok as well.

There is absolutely nothing wrong with you creating an initial guidance or starting a process and modeling it. But you have to turn it over ultimately to the people who need to own that process. Once you get the ball rolling, let them begin pushing and if necessary change direction or change the game altogether.

What you should spend the time doing is clearly articulating the need being met, the end goal being accomplished and the expectations you have of the effort. Don’t let the pride of being the initial creator get into the way of how the work is done. Once they get the understanding of the process you champion, the underlying goals and the expectations, they will either continue as you modeled or may even take it to an even greater level you never though of. Your continued method of involvement is expectation and accountability at that point, not direct involvement.

Let you managers manage how things get done

The last advice I will explore starts with a reiteration of what a leader needs to do in their role:

  1. Set vision and direction
  2. Set expectations for the things from the organization to meet your goals
  3. Trust your people to do what you hired them to do and get out of the way

In closing, if you have an operational manager level, please allow them to do the job for which you hired them to do, manage the work. Part of managing the work (and the people as there is administration that occurs with people management) is organizing the work and often designing the workflow of effort. Let them learn to to do that with the people in which they need to get the work done. Hold them accountable that a consistent, visible, clear method that can be communicated exists and hold them accountable to how they say the work will get done through actual value deliverable and continuous improvement (as any organization should focus on both).

Let them solve problem with the people that they have to work with to ensure that the work is getting done so that the work and the pipeline of work is more sustaining at that level than the leadership defining it. Those things tend to have a destructive effect when leadership leaves as a) people are often unclear “why” the work was done this way and b) the ownership of the how of work is completed is lessened by the lack of direct ownership.

Hire managers that can shape this work with team members and peers, getting the right people in the room and that focus on the growth or the organization to meet the pipeline of work, Give them the space to execute on the large ideas that you feel are important for guidance and work to refine them into tangible things. Trust, support, mentor and coach them. These may be the future leaders in the very organization that you lead today. Prepare them for that should they take on that responsibility.

I hope this helps you really think about the difference between leading and managing in a broad sense. I have to remind myself of this a lot and constantly remind myself to stand where I need to be in terms of being an effective leader. It’s a hard thing not to get pulled into those conversations in which I get to be in the weeds or abandon these ideals. I just have to remind myself of all of this and why it is so important,

Until next time, stay agile!

Advertisements

My Ideas for Hiring and Onboarding – Part 1

“Mistakes are the best lessons while experience is the best teacher” – Anon

One key piece of agile leadership is the deeper understanding that the people that are doing the work are a core component to your success.

As a leader who personally cares about the organization that I work for (as I do with any employer that has a mission that is aligned to being a more progressive and agile group) I spend a lot of time thinking about people. Not only the people who are here today as staff members, but the people who will join us from the trails we set today.

I often ask myself a continual set of questions:

  1. Is our hiring process (as much as what is under our direct influence or control) optimized and are we keeping it fluid to change to the changing landscape of hiring and the changes in the market?
  2. Are we using hiring practices using a balance of demonstrated skills but remaining open to closely listening to how people think through problems to discover potential undiscovered gems of employees with lesser demonstrable skill?
  3. What is the end user experience of our employee on-boarding after the hire? Is it consistent, cumbersome or does it provide them with something that begins positive employee engagement? Are we gaining feedback?
  4. How do we setup our hires for success in terms of tooling preparation for their job, understanding our technical, diverse social, political and cultural environment and celebration of them joining us?
  5. Are we learning from our experience and examining the ways others perform this process on a routine basis?

I ask these questions and I will be open and admit, the answer is not always a resounding “YES” in my mind. And this … always troubles me. My desire is to create an experience of joining my teams that makes you excited that you are here and ignites that initial spark to not only do the job that you were hired to do but to find a way to be a part of improving the culture as we move forward.

I freely admit, that as a leader I often suffer from the inner struggle of having ideas bouncing around like bumble bees but not always having all of the support I need to align my vision to the end real outcome. I have learned to understand this about myself as it creates a constant inner tension of “there is more I can do” which is both a positive drive but can be draining (which means I have to allow myself to level set and recharge when I since this).

But I began to really think about what this overall process looks like to me and how I might advocate to try an implementation focused on:

  • Hiring the “right candidates” that provide value-add to the current culture in helping it grow.
  • Providing an onboarding experience that is timely, engaging at both the micro and macro levels of the organization and provides a positive experience that engages and supports them from day 1 and that learns from doing.
  • Create an opportunity to “prepare them for success” in their new role through proper tooling and focused education and direct experience before introducing them into their daily routine of their role.
  • Possibly hire them with other team members so that through the process an underlying sense of bonding can occur to create a secondary support system when they transition to their daily work.

Many of you are reading this right this moment and thinking, “big deal; my company does that” … But my company is part of the public sector serving citizens and concepts like this are not the mainstream of thought and definitely not the concepts of the people in leadership. But I have always been one who asked “but why couldn’t we be this”?

It may be often more easy as it may be when the company is owned by a group of share holders or private investors but just as they have concerns over profit margin, the public sector always has to consider the responsibility of fiscal trust granted through being financed by the public (even though some betray that trust I know).

How hiring often is done today in the public sector

When I started in my current role, hiring was very suspect to me in the sense that it did not typically contain any form of demonstration of possessed skill for securing the position for which a person was applying.

It was usually 100% conversationally based or had a minimal “test” for skill that was often used to determine “right or wrong” as the answer subjectively (which code implementation can often be) without any real understanding of the person doing the work. I have often said many public sectors went like:

Employer: “So I see on your resume that you have N years of experience in technology X”?

Me: “That is correct. My most recent experience being (blah blah blah)” – This is where I regurgitate my resume and add some detail.

Employer: “How would you rate your skill from 1-10 with technology Y”?

Me: “I would say I am a 9 as no one is perfect. Fill in details” – This rating means nothing as no one actually knows what the scale is for each increment. Years? Lines of Code?

The review of my resume and asking questions derived on the spot from it would continue …

The conversation continues (for at least one hour) and often if there is a click and the resume seems fine, the conversation degenerates into basic technical chit-chat. Boom. You are hired.

But what is the glaring issue here? You have absolutely no idea, except from my exceptional resume, if I know what I am actually talking about other than perception. We did not discuss anything tangible to the skills you needed for the position. It was primarily based on what I told you I had done and provided on my resume.

This is of course a very simple viewpoint and not taking into account many people who interview, like myself, that may have worked with solid team members who knew my caliber of work and could vouch for such effort and skill to the hiring manager.

And worse, many public sector hiring managers operate under the assumption that if you do not work out during a “probationary period” that you will be dismissed. This rarely happens as they do not have the uncomfortable conversations with the employee during this period informing them that they are not doing the job as to be able to justify that release (a requirement of public and many private HR policies).

How did we change our approach to hiring?

When I assumed my current role one of the first things I sought to do was 2 things in reference to the hiring process:

  1. I wanted it to be more in line with general private industry hiring practices that invested more deeply into hiring practices so that it required not only an employee to invest deeper into the process but also combine it with some base skill exercises guided with the hiring team to see skill level and how they thought through problems.
  2. If the right candidate did not show up for the interview (meaning that they were someone who “might fit” but we did not feel confident in them) that we would not hire out of desperation of losing the position, frustration of starting over or to fill a quota. I had experienced too many times that hiring managers would hire “the best person who showed up” and compromise the position as to not have to jump through bureaucratic hoops again.
  3. I wanted to utilize grass roots recruiting and look for ways to personally connect with potential candidates when possible to demonstrate to them that work in the public sector for a technical person can be fulfilling and have many opportunities for serving others as well as provide an opportunity for some benefits not seen when joining a startup or boutique development company.
  4. I wanted every single candidate that left our interviews to have felt challenged to earn the job and the experience we created through the process to make them want to join us, even if they were not our selected candidate.
  5. I wanted the hiring process to be focused on “what we needed” in a broad sense and just not distill to a checklist of technologies or experience.

The first thing I focused on was making the hiring process more meaningful to hire the right people through a deeper and richer hiring experience that focused on learning more about the candidate from a behavioral and technical viewpoint.

Together with my leadership team, we implemented a two fold approach in which a hiring panel would first have conversations around concepts of behavioral based questions (for about an hour) to begin to gauge their thinking process around typical issues or team situations common to the role followed by 2 hours of more in-depth technical exploration and hands on work ending with a pair programming exercise in which they were the driver in the scenario for developers and other scenarios based on the role. This worked out really well for a couple of reasons:

  1. It allowed us to give them the opportunity to relate previous experiences of situations and shape the questions around what they learned from the experience or why they took a specific course of action. This allowed us more insight into how they reasoned through a situation from the most routine to the most challenging within their role.
  2. It allowed us to examine the candidate from a technical point of view apart from trying to get to know them in terms of personality and really focus on what they already knew from a technical perspective but also how they reasoned through areas they did not know or how they approached something to which they had little or no familiarity. Did they try to BS their way through? Did they openly admit they did not know and not try or did they tell us about their lack of knowledge in the area and reason how one might approach something or use a certain technology even without that knowledge. The first 2 gave us insight into the ability to be humble in the face of the unknown and how they handled this but the latter opened us up to see the potential of a person’s growth with us and often led us to finding people who we could see wanted to know and had that drive to learn. Learning how people think through a situation can be as invaluable as just the right answer.

We always de-briefed after a hiring process not only to decide on a potential hire but also to talk about how the process went overall. We used the concept of a retrospective within our hiring process so that we could seek improvement the next time or adjust things that were not working. This was tremendously helpful and a far cry from the ending of standard hiring cycles I had experienced before. It incorporated the potential of improvement through reflection.

It allowed us to not only to apply agility into our people operations through inspection of the process but to allow us to gain better insight into the candidates coming in a bi-modal manner within a more reasonable timeframe for a technical interview.

What were our initial constraints that we had to work around?

  1. Public sector hiring is a highly regulated, rules driven system that has fixed timeframes and candidate constraints and posting for positions is often outside the hands of the hiring organization but rather handled in a centralized manner using template position descriptions.
  2. There are minimum educational qualifications that preclude candidates without a formal college education (and matriculation) or significant enough experience within the given field from qualification that can exclude many candidates. This meant that often people without formal education or experience fell beyond our reach. We could not just hire a technical savant that had never done anything or had any IT degree based on the hiring system.
  3. Protected class groups are given some preference in consideration (not preference in hiring) and justification must be made when not hiring a candidate from a HR protected class. So we had to ensure that if we rejected a candidate it was for sound rationale, not a gut feeling.
  4. Large scale private sector hiring processes are not unlike large public sector hiring processes. They are often slow and there is delay from groups external to the hiring group to confirm the hire, mandatory processes for which the information must pass, established formats for hiring submission for consideration by hiring managers, etc.
  5. Salaries, especially public sector technical salaries, are often non-competitive with private sector positions and often specific job classes simply do not exist meaning you have to employ grass roots marketing to use a position in a different manner and have people apply through personal recruitment. We had to consider a “hire and grow” strategy to remain competitive with the market and for more seasoned people we needed to find those that wanted a better balance in terms of their career and life needs.

Some, or all of these challenges are not uncommon to any person who hires within the public sector. So how did we address them?

We actually were fortunate to have a local human resources leader and team that wanted to ensure that we understood the process but remained open to conversations about what these obstacles were and work to address them with the centralized hiring authority. Forming a relationship with the HR team and understanding their world and the constraints under which they are responsible helped us work together to find the best way to work. There were some things we could not eliminate but what was possible was examined. Creating and maintaining this partnership helped us understand and better traverse the system of hiring in the private sector.

In my opinion, these partnerships are critical. The overall process is fraught with its own rules, domain language and understanding. Having people that can assist and become a partner that understood this world better than I became tantamount to driving towards a new approach. I would highly recommend that people desiring change in this space of the process build these partnerships. Without them, you are trying to traverse a system for which you may be woefully unprepared to understand all the nuances and aspects to this approach. These partnerships have been invaluable to me in understanding the roles and responsibilities of the HR system in the public sector and the things that I do to assist them in helping me get things accomplished when it comes to hiring staff.

Grass Roots Marketing

One of the things that was very important to us, and still remains a primary focus, is to share the story of our environment and culture with others that may seek to join us. We have spent time connecting with the local community and seeding the work we do to others as well as creating a significant “word of mouth” through our past hires and ongoing meeting with local groups such as software schools and developer meetups.

Often times, many large scale private enterprises have much more capital that they can put behind their hiring and recruitment processes. So, as a public entity; you often must become creative and put forth more personal effort without that budget to assist you.

We are very fortunate that our HR team understand the benefit of recruitment and is very progressive in the way they think about attracting candidates often hiring domain specific staff to help them understand and connect to the areas in which they are recruiting. This deeper understanding of “why” people want to come to work somewhere and the personal investment in the candidate is in alignment with our thoughts as well.

Staying connected as often as possible to groups to share the view of your environment and culture helps potential candidates get a better idea of who you are and why they would want to be a part. We are always thinking about this message and how it can help us attract the right people into our culture that can continue to be a value add and help us grow today and shape what we become in the future.

The Follow-up

The public sector, hiring often fails as the transition to potential candidate to “new hire” breaks down in the lull of the process. This is not unlike larger scale private enterprises but what they seem to manage much better than public sector is the process of pre-onboarding engagement.

We found a lot of our potential hires did not have the understanding of the lumbering beast that can be large enterprise hiring processes. It often involves multiple groups, departments, sign-offs and approvals. In a larger environment, the processes are often streamlined more for oversight than for speed to on-board. So it becomes critical that you become good at retaining that engagement during this process. Most people, even though excited, have some nervousness about starting a new position. I think a great deal of that stems from the unknown of the new job and role as they only get a small glimpse into the organization during the hiring process. We made visits to local bootcamps to educate potential candidates about the difference that applying to a larger scale enterprise company can be in terms of times so they understood this better.

This is a great opportunity for you to use that tie to help them gain a better picture of what their first day, their first week, etc will be like when they join a company. I have seen many companies that are master at this seeding periodic information to a candidate during this process so that they feel a part of something larger. This is something, as a public sector organization, we can become better at and do effectively without a large scale investment. Here are some examples:

  1. When hiring someone in the public sector, know what the average process length might be and set the expectations up front when hiring someone. The worst thing you can do is have a candidate wait in a black hole and wonder if something is wrong. Connect with them regularly to let them know about stages in the process and pass along helpful information to allow them to prepare for their new job.
  2. Send a personal email welcoming them with information about benefits (or pointers to benefits) that lets them know more about their group. Consider creating a marketing document or website that lets them get to know people before they arrive in some manner and gives them a glimpse into reinforcing why they chose to come work for you. If you have materials that introduce your culture and how you work, get it to them during the interim.
  3. Encourage questions and connection. Be accessible to them if they think of a question, find the answer for them or connect them to the right people.
  4. Organize something after work so they can interact with their new coworkers. Invite them to connect over coffee or drinks so that they makes those pre-connections before they start.
  5. Send them a final confirmation of employment when all is approved restating the salary, start date and pointing to benefits. Send an employee handbook and other materials that might be useful as well as anything else they need to experience the least amount of friction on day 1.
  6. Prepare for their arrival and have a consistent on-boarding process to help them be setup for success. Confusion and red tape starting day one is a great way to leave a sour taste in someone’s mouth when starting with a company. Having there location, tools and access in place demonstrates that you were focused on their start, not that it was an afterthought.
  7. Give them a voice in providing you feedback about their experience. This not only demonstrates that they do have an active role in the organization and use their insights to critically evaluate what you do. Keep the process as lean as possible so that you can change as needed.
  8. Realize that starting a new position is change and with change is often fear of the unknown. Meet with the team that they will work with prior and express your expectations of growth so that neither the team nor the new team member are confused about the organization’s expectation of their progress.

In this blog post, I have discussed the prior hiring process, how we approached it in a different manner to hire today and why these things are important and how we can set them up for the best outcome in the public sector.

In part two, I plan to diverge more into how we might consider on-boarding new candidates and explore some of my personal thoughts on ways outside of what we do at my organization that might further enhance the approach or different ideas that someone might try.

I end this post with a quote that I think embodies the importance of this activity:

“The most important thing you do as a leader is to hire the right people” – David Cottrell

Capacity and Performance

“Your capacity to say no determines your capacity to say yes to greater things”        – E. Stanley Jones

This is something in business we all struggle with in my assessment. How to sequence “just the right amount of work” to deliver value and still all the desired ability of an organization to remain responsive to shifting value needs. My organization has struggled with it as I feel confident many of you have as well.

There are a lot of techniques, both agile and not, to determine capacity and we’ll look at a few and I will express my own opinions here and what effects poor capacity planning can have on teams and organizations.

Somebody call 911!

A lot of us live in a world of “firefighting” as an organization. Not literally, but what I mean is that we become reactionary as an organization as opposed to responsive.  Organizations often confuse responsiveness as the ability to handle each fire as it occurs when it reality this is chaos at its core. Often, these organizations are so busy fighting the blaze that they never take the time once the situation has passed to ask why the fire actually started in the first place or they confuse every flare up on the same level as the entire city in flames. This is not responsive, it’s reactionary and although you may be defined as the “hero of the day” in the moment, it eventually raises much deeper problems that can become exposed and have to be addressed.

Being a reactionary environment is inefficient. It means that there is a significant amount of waste happening waiting for the disastrous event or worse yet it is a sign that work is improperly sequenced to allow a balance of responsiveness and performance. Signs of this are often team member turnover, sick time increases, increased deep policy to attempt to be preventive (the “ban all matches” approach) or just a general negative outlook to solving a problem. Be vigilant in observation for these types of issues as one you define yourself as this type of an organization, it is often very painful to change.

Capacity, Performance and the myth of being busy

One of the things that I have always believed is “do less better”. Ensure that you are meeting the highest value items for an organization but in the face of emergent needs you have to deliberately create slack within your work capacity for numerous reasons. Things like actually being responsive to the emergent pet project that comes up, capacity to nurture your teams and team members to allow them to grow and give back to the organization in doing so and generally to improve performance throughput

Basically capacity boils down to “how much something will hold” from a true math reference bt in our terms it means how much time and work can we consider and remain effective in our performance. Finding area and volume of a given shape to determine capacity is a relatively simple formula but when it comes to people and time, it often gets tougher (although I know many PMP folks who would explain to me formulas of resource management, resource being a word I strongly detest when referring to “people”).

A general rule of thumb is that you will never receive the maximum capacity of a given person or team. Accept this. If a person works an 10 hour day, the best you can hope for us 70%-80% which is roughly 7-8 hours at the high ends. The reason for this is that people are social creatures and have needs like going to the restroom, checking emails, diverting their attention after prolonged focus, casual conversation, meetings, etc.

If there are CIOs/CFOs/COOs/CEOs reading this in awe and shock, welcome to the reality of people. And it is even possible that 10% of your overall workforce is performing suboptimal based on lack of skills, poor work ethic, sickness, burnout or whatever reason. So how do you handle this and still maintain a level of performance without remaining in a constant hiring frenzy of cycling burnout workers?

First, accept your reasonable capacity levels and plan strategically. If you do, you will find that you optimize the flow of delivery within that capacity and you often see higher percentages executed (which can be a different topic to watch for … “dark work” that has no visibility and creates strain but as things are delivered on time no one questions).

If you think more bodies are the answer. You’re wrong. Read the Mythical Man Month. As you increase complexity to any systems you fragment pathways making performance degrade. Think of a small intimate dinner gathering and how conversation can flow well between 2 couples (as they can keep up with topics or break into smaller sub groups and still reflect to the group). Now introduce 2 more, and 2 more, and 2 more. Make it a large dinner party and afterward come home to discuss the topics of conversation. The pathways are too complex. You cannot keep everyone in the loop on all of the conversation occurring.

The same thing occurs with software development. As you introduce more and more staff you increase the complexity in the forms or handoffs, communication pipelines, individual or small group decisions that get made, etc which make it slower as rediscussion, rework and deeper changes are often a result. This is often why I prefer product feature teams as opposed to component teams whenever possible.

Secondly, if you want to be responsive; be deliberate in building in slack to your approach. Let’s take 3 examples; road networks, servers and teams.

Road Networks:

You are driving to work. There are 30%-50% of other cars on the road. You make your commute in a reasonable amount of time. But we are not utilizing all of the capacity of the road! So let’s crank it up to 100% and make that same commute. What is the expected result? Traffic jams, delays due to accidents, road rage. We actually decreased our performance by trying to fill all of our capacity.

Servers:

This is a little tougher as in the day of invisible scalability of cloud networks it may seem a poor example, however, if a server capacity is maximized to 100%, performance degrades; it is a given. It results in unneeded swapping just to meet all requests. It may seem negligible but if you have ever been frustrated waiting for a web page to load, you may have been experiencing exceeded capacity.

Teams: 

Filling a team capacity to the brim can result in whiplash when trying to meet those emergent needs With that allowed focus, you have teams that maximum their throughput through selection, self-organization and a regular cadence. If they have other responsibilities (support, meetings, etc) not building in that capacity that is aware of these things will result in feelings of being high performing but in fact often degrade performance and hide a lot of work being done on an employee’s own time (which can result in a whole host of issues).

But we have to keep people busy

Do we? Did we hire the individual with a specialized set of skills to ensure they remained “busy” or did we hire them to ensure that we had the necessary skills to realize the end result of value?

If a manager pops into a team room and a team is relaxed, having a conversation about Dr. Who or some world event is that ok? Sure it is. If they are personally making their commitments and failing to deliver value, then you might sense a problem which could be everything from they are sandbagging to they are being disrupted externally for other work to the guidance they are receiving is creating deep and counter productive conversations at the time of delivery from a lack of understanding. It could be lots of things.

The point is not to keep people busy. In trying to do this based on observations of social interaction as a sign of low productivity, you toss the idea of capacity out the window. For me, I want a highly motivated team that wants to come to work and deliver because they know they have a direct voice in setting and communicating reasonable expectations for feature delivery. Does this not mean that occasionally the team may not be forced to ramp up commitments to meet a deadline? Absolutely not. But if you trust the people doing the work to be reasonable and responsible in communication, transparency and of the delivery of that work; often times I find teams will rally to address the hard need.

Otherwise they are back in firefighting mode.

Seeking to ensure teams and team members are “all busy” is a false goal. It equates people with server throughput. People should be cultivated and grown if you want to create longevity of any sort in your company with employees. They will become your greatest champions and advocates if you embrace this. They will tell others of the great company they work for and they will work hard to deliver of their commitments.

I write this post today not out of any personal or professional frustration but from an observation that many organizations focus on “busy” as opposed to intentionally creating space to be responsive to emergent needs. Just like a home’s unused space get filled, professional people fill the unused space (through skill acquisition, environment improvement, idea sharing, etc). But just like a home; should you inherit your grandmother’s giant steamer trunk if you have filled all of your capacity of space it gets placed in an odd location or you “make room in the attic”.

Be honest and kind to yourself as an organization, your people and reflect a true understanding of capacity by considering more than just “delivering more” or “being busy”. Understand what other impacts that people have that impinge on capacity and to become truly responsive, be intentional in creating slack within your overall capacity.

As I always say and I will say once again … “Do less better”.

 

Observations and Adjustments

“One must learn by doing the thing, for though you think you know it-you have no certainty, until you try.” – Sophocles

I always thought this was an interesting quote. You cannot gain any certainty without trying … something. And even at that, you may actually fail. But if you are truly learning, you adapt and adjust and give the next experiment a fair shake of success.

From software to science, using experiential learning as a way to define an experiment, to conduct and observe the outcome to potentially learn and adapt the experiment as needed has created amazing products and scientific breakthroughs.  It works. I think we can all agree on this.

So, why do you think we don’t apply it to something like organizations?

Fear of Failure

Thomas Edison is quoted to have said “I have not failed, I have just found 100,000 ways it will not work” in relation to his research into the first lightbulb. This is a very healthy way to look at progress but very contrary to a lot of business thought. Why do you think that is? My speculation, which could be very wrong, is that for Edison there was the possibility of the realization of a dream forged from that creative spark with future potential of a product. For many businesses, the future capital earnings heavily outweigh the creation of “the thing”. Many of the successes in the world have been born from the want to capture an idea and then only become monetized later therefore reducing the fear that capital is burnt without return.

Often times, creators of these eureka products (Google and Facebook as a couple of examples) are often shaken by the idea of monetization as the creation was the core driving factor, not the end profit result.

I honestly feel that the initial introduction of the drive to capital gain often induces this fear and it creates a trickle down effect from the very top all the way to the source of creation of the product. The pressure to get to market first and capitalize of the highest money stream may cause people to become less innovative, take less risks and instill a fear of product failure even before it hits the waters.

But I contend that keeping the horizon for learning at a “just enough” level not only helps you determine a better product but it can save money from building out full features that are often unused (see the pareto principle as applied to software features) or poorly received.

Minimal Viable Product

Eric Ries of the Lean Startup approach introduced this concept (I think it had rolled around for sometime but he is connected with the idea) as producing the smallest amount of the idea to learn from. Basically a seed of a product to gauge a posture to “pivot or persevere”.

One of the most noted examples of this approach is Dropbox. The initial MVP for this product was a marketing video explaining the product and how it would work. This was launched and an accompanying form was created so that potential customers could sign-up for future information about the product or provide feedback.

This allowed them to gauge interest to know if their investment into the product in which they saw high potential value showed a reaction by their potential market. This was actually one of the most brilliant approaches I had ever seen. They were actively working on the product and seeded their base features before completion to test the market space. Had they gotten a less than exciting response, they could have targeted marketing research and determined why or pivoted their approach in some way (either the campaign or the product work).

How did this help them in proceeding this way? It allowed them to learn about the interest of their potential market and gauge feedback from customers before launch so they could consider the feedback and potentially pivot with the market. If the feedback was a “lame duck” they could have abandoned the product altogether and pivoted towards a new direction. This allowed them the potential of failure much earlier. The potential magic of all product management after this stage is having that gut feel for how long you can ride this curiosity until the product must get to market. This is why really good product owners stand out.

Minimal Marketable (or Lovable) product

This is another concept introduced that we see extremely frequently in the market space of software and software services. Determining only those core level services or features that get buy-in to a product for more. This means that product vision has to be solid to get these to market and feedback and seeding of new features is sought to be cadenced regularly.

The initial iPhone release is a prime example of this approach. When initially released, the iPhone lacked many features that were present in many of the competition in the marketspace (MMS messaging, apps and the ability to copy and paste). But when released it became one of the fastest selling phones in the cell phone market (competing more closely with mass volume sales of game stations like the Play Station 3). Which it did seed was a phone level OS with an SDK for developers to build upon (even though there was no store in place yet for deployment or sales mechanism). These “missing features” allowed them to gauge the market reaction as they had faith in their initial MMP to ensure the importance of future features and to allow them space to ensure that they released the best quality updates with these features sought by customers.

They released a product that seeded a way for it to grow (the iOS Phone SDK), made it available to the developer community and focused on those features of differentiation that allowed them to not only contend with the market but even under strong criticism and scrutiny release the features not initially there in a thoughtful way consistent to their brand and end goals. They essentially “hooked their customers” through thoughtful and innovative design and a stellar responsive interface (far better than competitors) which allowed them to build the features that would build a community around the product. By making the Phone OS available, they even made it possible to “jailbreak” the phone and create some of the missing features which could allow them to gauge what potential customers seemed to be drawn to use. This allowed them to strive to introduce the right features at the right time and draw from the community at large to create a learning opportunity and pivot as needed.

The Design Sprint

Another recent approach to the idea of validated product learning is the Google Ventures Design Sprint . This idea distills the idea of rapid learning through a functioning (and often simulated) prototype to gauge immediate and rapid feedback from real potential customers for a idea over a short span of time. O’Relly Media has also written an excellent book on this approach which can be found here. The idea itself has been around for sometime and often attributed to be initially used at IDEO Design as early as 2009.

The idea divides the approach optimally into a 5 day approach which breaks down to one day focused on the following events:

  • Understand – Define and unpack the problem to solve (though interviews and research)
  • Diverge – Generation of ideas to solve the outlined problem (more is better, no wrong answers)
  • Converge – Determine which ideas or pieces of ideas will be pursued for testing
  • Prototype – Build a prototype of the solution that end users can actually play with and develop testing criteria to observe
  • Testing – Validate your assumptions through observation of user interaction with prototype and providing feedback

Here are a couple of real world examples of how this has been performed

Building a new Shopping Cart (IDEO, 2009)

Savioke – Building a Room Service Robot

This approach may not work for every scenario but as a tool in your toolbox for learning, this can be a rapid way to learn what resonates with your potential market and generate immediate feedback from real-world interaction.

So, where does that leave us?

In the vein of this blog being focused towards being about agile leadership, I wanted to explore this topic to hopefully inspire those leaders to truly see the value of a targeted small experiment from which you can gain quick knowledge about your potential product from which you can pivot, persevere or abandon. The key being that failure should always be an option but seen as a mechanism for learning and focus as opposed to use as something to vilify a bad approach.

I hope this will guide you to finding tools to help you target your search for knowledge or even better be inspired to create the next approach of which I blog about.

Fail fast and stay agile!

— Todd

 

The cobbler’s children have no shoes.

“If we desert the inner self to focus on the energy outside, it leaves a vacancy inside”              – Trudy Vesotsky

There is a dilemma that every software group I have worked with has faced and I have never seen anyone actually “solve it” in the grand sense although I have seen some really good ideas in action. It’s the idea of investing back into the work you do as a software group so that you can leverage this investment in the ability to continue to “do the work” for others.

Hence the reason for my blog title. The cobbler does amazing work for all of the paying customers wanting to buy shoes but never finds the time to put shoes on his own children’s feet or teach them to be a cobbler themselves.

Where does this often stem from?

In my experience, this perpetuates inside an organization in several different ways:

  • Fear to apply capacity by the leadership for something in which direct end profit is not seen or justification seems hard to communicate upward to these leaders without technobabble.
  • Guilt, on the side of the workers, who feel like they will never be granted the ability to do this so they either complain or burn the candle at both ends to make it happen in shadows.
  • Lack of focus or understanding of need. As Stephen Covey talks about in his works, sometimes we are “too busy picking up rocks to as what kind of rock we are looking for”.
  • Sometimes it is just culturally engrained (which is the toughest). It is just generally accepted (and often with great grumbling) that anything without direct tangible end stakeholder benefit is just less important.

I remember when I was a young IT professional and I was sitting with an assistant director of the company who had tasked me to thoroughly understand how their IT organization worked and look at improvement opportunities.

I posed the question “I have observed that any project that is related to the business receives a budget, people and focus but I cannot find where the same approach is made when approaching upgrades of tools, servers or your technology stack and training, why is that”? There reply was immediate without hesitation, “those things are the cost of doing business and therefore below the line and as they are internal in nature are more flexible than customer delivery”.

I paused for a moment. “So, if they are the ‘COST’ of doing business, why are we paying for them on a revolving payment plan? What I mean is if the core goal and mission is to deliver modern and innovative solutions to end stakeholders, how can the justification of making the things upon which support your competitive advantage in the market be something that is addressed in a “stop and start” manner to be superseded by other items without completion”?

And here it came … the death blow. “This is the way it’s always been. We cannot just take time to improve internally and not deliver things to the customer”. Discussion over.

I walked away from this discussion feeling really sad (and as a young professional, deflated and experiencing an early disillusionment) as this company had so many bright, excited people who were inspired to do the work they did. They wanted to do interesting things and support the business through bringing potentials of innovation. They were, instead, given the communication that we keep the factory running. We only think about making improvements when a production shutdown is going on. What this meant for them over time was they saw themselves get further and further behind and the climb to get current made the effort, the learning curve and possibly the investment so great that they would never receive the support they needed to make it happen. So, they grumbled, they left, or they resigned themselves to work with what they had to get the work done.

I tell this cautionary story as in reading it you may see similarities in the company you are in now. If you are and you are a leader in this organization. Affect change. Even the smallest changes you can do as seamlessly as possible to keep some cadence of improvement going. Don’t let the hill you pile up for yourself make it impossible to climb.

So what can we do about this?

Again, I do not have “the answer” as my organization struggles with this like others do. We have at least made a commitment to our culture and ourselves to keep visibility on this and push for these things without fear. Sometimes we win and sometimes we don’t.

Please do not misunderstand me in discussing this. I am not talking about the “junior level developer fascinated by every technology under the sun” sort of change. Not that you are in a constant pivot. But that if you are going to be in the business of software, you have to ensure that your tools and approach allows you to grow at a reasonable pace with the industry”.

You do not want to find yourself in a situation where the iPhone has been out for a decade telling your team, “we need to learn how to develop for mobile”. You might get there but it’s not likely that you are going to be competitive here. You probably missed your window. The same comes from jumping on tech early just to “get there” with no plan on  cultivating the approach or refining the skills. I cannot tell you how many government agencies (and companies that contracted to them) I saw build a native iOS mobile or Android app just to see it wither on the vine, never get updated or enhanced and die on the vine. Mobile App storefronts are littered with these types of applications. They wanted to be “first” so they could take advantage early for the trend but in hiring out the work, they created a dependency on a end vendor to update this platform and typically at a premium, which often meant that unless the app was getting mass attention, slowly stopped being paid to update and support.

Those cautions aside, have some seasoned technology professionals (CTO, architects, senior developers) in your organization that watch technology trends and “sticking patterns” of languages. Understand your regional technology market so that you can hire for technology you can support more readily or develop a good “gig based economy” model for models that work in conjunction with teams you are training on a new technology. Don’t think you can ever stop learning and growing. And as a result of that, keep your toolsets as current as reasonably possible so that you are riding closer with software trends and not trying to just race to catch up.

If you are in the business of software, and this applies even if you are a software group within a non software company, cultivate and advocate to the business leaders as a whole being reasonable about the investment they make in technology as a core support of the business. Don’t be silent while budgets are drawn and plans are made and let the needs of the very thing you do not be heard. Be certain, the “cost” of doing business in building software is in fact a cost. Do not let it become something to do when there is time.

Get creative.

One thing we can try (and that we do here) is to adjust capacity of people to try and free up time for focus on doing these types of things. This can often be more palatable for a business. The idea of losing 2-3 people for 1-2 weeks to focus on this thing is something that “feels” reasonable on face value. It’s about the impact of a vacation by an employee. You will be amazed at what people who are motivated to leap, with some small pre familiarization, can get done when freed up to focus on a task. Just try and keep things small, targeted and end goal based. Even if the goal is research of a technology, have an end goal in mind like a “go/no go” and recommendations for investment.

Outline the tangible benefit for the effort. Think about what the investment will ultimately do for the business. And it does not have to be only about technology. Maybe it will allow you to recruit better in the market space, maybe it will allow you to retain staff as they continue to grow, maybe it is an early investment in the direction a given technology is headed. And sometimes, just sometimes; it’s to ensure the business does not make a large scale investment technically that it will be dependent on a recurring vendor cost to support, maintain and update or the marketspace indicates that leveraging of this technology is actually less effective than the vendor indicates. But stay focused to work on it. Don’t shelf work each time more work comes in. If you continue to do this two potential situations can result a) the ramp up time to get back to where you left off multiplies each time you walk away or b) the direction you were headed becomes obsolete and therefore require starting over or abandoning the effort (which may not be costly but it does have a negative impact on those who have done the work).

Don’t let yourself keep building shoes for others and never attending to your own family.

Take a moment and pick one of these kids and build them some shoes!

Recommended Read

“If you’re comfortable with the amount of freedom you have given your employees, you probably have not gone far enough”. – Lazlo Bock (Work Rules!)

I recently completed the audiobook of “Work Rules!” by Laszlo Bock (I went back a read passages I really wanted to dig into in the paperback as well). For those of you who are unfamiliar, Laszlo Bock is the Senior Vice President of People Operations for Google. He shares a very interesting insight into how they apply programs, policy and practices that impact employees and surprisingly how much data they collect to understand if they are actually making any real impact to the employees or the culture at large.

Some of the mystery about what/how and why Google does some of the things they do were outlined in the book. A few of them were:

  • Many of the services (like the haircut bus) provided to Googlers are at no cost to the company. It is often a brokerage between people operations and businesses for them to generate business buzz and customers. Many of things are often out of pocket for employees but adds a convenience factor for them to not have to schedule time to go and do these things.
  • The “micro kitchens” famously known at Google that allow googlers to grab a snack, a coffee, water, etc are actually spaced throughout the campus with intention to stimulate “unplanned interactions” where people from groups that might not directly work together might interact or spark and idea in one another.
  • Google has a performance management process and it gets scrutinized for effectiveness and adapted to bring the most value.

There are some really interesting ideas in this book. Not all of them are applicable to every organization but the underlying message is. If we have people focused on the operations of people and people are our greatest company investment, where is the downside?

The spirit of this book will hopefully inspire you to just think differently about how you can impact your culture in small ways and use data to determine if the “perks” you are providing are doing what you intended. I was so inspired by this book that I bought an extra copy so I could share some of this with our human resources, who are progressive thinkers as well.

I would highly recommend this book if you are leading a team, transforming an organization or maybe are part of people operations in your own company.  It will definitely inspire you to think about what things that you might be able to do to enhance the work environment and how you determine if it is working.

Stay Agile! 😀

 

 

 

 

 

 

Draw How to make Toast

Just a quick redirect to something I have stumbled across and found fascinating and wanted to share. This approach is an introduction to systems thinking and what they call “Wicked Problem Solving”. This is another approach from Tom Wujec who outlined another team approach to iterative innovation in the Marshmallow Challenge Website.

I just found this a very interesting way to get to core problems to solve for a group. Check it out:  Draw How to Make Toast Website .

Hope this gives you another tool in your agile toolbox to do great things!