Random Acts of Architecture

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

Tag Archives: Culture

Toppling alpha developers

Leave a comment Posted by on May 18, 2018
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.

Op-Ed, Software Development , , , , ,

Rebranding Corporate Politics

Leave a comment Posted by on January 16, 2017

politicsThe term “corporate politics” conjures up images of sycophantic, self-serving behavior like boot-licking and backstabbing. However, to some IT professionals’ chagrin, we work with humans as much as computers. Dismissing humans is dismissing part of the job.

The best way to “play” corporate politics is solve big problems by doing things you enjoy and excel at.

“Big problems” means problems faced not just by your team but by your boss’s boss, your boss’s boss’s boss and so on. If you don’t know what they are, ask (easier than it sounds). Otherwise, attend all hands meetings, read industry literature or look at your leaders’ social network posts, particularly internal ones.

This is not just for those wanting promotions into management. Individual contributors still want better benefits and higher profile or challenging projects. These come easiest to those known to be providing value and not the strict meritocracy some IT professionals think they work in.

Start by solving small problems as side projects. Choose something impacting more than your own team and minimize others’ extra work. Build up to bigger problems once you have demonstrated ability and credibility.

You need not be the leader. Assisting others making an effort can be just as effective. You can own part of it or bask in the halo effect. If not, recognize those that are. This creates a culture of recognition that may recognize you in the future.

While some IT professionals solve big problems everyday, communicating and evangelizing their work “feels” wrong. This what salespeople do, not IT professionals. Many also think their work is not interesting.

Being successful requires people knowing what you do. This may be as simple as a short elevator chat, a brown bag talk or a post on the corporate social network. It also helps get early feedback and build a like-minded team. Others will be interested if you are working on the right things.

What about the potentially less savory aspects of corporate politics like work social events, sharing common interests with management, supporting corporate charities and so on? These are as much an art as a science. Focus on common goals and building trust, internally and externally. People like to deal with people at their level and contact builds familiarity.

However, this is no substitute for solving big problems. If you are delivering value, interactions with senior decision makers and IT professionals with similar goals should occur naturally. Build on that.

Be aware that problems change over time. Problems get solved by others. The market changes. Competitors come and go. Understanding organizational goals is an ongoing process.

Also realize decision makers are human. They make mistakes. They want to emphasize their achievements and not their failures, just like software developers’ fundamental attribute error bias for their own code and against others’.

However, if your organization makes decisions regularly on “political” grounds, leave. Culture is rarely changed from the ground up and many organizations are looking for good IT staff.

Ignoring the worse case scenario and IT professionals’ bias against self evangelism, the biggest problem with “corporate politics” is actually its name. The concepts behind “agile” and “technical debt” came into common usage once the correct metaphor was found. Corporate politics needs rebranding from something avoided to a tool that IT professionals use to advance themselves. It badly needs a dose of optimism and open mindedness.

Image credit: http://thebluediamondgallery.com/p/politics.html. Usage under CC BY-SA 3.0.

Information Security, Op-Ed, Software Architecture, Software Development , , , ,

A Clash of Development Cultures

3 Comments Posted by on October 22, 2012

Software developers often consider themselves perfectly rational. After all, their jobs consist of programming deterministic, rational machines (computers). However, anyone who has worked with developers realises this is completely untrue. In particular, leaders that direct or influence different groups of developers need to understand what motivates them, especially the more vocal and influential developers and technical leads.

There are two types of influential developers. The first are the “craftsmen” (or the gender non-specific “craftspeople”). Craftsmen are motivated by the respect of their peers and want to be known as “good” developers. Craftsmen tend to:

  • Want to work with cutting edge tools, such as the latest version of an IDE or library, and techniques, such as agile development methodologies.
  • Think “good” code not only satisfies the requirements but is clear, maintainable and is an example to others. They are more likely to refactor code, follow (or create) coding  style guidelines and create automated tests, particularly when they have advance warning their code is going to be reviewed.
  • Thoroughly research and experiment with different ways of solving a problem. They are often critical of designs or direction from others, particularly those removed form the code.
  • Prefer a more egalitarian, flatter management and team structure. They are happy to work in a group of peers, each with their own area of responsibility.
  • Code in their spare time, discuss technical issues over lunch and read or write technical blogs. They hold examples of collaboration, such as open source software, in high regard. They tend to look past certifications and degrees to focus on what was studied or produced.
  • Hold technical opinions strongly. They may argue weakly because they feel their points are “obvious”.
  • Be more common in western cultures like in the US, UK and Australia.

The second are “success-oriented“. They see software development as a relatively well paid and respected stepping stone, usually to management.  They tend to:

  • Prefer familiar tools and techniques, so long as they are well compensated and have promotion opportunities.
  • Think “good” code meets requirements. Other facts are less important.
  • Seek help for problems when there is no immediate, obvious solution.
  • Look to seniority or management for guidance and direction. Indeed, if they are in a senior position, they will often demand the right to design or give direction.
  • Respect and seek “authoritative” measures of achievement such as degrees, certifications and training. The goal is usually to decrease the time to the next promotion, enter the industry at a higher position or be paid more.
  • Hold technical opinions weakly. They may argue strongly because it their training and education emphasized it.
  • Be more common in eastern cultures like in India and China.

Clearly, these groups are not well-defined or mutually exclusive and are generalizations. Craftsmen still want promotions and pay rises. Success-oriented developers may still be interested in technology. They key difference is that the software written by craftsmen is part of their identity so they work to make it as good as they can. They grok languages rather than just learn them.

Craftsmen are not better developers than success-oriented developers and vice versa. For example, craftsman may get distracted by perfectionism or experiments but may drive the organization to newer and (hopefully) better processes. On the other hand, success-oriented developers often use well-understood paths to complete tasks sooner and are happy to maintain older software using older tools.

Success-oriented developers are not more likely to provide business value than craftsmen. Although success-oriented developers are less dismissive of non-technical users and focus more on pleasing management, they commonly implement the requirements verbatim without additional understanding.

Although team composition and work assignment are often the domain of team leaders and management, it benefits everyone in the team to understand others’ motivations. For example, pointing out a better solution to success-oriented developers may frustrate them since their solution is no longer “successful” and requires additional work. Point out the simplicity, time-saving aspects of the new solution or how marketable the new skills required are to motivate or influence success-oriented developers. By comparison, pointing out a better solution to craftsmen may embarrass or make them feel threatened. Point to relevant code, articles or recommendations of industry thought leaders to motivate or influence craftsmen.

Also be aware the type of developer when soliciting feedback. Craftsmen generally give better feedback. Many success-oriented developers are happy to be directed by those more senior or want to direct those they perceive as junior. That said, craftsmen are likely to push newer designs and techniques while success-oriented developers look at things in the context of existing practises.

Moreover, having both developer types working together without self-awareness can create friction, such as when a success-oriented senior developer or manager asserts authority over a craftsman developer pushing what he or she considers a better solution, perhaps backed up by blogs or articles. Outsourcing or mergers/acquisitions often cause or exacerbate this.

The challenge is that developers have weak soft skills and many consider meetings and discussions unproductive time. They rarely focus on interacting with each other, sometimes oblivious to the problems it creates. Unfortunately, developers are not perfectly rational but understanding their motivations can solve common problems or avoid them completely.

(Thanks to Bryan O’Donovan for the helpful review and comments.)

Software Development , , , , , ,

%d bloggers like this: