Note: For this discussion, I have focused on my own area of expertise, namely SAP software development. However, I believe this discussion can be generalized to cover any individual contributor.
The Dilemma
In my career as an SAP developer, a question that has often come up is:
“Would you be willing to lead this development team?”
This is a question that is always good to hear. However, my focus here is on the question that often follows, right after I’ve said yes to the first one:
“And would you mind also being one of the team members/developers as well? It wouldn’t be much additional work.”
For a long time, my thought process went something like this:
The client has hired me as a technical resource, so that’s the primary benefit I’m bringing to the project, and –
I’m good at what I do technically, and –
I don’t want to lose my technical edge, and –
they did say it wouldn’t be much additional work, and –
I do want the client to see me as adding even more value, so—
yes, I’ll agree to this hybrid leader/developer role.
What Didn’t Work, And Then What Did
In hindsight, I can see now that that decision was not the right one for me. However, I only realized this after suffering through many painful projects in the hybrid leader/developer role. On a recent project, something clicked, and I reached down deep to answer differently this time. My answer was, “No, I think I can do a better job as team lead, without trying to also be a developer.”
The result was that I had my most successful team lead role yet, loved the process and asked to be able to do it again on the next project.
Nature of the Problem
In my experience, someone in a hybrid role as lead programmer/team lead inevitably faces conflicting priorities. That person is responsible for at least two very different categories of tasks: development and administration. The heart of the problem is that development tasks always tend to overwhelm administrative tasks, and thus team leadership suffers. Reasons for this arise from the nature of development tasks, when compared to leadership tasks. Development tasks have the following characteristics:
- They are typically focused on just one person’s work—yours. Not much coordination or discussion is needed; just do it.
- They also offer quick, individual, tangible rewards: See how fast and easily I got that request implemented and tested! Check that off my list!
- They are often within the comfort zone of technical team members, which means there’s no need for that person to stretch to new skill sets to get them done.
- They appear deceptively easy, in the sense that a 1-hour change to code also implies multiple hours of other activities that aren’t usually front-of-mind when the developer is planning what to work on. This can include unit testing, integration testing, defect resolution and bug fixes, discussions with business users, and integration with other technologies or areas of the project.
Trying to manage, coordinate and track the efforts of a development team requires interaction with other parts of the project as well as load balancing across the development resources. This requires time, effort, mental agility and in fast moving projects a basic conflict arises between needing “me-time“ to get my development done and the need to be responsive to overarching project needs. It is a tough balancing and prioritization act and it is very easy to overestimate your capabilities. My revelation was recognizing that trying to be in both roles meant I did neither well.
Going further
What we have looked at today also raises several questions, which I plan to address in future blogs:
- How much was this dilemma mine alone? Can other people straddle the two roles easily?
- Are there criteria available to help decide between staffing dedicated vs. hybrid team leads?
- How do project managers justify their decision, often in the face of budgetary pressures?
- Do these questions apply even beyond technical teams, to the management of teams generally?