Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Communication

Working Remotely and Successfully

A software architect is a difficult role at the best of times, particularly when working in a different office, time zone or country to the development team, other architects or management. In this case, architects miss the “water cooler” and “hallway” conversations and, unfortunately, “out of sight” is often “out of mind”. Much of what follows applies to non-software architect positions, too.

To be successful, remote architects must first create an environment where they are involved. A regular 1am team meeting on Saturday, for example, is neither sustainable nor fair. The team and its management need to adjust. Share minutes or notes for those that cannot attend meetings, too.

Remote architects must use meeting time effectively. They must know what information they need, who they are going to ask and follow it up afterwards. Regularly ask what team members are doing, such as training, travelling or talking to customers. Make time for small talk and rapport building, too.

Apply this to wider communications, too. Move away from E-mails for distributing documents and move to a common repository, like SharePoint or a Wiki so everyone can see what others are working on in addition to helping with versioning, auditing and knowing where the latest version is, and use an approved instant messaging system. When communicating, use a communication mechanism that targets the widest appropriate audience, such as a Wiki, and send notifications or links via traditional mechanisms, like E-mail.

Video conferencing is not as useful as many would claim. Skype and similar products suffer from the lower bandwidth and higher latency of international Internet connections. Professional telepresence systems like HP Halo are like being in the same room but can be difficult with people in different time zones or those that live or work away from the office.

Ensure the team travels to a central location for face-to-face meetings several times a year, too. If the organization cannot afford to bring important team members together for face-to-face meetings, an organization cannot afford to have remote employees. The critical aspect is not the meetings but the lunches, the drinks in the bar afterwards and relationship building, something video conferencing lacks.

During this “non-work” time, identify common interests with other team members, such as sport or similar aged children, and share them. Add the human element back into the team. As a previous workmate of mine once said, “You need to build a relationship before you can do business“.

Remote architects must recruit allies. Architects should talk regularly with their management, ensuring they understand their wants and needs, including up the management chain. Even the best communicators chronically under communicate with remote peers or subordinates, so remote team members must accept that their immediate manager cannot provide them all the information they require. They should talk to their peers and others outside their team, advertising their contributions and strengths, and create mutually beneficial relationships

Remote architects should do something interesting, professionally or not, and share it. Write up a few paragraphs and E-mail it to the team after attending conferences. Work on an open source project, join a local interest group or tutor a local college class.

Remote architects should make an effort to help others within the organization. For example, if someone wants a document proof read or reviewed, take the time to send intelligent comments through and carbon copy (CC) the rest of the team for visibility. Publicly give credit and thanks to others who help you with internal organizational reward systems, if they exist. Laugh at and remember other people’s jokes. Making people feel included will include the remote architect in the process.

Remote architects should get involved in projects outside their area or team. Many large organizations have discussion groups or committees, such as strategy or  review committees. Participating introduces the architect to new people, exposes his or her ideas to wider audiences and, once again, builds relationships.

Most importantly, remote architects should make an effort not to fall behind. They should do  training or otherwise become known as  experts in a field or a product, drawing them  into discussions about this area or product. Volunteer for new projects, particularly high-profile ones, and work hard to make them successful.

Ultimately, the success of a remote software architect is the architect’s responsibility. not the manager or team. This is the ultimate example of “managing your manager” and, if done right, allows an architect to enjoy a compromise of life style and professional success.

Who Needs a Software Architect?

Small teams of senior people working on a well understood problems with known tools and little integration or dependencies on other applications do not need architects. This covers a significant proportion of line of business applications written today. However, there comes a point where cracks appear. There is no well understood threshold for a team size or a product’s complexity to require a software architect – no two individuals, teams, products or deadlines are the same, so what works well for one may not work for the other. However, there are four indicators or “smells” that a software architect is needed.

First, the product either lacks or does not meet non-functional requirements such as scalability, performance or security. Product Managers (PMs) or other customer advocates rarely articulate such requirements and, when they do, usually articulate them poorly or give them too low a priority. A software architect can balance the customer or business requirements with technical ones and provide the technical foundation to meet the customer requirements.

Second, the product lacks technical vision. Enterprise applications rarely exist in a vacuum. They need to integrate with other applications, often share components and need to lay the foundation to make likely future changes easier. Useful new components, frameworks or libraries may become available that allow the team to focus on business value and not solved problems, especially for older products (i.e. 10 years+). The industry may trend toward different platforms (e.g. mobile) or business models (e.g. cloud). Development teams are often too focused on the current release of the current product to take a step back and few others have the technical knowledge required, unlike a software architect.

Third, the development group has poor interteam communication and collaboration. Effective communication is easy for small teams of three to five people. This is much harder if the group has several hundred members in different continents and time zones. Effective cross team management may be difficult because individual team leads are usually focused on their own teams and the common management point may be a director or even an executive who has bigger problems on his or her mind and lacks the required technical focus. A software architect can divide the work and act as a coordinator between teams.

Communication with development teams outside the group is also critical. A development group often needs someone with broad rather than deep knowledge to evangelize their product(s) or identify integration points or sharable code. Once again, team leaders are usually too focused on their teams,  directors are often too removed from the technical details and individual developers find the higher, longer term views too distant from actual code. A software architect usually has better communication skills, the right breadth of product knowledge and understands its technical vision. Similarly, non-technical but development-related teams like user interface designers, documentation writers or localization require someone with a broad technical knowledge and a customer focus.

Fourth, the group has unclear requirements or problem domains. Relatively few teams boast many subject matter experts or developers that use their software like their customers, particularly in junior teams, remote teams or those with a high turnover. PMs are often focused on dealing with customers or support issues rather than communicating detailed requirements to every developer. They also may not understand what the developers do not know and so provide too little or too detailed information. This process is also ongoing due to turn over and changing market conditions. Lastly, requirements also change as the project progresses, whether due to changing customer requirements, competitive landscape or just learning more about the problem.

These are traditionally areas where business analysts (BA) rather than software architects are used and can be used in tandem with a software architect. However, one exception is where business requirements may have unclear technical ramifications and feasibility, such a compliance with industry standards or regulations. Federal Information Process Standard (FIPS) 140-2 or Common Criteria require changes and documentation at many levels of detail which an architect is better suited to than a BA.

Note that software architects do not solve all problems with development. In particular, they highlight or exacerbate political or organizational problems when they try to bring stakeholders together or reconcile conflicting decisions and requirements. This may be intentional (to drive change) but is not sustainable in the long term.

%d bloggers like this: