One of the interesting discussions I had when I came on board at my current job was with the XP Coach. Part of bringing on XP at the company was that he convinced them to do away with the front-line technical managers. Everyone became a developer.
It’s an interesting study because there are two primary teams (of about 30 devs each). One of the teams embraced this (or embraces it now) while the other seems to fight it. And in that, it seems like the ones who embraced it – who traded management for self-managing teams, who traded assigned leaders for those who showed their strength for it in the group – are doing much better. In fact, they are coming off a 600 unit story that they completed the week they said at the onset being only 4% over budget. Not bad. 😉
I find the idea of doing away with my job fairly appealing. I love the idea and practice of self organizing teams. My personal goal both in consulting and as a development manager has been to bring the team up to a level where I was no longer needed.
I do have fears however that some stuff gets left behind by making everyone a developer. Most organizations just have a lot of administrative stuff that someone has to take care of to keep everything rolling along. And someone has to focus on things beyond the project at hand. In a team of developers who does one-on-ones, fills out the purchase orders for a new build box, or makes sure time sheets get signed off and approved.
The admin duties of a line manager can get absorbed in part by the team. Someone can take the task to run the purchase order through the procurement division and make sure it arrives. Tracking down time sheets can fall to the ScrumMaster. Reviews and feedback can come from other team members and mentoring relationships can be established while pairing.
And Cory’s point here is that your trading your assigned leaders “for those who showed their strength for it in the group.” Thus leaders are elected by the group and not chosen. I have a healthy ego, but if the group wanted to elect someone more qualified, I’d be pretty happy to have someone to use as a mentor.
At one startup in the past I experienced something like this process. The startup was opening a new office in Las Vegas of all places and I was brought in as the first web developer along with a senior Java programmer and one Microsoft programmer. I was never officially granted any management title, but I simply stepped up and took the reins. As I performed on projects and helped stabilize the web developers we were hiring, they just started referring to me as the lead/manager. As a nice bonus they started raising my salary without even telling me. I remember looking at my paycheck and noticing it had jumped three separate times in a single year. This was of course when you could barely type out some HTML and recruiters would throw crazy salaries at you.
Eliminating front-line technical managers can probably work, but within a corporate environment it’s going to be a tough sell. I know at my present company it would raise more than a few eyebrows if we attempted it, but given enough time and organizational change we can get there. But, darn as James Shore asks:
Is burnout inevitable for anyone attempting organizational change?
My manager mentioned a common difficulty to me at our last one-on-one meeting:
“You don’t want to make role of a manager appear too frustrating or you can’t find anybody willing to take it. And since senior developers can often make as much or more than their managers you have the problem that no one wants the job.”
He spent a good portion of his career at EDS so I often get good insights from his prior experiences.
This might explain why too often we see the case where a technical star takes on a management position in order to advance their career or sometimes for more money. They end up doing a poor job primarily because the managing part of the job never really interested them and they can easily fall back into coding and architecting and let the management part suffer.
I’m not sure how you make the concept of technical management appealing and draw more good candidates into the pool. I’ve known quite a few good friends who’ve stepped into a management role because they were asked or possibly for the money and found their lives a miserable mess. Going back to senior developer lowered their stress and made them effective again. They often point out they’d never want to do what I do now.
Leading a team and making them more successful is a special sort of reward, but it’s very different than being able to solve a particularly difficult coding problem in software. It’s really less about individual achievement and more about the team, much like a sports coach. At the end of the day your teams done great things, but if you’ve done your job well not of that code that is delivered is yours.
I suppose another fear of many developers is that if they commit to doing technical management, many of their coding skills will wither away. If the last time you did much coding was back in the days of client server you’re vulnerable to a downturn in a way none of your developers are. I avoid much of this dilemma myself by doing development in my spare time as a hobby, but that isn’t be an option for everyone.
I’ll continue to grapple with this, as you have to do some succession planning as a manager.
- Introduce Agile ideas
- Setup standup meetings
- Bring architects into the fold
- Start informal code reviews
- Add version control
- Add unit testing
- Add build automation
I can vouch for most of this advice, because before Practices of an Agile Developer existed this is pretty much how I started introducing practices on my team two years ago.
I inherited a large project in which all 10 of my developers were working at the time. The project was a classic big design up front train wreck kind of project and most of the developers were burned and demoralized.
I came into the organization determined to finally implement something like Scrum. At my previous professional services firm, I had to work within accepted fixed bid contracts with conservative customers and very little leeway. This environment was a chance to really implement a better way through Agile (OK, I can be a bit idealistic).
I setup a standup meeting with all the developers a few weeks after I started. I had to get ahold of where the project was on a daily basis and it forced the developers to share information on the different modules they were working on. A bit of grumbling intially, but they came to see the value in it after a little while and we had a much better idea where we stood. I was excited I had snuck in a Scrum practice, but I didn’t go around calling it that yet because I was still fairly new.
I didn’t have architects on the project, but I did have only 2 of 10 developers writing the back-end code where 80% of the work was. After some prodding I got them to understand that we were going to have to mentor up more developers if we ever hoped to get the project done. By the end of the project everyone was able to work on the back-end code.
Next suggestion would be informal code reviews. We talked about this, sort of buddy type reviews, but we really never implemented them. After two years we’re just now implementing code reviews, and I can see why we should have done it so much sooner.
Luckily we had version control, unit testing, and an automated build in place. There were big issues with out unit tests though. They were largely integration tests and they were brittle. One of the developers had Cruisecontrol up and running so we had that covered, but since the integration tests were often failing we’d have broken builds for weeks at time.
These were some of the hardest areas to really implement, with unit testing being the most difficult. Due to some architectural decisions in using a enterprise level rules engine writing unit tests was next to impossible. At least at the time I felt that way, had I been around for the beginning of the project, I probably would have avoided the enterprise rules engine in favor of a simpler solution that was testable. It’s turned out that implementing true TDD and code reviews have taken longer than I hoped, more like 2 years.
As a sidenote the large project I inherited was killed off by the customer after we delivered to the final specification. Adopting Agile practices is no guarantee you can save any project.
Some days the plans come together. I’ve been pushing hard to implement TDD, code reviews, and continuous integration for at least a year now. Today I helped one of my developers setup Clover to exclude the one package of generated code that didn’t have or need many tests. This is a pretty small code base, that just performs about 30 business rules and returns the results via a web service. A quick run of the tests and:
The remaining 2% were a few exceptions that weren’t thrown and captured in the tests. The caveat is because of time pressure and figuring out how Websphere handles web services the developer wrote the tests after sending off the code to QA. Still it’s definitely a great sign of progress.
I’ve never been one for model, tool, or drag-and-drop based development. Oracle development, at least as presented to us and as illustrated in the hands-on-lab (where we actually coded up EJBs and Web Services) is all three of those to the extreme. I call it ‘Right-click Coding,’ because you’re always right clicking on things to configure different wizards and properties instead of writing the code.
Unfortunately Right-Click coding does make great demos, though things like Rails are making in-roads there with command line driven demos. I despise these demos since they’re typically shown by sales engineers who never have to maintain these quick demo solutions. There’s a lot of hand waving about how you have this fully implemented domain model that allows you to just hook together all these loosely coupled services even though you’d actually have to write all those nice services in the real world.
The worst part is that they’ve invited a few business folks, who now thing all the coding is the easy part. Luckily a lot of sales engineers push inane ideas to the hilt and say the magic words, “Oh, with tool X you can just have your business analysts draw out the process.” I do a bit of cheering at this point, because those same business analysts have heard this line before. They’ve tried to use these right-click modeling tools before and they just don’t behave like Excel or Visio. Usability appears to be a very low concern for these tools which often assume you’re a developer who’s spent years in various difficult IDEs. And that’s the point business analysts get completely, “Heh, this stuff is for programmers.”
And then then there’s the other down side of relying on a tool to just generate everything:
Of course, I’m not sure how well things will go when you start having to debug and track down problems. I’m not sure there was a right-click option for ‘Fix all broken things.’
My favorite question to ask the vendor at this point is a pretty simple one,
So how do I test this?
Oh, well you can load test it for performance with something like Mercury’s LoadRunner product.
No, how do I unit test the code?
Well, your QA department can will fully test the code with a set of test cases.
But, how would I write a unit test for this?
Hmm, well the web service we just created has a client code and a simple HTML test page that you can use to test the web service.
OK, but that’s a manual integration test that tests the whole service at once, how would I just write an automated unit test.
Well, let me get back to you on that I know there’s a feature we have to cover that I just haven’t used it.