I realized after this last blog post I had more I wanted to say, mostly to clarify some points.

In that last post, I discussed the differing management approaches of more strict project and task tracking (Type A), as opposed to a laissez faire approach where staff is communicated strategic goals and then given free reign to develop and implement solutions (Type B).  Both ideas have pros and cons, and one important point I made is that selecting the balance depends greatly upon the organization and the team.

If you are in a large, bureaucratic organization, and the team is still facing culture challenges and perhaps struggling, then taking the initiative to be involved on the specific taskings and workflow might be a better approach (if you have the character to handle it well, that is, encourage and coach people and not be a micro-manager).  Alternatively, a very strong team in a permissive organizational environment may thrive and excel in a more MBWA (management by walking around approach), where the team members are experienced and knowledgeable, can work well together, and have a strong understanding of the vision and goal.

Where my thoughts led on this, however, applies to either case.  Let’ say you, as a technical lead, are taking the first approach.  Who actually defines the tasks?  Who comes up with the higher-level Epic tasks, and decomposes them into smaller and smaller chunks, and gets those tasks assigned?  This requires some fairly strong technical skillset, both knowledge in the problem domain but also skills in requirements/systems engineering.  But what if you are taking the second approach?  When you are having a deskside conversation with a developer, or discussing designs and approaches, are you expected to be involved and knowledgeable?  Or do you basically just sit in your office and play games while the team works away?  Of course not; you need to be able to provide input and make sure the technical approach and execution is aligning with the strategic goals and vision.

The takeaway is, in any case the lead needs to have some technical knowledge relevant to the situation.  I don’t mean they need to be an expert, either in the technology being used nor in the actual system being designed or implemented.  But the lead needs to be knowledgeable enough to listen to a high-level discussion of the technical details and not be completely lost.

Now this cuts both ways.  First of all, the developer needs to be able to explain things in a simple enough manner that it can be understood by another person of reasonable or equivalent technical skill.  If someone cannot explain something simply, then they don’t understand it that well themselves.  This might be offensive to some people, but generally I find it to be true.

“If you can’t explain it simply, you don’t understand it well enough.” — Albert Einstein

The flip side is, of course, the manager needs to be able to understand what is being explained.  Again, this assertion might be unpopular or even offensive, but I believe that in order to lead a team you have to be knowledgeable in that team’s domain.  Would you think that the leader of a team of race car mechanics could lead if they didn’t know anything about race cars or mechanics?  Don’t get me wrong, I’m not saying this situation doesn’t exist; on the contrary it exists all over the place.  But this idea that a generic business background can prepare you to properly manage a highly technical team is not only wrong, its dangerous.

The true challenge for the manager is being able to be knowledgeable in the technical detail and yet still have enough humility and leadership qualities to encourage and coach people without being condescending, a micro-manager, or letting ego get in the way.  The frequently-seen alternative to a generic manager is promoting a technical team member to manager, and that new manager does not have any leadership qualities, nor takes the time and effort to study, learn, and grow as a leader.  And now you have a situation where the manager overrides the developers’ technical decisions, frequently considers their solutions to be superior to the team’s and thus forces them in, and in general micromanages the team.

So how can you do this?  How can you provide technical oversight without micro-managing?  Personally, I take the Socratic approach.  I make people explain to me what they are doing, in a way that show that they understand their own ideas and designs and solutions.  I use my personal technical skillset to ask questions. probing into the design to ensure that they truly understand their own work, and also to make sure they’ve thought about all the angles.  Most importantly, I stress to people that I’m not questioning their technical skill, I just want to make sure that I personally thoroughly understand the approach.  And I make sure to praise them for a job well done.

If you, as a leader, can embrace all these qualities and take the time to do personal development to build these skills (both leadership skills and technical knowledge) then this will reap great rewards with the team you are leading.