Architects on software teams often have sizeable responsibilities for the project’s success but little direct authority over the developers working on the project. In many cases, particularly in the consulting world, architects are resources shared across several projects. Often they’re not responsible for the daily successful execution of the project – that falls to developer leads and project managers. Instead, an architect is usually brought in during the project’s initial proposal and design phase, kept on as the project spins up, and transitions into the role of an infrequent visitor as the project moves to completion.
Despite this perceived “visitor” status architects must provide subtle, but strong leadership in a number of ways. Architects must be the primary leader on enforcing deliverable business value to the client. Architects must also lead by ensuring clients have reasonable expectations on the project’s scope and feature set. Finally, architects can provide critical, trend-setting leadership for the entire team by ensuring the project starts out with a strong commitment to respect, plus open, honest communication throughout the team.
(I’m a firm believer that a “team” is the entire group of people working on the project: devs, leads, architects, project managers, and most importantly the client.)
Deliverable business value is something that too often is forgotten by the technical folks building a system. Historical data shows a large majority of features in any given system are never used. Architects need to show leadership on the team by pushing back on features which the client hasn’t specifically asked for. If there’s not a good business driver for the team’s idea, then the client likely doesn’t need it. Adding dynamic, real-time workflow visualizations of items in a claims processing queue might be cool, but is that week of effort actually going to help your client do their job?
This concept isn’t just for neat feature ideas conceived by the team, it’s also pertinent to the underlying technology you’re using for the project. This is especially true for consulting companies which must always balance keeping their team members’ skills up to date with understanding that many of their clients are several releases behind the latest technology. You can’t build a solution on tools, languages, or platforms that the client will be unable to maintain once you’ve delivered and left the site.
By all means, bring good ideas from the team up to the client, but drive the team to ask “Why?” before going through that exercise. Ensure that ideas from the team will help the client meet their goals, then let the client decide if those ideas make sense. Remember, it’s the client’s money and they get to dictate priorities!
The flipside of the above point is holding your client to the same standard: ensure your client’s changes are driven by concrete business value needs. Obviously, you need to work at your client’s direction and support their priorities, but help them get the most out of their budget dollars by in-depth conversations around features they’re looking to have you implement. Clients may not understand the impact on your overall system’s architecture, so it’s your job to help them understand the ramifications of complexity, increased maintenance costs, and potential changes to underlying infrastructure such as servers, load balancers, pipelines, etc. Walking through something like the Five Whys [1] can often help.
Holding the line against gold-plating by the technical staff, or feature creep by clients, ensures that clients are getting the most value for their precious budget. Moreover, being brutal about Lean Software principles [2] also ensures the system you’re building avoids unnecessary complexity. Simpler systems are easier to build, scale, and maintain. The entire team wins when architects ensure the initial scope of the project is adamantly limited in both business and technical aspects.
With the technical and scope issues out of the way, architects can often help set the tone for the entire project’s culture by getting the team off to a good start with the team’s culture. Architects are often more senior members of any team, and they should put their experience and hopefully calm demeanor to work.
Foster respect in the team. If you want a successful, healthy team then the folks on that team have to begin with a foundation of respect. Base that respect on good communication with your teammates. Ivory tower architects who don’t listen to the experience of those around them are, to use a Twitter vernacular, fail whales. As an architect you’re likely a smart lad or lass; however, it’s silly to think you know everything. Solicit feedback from your team as you’re working. Moreover, actually listen to that feedback! Your team will feel valued and you’ll be gaining knowledge you might not have otherwise had.
Share bad news honestly and in person. Bad things happen on every project of any significance. Every project. The magnitude of those problems varies, but what never varies is the need to quickly and forthrightly communicate those problems. Additionally, you need to communicate those issues in person wherever possible, regardless of whether you’re communicating outwardly to your client or inwardly to your team. Was there a misunderstanding of the targeted volume of site users, forcing you to re-do some critical data access pieces in order to ensure scalability? It happens. Fix it and move on. Don’t try to hide these issues, and don’t get someone else to act as your front man. Share the news clearly and concisely, and get it done early. Your honesty and forthrightness about the issues will pay off in the long run, both with your team and with your client.
Because of their perceived “visitor” status, architects often aren’t thought of as leaders in teams. That’s a mistake because the team misses out on an architect’s unique experience and viewpoint. A project’s chances of success can be greatly increased when an architect uses subtle, positive, and respectful leadership practices. The entire team wins.
[1] A process of asking “Why?” five times to dive down to root causes or needs. See http://en.wikipedia.org/wiki/5_Whys.
[2] See Implementing Lean Software Development by Mary and Tom Poppendieck
Jim Holmes:
Father. Husband. Geek. Veteran. Over 20 years IT experience. Co-author of “Windows Developer Power Tools.” Coffee Roaster. MVP for C#. Chief Cat Herder of the CodeMash Conference. Liked 5th grade so much he did it twice. One-time setter, middle blocker, and weakside hitter. Blogger ( http://FrazzledDad.com). Program Manager for Telligent Systems, makers of Community Server and other neat products. Big fan of naps.
Subscribe (RSS)
