Influencing Organization Value —
What will you learn?
- A simple method to analyze how a tech choice influences the life of the organization.
- More connections between our everyday tasks and the process optimization ideas.
- A 3-step process to asses technology options based on their effects on organization performance.
Organizational Impact Evaluation
It's time to answer the question, how do you identify the consequences of a tech choice on the life of the organization. I will define the entry point here. It should start with the everyday aspects of our work and show the related process improvement aspects. What I found has a really small surface area. The relevant factors can be summed up into 4 high-level points again, which is pretty neat. I honestly thought this will be a mess to deal with, but at least in a broad sense, we can use a simple list to start analyzing the effects.
- Workload
- Attitude
- Responsibilities
- Processes
It makes a nice acronym again: WARP. It can also be meaningful in this context with a little stretch, as a tech choice can "warp" the organizational life through these factors. This is why I also call it the Organization API. Let's examine each of the areas.
Workload
When we make a tech change, it can have wide-ranging consequences on the workload of many employees. This is the most comprehensive list I could come up with. You can use it as a checklist. Go over each type of task and see if it will be influenced by the choice. Look up the related questions from the previous chapter to see how to evaluate the tool in that aspect. I will discuss what factors affect their control concerns and what kind of wastes can be generated by them so you can follow their consequences on the organizational performance. Keep in mind, the common concerns of control apply in all cases, I only explicitly mention it where no other forces are at play. Using this method, it's easy to examine the organizational effects of a change in workload. With that in mind, consider if the introduction, upgrade or decommissioning of a tool affects:
- Research - Preparation of technical decisions, exploration of possible solutions.
Control Concerns: Planning - All
Wastes: Motion - 4, 5, Defects - 1, Overproducing - 4, Waiting - 8
- Planning - Of features, architecture, tests, designs, operations tasks or any other actions.
Control Concerns: Planning - All
Wastes: Overdelivering - 1, 2, 4, Motion - 4, 5, Transport - 2, 3, Defects - All, Overproducing - 4, Waiting - 8,
- Coding - New development, refactoring, removing code or fixing issues.
Control Concerns: Development - All
Wastes: Overdelivering - 1, 3, Waiting - All, Transport - 1, Inventory - 1, 2, Motion - 5, Defects - All, Underutilization - All, Overproducing - All
- Reviewing - Code review, plan review, external reviews like a security audit.
Control Concerns: In case of code and plans: Planning - All, Development - 2, 4, 5. In case of external audits: Q&A - All
Wastes: Defects - All, Motion - 4, 5, Waiting - 2, 4, 5, 8, Overproducing - 4, has a part in allowing Overdelivering and Transport wastes
- Testing - By developers, QA or users who are creating, updating or removing tests cases or processes.
Control Concerns: Q&A - All
Wastes: Defects - general, Waiting - 3, 5, 8, Motion - 5, Overproducing - 4
- Operations - Deployment, maintenance, updates, decommissioning, infrastructure.
Control Concerns: Operations - All
Wastes: Defects - general, Waiting - 1, 5, 8, Transport - 5, Overproducing - All, Motion - 5
- Support - Offered to the users, customers or other employees.
Control Concerns: When a developer works on mitigating production issues: Development - All, Operations - All
Wastes: Overproducing - 3, Motion - 4, 5, Waiting - general, 8
- Learning - Self learning, participation in trainings - about anything necessary for the job.
Control Concerns: Common Concerns
Wastes: Motion - 2, 4, 5
- Mentoring - Teaching others the usage of- and supporting their work with- the tool and related technologies.
Control Concerns: Common Concerns
Wastes: Motion - 2, 4, 5, Waiting - 4
- Documenting - Creating, updating or removing documentation.
Control Concerns: Common Concerns
Wastes: Overproducing - 3, 4, Overdelivering - general, Motion - 5
- Reporting - Manual or automated, about measures or activities affected by the tool. It can also mean indirectly related reports like the performance of the development process.
Control Concerns: In case of implementing automated reporting: Development - All. In case of monitoring: Operations - 3
Wastes: Overproducing - general, Overdelivering - general, Waiting - general, Motion - 4, 5
- Communicating - Aligning with other teams, managers, experts and coordinating development efforts or any other form of work related communication.
Control Concerns: Common Concerns
Wastes: Waiting - general, Overdelivering - general, Motion - 4, 5
Workload is always an easy target for improvement, because we can directly influence this aspect of the organization. To know what counts as a positive change you should look up the related parts of the COOP list through the variables and wastes. In general, this is a cross cutting concern, it includes aspects of both the organize and produce parts. Furthermore it's mostly an efficiency and utilization influencing area, but through reporting and testing this contributes to the effective execution of the company strategy.
Attitude - The Wizard's Haven
After a long journey exploring the full context of software we finally arrived to our home on the island of Everhack. This is not our last destination, but we will stay here for a little while and look around. Source code flows freely over the landscape, shaping it into different design patterns as it goes. Wherever you look, wizards are discussing their latest tech spells and the newest breakthroughs of the archmages exploring other planes of software. We want to find something here, that can only be found in the lab of a real code wizard. We are searching for the elements of passion that drive our hearts in the pursuit of code craft, as an enthusiastic developer can really do magic at work.
A tech change can affect people in many ways. Some of them are beneficial and some of them are detrimental to the success of the organization. Here I will show you the main factors that can change the attitude of colleagues towards a given tool. Following the established pattern this can be called the Developer API. It all comes down to how it will affect them in the following areas:
- Career advancement: Whether the adoption helps or deters getting a promotion, reaching a milestone or enhancing their CV. If it has any of these effects, you can bet people will change their attitude towards the technology.
- Challenges: It's an equally or in some cases even more important factor than career advancement. Often, people feel like they need to step up their game in order to grow and the introduction of a new technology might just bring the opportunity they were waiting for. It can mean both professional or personal growth. On the other hand they might be contempt with what they know and don't want to be bothered with learning something new, just leave their comfortable life undisturbed. Whichever is the case, it will affect their feelings towards the technology.
- Security: When the choice affects the stability of their envisioned path to the future it will definitely influence the opinion they have about it. Two of the most important aspects are job security, and job market viability.
- Professional preference: For various reasons they might like or dislike the tool based on its positive or negative impact on: their curiosity, code or workflow quality, the software's non-functional attributes, the product's functionality and professional aesthetic appeal. Out of all this curiosity is the most impactful on developers, in my experience. Motivated engineers are always looking to expand their knowledge and working with a new tool is many times the ideal way to achieve that. Aesthetics also plays a big role, many developers have their own taste regarding code style, ranging from the language features and mental model to the patterns and standards in use. When a new technology brings improvements in this sense it boosts the motivation levels.
- Personal attachment: For various reasons they might like or dislike the people, the tool's adaptation would lead them to work together with. Some factors might be: close relationships, good or bad history, positive or negative reputation. (example if the team adapts X then my cousin might join the company or former teammate might rejoin, which can actually be a huge win if the person is a great developer, leader, mentor etc)
- Value match: When the technology change is so drastic it affects the mission or social value of the product, the new direction might influence the motivation of some developers based on its match with their personal value system.
- Hype: Like it or hate it, tech adoption is the developer's fashion and it has a real influence over our motivations and plans. On a bigger scale it even affects the job market if lots of programmers flock to a technology. This way it can't be ignored in a precise analysis. It has all the same motivators as in the case of clothing. I did a little research on how it works. It's interesting and funny to see the way it translates to our case. Social status: Frequently changing expensive cloths was only affordable by high social status people back in the days. Good examples are the queens. By mimicking their behavior and choices one could signal their close ties with them and their own high social standing. If we replace the queen with companies like Google or Facebook or industry influencers we have a pretty good analogy. Belonging: By copying the appearance of a group, one tries to fit into that community. Essentially it's the desire to become the part of a tribe. This way one tries to acquire the coveted properties associated with that group. Think of all the cool developers promoting a certain technology. It's an understandable desire to belong to the users of the same tool as all the great programmers you follow. Counter trends: They work the same as any other trend, but their reason is to oppose a mainstream style in order to appear unique or distinct. First thing that came to my frontend developer mind is the recent surge of articles promoting going "frameworkless" or ditching the now mainstream trend of using any of the frameworks that came to prominence in the last decade. Voting for the underdog is also a similar choice. Financial: Because fashion is a business, the manufacturers are incentivized to generate new trends and keep up the demand for their work. They also try to dominate the market for the greatest profit possible. This translates to the opensource battle going on, as developer mind share is the main resource for the opensource business, the creators actively try to increase their project's popularity, dominating the market, as they need to keep them in demand to generate profit, either financial or non financial.
- Work-life balance: The tasks coming with a tech change can affect the working hours and stress levels of the developers. Their reaction is unique to their life situation, personality, personal goals, commitment and other factors. Nonetheless a change in this area will surely have consequences on the organization's efficiency.
- Work efficiency: If the tool makes work easier or processes simpler most developers will be happy about it. The opposite is true as well. I saw many developers begrudgingly acknowledging a new technology choice because they knew it will make their work less effective. Slowly many of them moved on to other projects or jobs. Equally important here is the general efficiency of work. If non technological factors make them a pain, it still leads to the same kind of dissatisfaction. Here goes a few common examples. When the developers are overloaded and don't have enough time to get their job done properly or they are not allowed to handle technical debt. Organizational issues like when dependencies on other teams cause delay in getting the job done, or the required knowledge is not available all can lead to the same outcome.
- Recognition: If the work done with the new tool can lead to any kind of recognition it can have a positive effect on the developers. The range of possibilities here is very wide. It goes from a personal blog post about the achievements or acquired knowledge to a personal thank you from the CEO or great customer feedback, a hefty performance bonus, the opportunity of giving a talk, a badge in the internal system, a beer invitation from the team lead, a LinkedIn endorsement, earning the respect of teammates, or some nice words from Mom.
These factors are complicated, because a positive attitude makes a successful adoption more likely to happen, but the individual preferences might not be aligned with the goals of the organization, so these should be evaluated for net benefit. This topic can involve company politics, that's an intrinsic part of any organization. Even if we don't like it, attitude plays a serious role in the final outcomes of our work so to be the most effective, somebody needs to tackle these questions too. In the organization context definition I give a few ideas how to see this part of our job clearly.
Comparing the size of this tiny island to the rest of the material you can get a sense of the relative weight of our concerns in the overall process of creating software. I have a part inside me that shouts: "It's not true, we enable all this, there's no software without us!" And while it's a correct statement, so is that there's no software without a need for it, without a business creating and selling it, without an organization formed around its production and in many cases without people operating and supporting it. I honestly think the humbleness this realization brings helps to see that we are not the single most important factor in creating software. It really helps to shift our focus towards the whole context of software and a away from the life on Everhack.
So let's connect this to the context of organizations. This is a P element from COOP, mostly influencing efficiency. It means the motivation of developers in general is determined by the elements described here. Out of all control concerns it will only affect the human factor which is a single item but spans all stages of the work. It's connection to the waste types is more nuanced. Many factors here can lead to Overdelivery because when the level of professional curiosity, aesthetic taste or challenge the work provides is low developers are inclined to improve these for themselves by creating solutions they enjoy working on even when those are not aligned with the real needs of the company. That will lead to further Inventory issues and will include wasted Motion and added risk of creating Defects. The source of this issue can also be the general aspect of Underutilization.
As a last message while leaving our home and moving towards other lands, I have to mention that the factors we identified here, if abstracted away from software development, affects all our colleagues just as much as us. This means if any of them, from other professions, depend on the results of your work, or have a saying in the direction you take, analyzing their attitude is necessary to see the full picture.
Responsibilities
We already touched upon this topic while discussing the attitudes and also at the beginning of Chapter 9, but even without them it's evident if we introduce a new technology that can result in a change of roles and responsibilities. Of course upgrading a library to a new version usually doesn't have such effects but a major rewrite of a platform can bring about many of them. First, learn to identify the major types of changes.
- Leading people: Bringing a change in a leadership position. It can affect every level of the organization, from a single team, to many of them, from a department to the whole company and of course based on its scope it can bring in some serious consequences. In the regular case however you will only see a few affected teams with a singe digit number of affected people. It doesn't have to be a formal position, if your teammates start to listen to your opinion in any given new situation you have informally picked up a new role.
- Leading development: This is often connected to the previous category, but it's also not rare to see this kind of responsibility concerning smaller parts of a system to be delegated downwards. In practice, this means tasks like the planning of the solution or a decision-making role in the planning process, the responsibility to ensure quality and timely delivery, solving all the problems during implementation, guiding the developers working on the tasks, etc... The impact of this category also scales up heavily with the number of affected people.
- Responsibility for the product: Ensuring the proper functionality and expected quality of the whole product or some parts or aspects of it like a set of features or security. For developers it maps to keeping the software alive in production with the expected quality or to handling the issues the customers face and report. A technology change mostly affects the involved experts of the tools used to build the system and it leads to either their inclusion to or removal from handling these responsibilities.
- Responsibility for initiatives: When self organizing groups exist within the workplace, that center themselves around some technologies, a tech change affecting the work of their members will have consequences in the life of the groups. They can rise in popularity as their relevance to the company and people can increase or even the organizers can lose interest in them. All of these can lead to changes in their internal roles and responsibilities.
- Responsibility for processes: Similarly to all other points here, if there are high level positions responsible for whole processes like feature delivery as a whole or UI visual consistency, they can be affected by a tech change so does who is necessary to fulfill them.
When you identify any such possible consequence of a technological choice, the next goal is to see how they affect the organization values. This topic is the purest manifestation of the OO areas in development and it affects all 3 elements of organizational performance. Looking up their optimization goals offers a general guideline for the impact evaluation of this category. In the end you should identify if a change in responsibilities makes the organization more efficient, effective or more utilized in any way. You might ask for help from managers, or team leads to determine if the proposed person can bring about positive results. In terms of control concerns this is only affected by the C3 factors. All waste types are connected which depend on at least one O. It means the general aspects of Overproducing, Waiting, Overdelivering, Motion, Defects, Underutilization and indirectly Inventory. Yes, it's all of the types except Transport because in the case of software development that's a purely technical area. This reinforces what we already noticed in the previous chapter, the human factor is one of the most influential force affecting the organization value.
Processes
A tech change can of course affect many kind of processes going on at the company. It's important to identify all that gets influenced by an option and explore what kind of pros and cons will it incur. The processes can be development related like task preparation, coding, testing, documentation, deployment, monitoring, or more organizational in nature like status meetings, decision processes, community discussions and most importantly it can also mean the scheduling of work and even the implementation of the company strategy. The options are so numerous I can't possibly cover all of them, but you can easily find the related processes if you analyze each of the SDLC stages as they are used at your workplace and take a look on what happens at each of them. Once you have the list of relevant processes, you can continue to look for the organizational outcomes by checking if the tech change will:
- Add or remove steps
- Change the order of steps
- Add or remove involved people
- Create or remove dependencies
- Create or remove whole processes
- Change the quality of the process
From our current perspective, what happens inside the steps and how optimal those things are doesn't matter. Their effects are covered by analyzing the workload types. What matters is the change in the process itself. Every type of change in the list is quite trivial and should be easy to identify except the last one, process quality. That can be done using the technique from the last chapter.
From the COOP categories all of them are connected. C is related because large scale process changes can influence the strategy execution plans of the organization. If somebody in a lead role gets involved or removed from a process, that directly influenced the Oversee aspect. The Organize category is relevant as all 4 process elements can be coordination related. P might be affected too because with the exception of people, all elements can stand for some type of work on the product. In any case, you can identify how they affect the organizational performance by what you learned in Chapter 9. The relevant control concerns are from the C3 group. The relevant waste types are in common for all process elements, they are: Waiting, Transport and Motion.
How to use WARP?
It's really straightforward to apply this method when making decisions. What you saw so far helps to identify the relevant aspects of the organization, where we should inspect the effects of our choices. I showed their relationship with the organizational performance, but some details are still missing. How would you compare two alternative options affecting the same workload types or responsibilities? Besides analyzing both the control and waste type optimization concerns for every involved factor, we also need to calculate with:
- Scale - How many people will be affected and on what level? Will it make a major or minor difference on their life? It's important to see the scale of the consequences to properly evaluate the impact of a choice.
- Resources - How much resources will it need? A few examples are time, workforce, knowledge, certifications, hardware, software or simply money. Do we have enough? If not what can we do about that? If yes is it easily affordable, or will it take a major investment?
- Gains - How much financial improvement is expected? Can it offset the expenses? If yes how long will it take? If not will it be worthwhile in other ways? Are there non financial benefits? How much risk is involved?
It's not a big deal if you don't know the exact answer to these questions. Practically speaking it's often enough to have a good general impression about the weight of these factors. When exploring this it might be necessary to collaborate with non developer colleagues to find the right answers, especially if they need to be precise.
So to sum this up:
- Identify the elements of WARP affected by the tech choice.
- Analyze the impact using SRG. Give each element a weight based on the findings.
- Examine the related organization optimization factors and change the weights using that insight.
TL;DR
How to evaluate the organizational impact of a tech choice:
First we define the entry point of this process from a developer's perspective. There are 4 areas that are directly connected to our work where we have a high chance of easily spotting the changes a technology would bring about. They are the Workload, Attitude, Responsibilities and Processes. I named this the WARP method for this reason. If you identify that the technology will have consequences in a given area, the details are discussed above about their effects on the organizational performance. Because of this mechanism I gave it an alternate name, the Organization API.
Workload simply means any task we have to do to get the tasks done. I found 11 types of them, but there might be more in specialized jobs. I'm sure you will notice immediately if this is an area you need to pay attention to.
Attitude details the factors that influence our opinion and feelings towards the adoption of a new technology or the decommissioning of an old one. It's important to analyze this area as for example a quitting colleague can mean serious issues in some situations. It includes non developer coworkers as well who are related to the development process.
Responsibilities are relevant in the situations where people pick up or put down roles or ownership of some aspect of the work or product.
Processes are really specific to every situation, but the general categories are discussed here. On a very high level there are two groups the development related ones like the CI/CD process and organizational like the scheduling of work and the product roadmap.
Finally, there's the SRG analysis, which stands for Scale, Resources and Gains. Besides examining the related organization performance concerns at each of the affected WARP areas you should always weigh their impact by these 3 factors.
Scale means the number of affected people and the level of impact on them.
Resources show what, and how much of it do you need to get the tasks done.
Gains factor in the financial costs and benefits.
Applying these steps in order will lead you through a full organizational impact evaluation of any technology.