Roy van de Water, Clayton Lengel-Zigich, Jade Meskill and David Foster discuss:

• What’s a senior developer?
• Software developer job bands
• Compensation based on performance

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the “Agile Weekly Podcast”, I’m Clayton Lengel‑Zigich.

Jade Meskill:  I’m Jade Meskill.

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

Clayton:  Joining us today is David Foster. Say, “Hi, David.”

David Foster:  Hi.

Jade:  No, say, “Hi David.”

Roy:  Hi, David.

Clayton:  All right, good job.

[laughter]

Clayton:  As usual, it’s guest choice for the topic. We wanted to talk a little bit about what it means to be a senior developer, and maybe even more specifically from a manager’s point of view. How do you define those things, and what’s the whole process?

David, this is something that you’ve been working with for a little bit now. Can you explain where you are, and what struggles you’ve had so far?

David:  There’s three development managers in our organization, and we’ve been working on this for the last several months.

We recently transitioned from an organization that was definitely more hierarchically driven. We wanted to be able to move into more of a management stance where we’re actually empowering the teams, and letting the teams make decisions on their own. Which of course calls into question, what is our role as managers?

We look at it as if the teams’ products are the software that they’re actually building and delivering for the product owners, then our product is actually the teams themselves. What would be our responsibility in helping the teams to be better teams?

We decided that one of the things that we could do was try and set a vision for what we saw as being the kind of characteristics that a senior developer should have on a team. A “Senior” being defined as somebody that would help with the growth of the team, help with the creation of the team, and making sure that the team is running well, as a team. They would be a lead, in that respect.

Clayton:  I think some people would say, “Titles are stupid,” and, “Why do you need a senior developer role?” What do you say to that?

David:  I would probably agree with that, from the perspective of having an organization that is completely run by titles, where you’re just pigeonholing people into some position and role, based on what you’ve hired them for.

We definitely want to have teams where the teams can organize themselves, according to whatever the context is that they find themselves. What is the problem that they are trying to solve?

In order to distill that into what we’re looking for, the criteria we came up with were really more along the lines of the kinds of things that we would expect to see from an Agile team member.

Not so much somebody who’s just a senior developer, as defined by typical enterprise cultures these days, where it’s defined by the kinds of things that they do from a skill perspective, and the kinds of things that they do from the coding perspective. These are really more of the kinds of skills that we would see in an Agile team.

Roy:  What about loyalty? I feel like the title of “Senior” is oftentimes a reward for loyalty. Like, “I’ve been with this company five years. Shouldn’t I get some recognition for that?”

Man 1:  Yeah, that’s basically what we find ourselves with in the company structure, because the company definitely has that, from an HR perspective. They definitely have that, where the actual salary is banded to a specific kind of a title.

There’s a senior‑level band, and that has a salary range that’s associated with it. If you want to actually progress according to the company’s HR department, then you have to be able to fit within these bands. That’s kind of a constraint that we had as a management team.

We want to be able to have a fairly flat hierarchy, where we’re not really telling the teams what to do. We’re not really acting in the traditional role of a manager, the teams can decide for themselves. But we still have to be able to help them along with a career path within this organization that is still hierarchical.

Clayton:  Jade, I was going to ask you. We’ve never really had a big hierarchical situation, or really big on titles at all. Do you think that ever had a negative impact with Integrum?

Jade:  It’s something that we’d discussed a lot when we were first starting the company. We tried really hard to map people into all these different levels. It just got so confusing and so hard that we decided to throw it out the window and say, “Who needs this crap? We’re going to do this totally differently.”

As far as did it cause any problems with the organization? I think it caused problems with individuals who are looking for that recognition. Either they wanted it on their resume or for their ego, or whatever it is, they wanted to be called a “Senior Developer.”

As from the actual organization standpoint, I don’t think it caused us any problems. You guys were there. What do you think?

Roy:  I remember interacting with a few people while I was still in the intern, and that I was at first somewhat treated a little bit as an intern, and then there was somebody else who considered themselves a “Junior Developer.” I don’t think anybody in the organization would have said, “Oh, this title is ‘Junior Developer.'”

I remember that being kind of interesting, because I remember acting not like an intern, and it very quickly stopped. I was no longer treated like an intern. I still had the lack of knowledge. I had the amount of knowledge as an intern, I just acted a little bit more confidently.

I think that was interesting to see, that he was still stuck in the “Junior Developer” role, and couldn’t get himself out of that, to step out. I don’t know, Jay. I think you know who I’m talking about. Did he actually have…

Jade:  Is this the person that became our senior intern?

Roy:  Yes, that’s right.

Jade:  [laughs]

Roy:  Was that a self‑assigned title?

Jade:  Yeah, very much so. I think he mentally assumed the role of intern, instead of imagining himself as coequal with the rest of his team.

Roy:  Because I see that as one of the big problems with titles, is you put yourself in the box. David, we’ve had this interaction with a few different people, where somebody says “This is my title. I shouldn’t be doing this other stuff. Even though I am passionate about it, and I think it should be done, that’s not me, that’s not my title. I shouldn’t be doing that.”

David:  Yes, we were definitely running into that. We know that by actually going this route, which is a complete change from what existed before, that there’s going to definitely be a major friction created by this.

We expect that we’re going to have people that are going to just be completely uncomfortable by this, because when we actually show these criteria that we would expect from one of these developers, they’re not oriented along the ways that they’re used to. “I just want a check list.” It’s not going to be like that.

It’s really going to be “These are the kinds of things we’re looking for out of a senior‑level developer, and we expect you to figure out, and set your own goals, for how you’re actually going to achieve these things that you may be lacking.” That is definitely different.

We don’t really know what that means, in terms of how many people are going to be uncomfortable with that. But just like you said, Roy, we’ve had some people that have already butted up against that.

“We’re empowering you to make decisions, we’re empowering you to find solutions for yourself,” and there are people that are really uncomfortable with stepping out of their box, their prescribed box that they’ve been given. It’s definitely going to create some friction.

David:  I’ve worked in jobs that have a traditional hierarchical organization, and one thing that was nice about having all those hierarchies was that you knew what was expected to go to the next thing.

Sometimes it was very cut and dried, and I think that’s one thing that’s difficult if you have a very flat structure. It’s hard to know what you need to do to improve. Most people I don’t think have the self‑awareness to realize where they’re deficient, or where they maybe could be more valuable, if they were to do certain things.

I think that’s something, at least the stuff that you’ve been talking about so far, that I’ve liked about the way you guys are trying to define what it means to be a senior developer. It’s that those things are very tangible things that I think you could grow towards.

If you looked at one of the requirements and said “I don’t really understand what it means to do X, Y, Z,” I think you and the rest of the management team could say, “Here are some more fine‑grained details about what it means to do those things.” I think that could be very helpful for people who want to actually grow in their career.

Roy:  I think it’s important, though, that there aren’t step‑by‑step instructions. Because if you have step‑by‑step instructions, anybody could follow it. At first that sounds like a good thing, but part of what you’re looking for, as somebody who is in a lead position, or whatever, is a mindset and a self‑awareness that you can’t get.

If you tell somebody, “Just do the grind. Follow these steps. Kill 300 boars in the forest and you’ll be level 12, then we’ll give you your salary increase.” That shows that somebody’s willing to throw themselves against a wall for however long, but that doesn’t necessarily show that they have self‑awareness, and leadership ability, and an understanding of what’s going on.

That insight to be able to figure out how to personally improve themselves towards these values is very important.

Jade:  How is personal improvement tied to compensation?

David:  Difficultly. At a very high level, what we’re looking at is…We don’t really have any junior developers, we really have senior‑level developers and then we have mid‑level and then we have what are called “Principals,” which are above a senior‑level developer.

Roy:  When you’re talking about these titles, you’re talking about people who have these titles, or people who actually fit these roles?

David:  I would say that people that are in those titles, that are in those job bands. I would not say that these are people that are actually necessarily in those roles, as we’re trying to define them now.

A mid‑level would be somebody who’s…In general it’s somebody who’s a really good member of the team. They’re definitely a contributing member of the team, they definitely work well with the team, and they’re learning how to be a more productive member of a team environment.

The senior would be somebody who’s actually able to help the team grow. They’re helping to nurture the team, they’re helping to grow the team, working with the product management, or the product owner, to really help make the team be more productive.

Then they’re able to, perhaps even go and create a new team, start a new team. We take an individual that is actually operating at a senior level and actually say “OK, we’re going to build a new team around you, because you definitely understand those principles.”

A principal would be somebody who would be helping to foster the creation of maybe multiple teams. That’s kind of how we’re looking at that. Compensation would be tied probably more towards those levels of activities.

Jade:  So what happens if you come across someone who’s really great at getting the team to be cohesive, to be effective, but they’re not strong technically?

David:  That is a team problem, and we would expect a team to try and figure that out. How they figure that out we’re not really sure, because we haven’t had a team empowered yet enough to actually address that.

We definitely have that problem with some of the teams, but the teams have to be able to ferret out what that means to them. Do they want to just shelter somebody and keep them going along, or do they want to actually confront the issue and actually make some changes?

Jade:  What if it’s not important that they’re strong technically, the team’s good enough to take care of that? They’re really great at getting people to work together and assemble and do all the things that you need to do?

Roy:  That sounds valuable me. It sounds to me like if the team feels that this person is contributing a ton of value, maybe they don’t have that much technical experience, maybe they should be made aware and know that that’s an area of improvement.

David:  I think the personal performance, and performance reviews and all that stuff, there are people that are maybe exploring, self‑organizing teams, or doing things differently, or having a flatter organizational structure.

It’s the same thing with facilities. You’re trying to do all this new stuff, and then you go to HR and they are operating in a much different capacity. For as much as I think the Agile community tries to shoehorn Agile stuff into HR, maybe it just doesn’t fit.

This example you’re giving, Jade, think that is a totally reasonable thing. Why wouldn’t you be able to set the compensation or to have the person on the team? I think the answer is because they don’t fit into “Software developer level one, tier three” category, so you don’t know how much to pay them.

You are trying to use this antiquated system to figure all this stuff out, and maybe you should just not worry about that, but that’s hard to do. You can’t just tell facilities, “I’m going to kick down the cube walls,” because someone’s going to freak out. That’s not how they operate.

Jade:  I think it’s a big challenge. Especially as we look at compensation, individual compensation has direct repercussions on your behavior on a team. It gets very complicated very quickly, as you start to muddle those things together.

Roy:  It gets really weird too, because sometimes you think you are rewarding a good behavior. You’re rewarding a good outcome, that can lead to some really bad behaviors.

David:  The most radical example of fixing that problem would be where the team has some salary budget, and you basically just tell the team “Here’s you’re budget, and you divide it amongst yourselves.”

Jade:  Yeah, there’s people that do that.

David:  Which is a very scary thing. Even for smaller organizations, that usually doesn’t fly. I think when it comes to payroll and compensation, those things are so stuck in the old way of doing things.

Roy:  Very taboo.

David:  Yeah exactly, it’s taboo. Can you imagine if you took the average kind of corporate Scrum team, even if they were a pretty good self‑organizing team, and you said, “Here’s everyone’s salary, and feel free to move everyone up and down the slider, according to where the team thinks they are.” I can’t even imagine doing that.

Jade:  We’re pretty progressive and pretty crazy, and we have not even touched that issue.

Roy:  Every time we talked about bringing it up, we keep switching over to something else. It’s crazy too, because from a logical perspective it doesn’t even make sense.

The idea, and I don’t know if it’s an American culture thing or a world culture thing, but you are never supposed to talk about how much you make, and you are never supposed to bring that up with other people. You’re not supposed to know how much other people make, and if you do find out, you keep it to…Why is that such a cultural thing?

Jade:  That sounds like another topic. [laughs]

Roy:  Fair enough.

Clayton:  It underscores the fact that some of this stuff gets int territory where we don’t act super‑rationally about things, which makes it even harder.

I think we are about out of time. David, did you have any parting thoughts, or anything you’d like to leave behind? If there’s another person in your position who’s considering doing something, did you have any advice for that person?

David:  The simplest advice I could give is just figure out a way to get yourself out of the mix with the teams. It’s a really hard thing, as a manager, to want to go in and mess with things and to toy with things. The sooner you can get yourself out of that, the better off the teams will be, and being able to perform.

Clayton:  Great, thanks.

Roy:  Thanks.

David:  Thank you.

[music]

Man 1:  Is there something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

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

Man 3:  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.

Man 4:  Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline, it’s free! Call 866‑244‑8656.