Developing and improving software or IT services is challenging. With change the only constant and competition fierce, organizations often live and die by their ability to adapt.
Unfortunately, most organizations are not structured to adapt quickly. Many fool themselves with superficial agile practices without building any real understanding. Some hire external consultants whose benefit ends with their consulting engagement. Others undergo discrete transformations, unaware that adaptation is continuous.
I find it helpful to think of software or IT services requiring three primary foci.
The first is automation. Usually fulfilled by software developers, this is what most people think of with software or IT services.
The second is knowing the customer. For example, an IT service targeting health may need to understand how doctors or clinicians work. A network management service requires understanding routers, networking and network security.
Multi-sided markets may require understanding multiple customer types. Uber, for example, requires understanding both passengers and drivers.
The third is providing the service. This focus includes onboarding/offboarding, billing, service desk/support, security and scalability/performance. Multiple roles within an organization often handle these.
The challenge with most organizations, and a significant reason they have difficulty adapting, is they hire specialists for each focus. Software developers, for example, are usually hired solely for their ability to write software.
Unfortunately, understanding one focus can only take you so far. For example, if you only understand the customer, you risk creating an uneconomical or impractical service. If you only understand automation, you risk automating things of little value. If you do not understand delivering a service, you will struggle to provide one efficiently and economically.
There are exceptions. Product Management is often familiar with the customer (second focus) and providing a service (third). They understand the economics and finances. However, they often distance themselves from automation to prevent a bias toward what their existing services can easily provide.
Management also absorbs a little of all three foci. However, their understanding is often shallow. Their attention is usually broader than just product improvement.
The solution is to identify and then incentivize specific staff to generalize across all three foci. They need to learn enough of each to (1) understand the impacts of a decision or change in one focus on the other foci and (2) identify when opportunities in one can provide a nett benefit.
By comparison, separate individuals struggle with this, even those who communicate well. We often think we know more about others’ roles and needs than we actually do. There is a “critical mass” of understanding that these generalists need to achieve.
The concept of hiring generalists or “T-shaped” skills is not new. However, this usually applies within one of the foci. For example, software developer generalists are often “full stack” developers, not ones familiar with non-technical areas.
Finding generalists is difficult. Each business is different and has different needs. While many universities offer combined IT and business degrees, they usually produce IT management candidates. While some universities provide mixed degrees, they often neglect the third focus on effective service delivery.
Similarly, many want to specialize and master their chosen craft. It is a better understood and measured career trajectory.
Importantly, these generalists do not replace specialists. Organizations need sufficient specialists to deliver each focus.
However, the best generalist candidates demonstrate interest or passion across all three areas. Submerge them in each focus, challenge them to translate the challenges and benefits of each and then task them with identifying bottlenecks and potential improvements.
One of the first hurdles they usually encounter is management structures. Organizations are usually built around similar skills, not business output. Organizations usually incentivize teams or departments around cost minimization and throughput, not customer value.
However, with executive support, creating and supporting these generalists will break down barriers and help the organization adapt quickly. Without doing so, organizations will stagnate, often too siloed or distracted by short-term problems.
Charles Darwin was right. Natural selection applies to organizations, too. Those that cannot adapt will be replaced by those that can.
Fueled by the advent of social media, opinions now surround us. Seemingly everyone has them and broadcasts them to the broader world. Untethered from context and expertise, such expression usually leads to validation or ridicule instead of healthy debate. Uncritical opinion sharing can drive tribalism, becoming a foundation of identity as adherents one-up each other with more extreme views.
Professional environments face different challenges with opinions. They are smaller and simpler than worldwide social media and rarely emphasize extremes. However, organizations frequently need to make quick decisions on incomplete or uncertain information. For example, to solicit feedback on a proposal or design.
Opinion gathering can be a helpful tool. Requesting opinions can reveal similar initiatives, valuable metrics and new perspectives. It can also extract contradictory, irrelevant, ill-informed or otherwise not valuable input from the wrong people.
Effective opinion gathering requires preparation then focusing on relevant motivation, experience and facts.
Preparation involves asking the questions you should ask before seeking feedback.
Creating and sharing a succinct document or presentation clarifies the problem, sets its scope and answers common questions. It gets better quality opinions sooner.
Defining the audience ensures the audience is complete and not excessive. It also helps set an end to opinion gathering.
Preparation should be proportional. Not every issue needs documentation and a plan. However, taking a few moments to think is almost always beneficial.
Unfortunately, opinions are sometimes unsolicited or not on topical problems. On topic opinions may be outside the scope or imply impractical changes.
While perfect alignment is rare, the most useful and actionable opinions come from those with benign motivations. Opinions from those with different views or incentives need careful consideration.
For example, salespeople are often commission-motivated. They are likely to favour whatever gets them their next sale. However, they also have frequent close contact with customers, giving unique insights.
In IT, non-technical stakeholders are not accountable for warranty (e.g. speed, security, reliability, maintainability), only for utility (e.g. correctness, completeness). They will often neglect or downplay quality issues. However, they may also represent a broader or long term view than just the immediate technical details.
Stakeholders may have conflicting motivations. Managers have to weigh short-term targets against long-term goals. The decision-fatigued or overworked may suggest the easiest path over the best one.
Even well-intentioned opinions can be problematic. For example, aspiring experts may give unsolicited ideas, trying to appear knowledgeable in the guise of assistance. Some merely repeat others’ opinions they found compelling. Confidence and credibility are different things.
Potentially the most dangerous opinions are those with an unknown motivation. Actual dishonesty is rare in professional settings. However, self-promotion and self-preservation evolve from helpful to essential as you climb the management ladder.
The opinion giver’s experience is also significant. It prevents foreseeable mistakes and imparts acquired wisdom.
However, there is relevant and less relevant experience. “The last time we did this” may have been under different market conditions, finances or staff.
Experience does not imply expertise. Seemingly capable people may have knowledge gaps, poor tools or incomplete awareness.
People may not adapt or improve, repeating poor practices or old mistakes. Sometimes years of experience are just repeating the same experience.
Like motivation and experience, saying facts are pertinent is an understatement. These include measurements, dates, budgets, quotes and anything that most agree is hard to dispute. They are more effective at forming or changing opinions in professional settings than on social media.
Often the source’s trustworthiness is the most crucial factor in disputes. However, referencing “The Lean Startup” by Eric Ries, anything auditable, actionable, and accessible should be convincing.
Facts should be complete and, like experience, relevant. Statistics or definitions can ignore inconvenient data. Averages imply an often inaccurate or oversimplified modal distribution.
Fact-producing experiments are generally more effective than expertise. They consider local conditions and capabilities. Repeatable experiments are even better because they can become goals to achieve or metrics to track success or failure.
Changing your organization or peers to give better opinions is challenging, particularly given the self-entitlement enabling social media that surrounds us.
However, you can change the way you give and receive opinions. While everyone is entitled to opinions, not all opinions are equal. Thinking critically about those given and received helps professionally and in the broader world.
Elon Musk sparked controversy with this recent attempt to take over Twitter. Many support him, citing Twitter’s relatively poor revenue and Musk’s success in turning seemingly unprofitable ventures, like electric vehicles and space exploration, into successes.
However, his recent Twitter poll caught my interest, where 82% of over one million responses voted that Twitter should open source its algorithm.
Musk explained further during interviews at the TED 2022 conference. The “Twitter algorithm” refers to how tweets are selected then ranked for different people. While some human intervention occurs, social networks like Twitter replace a human editorial team’s accountable moderation with automation. Humans cannot practicality and economically manage and rank the estimated 500 million tweets sent per day.
By “open source”, Musk means “the code should be on Github so people can look through it”. Hosting software code on github.com is common practice for software products. Third parties can examine the code to ensure it does what it claims to. Some open sourced products also allow contributions from others, leveraging the community’s expertise to collectively build better products.
Musk says “having a public platform that is maximally trusted and broadly inclusive is extremely important to the future of civilization.” People frequently demonize social networks for heavy-handed or lax “censorship”, depending on their side in a debate. Pundits claim social networks limit “free speech”, conveniently forgetting “free speech” means no government intervention. Pundits cite examples of the algorithm prioritizing or deprioritizing tweets, authors or topics. They also cite account suspensions and cancellations, sometimes manual and sometimes automated.
Musk assumes that explaining this algorithm will increase trust in Twitter. He called Twitter “a public platform”, implying not just public access but collective ownership and responsibility. If people understand how tweets are included and prioritized, the focus can move from social networks to the conversations they host.
Unfortunately, understanding and trust are two different things. Well understood and transparent processes, like democracies’ elections or justice systems, are not universally trusted. No matter the intentions or execution of a system, some people will accuse it of bias. These accusations may be made in ignorant but good faith, observe real but rare failures or be malicious and subversive.
Twitter’s algorithm is not designed to give equal exposure to conflicting perspectives. It is designed primarily to maximize engagement and, therefore, revenue. It is not designed to be “fair”. Social networks are multibillion dollar companies that can profit from the increased exposure controversy brings. Politicians alienate few and resonate with many when they point the finger of blame at Twitter.
Designing an algorithm for fairness is practically impossible. You can test for statistical bias in a numeric sample set but not across the near entirety of human expression. Like the philosophers opposing the activation of Deep Thought in Douglas Adams’ Hitch Hiker’s Guide the Galaxy, debating connotation, implication and meaning across linguistic, moral, political and all other grounds is an almost endless task.
Assuming transparency can assure trust and fairness is possible, open sourcing the Twitter algorithm assumes the algorithm is readable and understandable. The algorithm likely relies on complex, doctorate-level logic and mathematics. The algorithm likely includes machine learning, which uses no defined algorithm. The algorithm likely depends on custom databases and communication mechanisms, which may also have to be open sourced and explained.
This complexity means few will be able to understand and evaluate the algorithm. Those that can may be accused of bias just like the algorithm. Some may have motivations beyond judging fairness. For example, someone may exploit a weakness in the algorithm to unfairly amplify or suppress a tweet, individual or perspective.
Musk’s plan assumes Twitter has a single algorithm and that algorithm takes a list of tweets and ranks them. It is likely a combination of different algorithms, instead. Some work when tweets are displayed. Some run earlier for efficiency when tweets are posted, liked or viewed. Different languages, countries or markets may have their own algorithms. To paraphrase, J.R.R. Tolkein, there may not be one algorithm to rule them all.
Having multiple algorithms means each must be verified, usually independently. It multiplies the already large effort and problems of ensuring fairness.
Musk’s plan also assumes the algorithm changes infrequently. Once verified, it is trusted and Twitter can move on. However, experts continue to improve algorithms, making them more efficient or engaging. Hardware improves, providing more computation and storage. Legal and political landscapes shift. Significant events like elections, pandemics and wars force tweaks and corrections.
Not only do we need to have a group of trusted experts evaluating multiple complex algorithms, they need to do so repeatedly.
Ignoring potentially reduced revenue from algorithm changes, open sourcing Twitter’s algorithm also threatens Twitter’s competitive advantage. Anyone could take that algorithm and implement their own social network. Twitter has an established brand and user base in the West, but its market share is far from insurmountable.
There are other aspects to open sourcing. For example, if Twitter accepts third party code contributions, it must review and incorporate them. This could leverage a broader pool of contributors than Twitter’s employees but Twitter probably does not need the help. Silicon Valley tech companies attract good talent easily. Some contributions could contain subtle but intentional security flaws or weaknesses.
If the goal is to have a choice of algorithms, is this choice welcome or does it place more cognitive load on people just wanting a dopamine hit or information? TikTok succeeded by giving users zero choice, just a constant stream of engaging videos.
Evaluating an algorithm’s effectiveness is more than just understanding the code. It requires access to large volumes of test data, preferably actual historical tweets. Only Twitter has access to such data. Ignoring the difficulty of disseminating such a huge data set, releasing it all would violate privacy laws. Providing open access to historical blocked or personal tweets would also erode trust.
Elon Musk has demonstrated an uncanny ability to succeed at previously unprofitable enterprises like electronic vehicles and space travel. Perhaps there is more to Elon’s Twitter plan than is apparent. Perhaps he is saying what he needs to say to ensure public support for his Twitter takeover.
While open sourcing Twitter’s algorithm appeals to the romantic notion that information is better free, increased transparency will not create a “maximally trusted and broadly inclusive” Twitter. Social networks like Twitter coalesce almost unbelievable amounts of data almost instantly into our hands. They have difficulty with contentious issues and, therefore, trust because they reflect existing contention back at us. It is easier to blame the mirror than ourselves.
It is hard not to find advice on being a great IT architect. Beyond modelling and technical details, good advice includes effective persuasion, people skills and persistence. However, the need for non-technical skills is often left as self-evident or explained superficially. It also glosses over important details and distinctions.
Traditionally, IT has two types of roles. The first role is the implementor, such as a software developer, network engineer or QA. They produce non-delegatable outcomes. The second role is a manager or executive, someone accountable when something goes well or poorly.
IT architects fit into neither role. Their value becomes apparent when the project or organization gets big, complex or conflicts with team objectives. They are not more intelligent or more capable than implementors or management. Instead, they solve an emergent need.
IT architects are internal consultants, helping team members to execute and management be successful. Enterprise and senior solution architects increasingly provide executive decision support instead of design, almost becoming a separate role.
However, being a consultant has two fundamental but often missed implications for IT architects. The first implication is an IT architect has no intrinsic authority. Their authority stems from the stakeholders, usually management or executives, that their architectures enable or support.
Whose authority is usually evident in client-facing product teams who share a reporting structure. However, this is often unclear in projects spanning multiple reporting lines, such as large or siloed organizations or internal IT projects. Shared responsibilities between business and IT muddy this further.
The second implication of an IT architect being consultative is people often incorrectly think IT architects, like consultants, are paid for their opinions. Yes, implementors consume the artifacts produced by IT architects, like designs and principles (“opinions”). However, neither stakeholders nor implementors blindly accept them.
Instead, an IT architect should prioritize and justify their outputs as stakeholders do to their superiors. This approach consists of three pillars.
The first pillar is financial. How do the IT architect’s actions make money, save money or lose less money? Start with understanding how the organization funds projects. For example, if maintenance and operation costs are separate, the IT architect may need to justify up-front efforts to reduce each to different stakeholders. A move to IaaS cloud hosting is easier if the organization favours OpEx over CapEx.
The second pillar is metrics. Executives and managers often have objectives, measures or other targets they need to reach. While they are rarely perfect, an IT architect should understand them and reference them. For example, if cost-saving is a metric for a critical stakeholder, ensure the design reduces net cost.
The third pillar is language. The IT architect should learn and use the terms used by executives and managers. Such language varies between organizations and shifts over time but talking like decision-makers helps an IT architect seem credible.
Another question is how much authority the IT architect holds. There is no definitive answer. Less technical management and executives often dismiss the question as an IT issue. IT management may lack the strategic incentives to avoid cutting corners. Organizations rarely question the level and nature of authority when successful. However, they can scramble when things go downhill.
Aligning expectations and processes beforehand, both individual IT architects and the team, is a practical first step. How is development tracked against the architecture? Is there a process for changing or disregarding parts of an architecture? How do you differentiate poor execution from a good architecture or vice versa?
Once an IT architect establishes this, IT architects can then differentiate the value of their project from their value as IT architects. The accountability for a project rests with the appropriate executives and management, not the architect. The IT architect needs to focus on their part in it.
Selling an architecture or design and selling the value of an IT architect are related but different activities. Selling a design, for example, requires helping the customer meet their own goals more effectively. It happens periodically, usually once per project. It makes you authoritative for that project. Selling an IT architect role and understanding stakeholder needs are both ongoing, continuous processes.
IT architects are a bit like CEOs. CEOs’ primary customers are the investors or owners of the organization. While ignoring actual customers or staff seems cynical, good investors care about the organization as a whole and beyond just customers’ short term needs.
An IT architect’s “investors” are their stakeholders. Like CEOs, IT architects will rarely keep everyone happy. Not every team will have every need met. Every change involves winners (profit, less work) and losers (more work, more responsibility).
The success of an IT architect relies on their ability to identify and sell their value to the correct set of stakeholders. Selling is challenging and complex. Stakeholders are rarely technical, at least from an architect’s viewpoint, and require empathy.
For example, non-IT management wants justification in business terms, usually financial. They often regard “good design practices” as an unnecessary expense. While organizations are using more technology, technology is rarely a core business competency or differentiator. The onus is on the IT architect to justify anything beyond a minimal expenditure.
Having to justify technology use constantly is frustrating. IT architects often evolve from technologists who “look up” or “see the big picture”. However, the big picture is not really about technology. It is about the application of technology to broad, often ill-defined and contradictory goals. If it were easy, we would not need good IT architects.
For most of us, smartphones replaced paper maps long ago. You enter your destination, and it presents you with multiple potential routes. Given one route is often fastest, why bother?
The smartphone may not have all the information, such as weather or traffic. The phone does not know that an alternate route may be faster.
Perhaps the environment changes after navigation starts. Having a prepared alternate makes switching routes easier.
Speed may not be the crucial attribute. Maybe the driver wants the psychological safety of a familiar but slower route. Maybe one route is more enjoyable and scenic. Maybe the driver wants to shop on the way.
The fastest route may also have variability or risk. Maybe a football game at the local sports ground will finish soon. If time is tight, the time of a slower route may be more predictable and, therefore, better.
These reasons also apply to IT architectures at any level, whether technical/component, solution or enterprise.
The problem is most IT architects come from an implementor background, like software developers or network engineers. Good implementors build complex and deep mental models of their systems. These models allow implementors to both isolate issues and plan small to moderate changes quickly and effectively.
Organizations incentivize implementors to make changes quickly and with low risk. Having a good mental model facilitates that. The sooner an implementor can envisage and choose a solution, the sooner they can implement it and the sooner it can ship. This speed inspires confidence and provides technical leadership.
However, architects need to think differently to implementors. They still need higher-level mental models but should think more strategically (“Are we solving the correct problems? Is the solution complete?”). IT architects also need to think politically (“How do I convince stakeholders of the solution’s value and my value?”).
An architect should own all technical solutions in a business problem space. Providing a single solution implies the architect owns the solution, not the problem space. Subsequent design changes, even improvements, may diminish the architect’s credibility.
Focusing on a single solution alters how people justify them. The more assured people are that a solution is best, the less strongly they argue for it. They lose empathy with others to whom the solution’s merits are less clear. They often think beyond the design and evaluation stage and are frustrated when yanked back. Alternatives contrast and identify the solution’s pros and cons.
Providing multiple solutions helps generate discussion. Stakeholders may have differing preferences. Presenting different solutions, like playtesting a game’s rules or A/B testing a website, can draw out these preferences and derive the best solution. Stakeholders are customers.
Creating good alternatives and fighting an implementor’s instincts is difficult. The trade-offs are situation- and stakeholder-dependent.
That said, most organizations treat IT purely as a cost. Therefore, the biggest concern in any IT system is cost, including staff, time, and money. Create alternatives that minimize one or more of these by dropping, substituting or minimizing features.
Never sacrifice quality when creating alternatives. Stakeholders, particularly executives, are often not accountable for maintainability, security, availability, and the like. If they are not accountable, they do not care. For those that are accountable, quality is hard to quantify or demonstrate, so executives almost always delegate it.
Another alternative source is the “shortest path to value” (SPV). SPV identifies small projects within large ones with the biggest “bang for buck”, embodying the Pareto principle or 80:20 rule. SPV reduces otherwise massive projects that are hard to scope or have high schedule risk, making them more concrete and predictable.
Consider implementing the project using different technologies (tools or frameworks) or teams. Another team, even if only hypothetical, may take a different approach. Using or avoiding the technology de jour also opens possibilities. A greenfield project has advantages and disadvantages over non-greenfield projects.
Re-examine constraints or “bad ideas”. Even “hard” constraints are sometimes malleable. People often shun anything close to bad ideas. However, unrecognized good ideas often surround bad ideas.
Providing a single “best” solution undermines the architect’s credibility and removes agency from stakeholders. Like smartphone navigation, an IT architect often lacks full knowledge, may not grasp all requirements or environment, or solutions may provide unexpected opportunities for stakeholders. The biggest barrier is frequently identifying good alternates.
However, the biggest reason why alternatives are so powerful is IT architects need to differentiate themselves and sell their role. IT architects are not accountable like managers or responsible like implementors. Their value proposition is technical insights and good designs. Creating, evaluating and comparing the alternatives provides those insights and demonstrates the superiority of that design.
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.
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.
I am a self-motivated, adaptable, outcome-focused enterprise and solution architect that gravitates toward technical leadership roles. My experience covers architecture, management, security and software development roles over 20 years, from multiple startups to global technology companies. I am an inventor of multiple patents; hold a variety of security, IT and agile certifications and contribute to open source software.
I have worked as an enterprise and solution architect at global technology companies like NTT Limited and Symantec. My focus has always been client-facing services, ideally ones that mix software development and IT management.
This blog explores the deeper thinking and processes behind writing software, building IT systems, and how they fit into the wider IT and business landscape.
Opinions expressed in this blog are the author's and not necessarily those of his employer or its affiliates.
Content is published under the Creative Commons Attribution-Noncommercial-No Derivative Works 4.0 License.
The header image and blog icon are from the blog Random Acts of Photography. This is used with kind permission from the author and under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
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.
Anthony Langsworth
@alangsworth
anthonylangsworth
Random Acts of Architecture 
