Leadership, Communication and Architecture

by Robert Cooper

I have been struggling with this lately, and Jeff Attwood sums it up really well

But some commenters were understandably apprehensive about the idea of having a Senior Drill Instructor Gunnery Sergeant Hartman on their team, enforcing engineering discipline.

You little scumbag! I've got your name! I've got your ass! You will not laugh. You will not cry. You will learn by the numbers. I will teach you.

Cajoling and berating your coworkers into compliance isn't an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn't to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.

Here is the thing. I fully accept this premise. The problem is one of communication. By that I mean, communicating what the engineering goals should be in a concise form, without starting out having everyone on the same page.

Let me elaborate on this a bit with a couple of personal examples. A *long* time ago, I was tech lead on a dev project. Back when XSLT was brand spanking new, we had a project come through a Professional Services company I was with. I immediately realized we needed something like this, and outlined a whole architecture for a multi-skinned/multi-host/user customized app. Most of the people on the tech team had never worked with any of the technologies before, but I wrote a couple of core classes, and gave very explicit interfaces for each of the components, worked with the "web dev/design" group on XSL and gave them sample documents. Over time the project snapped together like lego, and I was very full of myself. I still feel like this was my best experience with a large team effort, because I was able to build language-level interfaces and test cases and tell people "build this." Over time, we could optimize later (as you should) and where appropriate, and the architecture grew into a methodology.

Lately, however, I have had a harder time. When you are building more generic frameworks, rather than for a specific app, you need to communicate a *philosophy* of app construction. The problem here is without a "look at this" example, I have not been able to communicate the ideas behind the structure and lifecycle. When you have a team that has diverse backgrounds and maybe doesn't have the same mental shorthand based on "everyone has built the same apps, read the same blogs, read the same books", selling, if you will, a new design philosophy is really hard.

The core rules Dennis provides are great:
Be humble. Always first presume that you're wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you're certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.
Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.

The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes -- like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet -- won't yield the same effect, and are more easily neutralized.

Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you're just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they'll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn't guarantee that the initiative will fly, and the effort might be for naught, but the team will identify that it's actual motiviation and effort behind it, rather than an attempt at some easy points.

There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that's the most common best-practices subject doesn't mean that it's even remotely the best design philosophies for the group you're joining.

My question is: if you have a vision, and want to try something that is honestly new, how do you communicate that vision to software developers... without software?


2007-08-22 02:16:37

Probably by making them aware of the benefits of learing new things for their career perspective?
b)Giving them live examples what's happening in the world like type of dev work in google etc.


Rob Di Marco
2007-08-22 08:52:37
Some suggestions:

1) Do not try to change everything at once. In the book Peopleware, DeMarco and Lister talk about introducing exactly one new thing (not zero, not two, but one) on every project that you execute. This way you can introduce change and progress without taking on enormous risk.
2) Leverage better communicators than you. In the blog post, Jeff talks about introducing a variety of materials, including Joel on Software, Code Complete, Mythical Man Month. I highly recommend this as a good way to get people understanding what your motivation is and why you think you need to be making changes. If your team understands the motivation and inspiration behind your vision, they will respond much better.

John C. Walker
2007-08-27 07:35:49
Even with great leadership, there seems to be always a few stubborn developers who refuse to change their ways. I've joked about hiring a gunny for years to help solve the problem.

Unfortunately, gunnies are only effective during the remaining malleable years of late youth (between 18 and 25) where discipline can still be taught. After that age, many adults are either unwilling or incapable of changing their ways. I continue to be amazed at the number of software engineers who refuse to learn or adopt anything new once the have left their academic programs. For these individuals, only Divine Grace can help them. Hence, if leadership doesn't work, try prayer. If that doesn't work, replace them.

John C. Walker
Software Architect, Charlotte, NC.

2007-08-29 00:40:07
Tell those gunnies it's the role your have to keep or you will do it again and as a lead you have to check carefully all the time
Shashank Tiwari
2007-08-29 10:31:28
There is a very clear distinction between a good software developer and an ordinary one. It is not only his or her ability to build software now but also the ability to continuously learn both by actively reading and actively trying. Having said that no amount of motivation can create good software developers out of those who inherently lack the attitude I mentioned earlier. However, many a times this attitude and potential is unexplored and dormant. In such cases providing an environment to learn and creating a sense of exploration and excitement helps (look at the way Google uses multiple methodologies to create a sense of excitement and exploration within the company!).