Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Tag Archives: Value

Talking Non-Tech

IT architects often pride themselves on their technical knowledge. Tasked with designing a system from end-to-end and taking responsibility for that design, they need to ensure the details are right. They also need to demonstrate technical prowess to earn respect from technical developers and engineers.

However, as discussed in previous posts, architects also have to talk to non-technical people to gather requirements, understand the business context and assure them that a design will meet their needs. For people used to delving into the technical details, this context and mindset switch can be challenging.

First, understand the value the architect’s proposed changes bring to stakeholders and organization. Understand not just what each stakeholder has asked for but how that stakeholder’s performance is measured and describe the impact of proposals in those terms.

Taking an operations manager as an example, describe how this will reduce incident frequency or severity. For a salesperson, relate this to imminent or key deals. For any management, ensure they understand how the changes relate to KPIs, long-term objectives or organizational policies.

A quick way to do this is to describe a technical change then ask “So what?”. Relate it to each stakeholder in a sentence or two then invite questions. Take note of anything asked and ensure it is covered next time.

Sometimes non-technical people suggest technical solutions. While most IT architect’s immediate reaction is to dismiss these as ill-informed, a better response is to understand the reasons behind it. Did this suggestion work last time? Is the relative cost for the asker small? Is a suggested tool the only one the asker is familiar with?

A better response from an architect is to evaluate suggestions and provide quicker, cheaper and/or better alternatives. Sometimes, however, it is important to buy-in by using elements of their suggestion, even if it is technically suboptimal.

Unless the organization has prescribed formulas or a culture of doing so, avoid trying to express impacts in financial terms. Chances are architects will get it wrong. Be careful using jargon or discipline-specific terms, too. Technical people cringe when non-technical people misuse technical terms. It happens the other way around, too.

Describe the context of a technical change in both technical and business terms. What existing systems or processes are impacted? What can we do now that we could not before? What can we do better or cheaper? What additional work is required or what work is saved?

No system exists in a vacuum and there are always flow-on effects for every change. If an architect cannot articulate these, chances are the requirements were not fully understood or analysis was lacking.

Describe the impact constraints have on the design or team implementing the design. Do not just list them (“We only have three engineers”). Say how this impacts the solution (“Option A is a better solution but, because we have a small team and a tight deadline, we are going for option B”).

Everyone in the organization has to deal with constraints. Sharing them helps build trust across teams. It also invites stakeholders, who sometimes have more experience, to suggest better ways of dealing with them.

Produce and use good quality communication. Consider using multiple views of a solution for different audiences, emphasizing different aspects. Use aesthetically pleasing diagrams with consistent use of symbols and colour. Do not be afraid of detail – it gives the audience the impression you have a deep understanding of the problem and solution – but ensure the communication is broad, covering the value and context as outlined above, instead of deep. Provide overviews or summaries to help time challenged people understand important points.

Communication should also cover solutions that were not selected or implemented. The implemented design or change will be evident. Understanding what alternatives were considered is often forgotten, particularly for trade-offs or others’ suggestions.

Beyond communicating better with non-technical people, these practices help architects understand the impact of technical changes on the organization beyond the immediate. It raises questions about larger impacts and exposes gaps in the architects understanding. It also helps build relationships.

Ultimately, being able to communicate effectively with non-technical people makes the architect a better architect. IT architects are more than just designers. They are collaborators and evangelists and they cannot do this if they can only talk and think like engineers. Architects are often the face of the team, department or company and the impression the architect needs to make a good impression.

Moreover, an architect’s technical solution exists within the organization’s social and political environments, not just technical. The architect is responsible for their work’s political and organizational success, too.

Image Credit: http://www.thebluediamondgallery.com/wooden-tile/v/value.html under Creative Commons 3 License (CC BY-SA 3.0)

Toppling alpha developers

Building blocks

Many people are attracted to software development because they love technology and development. Viewing it more as a hobby they are paid to undertake, they gladly spend time outside work solving that nagging problem, mucking around with the newest framework, contributing to open source software or exploring opinions on Twitter.

There is a subset of software developers that takes this to extremes. It is possible for someone that does not “eat and breathe” code to still take pride in their work, to still be a craftsperson or to want to learn more and improve. However, alpha developers make software development part of their identity and their desire for respect drives them to competitiveness.

From a hiring organization’s perspective, these alpha software developers are wonderful. Their pride dictates they produce high-quality work, often at the expense of their personal time. Training costs are minimal because they already know or quickly assimilate new tools, frameworks or techniques. Their competitiveness can force everyone to produce and learn more. They are happy to leave business decisions to others and focus solely on the technical. While these all have downsides, successful companies have learned to temper them.

However, alpha software developers create barriers. Alpha developers’ pride compels them to take technical leadership roles and demand others live up to their standards. Their knowledge of new tools and techniques and almost overriding urge to try them out can shut out discussions of other solutions. For those less enamoured with software development, alpha developers can be intimidating.

When asked to train others, alpha developers feel that owning one’s technical development and career path is a rite of passage. It is not that they look down on people who know less, more that alpha developers made the effort to train themselves so why should others be given special treatment?

Meanwhile, alpha developers feel their performance is judged on their own output and helping others interferes with that. Indeed, alpha developers will work around other developers if they feel they have to “save the project” by rewriting others’ code or taking on others’ work out of impatience.

This problem is exacerbated when alpha developers move into leadership positions. When hiring new developers, they perceive alpha developers as superior and hire them over others. When evaluating others, they reward alpha qualities.

Focusing on alpha software developers creates a monoculture, focused inward on technical prowess and knowledge. Decisions need broad, representative viewpoints. While few companies will have ample members of the target audience on staff, few companies’ target audiences are solely alpha software developers.

This relegates non-alpha developers to permanent “junior” roles. This blocks their career progression even though they may be well suited to roles that software development feeds into like business analysis, user experience, consulting, quality assurance, IT administration or solution architecture.

This also risks the competitiveness between alpha developers boiling over to conflict or burnout. Like a sports teams, having too many ego-driven superstars creates problems. Teams work best with people in a variety of roles and software development is a team sport.

Solving a problem like this, particularly something a deeply ingrained in software development culture, is not simple.

The first reaction is to move away from using lines of code or other similarly easily measured metrics as the primary determinants of productivity to ones that indicate the success of the project. This encourages a team-centric view of productivity, not individual-centric.

However, the problem is deeper than that. Like using the term “craftsperson” instead of “craftsman” at the start of this post, we need specific language to drive specific thinking. It is hard to conceive of ways to drive value without terms to describe them.

For example, a “developer experience” engineer could focus on improving the efficiency of existing developers and hastening the onboarding of new developers. While documentation is part of this role, its focus is more on fixing inconsistent APIs, gathering useful diagnostics, ensuring error messages are complete and descriptive, replacing or fixing buggy libraries and improving internal tool reliability.

This role focuses on the productivity of other developers and understanding how they work instead of raw lines of code. This person should not get too involved in the internals of the software. Otherwise, he or she may start to overlook or forgive bad practices.

Another potential role is a “business process integration” engineer. Working on a lower level than a user experience engineer, they look at product customization, integrations and automation/orchestration opportunities. For internal systems, this could be about integrating the system into a Business Process Management (BPM) or workflow solution. For external systems, this is similar to a customer-facing solution architect but works with the code directly to help users customize or leverage the product.

This role requires an understanding of the broader business context, how software is used by the organization and what the organization views as important. It is a good conduit into business analysis or enterprise architecture.

This all boils down to a search for value. While focusing on software is what others would expect software developers to do, focusing it to the exclusion of some of the software development community is a poor strategy. We need to change how we view and measure our software developers and change who we see as aspirational.

Image from https://commons.wikimedia.org/wiki/File:Autism.jpg. Used under creative commons license.

%d bloggers like this: