Continuous Learning

Pushing Past the Peter Principle

The path that I have seen often in leadership / management is that the best individual contributor gets promoted.   They get promoted because they are the best at what they do and obviously they should be the one that trains, manages, and grooms the other people that do exactly the same job.  They do this for a few years and are great and passionate about it.  They spend most of their time setting up standards, scaling the team with people that were less productive than they were and try to coach them to be just like them.  They are still afraid of their skills as a manager, so they don’t hire someone as talented or better than they were.  The do a good job and then their manager begins to include them in some of their tasks or gives them some of their responsibilities [because management is lonely].  Then they get promoted to manager of managers  and they make it – right?   Not necessarily.

Change and Innovation is the killer of most good managers
It is very hard to keep up to date with the tools and skills that you used every day in your craft after becoming a manager.   You lose some of the skills the less you use them.   That is sustainable to a point – because you don’t need to do that job anymore, right?  The nuances in your domain change and evolve too – but you can get that just by talking to your staff, right?

It is not that easy.   Most knowledge workers become experts in their field through repetition.  We see things more than once – often more than 10 times before we mark it as a trend and begin to put standards or patterns around it.   The standard is that it takes 10,000 hours before you become an expert at something.  However, it is not often so simple as if you see x then do y – there is often nuance in it where you need to understand the complete context of the item.   This is often lost when we are only getting the view from the sidelines or the coaches box.

Remember the game of telephone? [we are going to need a new analogy for this soon.]  The game of telephone is a game played in elementary school where the teacher gathers all the students in a line and tells the first student a phrase and then each of the kids one by one tell the next kid by whispering it to them.  Finally the last student in line has to say what they heard out loud.  At the end the version of the story is always wrong and it is often VERY wrong. — The further you get removed from the problem the more context that slips through your fingers

Another disadvantage of the common management career trajectory is that your boss ends up involving you in their job – now both of you are sharing responsibilities and two people are doing the job of one.  It is good for SPOK [Single Point of Knowledge] remediation, collaboration, and skills grooming, but be careful that you are not over coupling the process and slowing things down.

Why this is worse in software?

Software is changing very rapidly and will continue to grow and change.  Last decades best practices are today’s biggest gotchas.  Software is very good at identifying the biggest problems and challenges and reinventing itself to improve those areas in the most dramatic fashion.  For example, 15 years ago standardizing all of your functionality in a database was the recommendation.   Lock down your data model and use it to force all of your rogue developers to use the same standards and be aligned on the data model.  Today, the database is a commodity where you should be able to point your domain model at any database or god forbid a non-relational database or none at all and it will just work.

Meh, I am solidified in management’s inner circle – I have nothing to worry about…

Now, remember why you were promoted in the first place.   You were a highly skilled individual contributor that was there to bridge between the business and your team as the organization scaled very quickly.   You were the best of your team and would be able to guide the business on making good decisions because of your hands on knowledge, intimacy with the domain, and ability to think about the bigger picture.   Do you still have the skills to provide that value?

So, what can you do about it?

  • Never stop learning.
  • Roll up your sleeves.
  • Dig in.
  • Get VERY involved with your teams.
  • Help them with any and every chance you get.  Take a step back – do whatever you can to remain relevant.

The business needs pure managers too – right?
IMHO, pure managers are a dime a dozen.  There are always new staff that ARE experts in the day to day and can learn/be coached/grow in management.   It is much easier to teach someone management skills than it is to teach them the core skills of a team or a domain.   Plus, trust me, managers are out there to be hired.

What I did about it?

I found myself in this situation because I had focused all of my time and all of my learning just on leadership and management.  I had let a gap grow for too long at a time when it seems like everything changed.  I had gotten involved with a specific domain and focused on the specific problems in front of me.  Until I realized how far removed I had gotten and how I could not jump in and help out a team under a deadline crunch.  On the other hand, I had learned a lot about leadership in the past and I do not regret the learning I did on those skills.   They helped me focus on improving in the skills I needed to get what I wanted to get done.  The one thing I might have changed was to have more of a balanced approach.

I focused my life on continuous learning.  I started from the beginning and did not rush it.   I spent mornings and weekends watching videos to get up to speed with the technologies that had changed.   I shadowed teams and got involved as much as I could.  I started a side project.  I volunteered to jump in and do some of the work the teams would normally do and did it in addition to my other responsibilities.

I keep a learning journal and in the style of Benjamin Franklin I write down what I learned each day (I am getting more consistent about this at least).  I have made this a habit.  I keep a list of things that I want to learn and I leverage others to teach me how we do specific things.

I tried to get as hands-on as I can – and I had a lot of fun doing it.

Now, is my goal to become the best developer on the team? — hell no, that would be a waste of my time and I would be wasting the company’s investment in me.   My goal is to have enough of the context to truly understand the challenges and day to day work of my teams.   This will help me do the best job that I can in my role and be able to steer my team into delivering the most business value that I can [which in the end is my job].

What I did realize was that I forgot how much I loved my old job.  It is fun to solve problems and provide instant value to the business.  You get a much better understanding of the impact of decisions when you understand the little picture as much as the big picture.  You feel good and it may help ignite that spark back in you that you had when you did that job and wanted to get into management.

A word of caution…

If you have stopped learning for a while it can be very hard to get back into things.   A manager’s lifestyle can sometimes be going more shallow into ideas and trying to make quicker decisions which can make slowing down and learning harder.   That ability to tune everything out and focus is like a muscle that might need to strengthened first.  I would check out Cal Newport’s book Deep Work if you want to learn more about this.

One last contributing factor

Phil Libin of Evernote discussed in his podcast on Tim Ferriss show that most companies need to throw away and rebuiild the way that they work every time that they scale x3 – 1-3-10-30-100,300, etc.  I think that managers need to identify the time when they have a disconnect with the way that they used to do things.  They may need to go deep and spend time getting their hands dirty again.  Consider it a management sabbatical or a side job.  After going through mine, I feel that I am making better decisions based on it.

An alternate view
One might argue that if you have teams that are empowered and self organizing that you can be hands off and let them make all of the decisions and recommendations from the bottom up.   I love teams that work like this and completely agree that they are the most effective teams.  In my experience the best business decisions are made when both the teams and management collaborate on the problem solving and decisions and have a shared pool of knowledge (not always shared agreement on facts) to work through.   Believe it or not, there is a reason for management, and the more on the same page the teams and management are  — the better for the business (which is what it is ALL about).

 

 

Guest on Developer on Fire

devonfire

Last spring I had the pleasure of being on David Rael’s very popular developer podcast – Developer on Fire.  First of all, I had a blast.   The format of Dave’s show allows the opportunity to talk about your career and what you as an individual bring to our field and focus on why we do what we do.  Most of all, it focuses on delivering value in our careers and in our personal lives.

If you have not heard it yet – I would recommend checking it out.

Here are some of my favorite episodes:

http://developeronfire.com/episode-167-anthony-shaw-innovation-and-inspiration

http://developeronfire.com/episode-032-ted-neward-presence-and-values

http://developeronfire.com/episode-083-scott-hanselman-learn-balance

http://developeronfire.com/episode-106-gary-stonerock-finding-the-underlying-problem

http://developeronfire.com/episode-023-mark-heath-blending-software-with-passion

http://developeronfire.com/episode-049-dave-thomas-programmer-first

and a link to my episode

http://developeronfire.com/episode-135-jamie-romanowski-leading-leaders

 

 

 

Sitcom Theory of Communication at the office

 

As a leader, how many times in your career have you come across a situation where teams are not aligned on a common goal? You know that you spoke to all or most of the members of the team about the purpose and approach for a project – but now it is going in a direction that is not focused on the business problem that you are trying to solve. You may have a case of what I refer to as the sitcom theory of communication at the office.

Taking a step back…

joyce-dewitt-400384_640

Three’s Company was a very funny sitcom from the 80’s used a very formulaic process for all of their episodes. The sitcom was about three people one guy and two gals that shared the same apartment and the manager of the building, Mr Roper, thought that they were swingers and would keep trying to find out what was going on. Most episodes consisted of the same plot – Mr. Roper would hear part of a conversation often hearing something out of context. He would make the completely wrong assumption and then the story would move off in very funny hijinks only to be cleared up in the end in hilarious form.

There is a version of this that happens at work – but the results are often much less humorous. I call this the Sitcom Theory of Communication at Work.

I work in software and the hardest thing about most software programs is people and communication (and people).  A lot of the problems stem from the following mistakes:

  • Jumping to a solution very quickly and not understanding the full context of a situation  [jumping to conclusions]
  • Someone listening to someone else talk in order to respond and not to understand
  • Being stubborn and not thinking through a whole problem in the mindset of what is best for the business – often just thinking about their own proposed solution
  • Multitasking, not respecting the viewpoint of the person that is talking, or just bad communication skills
  • Having a different opinion or objective and not really focusing on what is best for the business
  • Not fully respecting another person in the conversation and missing the signal from the noise

There are numerous blog posts, talks, and books that all state that understanding the business problem and the complete context of the user experience BEFORE committing to a solution is KEY for major success — but we often forget about this when we are in the moment. In the book “Nudge: Improving Decisions about Health, Wealth, and Happiness”, authors Thaler and Sunslein define this as our Automatic Thinking process which is “rapid and is or feels instinctive, and it does not involve what we usually associate with the word thinking”. It feels good to begin work on a solution, doesn’t it?

With that said, it is hard enough to realize when you do this, it is even harder to identify when someone else goes down this path – especially when it is a team that works with you. The purpose of this article is to point out how to how to identify when it does occur, how to correct them, and tricks to limit the chance of these situations occurring in the first place.

How to identify a sitcom situation

Listen and think. It is really that easy. As a leader you need to not be the one talking all the time and take your time to listen to other points of view and think about why they are thinking the way that they are. Where this gets complex is how often to engage these teams. As a leader you should be hands off with most of your initiatives or you will just get in the way and slow them down. However you should still remain in touch with your teams. Some leaders prefer weekly stats meetings, other prefer the managing by walking around method. I kind of like a little of both depending on the situation and the criticality of the project.

It is important to read people in these types of situations. These situations often lead to friction on the team which leads to stress which leads to unfocused work which is waste. Streamlining these situations is key to delivering the most business value you can [which is your job].

The best way that I have found at identifying these situations is from asking two different roles about challenges in the project and listening to what (and how) they say it and especially WHAT THEY DON’T SAY. Every team member should be able to articulate WHY this functionality is so important based on the domain. This is how I do it with my current teams. One of the main responsibilities of my job is being the delivery manager for multiple agile teams. Between technical challenges, requirements, product owner feedback, personalities, personal and team level agendas, and pressure around timelines there are plenty of chances for these types of situations to arise.

This is my hands-off approach. I join the teams when they are discussing their designs. I sit in these meetings and try to not talk at all – I just listen to what they are saying and how they are collaborating. I usually only jump in when some kind of business clarification is needed or they want my input on a crucial decision. From these meetings I get a very good understanding about how the teams and the work is flowing. Each of the decisions and tradeoffs should be touched on in these meetings and they should tie back to the business value of the work. I get to understand how well they understand the business value by the way they discuss it in the meeting. The other side of the story I get is from the project and product management status meetings. In these meetings the project and product managers bring up their thoughts and concerns about the current projects and how the teams are responding. Listening to both perspectives allows me to see where there is friction or misalignment across the teams. At that point I will usually clarify the item on the spot or I will give one side some questions to go and discuss with the other side to get more understanding.

This is my most hands-on approach. I join the team for each and every meeting and clarify everything. I make people verbally describe everything at each step. We all sit in the same room together and use a white board to manually update items as we go through them.

I hardly ever use the extreme hands on approach – only if there are valid business reasons like a production outage or a critical (non-rollback) situation. This kind of management process kills team morale.

My typical approach is to join the planning meeting per iteration, design (the most fun of all the activities), and any status meetings. I recommend that you have 2-3 teams and any more than 4 is too much.

Tricks:

  • Never let a team get too far
  • Look for the questions that the team is not asking
  • Look for a leap in a discussion to the solution – make sure it is not too soon – no matter how much pressure is on the team. Doing the wrong thing is always slower in the long run
  • Make sure the right people are involved (the whole team including stakeholders / SMEs is ideal) – watch out for decisions by cliques [never healthy]
  • Adjusting along the way is good and healthy but the team should clearly be able to identify what they have as an open decision and what the criteria is for making that future decision
  • Write shit down – seriously just do it. The reasons you are making decisions are the best things to document in any project. They should include the business justification, the tradeoffs, and the thought process that led to the decision

Oh no, this totally happened on one of my projects

  • Don’t let these misunderstandings go, no matter how painful the conversation is going to be
  • Fill in the gaps – you are responsible for conveying in a matter of fact tone the misunderstandings across the team and getting everyone in alignment
  • Pull together everyone – build teams and tear walls down

What can you do to be proactive?

  • Always bring up what the business problem we are trying to solve is
  • Always be clear and vocal with WHY we made certain decisions [Write them down]
  • Always have your door open to discuss any topic – not matter how taboo
  • Be diligent
  • Make decisions with a common framework aligned to the business strategy AND always make them for what would be best for the business

And always, having fun solving problems