Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.
Positive energy
You need to keep the circle positive
As a hands-on architect, you're probably the person that everybody in the development team looks up to the most. The main reason for this? Many of the team are probably aspiring software architects themselves. Although this is a flattering situation to be in, there are some major downsides if you take your eye off the ball.
Whether you've recognised it or not, you're in a very influential position and the eyes of the development team are likely to be watching your every move. For this reason alone, you have the power to change the whole dynamic of the team, whether you like it or not. If you're motivated, the development team are likely to be motivated. If you're enthusiastic about the work, the development team are likely to be enthusiastic about the work. If you're optimistic that everything will pan out, the development team will be too.
You can almost think of this as a self-supporting loop of positive energy where your enthusiasm drives the team, and their enthusiasm drives you. This is all fantastic but it's not hard to see the damage that can be caused by a slip-up on your behalf. Any degree of lethargy, apathy or pessimism will rub onto your team quicker than you can say "but we'll be okay" and you'll start spiralling towards a vicious circle of negativity.
We don't often talk about the softer side of being a software architect but often the soft skills are more important than being technically strong. A happy team is a team that delivers. As the software architect, it's your responsibility to keep that circle positive and your role in the overall team dynamics shouldn't be underplayed.
Re: Positive energy
Positivity isn't quite the same as optimism and I think it's worth stressing the difference. Optimism implies seeing the good side (ok, the positive side) of things whereas positivity carries an implication of assertiveness. There's definitely nothing wrong with seeing the positive side but one key architectural responsibility is derisking, and that requires an eye for the bleaker side of things. But then I guess if you've mitigated appropriately then you can be genuinely optimistic!
As an architect you're also engaged with various audiences such as the dev team, the users, the project board and the ops team. One style probably won't fit all and some may just prefer candour.
Re: Positive energy
I don't think that positivity and candour are mutually exclusive. If things are going badly, you can say "We are all doomed", "we'll all been looking for new jobs soon!" etc or you can say "This is tough, we need to work through this" or "I am worried about X, we need to make sure we have a plan to prevent a problem".
All of the statements are candid, but the latter are positive not negative. I used to work for a guy who was always professing doom, but he did it with such positive energy it actually enhanced moral! I guess it was because his tone belied his apparent gloom.
Tom
Re: Positive energy
I couldn't agree more. We've recently been working through an exercise of renewing the description of an "Architect" and defining the competencies that someone in this role should possess. This exercise has led us to strongly emphasize the "soft" skills such as leadership and communication. In fact, I think the Microsoft Certified Architect (MCA) program does an outstanding job of decomposing the competencies into seven skill groups:
1. Leadership
2. Communication
3. Organization Dynamics
4. Strategy
5. Process and Tactics
6. Technology Breadth
7. Technology Depth
Among these skill groups, you'll notice only two out of seven have any technical component at all.
Not long ago, after giving a talk on the role of the Architect, I was approach enthusiastically by a manager who explained that her organization had incorrectly applied the role, and she couldn't wait to get back and begin making a shift. In this case, the employer had unwittingly allowed the Architects to become the "ones that know everything" or "the Subject Matter Experts", and they had failed to develop leadership and communication skills.
In my experience, it's these soft skills and the ability to apply them in a highly technical context that truly define the capability of the Architect and maximize the value.
Brian
http://blog.softwarearchitecture.com
