(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Monday, March 06, 2006
I heard you twice the first time
Dear programmer:
Most people have at least one manager. They may not have eight managers, but they have at least one. The way the software business is usually structured, most programmers have two managers.
The first manager is often called a team leader. Programmers report directly to the team leader and work with her on a daily basis. Team leaders direct the work of programmers, mentor them, and evaluate their contribution.
Team leaders do not have true 'hire/fire' authority. They also usually don't have final say over things like deadlines and requirements (although this may not be the most effective way to do things, that's how it usually works). In other industries, team leaders often have titles like 'supervisor,' reflecting the fact that they direct the work but have little tangible authority.
Programmers also usually have a true manager, often the team leader's direct manager. This manager has some real authority, usually including the authority to hire, fire, set pay or bonus, and negotiate what can be done by when.
Most programmers have no trouble with this setup. They work well with their team leader, have a reasonable (but not awestruck) respect for their team leader's manager, and in the fullness of time their contributions are recognized in the form of a promotion to team leader or something more technical like 'architect' (whatever that means).
However... From time to time a programmer chafes. He smarts at the setup. He agitates.
In my experience, there are several reasons for this. Many programmers don't respect their team leader's technical competence. Some programmers combine an adversarial personality with a short term horizon, and they have trouble reporting to someone who can't impose immediate consequences or rewards. Some feel unfairly treated because they are not the anointed team leader and feel the need to express this feeling at every opportunity.
Obviously, the programmer, the team leader, and the team as a whole suffers when one of the members of the team begins to express their frustration with the situation. I'd like to share the manager's perspective. What do you think is running through my mind when the feces begin to flow uphill and land in my in box?
The first thing is, obviously the programmer is sending me a message that he feels the setup is wrong. He ought to be the team leader, or we shouldn't have a team leader, or maybe we should have a team and a team leader but he's an exception and ought to report to me, or we should have a separate technical structure and he should report to the Exalted Grand Visionary Poobah of Architecture Astronautics, or some other scheme.
Well, my door is open and I want to listen, and it's ok to tell me that. But do me a favour, okay? Tell me directly and tell me once.
Quite often people walk around with this dysfunctional idea that there's a black and white, right and wrong for everything. When things aren't exactly so, they say things "ought to" be another way. By strange coincidence, the way things "ought to be" happens to be something that favours them. Go figure.
Anyways, I have found that this "ought to" mentality invariably walks in tandem with a belief that everyone should know how things ought to be. This means, in practice, that the "ought to" believer shouldn't have to explain how things ought to be, the rest of us should just get it.
Please, please, please don't let this pathology take over your career. If you have an issue, the very best thing to do is pretend that I'm a smart guy, that I get it, that I understand and support you, and that perhaps I've been a little busy with a ton of other things that need my attention. So just walk up to me and tell me flat out what you want and why you want it.
Don't drop hints. Don't undermine the team leader. I may not act like I get why you shouldn't have a team leader, but I totally get that something's wrong when you constantly come to me for decisions and information that you should be getting from the team leader. Sure, I'm pissed off at the team leader for not keeping you happy.
And if that's the reaction you wanted, congratulations. But don't think that somehow you're smelling like a rose. After all, everyone else seems to be getting along ok. Am I supposed to believe that you are the sole voice of reason in the building?
I also get that something's wrong when you undermine the team leader by somehow forgetting to do or being to busy to do a zillion things she asks you to do, like the administrivia of project management. But you know I don't get? I don't get the reports and statistics and numbers I need to do my job, which is convincing the people that write the cheques to keep the money flowing.
You know, I'm somewhat aware of the team leader's strengths and weaknesses. And thanks for double underlining the weaknesses in red pencil. And maybe she won't have my job one day, or my boss' job. Maybe I ought to find someone else to lead your team.
But you know what? I may be busy. I may have other plans for her and for you. I may have other priorities. That doesn't mean I will or won't act on your initiative. But it does mean that dropping hint after hint after hint very quickly goes from irritating to full blown obstruction to success.
Right now, I need software. Are your actions helping us ship higher quality software, with less risk, in less time? So...
Do yourself a favour. Come to see me. Talk to me. Make sure I understand by speaking plainly. And then listen to what I have to say. Be sure you understand. And then stop dropping hints. One way or the other, let's ship software.
Yours very truly,
Reginald Braithwaite
post scriptum
I've run into this several times in my career. From my experience, once it reaches the point of sabotaging the man in the middle, both parties become very tarnished, very quickly.
I'll share one story where I was the hapless man in the middle. I was managing the development activities for one company, where I had several team leaders reporting to me. The company founder also had an R&D team cooking up some revolutionary software.
This team had been whiling away the years on this project, and to all appearances they had an unlimited budget and schedule. The project required a very deep domain knowledge, and the team tended to hire people with high domain knowledge and little or even no experience writing software, much less developing products.
The founder was exceptionally interested in this project and loved to brainstorm with the team. One day I got the news: he wanted me to manage this team, to teach them how to ship software. He saw their brains and my experience as a match made in heaven. The team's leader was told to stop reporting to the founder and start reporting to me.
Well, managing software development isn't that hard, is it? I asked the team leader for a list of what he thought the team could accomplish, by when. I simultaneously asked the company's business development folks for a list of what we needed to have in order to close deals. I proposed that we put the two lists together and create a development schedule.
Apparently this was not to the R&D team leader's liking. He questioned whether someone lacking a doctoral degree in his field could understand the software, much less participate in its creation.
He flat out refused to participate in any management exercise I cared to propose, letting me know that the software would be ready when his team shipped it, and that it would contain whatever features his team deemed necessary to include, and that the team was not going to commit to those features in advance, as research was still underway.
And all the while, he continued to deal directly with the company founder, who remained involved as a 'product manager' while we pretended that I was the actual manager.
Needless to say, that didn't last very long. The company founder realized that the team leader was forcing his hand and reluctantly took action.
Dear programmer:
Most people have at least one manager. They may not have eight managers, but they have at least one. The way the software business is usually structured, most programmers have two managers.
The first manager is often called a team leader. Programmers report directly to the team leader and work with her on a daily basis. Team leaders direct the work of programmers, mentor them, and evaluate their contribution.
Team leaders do not have true 'hire/fire' authority. They also usually don't have final say over things like deadlines and requirements (although this may not be the most effective way to do things, that's how it usually works). In other industries, team leaders often have titles like 'supervisor,' reflecting the fact that they direct the work but have little tangible authority.
Programmers also usually have a true manager, often the team leader's direct manager. This manager has some real authority, usually including the authority to hire, fire, set pay or bonus, and negotiate what can be done by when.
Most programmers have no trouble with this setup. They work well with their team leader, have a reasonable (but not awestruck) respect for their team leader's manager, and in the fullness of time their contributions are recognized in the form of a promotion to team leader or something more technical like 'architect' (whatever that means).
However... From time to time a programmer chafes. He smarts at the setup. He agitates.
In my experience, there are several reasons for this. Many programmers don't respect their team leader's technical competence. Some programmers combine an adversarial personality with a short term horizon, and they have trouble reporting to someone who can't impose immediate consequences or rewards. Some feel unfairly treated because they are not the anointed team leader and feel the need to express this feeling at every opportunity.
Obviously, the programmer, the team leader, and the team as a whole suffers when one of the members of the team begins to express their frustration with the situation. I'd like to share the manager's perspective. What do you think is running through my mind when the feces begin to flow uphill and land in my in box?
The first thing is, obviously the programmer is sending me a message that he feels the setup is wrong. He ought to be the team leader, or we shouldn't have a team leader, or maybe we should have a team and a team leader but he's an exception and ought to report to me, or we should have a separate technical structure and he should report to the Exalted Grand Visionary Poobah of Architecture Astronautics, or some other scheme.
Well, my door is open and I want to listen, and it's ok to tell me that. But do me a favour, okay? Tell me directly and tell me once.
Quite often people walk around with this dysfunctional idea that there's a black and white, right and wrong for everything. When things aren't exactly so, they say things "ought to" be another way. By strange coincidence, the way things "ought to be" happens to be something that favours them. Go figure.
Anyways, I have found that this "ought to" mentality invariably walks in tandem with a belief that everyone should know how things ought to be. This means, in practice, that the "ought to" believer shouldn't have to explain how things ought to be, the rest of us should just get it.
Please, please, please don't let this pathology take over your career. If you have an issue, the very best thing to do is pretend that I'm a smart guy, that I get it, that I understand and support you, and that perhaps I've been a little busy with a ton of other things that need my attention. So just walk up to me and tell me flat out what you want and why you want it.
Don't drop hints. Don't undermine the team leader. I may not act like I get why you shouldn't have a team leader, but I totally get that something's wrong when you constantly come to me for decisions and information that you should be getting from the team leader. Sure, I'm pissed off at the team leader for not keeping you happy.
And if that's the reaction you wanted, congratulations. But don't think that somehow you're smelling like a rose. After all, everyone else seems to be getting along ok. Am I supposed to believe that you are the sole voice of reason in the building?
I also get that something's wrong when you undermine the team leader by somehow forgetting to do or being to busy to do a zillion things she asks you to do, like the administrivia of project management. But you know I don't get? I don't get the reports and statistics and numbers I need to do my job, which is convincing the people that write the cheques to keep the money flowing.
You know, I'm somewhat aware of the team leader's strengths and weaknesses. And thanks for double underlining the weaknesses in red pencil. And maybe she won't have my job one day, or my boss' job. Maybe I ought to find someone else to lead your team.
But you know what? I may be busy. I may have other plans for her and for you. I may have other priorities. That doesn't mean I will or won't act on your initiative. But it does mean that dropping hint after hint after hint very quickly goes from irritating to full blown obstruction to success.
Right now, I need software. Are your actions helping us ship higher quality software, with less risk, in less time? So...
Do yourself a favour. Come to see me. Talk to me. Make sure I understand by speaking plainly. And then listen to what I have to say. Be sure you understand. And then stop dropping hints. One way or the other, let's ship software.
Yours very truly,
Reginald Braithwaite
post scriptum
I've run into this several times in my career. From my experience, once it reaches the point of sabotaging the man in the middle, both parties become very tarnished, very quickly.
I'll share one story where I was the hapless man in the middle. I was managing the development activities for one company, where I had several team leaders reporting to me. The company founder also had an R&D team cooking up some revolutionary software.
This team had been whiling away the years on this project, and to all appearances they had an unlimited budget and schedule. The project required a very deep domain knowledge, and the team tended to hire people with high domain knowledge and little or even no experience writing software, much less developing products.
The founder was exceptionally interested in this project and loved to brainstorm with the team. One day I got the news: he wanted me to manage this team, to teach them how to ship software. He saw their brains and my experience as a match made in heaven. The team's leader was told to stop reporting to the founder and start reporting to me.
Well, managing software development isn't that hard, is it? I asked the team leader for a list of what he thought the team could accomplish, by when. I simultaneously asked the company's business development folks for a list of what we needed to have in order to close deals. I proposed that we put the two lists together and create a development schedule.
Apparently this was not to the R&D team leader's liking. He questioned whether someone lacking a doctoral degree in his field could understand the software, much less participate in its creation.
He flat out refused to participate in any management exercise I cared to propose, letting me know that the software would be ready when his team shipped it, and that it would contain whatever features his team deemed necessary to include, and that the team was not going to commit to those features in advance, as research was still underway.
And all the while, he continued to deal directly with the company founder, who remained involved as a 'product manager' while we pretended that I was the actual manager.
Needless to say, that didn't last very long. The company founder realized that the team leader was forcing his hand and reluctantly took action.
Labels: jobs
