Roy van de Water, Clayton Lengel-Zigich, and Drew LeSueur discuss:

• Typical class systems of organizations
• Cowboy Coders
• The real leaders

Transcript

Drew LeSueur:  Hi! Welcome to another episode of the “Agile Weekly Podcast.” I’m Drew LeSueur.

Roy van de Water:  I’m Roy van de Water.

Clayton Lengel‑Zigich:  And I’m Clayton Lengel‑Zigich.

Drew:  Today, we want to talk about Class Systems within Organizations.

Clayton:  Do you mean like Java classes?

Roy:  Yes.

Clayton:  Jars?

Drew:  Jars, class hierarchies, entity inheritance. What have you guys seen? How do class systems within organizations affect…?

Roy:  You mean classer developers, like second class citizens?

Drew:  Yes, like first class citizens and second class citizens, and it’s, “Oh, I’m better than you,” “Oh, they’re way better than me.”

Clayton:  I think the most obvious one is usually the division between developers and QA.

Roy:  Developers and senior developers?

Clayton:  Yes, that’s another good one, too.

Roy:  Developers and architects?

Clayton:  Yes. I guess the hierarchy is usually architect, and then senior developer, and then regular developer, and then maybe junior developer, if they have that, then the QA people.

Roy:  Then manual regression.

Clayton:  Manual regression people. Yes, you are paid to click a mouse and smash on a keyboard thing.

Drew:  Have you seen it where the people who are maybe higher‑up looked down upon the people who are supposedly lower?

Roy:  There you have it. That’s how being higher up works.

Clayton:  Yes. I think that’s just inherent in the definition. When you get promoted to be senior developer, or whatever, can you have that job title? Then that somehow means that you have more authority, or better you have more experience.

Roy:  And a higher paycheck?

Clayton:  Meaning more pay, more benefits.

Roy:  It’s probably even at an expectation that you treat the people that are below you with at least a certain amount of disrespect, in order to make your position more substantial, and in order to fit in with other people that are at the same level as you.

Clayton:  Other part, it depends on the on the manager. I don’t know anyone who would explicitly say that, but I could certainly see there’s management styles that are very hierarchical like that, that would really reinforce that thing. I could see a manager saying to someone like, “Hey, man, you’re a senior developer now. You can’t do XYZ, or whatever.”

Roy:  You can’t be hanging out with those lowly developer types. If they see you talking to those QA people, nobody’s going to take you seriously in this business.

Clayton:  I could see something like that.

Drew:  I really like the word “empower.” People should be empowered to do great things. If you have this system setup, it seems like it forwards that empowering of the people. What are some ways that you can go against that, this class system?

Clayton:  One thing that I think that you’re saying is that if you look at some people that are talking about agile stuff these days, they don’t like the word empower. They get like, maybe this is like second level thinking kind of stuff, super nuanced. But I think the gist of it is if you say that you’re going to empower people, it’s like you’re acknowledging that you work in a hierarchical structure, and so then people have to be empowered to do something.

I think that one way you can kind of get away from some of the hierarchical stuff is like self‑organized teams that are cross functional, like some of the scrambling prescribe.

Roy:  I think it’s easiest to come back from the higher up you are. If you are, let’s say, a senior level developer or an architect, and you have your own corner office, and perhaps your secretary and whatever it is that you got, because you got your fancy‑pants promotion. If you want to make a difference on the team, and you value the idea of everybody being equals, and being able to contribute equally into a project, then the best thing you can do is to give that up, and say, “OK, I’m just like you guys. I’m going to give these things up. I’m going to make my office available as a breakout room. My secretary if I have one can go work for somebody else.” You showed that you really mean it with your own actions.

Drew:  But you still make twice as much as they do.

Roy:  Come on.

[laughter]

Clayton:  Like Robin Hood and [inaudible 04:03] .

Roy:  I don’t know, I think that’s a really good question. In an ideal world, it should.

Clayton:  I don’t think there’s anything wrong with people in organizations, necessarily, being compensated differently. There’s a whole bunch of factors that go into that. But one thing that I’ve seen a lot is people will get a senior developer title, because they worked at the same place for a really long time.

Roy:  That’s what you need to be a senior. You only have to turn 65, and then you get a discount.

Clayton:  I think it’s funny, though, because I can see that someone might say, “Hey, I’ve worked at three different companies in my career, and three totally different industries, and three different sized companies, and so I have a bunch of experience using a whole bunch of different things, in different teams, and all this other stuff.” Let’s say that it was over a fifteen‑year period.

But if I worked for the same company for 15 years, doing the same job, every single day, am I really a senior developer, because I’ve just been there for a long time? That seems kind of silly. But that’s how most people are considered senior developers.

Roy:  In that context, senior implies loyalty more than it implies experience.

Clayton:  Yeah, I would think that’s probably a fair way to put that.

Roy:  There’s still something to be said about rewarding that type of loyalty.

Clayton:  Sure, but I think the one thing that always gets missed, though, that reinforces the class system stuff is you might have someone on the team that excels as a developer, and then they get this job as a senior developer.

Then they get treated differently in the sense of, “You used to have to work on this crappy part of the system that no one really likes, and you used to just have to do the boring work. But now that you’re a senior developer, and you know all this stuff we’re going to let you go prototype this new thing that’s in a new cool technology, and you get to do new cool stuff.”

I rarely see where the expectation of a senior developer is that they make the people that are below them better. I think everyone thinks “I am a total rock star,” “JAVA ninja,” “I’m so bad‑ass,” but then they can’t make the people that are the junior developers better.

Roy:  Just to clarify, I think I speak for all of us in that the idea of having different classes of developers on the team is a bad idea. Having everybody act as an entire team where there are certain people on the team who may have some weaknesses, and some people that have certain strengths, and the team values to bring out the strengths in everybody, and try to help each other better our weaknesses, and that that’s an idea situation.

Clayton:  I think if you think about it from a tribal aspect ‑‑ if I’m a member of the tribe, and I’m the one who’s trying new ways, new fishing techniques. I’m the one who gives you some of my food because your crops died, and I do all of those things, I’m going to gain your influence and you’re going to view me as a leader versus the chief just coming down and saying he’s the senior tribesman. That’s a totally different thing.

Teams can be the same way. You have these cross‑functional teams, where everyone can do everything and there is no real distinction in the job title perspective. Some people are going to rise to the top, because they do certain things that the team buys into, and people on the team will follow them.

Roy:  One of the huge problems I have with this type of class system, where there are multiple levels is that oftentimes it’s self‑sustaining in that the people that are at the bottom class are treated like crap, and given shitty assignments. They are given crappy, hard work and that type of thing. It’s almost like it’s really hard to overcome the handicaps forced down on you by the upper class developers.

“We’re going have riots with the 99 percent…”

[laughter]

Roy:  “…complaining about the one percent…”

[crosstalk]

Clayton:  I think that’s totally fair. It’s a culture thing. If the organizational culture is that there are different levels of people, and if it just so happens ‑‑ which is probably the majority of the time ‑‑ that the different levels of people are picked improperly or poorly.

Everything that happens to the people on the bottom of the totem pole reinforces the fact that they’re on the bottom of the totem pole, and every day you remind them they’re on the bottom of the totem pole. That’s where they’re going to be. You’re never giving them a pathway or any means to move up. They’re just going to leave.

Roy:  Even if the expectation is if you work here long enough, that’s how you move up, I think even that is a bad idea. Even the idea of a meritocracy where if you do really well you move up is kind of a bad idea, because it should be the entire team that’s moving themselves up.

If it’s a meritocracy where my success is causing me to go up, that incentivizes me to sabotage everyone else on my level to make myself look better.

Clayton:  If you don’t buy into team‑based work, and you don’t buy into the value you get out of team‑based work, it becomes pretty obvious. People are very smart about cheating the system, knowing who they have to influence or be influenced by…

Roy:  Or sleep with.

Clayton:  …In extreme cases, I suppose, to move up in the organization. I still think it all goes back to a culture thing. I think if you take the traditional software development organization, where you’ve got developers who are treated in some degree badly, but they are treated better than QA people, because they just lob their code over the wall and the QA people have to test it.

Roy:  Is it that shit flows downhill syndrome a little bit too? I got crapped on by the senior developer so I’m going to take it out on the QA people?

Clayton:  I think there’s something like that, too. I always remember that talk that Uncle Bob Martin gives about testing. He talks about how it’s basically immoral to have people do manual testing. The idea that someone would have a big binder and they go to some page in the application and they look at the binder and it says, “Step one ‑‑ enter x, y, z, colon, bracket, space and then click this button, then click this button. You do fourteen steps and then hit enter. Verify that the screen says this.”

How does any organization think that’s OK?

Roy:  It’s totally demeaning to the people that work in those positions, too, especially if they are more qualified.

Clayton:  The people never give a pathway to become better.

Roy:  I’ve actually heard of organizations where they’re like, “Oh, we can’t have those people do that. They’re just testers. There’s no way they could ever be developers.”

Clayton:  Exactly. I think there’s a bunch of testers who probably think, “I’m not interested in being a programmer. I don’t want to learn engineering stuff. That’s not what I’m interested in.” There’s still a bunch of things that, if you take more of a test automation approach, there’s a lot of things that you could have a testing background or a testing mindset, and still contribute just as equally to the overall value of what’s being built.

Roy:  Those types of people could be invaluable in a planning meeting, and would be a very good compliment to a regular developer in a pairing environment. You would start to see the lines blur between the two, because I think, as with anything, the QA people that don’t like to learn coding is probably because it’s uncomfortable and new to them.

Clayton:  That’s true. To give an example I was giving a presentation at this QA conference, this local QA conference recently, and I was describing some scenario. One of the people in the room had talked about how they could have avoided this big problem that they had if they had done better planning.

I asked them if they foresaw that before the event. They basically said, “Yeah, I saw that this was going to be a problem.” I asked them, “Why didn’t you say something?”

The idea that the tester ‑‑ or the QA person ‑‑ would interject in planning and contradict the developer, or tell them that they were wrong was so unheard of that she looked at me like I was from outer space. “That’s just crazy. How could you even suggest that?”

Roy:  “You can’t do that. Those are developers. I want to be one of those one day.”

Clayton:  You have that scenario in your organization. Look at all the stuff you’re going to miss out on. All the resentment you create and all these other horrible things.

Drew:  I’m thinking, sometimes you get these cowboy coders. It’s easy if you’re a good developer to have the mentality, “The work I do is so special. Nobody can do it. I am actually super gifted, super talented that I’ve been able to figure all this stuff out, and these people can’t learn it, or if they try they’ll screw it up.”

I think that’s a very dangerous attitude to have. It helps reinforce the classes that you could have. The truth is anybody can do this stuff. Anybody who wants to, has a desire, they can do that. If the team adopts that mentality, I like that movie Ratatouille, “Anyone can cook.” It’s the same idea.

Anyone can be a developer or can be whatever the job is. That mentality should be reinforced, so that we’re in the attitude of helping each other out. Get better as opposed to isolating ourselves, saying we’re the best.

Roy:  In that vein of, “Anybody can do it,” I totally agree in that anybody can be a developer as long as our heart is in it. I think we have worked with people where we see the potential, but they aren’t capable of reaching because they don’t want to work for it. Likewise, we have seen people that don’t know anything but were able to jump in it no problem, because they have the desire to learn. Which is why I think it is so important to hire for that quality over any technical experience.

Clayton:  I think that gets into learning organizations. Rather than being, “Oh, we’re going to strive to be agile,” or whatever that means, strive to be a learning organization where you have that. You don’t have the fixed mindset of some people are good at this, and some people can never be good at this.

Roy:  You brought the concept of cowboy coders are like rock stars. I agree that’s a dangerous thing. There’s times when organizations revere that type of behavior. That’s highly encouraged. You even see that amongst the major organizations like Microsoft and Google, where they’re rock stars. They love the idea of having rock star developers.

Clayton:  I think that’s a tortoise and a hare kind of thing. A lot of times when the rock star people or the cowboy coders go off, especially when they do the hero coding thing at night, they will deliver some super sexy looking that’s so awesome. In that moment it seems like the best thing ever.

No one takes the time to take a step back, and look at all the things that happened coming up to that. No one ever keeps that in their mind going forward, to think about what is the impact of this thing over time.

Three months later, when there’s some bug that comes in, and the team can’t fix it because the super hero coder has pulled another all‑nighter and hasn’t come in, is not going to come in until 11:30, and there’s no one there to fix it. No one ever connects those two dots and says, “Hey, gee. We wouldn’t have this problem if the team had worked on it.” Maybe the team wouldn’t have been so sexy, but at least we wouldn’t be in this bind. Everyone just gets mad like, “You stupid non‑rock stars. Why can’t you fix this thing?”

Roy:  They’re like, “Look at this rock star. He was working until 3:00 in the morning. That’s why he’s not here until 11:00. Why aren’t you guys working until 3:00 in the morning?”

Clayton:  Very management 1.5 or 1.0.

Roy:  1.23.

Clayton:  We were talking about Seinfeld earlier, it’s like George Costanza gets lock out of his car and his boss thinks he’s there before everyone, and he doesn’t leave until after everyone. If you can just trick your crappy development manager into thinking that you really work super hard then…

Roy:  Working hard is related to how many hours you put in.

Clayton:  Working hard outside the team makes you great. I think you can play the hierarchy system. You can gain that system.

Drew:  Thanks for joining us. To join in on the conversation please visit facebook.com/agileweekly. Thank you.

Clayton:  Thanks.

Roy:  Bye bye.

[music]

Clayton:  If there’s something you’d like to hear in a future episode head over to integrumtech.com/podcasts, where you can suggest a topic or a guest.

Looking for an easy way to stay up to date with the latest new, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile content delivered weekly for free.

The agile weekly podcast is brought to you by, Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes check out integrumtech.com or subscribe on iTunes.

Need help with your agile transition? Have a question and need phone a friend? Try trying the agile hotline. It’s free. Call 866‑244‑8656.