Organizational Ohm's Law—Case in Point: Engineering Velocity

Organizational productivity determines how fast an organization can utilize its resources to achieve desired outcomes. The ability to deliver is one of the most critical competitive advantages for any organization. Despite the well-proven empirical evidence and best practices to improve organizational productivity, it is still hard to comprehend the problem holistically because there are so many interdependent moving parts. In this article, we propose the concept of organizational Ohm's law inspired by Ohm's law in electrical engineering. Organizational Ohm's law is built upon well-proven empirical evidence. Organizational Ohm's law is a general descriptive model to comprehensively understand organizational productivity. We state that organizational velocity is proportional to outcome-output efficiency and organizational potential, and inversely proportional to organizational resistance. We then apply the model to understand engineering velocity, exploring factors that contribute to the parameters of organizational Ohm's law, and introducing an equivalent circuit approach to decompose organizational resistance. We show that the model is intuitive and effective when considering various engineering productivity situations. Furthermore, we share our stories of improving engineering velocity by transforming from a single product to a product platform, and by migrating from a monolith to microservices and macroservices. We also explain how to utilize organizational Ohm's law in practice using real-life examples from different companies. In the end, we give suggestions on how to use organizational Ohm's law as a both retrospective and predictive tool.

Organizational Ohm's Law-Case in Point: Engineering Velocity

Fei Liu and Todd McKinnon
Abstract-Organizational productivity determines how fast an organization can utilize its resources to achieve desired outcomes.The ability to deliver is one of the most critical competitive advantages for any organization.Despite the well-proven empirical evidence and best practices to improve organizational productivity, it is still hard to comprehend the problem holistically because there are so many interdependent moving parts.In this article, we propose the concept of organizational Ohm's law inspired by Ohm's law in electrical engineering.Organizational Ohm's law is built upon well-proven empirical evidence.Organizational Ohm's law is a general descriptive model to comprehensively understand organizational productivity.We state that organizational velocity is proportional to outcome-output efficiency and organizational potential, and inversely proportional to organizational resistance.We then apply the model to understand engineering velocity, exploring factors that contribute to the parameters of organizational Ohm's law, and introducing an equivalent circuit approach to decompose organizational resistance.We show that the model is intuitive and effective when considering various engineering productivity situations.Furthermore, we share our stories of improving engineering velocity by transforming from a single product to a product platform, and by migrating from a monolith to microservices and macroservices.We also explain how to utilize organizational Ohm's law in practice using real-life examples from different companies.In the end, we give suggestions on how to use organizational Ohm's law as a both retrospective and predictive tool.Index Terms-DevOps, engineering velocity, equivalent circuit, infrastructure, motivation, organizational Ohm's law, organizational structure, outcome, output, process, productivity in software development.

I. INTRODUCTION
O RGANIZATIONAL productivity determines how fast an organization can utilize its resources to achieve desired outcomes.The ability to deliver is one of the most critical competitive advantages for any organization.Organizational velocity is used to measure organizational productivity.Improving organizational productivity is top of mind for C-level executives, engineering managers, and software engineers.Over the last decades, extensive work has been done in this field, and we have seen great achievements in implementing best practices.The authors are with the Okta Inc., San Francisco, CA 94105 USA (e-mail: fei.liu@okta.com;tmckinnon@okta.com).
Color versions of one or more figures in this article are available at https://doi.org/10.1109/TEM.2022.3232311.

TABLE I EXISTING ORGANIZATIONAL PRODUCTIVITY WORK
We summarize the existing work according to areas of focus in Table I.For example, Andy Grove, the third CEO of Intel and the father of management science, introduced a goal-setting methodology: objectives and key results (OKRs) to set ambitious goals, create alignment, and track measurable results [1], [2].OKRs helped Intel transform from a maker of memory chips into the world's largest semiconductor chip manufacturer.John Doerr, a venture capitalist at Kleiner Perkins, introduced OKRs to Google, and OKRs were later adopted by most technology companies and even nonprofit organizations [3], [4].Also, there are many behavioral and psychological theories on how to best motivate employees.Maslow's hierarchy of needs [5], McClelland's three needs theory [6], Herzberg's motivation theory [7], and Alderfer's ERG theory [8] are content theories of motivation, which explain what motivates people.Vroom's Expectancy Theory [9], Adams' equity theory [10], Skinner's operant conditioning theory [11], and Locke's goal-setting theory [12] are process theories of motivation, which explain how motivation occurs and how our motives change over time.Due to the diverse workforce and the complexities of human nature, no single motivation theory can explain all aspects of employee motivation.Managers and executives need to understand various motivation theories to maximize organizational productivity day-to-day.Furthermore, optimal organizational design and operational excellence have been thought of as a path to boost organizational productivity.Conway [13] used the mathematical concept of homomorphism to describe the relationship between a system and its design organization and concluded that a design effort should be organized according to the needs of communication.Brooks [14] made the famous statement that adding manpower to a late software project makes it later.Amazon's management principles, described by the two-pizza rule and single-threaded leaders, emphasize that the key to going faster, being more innovative, and utilizing advanced technologies is to establish teams that have clear lines of accountability and are empowered to deliver business value [15], [16], [17].
In a software engineering organization, engineering velocity is used to measure the performance of the engineering organization.Since the emergence of DevOps, led by the work of Patrick Debois, who coined the term, and others, companies around the world have focused on increasing the speed, efficiency, and quality of software delivery by combining people, processes, and tools [18].Spotify implemented a people-driven, autonomous approach for scaling agile, and encouraged a culture of trust and rapid learning.The company organized engineering teams using squads, tribes, chapters, and guilds to balance autonomy, collaborations, and alignments [19].Forsgren et al. [20], [21], [22] compiled over 23 000 survey responses and presented key DevOps metrics: lead time, deployment frequency, time to restore, and change failure rate, in their state of DevOps work.Lewis [23] proposed the inverse Conway maneuver, a concept to align the organizational structures of software development organizations to match microservices architectures.Skelton and Pais [24] presented team topologies, which include four team types and three interaction modes, to effectively build and run software systems.Forsgren et al. [25] recommended a SPACE method for evaluating a set of balanced metrics to measure developer productivity.Thousands of software engineering organizations have tried to bring these learnings into their culture and daily operations.
Despite well-proven empirical evidence and best practices to improve organizational productivity over the last eighty years, it is still hard to comprehend the problem holistically because there are so many interdependent moving parts [26].In this article, we will propose an intuitive and effective framework to put all the things together.Our work is based on fully-demonstrated, highly-cited empirical observations, and aims to provide a descriptive model to comprehensively understand organizational productivity.
The rest of this article is organized as follows.In Section II, we will explain our research methodology.In Section III, we will introduce the concept of organizational Ohm's law inspired by Ohm's law in electrical engineering.In Section IV, we will apply the model to understand engineering velocity challenges.In Section V, we will share our stories of improving software engineering velocity and the lessons learned throughout this process.In Section VI, we will discuss how to apply organizational Ohm's law in practice using real-life examples from several other companies.In Section VII, we will offer suggestions on how to use organizational Ohm's law as a both retrospective and predictive tool and share our future work.Finally, Section VIII concludes this article.

II. METHODOLOGY
Fig. 1 illustrates our research method diagram.Since engineering velocity is one of the most critical challenges for companies like ours, we started the research with the intention to improve our overall engineering and product performance.As discussed in Section I, the topic of organizational productivity has attracted extensive interest from both academics and industry due to its practical impact.Experts with various backgrounds contributed to the understanding of engineering velocity.These experts are engineers, engineering managers, project managers, C-level executives, consultants, or researchers.Therefore, our work was based on the broad empirical examples from academic literature, industry best practices, and the viewpoints of experts with diverse backgrounds.We also incorporated our own first-hand engineering experience and conducted more than 20 interviews with internal and external engineers, engineering managers, project managers, and product managers to learn their pain points and observations.Inspired by Ohm's law in electrical engineering, we first proposed the organizational Ohm's law concept.We then deep dived into engineering velocity, analyzing the meaning of parameters in organizational Ohm's law and how they could relate to real-life scenarios.Afterward, we applied the framework to understand our own engineering velocity challenges and the challenges of other companies.We continued reading more related papers, articles, and blogs.We also shared organizational Ohm's law with our colleagues for feedback.We used new understanding and opinions to refine organizational Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Ohm's law iteratively to a state that the framework can provide a clear understanding of almost all cases.

III. ORGANIZATIONAL OHM'S LAW
Organizational velocity measures organizational productivity.The concept comes from velocity in physics, where velocity is used to describe the rate of change of a position where v is velocity, x is distance, and t is time used to complete the distance.First, let's bring electrons into the picture.Current is the variable that describes how fast a stream of electrons moves where I is current, Q is the total number of charges, and t is time.
Ohm's Law states that the current through an object is proportional to the voltage applied to the object and inversely proportional to the resistance of the object where V is voltage, i.e., electric potential difference, and R is resistance.
Next, let's use Ohm's law to abstract the concept of productivity where I outcome is outcome current, I output is output current, and η is outcome-output efficiency.We use outcome current to describe organizational velocity in terms of an effective outcome.Outcome current is the net useful velocity that aligns with organizational goals.Output current, however, describes output-based organizational velocity.Outcome-output efficiency is the ratio of the outcome current to the output current.This efficiency describes how efficiently the output current contributes to the outcome current.
Organizational potential equals an average of individual potential where V is organizational potential, and v i is individual potential.
Individual potential describes the potential for individual employees to complete their jobs.Two factors contribute to individual potential: employees' skills at performing their jobs Organizational potential equals an average of individual potential.Individual potential describes the potential for individual employees to complete their jobs.Two factors contribute to individual potential: employees' skills at performing their jobs and their motivation.Employees' skills include domain-specific abilities, time management, and interpersonal skills.In spite of its name, individual potential is a team and organizational concept.The individuals' teams and organizations strongly affect individual potential since both the skills and motivation of the individuals can be boosted or deteriorated by their environments.Company mission, company culture, the meaning of work, relationships with management and colleagues, and financial incentives are some of the essential elements contributing to employee motivation [27].
Organizational resistance is the opposition that an organization imposes on the flow of delivering outputs and outcomes where R is organizational resistance, R structure is structure resistance, R process is process resistance, and R infrastructure is infrastructure resistance.
There are three types of friction in any organization: structure resistance, process resistance, and infrastructure resistance.An organizational structure defines how activities are directed to achieve the goals of an organization.Some activities are to perform actual work, while others are to communicate information necessary to conduct the work or to wait for the completion of dependencies by others.Organizational structure determines how information and decisions flow between levels within an organization.Communication to reach agreements does not contribute directly to organizational outputs and outcomes, and it is expensive.Therefore, the communication results in unavoidable structure resistance for an organization.Moreover, structure resistance has a strong dependency on organizational potential.For example, collaborative culture makes communication between teams less painful, hence, lower structure resistance.Organizational processes define processes, procedures, and programs to get things done.Ineffective processes seriously impact organizational outcomes, since employees must spend unnecessary time navigating organizational bureaucracy, dealing with the inefficiency of large process resistance.Organizational infrastructure includes both physical and technological infrastructure.Some organizations, such as IT, are tasked with improving the overall infrastructure of a company so that employees can perform their jobs more effectively, and hence, reduce the value of infrastructure resistance.Sometimes, an internal team's outputs and outcomes serve as infrastructure for other teams to make their jobs easier.Moreover, structure, process, and infrastructure resistance are interdependent.The process of optimizing organizational resistance is at least partially a process of finding matching points between people, processes, and infrastructure.Additionally, if we can formalize a task into a process, we can turn structure resistance into process resistance.And, if we can capture a routine process into a well-defined workflow, we can turn process resistance into infrastructure resistance.The resistance transformation lessens human variability and dramatically reduces overall organizational resistance.Now, let's put everything together to arrive at a complete organizational Ohm's law Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Organizational Ohm's law states that outcome current, and hence, organizational velocity, is proportional to outcomeoutput efficiency and organizational potential, and inversely proportional to organizational resistance.In this model, outcome current is the target we would like to maximize under organizational resource constraints.The organizational resource constraints can be boiled down to budget and schedule constraints, i.e., an organization has to deliver desired outcomes with a finite money supply and a deadline.Be aware that action often causes changes in several parameters.Therefore, it is a practice to optimize the parameters according to the near-and long-term goals of an organization.

IV. CASE IN POINT: ENGINEERING VELOCITY
In this section, we will apply organizational Ohm's law as proposed in Section III to scrutinize engineering velocity.We will describe the meanings of each variable (I, η, V, R) in the context of a software engineering organization.We will then discuss factors that affect the value of the variables, explore their interdependence, and understand how to optimize them to achieve high outcome-based engineering velocity.In particular, we will introduce an equivalent circuit approach to appreciate the impact of organizational structures on engineering velocity.We will walk through equivalent circuits for various software engineering team interactions.

A. Applying Organizational Ohm's Law to Engineering Velocity
First, let's look at the output and outcome current in the context of a software engineering organization.In agile software development, engineering velocity is a metric for work done.The velocity metric is used for planning sprints and measuring team performance.Agile velocity can be considered as an example of output-based velocity, which is a metric that tracks how many story points a team can complete in a given sprint.For a product-focused engineering team, if the outputs of their sprints contribute to the goal of delivering functional products, the effort counts toward engineering's outcome-based velocity.However, the effort only counts to the company's outcome-based velocity if it contributes to product releases that are expected to generate revenue and profit in the near-or long-term.It is extremely difficult to optimize outcome-output efficiency in software engineering.Engineering teams need to balance between keepthe-lights-on activities, such as maintaining product reliability and security, providing ongoing customer support, reducing tech debt, and new product development.Furthermore, there are always more products and features you want to build than you can possibly deliver.Instead of spreading across many investments, the essence of goal setting, regardless of the methodology, is to enable companies to stay focused on only a few at a time.Single-threaded leaders empower people to focus on a single prioritized goal with full autonomy, minimal distraction, and limited context switches [16], [17].
Next, let's look at the organizational and individual potential in the context of a software engineering organization.Software development is one of the fastest-changing fields.Over the last decade, we've witnessed cloud computing, virtualization, containerization, artificial intelligence, and even blockchain become mainstream technologies.Web development has evolved from text-based static websites, to the trinity of Hypertext Markup Language, Cascading Style Sheets, and JavaScript, to various modern web application frameworks and technologies.Consequently, engineers have had to constantly upgrade their skills and knowledge.This environment implies a relatively short knowledge lifespan for software development skills and the need to foster continuous learning.Opportunities to learn and use new technologies are one of the top ways to motivate engineers.At the same time, engineers are highly motivated to refresh their knowledge due to high market demands and attractive compensation in this field.Alongside the common motivators, a culture of innovation is another factor uniquely important in boosting engineers' motivation.Hackathons are widely used in engineering organizations to encourage engineering creativity and cross-team collaboration.If your company builds developerfocused products or APIs, it is a big red flag if most of your engineers never play with them in their "spare" time.Nevertheless, a more trailblazing way to empower engineers is by allowing them to participate in decisions about their work.[28] To increase the organizational potential of an engineering organization, a company could also invest its resources in engineering processes or enhance engineering compensation.
Finally, let's move to the denominator of the organizational velocity equation.The organizational resistance of engineering is an aggregation of the structure resistance, process resistance, and infrastructure resistance of the engineering organization.In what follows, we will take a closer look at this relationship.Communication costs within and across engineering teams reflect the structure resistance of engineering, which we will discuss in detail in the following sections.Process resistance of engineering constitutes the process friction of performing engineering work.Agile planning, postmortem, retrospective, code review, release process, security review, and legal review are a few examples of engineering-specific process resistance.Of course, company-wide processes, such as goal setting, planning, budgeting, financial procedures, and performance reviews, also contribute to the process resistance of engineering.Infrastructure resistance of engineering refers to the friction of performing engineering work.In the companies that practice Agile and DevOps, teams responsible for engineering infrastructure are sometimes called platform teams [24], [29].Loosely coupled architectures, codebases with manageable tech debt, good version control, effective continuous integration and continuous delivery (CI/CD) pipelines, properly managed manual and automatic tests, and easy-to-find and read documentation are a few strategies for reducing engineering-specific infrastructure resistance.Of course, company-wide infrastructure friction, such as IT and workspace effectiveness, also contributes to infrastructure resistance of engineering.The improvements in process and infrastructure resistance may require purchasing or upgrading tools and implementing or revamping processes.Investments require money, in terms of salaries for employees working on improvements and cost of tools; and time, in terms of duration to establish suitable processes and infrastructure.Table II maps the well-proven empirical best practices for boosting engineering velocity to their corresponding variables in organizational Ohm's law.It shows that organizational Ohm's law provides a tool to holistically contemplate engineering velocity challenges by tying together interdependent moving parts.

B. Independent Engineering Team -Introducing Organizational Equivalent Circuits
Now is the time to dive deep into organizational resistance in a software engineering organization.The beauty of using organizational Ohm's law to describe organizational velocity is that we can use an equivalent circuit, i.e., a theoretical circuit, and its electrical characteristics to represent an organization and the interactions within it.
1) Workstream Teams: Let's analyze the organizational resistance of an independent engineering team m (R eng_m ), which is responsible for building products.Teams that are responsible for building products we refer to as workstream teams; their work contributes to the outcome current of their company.To extend the discussion in Section IV-A, the organizational resistance of an engineering team m consists of intrastructure resistance of team m R structure eng_m , interstructure resistance between team m and engineering infrastructure team R structure eng_m, eng_inf ra , interstructure resistance between team m and process team R structure eng_m, eng_process , process resistance R process eng_m , and infrastructure resistance R infrastructure eng_m .All the resistors are in series with each other since team m has to endure all the friction to deliver its output.Fig. 2 illustrates the equivalent circuit of the organizational resistance of team m.The equivalent circuit assumes that engineering team m interacts with company-level processes and infrastructure only through the engineering process and infrastructure teams.Otherwise, we would have to add R structure eng_m, company − process and R structure eng_m, company − inf ra to describe the communication friction between team m and company process and infrastructure teams.The value of structure resistance is proportional to the cost of all communication where p i is ith communication path and w i is the cost of the ith path.
The cost of communication corresponds to the time spent to reach communication goals.The time used to figure out suitable ways to work with others and to wait for others' effective inputs could be much longer than the communication itself.Therefore, it is critical to establish trust and collaboration between team members and across teams to facilitate effective communication.In addition, it's the responsibility of managers and technical program managers to overcome communication roadblocks.In general, communication within a team is much less costly than across teams, which implies that a small autonomous team is a desirable organizational structure for delivering outputs.15 bidirectional communication paths, and 30 directional paths for intrastructure resistance.As we scale the size of the team, the intrastructure resistance grows roughly proportionally to the square of the size of the team.The engineers get exposure to engineering and company processes through the manager as an intermediary.This is a reasonable approximation since managers generally play the role of interteam interface to cascade policy information and enforce process execution.Each team member also interacts with the engineering infrastructure team, which contributes to interstructure resistance.This is a good approximation since each engineer needs to get training on how engineering infrastructure work during their initial onboarding in order to interact with engineering infrastructure daily thereafter.The interstructure resistance of team m and the infrastructure team decreases dramatically after engineers' onboarding if the engineering infrastructure is robust and allows self-service.
2) Process and Infrastructure Teams: The organizational equivalent circuit approach also works for nonworkstream teams.However, the outputs of nonworkstream teams do not contribute to engineering organizational velocity explicitly.In other words, we do not connect the organizational resistance of nonworkstream teams to engineering organizational resistance (more discussion in Section IV-E).Instead, the outputs of nonworkstream teams contribute to the reductions of process or infrastructure resistance, improvement of outcome-output efficiency, or organizational potential.For example, the effort of technical program managers contributes to process resistance reductions; the effort of internal infrastructure teams contributes to infrastructure resistance reductions; the effort of engineering leadership helps to improve the organizational potential and outcome-output efficiency.

C. Independent and Dependent Workstream Teams -Exploiting Organizational Resistors in Parallel or Series
In this section, we will use independent and dependent workstream teams to understand how teams work together.Although we've chosen workstream teams as an example, the organizational equivalent circuit approach and the observations from workstream teams will also be applicable to process and infrastructure teams, as discussed in Section IV-B2.
1) Independent Workstream Teams Working on Two Different Workstreams: We scale our engineering organization from one workstream team to two.Assume team m and team n focus on building products independently.Since both team m and team n contribute to the engineering output current, the two organizational resistors are in parallel to each other in the equivalent circuit, as shown in Fig. 4. We get a higher output current by increasing the number of engineering teams.Let's assume the organizational resistance of the two teams is identical; by adding a second independent workstream team, we reduce organizational resistance by half and double output current.So, will we be able to keep increasing the number of teams to achieve ultrahigh output current?The answer is no, since the ideal independent team structure is not realistic as we scale our engineering organization.
2) Dependent Workstream Teams Working on Two Different Workstreams: As pointed out at the end of Section IV-C1, dependencies between engineering teams limit the increase of output current.Namely, you cannot expect proportional engineering velocity improvement by adding engineering teams.Fig. 5 illustrates the equivalent circuit for two dependent engineering teams, where the two engineering teams work on two different workstreams.The dependent organizational resistance dep R organizational eng of a team is equal to the independent organizational resistance ind R organizational eng plus interstructure resistance between teams R structure eng_m, eng_n , R structure eng_n, eng_m , as shown in Fig. 6, a simplified equivalent circuit compared to Fig. 5.The values of the interstructure resistance between teams may or may not be the same despite the mutuality of communication.For instance, team m needs help from team n, where team m may need to put more effort into initiating, following up, and getting results from team n.Now, let's look at an example of the effect of interstructure resistance.For the sake of simplicity, we assume that each team has five employees and one manager, with total team members of N = 6.We use the number of directional communication paths between members as an approximation of structure resistance.And we assume that the structure resistance of both teams to engineering process and infrastructure teams, process resistance, and infrastructure resistance are all very small compared to the intrastructure and interstructure resistance of the two.We further assume that members communicated bidirectionally with everyone else inside their teams and everyone in the other team, and the communication costs are the same.We get the intrastructure resistance of 30 and the inter-structure resistance of 36 for both teams.So, if we have only one team, organizational resistance is 30; now that we have two teams, the organizational resistance of the two teams together is (30 + 36)/2 = 33.By introducing the second team, we increase the organizational resistance, decreasing the output current, and engineering velocity.The cause for this decrease in engineering velocity when scaling the number of teams is that introducing new teams adds to interstructure resistance.In real life, extensive cross-team communication would introduce even more catastrophic degradation in engineering velocity since the cost of cross-team communication is much higher than that of intrateam communication.Previously empirical work in organization design aims to minimize unnecessary interstructure resistance between teams by optimizing interteam communication.Brooks's law, Conway's law, inverse Conway maneuver, and the two-pizza rule suggest that we should minimize interteam structure resistance by designing organizational structures and communication paths that mirror technology and product structures [13], [14], [15], [23].Moreover, supervisor-subordinate communication is more costly than subordinate-subordinate communication.For a team with multiple layers of management, delegating decisions and empowering less senior employees to play interteam interface roles reduces interstructure resistance [16].
3) Dependent Workstream Teams Working on One Workstream: Fig. 7 shows the equivalent circuit for two dependent engineering teams, where the two engineering teams work together to deliver one workstream.One team may need to hand over the work to the other team to complete the workstream.Or the two teams may need to collaborate to work out a solution for a workstream.In both cases, their independent organizational resistors and interteam resistors are in series with each other since teams own the workstream together.Work handover and extensive team collaboration are less efficient from a structure resistance perspective, but could be necessary.In fact, it may not be possible to form one small team responsible for an endto-end workstream due to technical, organizational, managerial, cultural, legal, and cost considerations.We will discuss these issues in more detail in Section IV-D (the roles of centralized engineering teams), and Section IV-E (collaborations among engineering, product, and sales).

D. Centralized Engineering Teams -Understanding Organizational Circuit Diagram Evolution
Companies normally have centralized engineering teams, such as the office of the CTO, research, or special project groups.These teams are tasked to tackle cutting-edge technology challenges, come up with innovative products, or build disruptive businesses.Retaining investment priority for long-term bets, [30] attracting special talent, and preserving idiosyncratic culture are some of the rationales for establishing centralized engineering teams.Here, we will argue that minimizing overall organizational resistance is another rationale for having centralized engineering teams.
As shown in Fig. 8, a centralized engineering team c has limited interaction with the rest of the engineering organization in its normal state.Extensive interteam communication only happens when their outputs become useful.Two things can happen at that point, a technology transfer or a team transfer.For a technology transfer, the centralized team works with engineering teams to transfer their outputs so that engineering teams can take over the output later.During a technology transfer, overall engineering structure resistance increases, however, the technology transfer ultimately improves outcome current by either increasing outcome-output efficiency, in the case of adding novel technology components to make products a better fit for customers' needs; or by improving organizational potential, in the case of upskilling ordinary engineering teams; or by reducing infrastructure resistance, in the case of improving the effectiveness of engineering infrastructure.After the technology transfer, the centralized team comes back to its normal state, with limited interteam communication with ordinary engineering teams.In short, the centralized engineering team imposes dynamic structure resistance on the engineering organization only for a short period, reducing overall structure resistance over time.In a team transfer case, before it's ready for transfer, the centralized engineering team is in its incubation stage, and its output does not contribute to the engineering output.Once the team's deliverable matures, it can become an independent team contributing to the overall engineering output current.
Generally speaking, interactions and communication between teams are never static even for ordinary engineering teams.An organization needs to evolve its structure to adapt to internal and external forces, such as company and product directions, product lifecycles, market trends, and workforce diversity.Thus, an optimal engineering organizational circuit diagram is constantly evolving over time.

E. Interacting With Other Organizations -Sketching Company Circuit Diagram Snapshots
An engineering organization needs to interact with other organizations to turn their engineering outputs into desired company outcomes, i.e., revenue and profit.To achieve the goal, generally, engineering teams work with product teams to come up with products that customers love.And engineering teams build, operate, maintain, and upgrade these products [31].As an example, as shown in Fig. 9, a product team operates with dependent workstream teams working on independent workstreams, then a product and product marketing organization works with a sales organization to drive company outcome.Now, let's sketch a company-level organizational circuit diagram for this scenario.First, the organizational resistors of engineering teams m and n are in parallel with each other.Their organizational resistance consists of independent organizational resistance ind R organizational eng_m , ind R organizational eng_n and interstructure resistance across entire dependent engineering teams, which are responsible for workstreams Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.Then, we put the organizational resistors of engineering teams m and n in series with the organizational resistors of product team m + n .The engineering and product interstructure resistance R structure eng_m,prod_m+n , R structure eng_n,prod_m+n , R structure prod − m+n, eng_m , R structure prod − m+n,eng_n is introduced to describe the collaborations at the product and engineering level.Consequently, we come up with the overall organizational resistance of engineering and product R organizational eng+prod by placing the organizational resistors of all independent workstreams in parallel.Finally, we connect the engineering and product organizational resistor with the sales organizational resistor R organizational sales in series and add the product and sales interstructure resistors R structure prod, sales , R structure sales, prod , since product and sales organizations work together to achieve revenue and profit goals.
For some organizations, a minimal team structure might consist of engineers, product managers, and designers.The thesis for this type of organizational structure is to encourage end-to-end workstream ownership and minimize organizational resistance.In doing so, the organizational resistance of product and engineering becomes the organizational resistance of the product triad, without unnecessary interstructure resistance.In the other organizational structures, there are multiple business units in a company, each with its own engineering, product, and sales organizations as well as profit and loss responsibilities.This is another approach to promoting end-to-end autonomy and ownership [17].Each business unit will form an equivalent circuit diagram like the one shown in Fig. 9, then each business unit's organizational resistors are placed in parallel to form a complete company organizational circuit diagram.
As a recap, we build up a company organizational circuit diagram from a business unit organizational circuit diagram.Company or business unit organizational circuit diagrams are composed of independent organizational resistance of engineering, product, and sales, as well as the interstructure resistance at play among the three organizations.

V. OUR OWN STORIES
Early on, our product functionality was designed in a hardcoded way to satisfy 80% of customer requirements.As we grew, we saw increasing complexity in customer needs, which constantly required us to make tradeoffs when introducing new features.Furthermore, we expanded our business to fulfill different categories of customers.As a result, we needed to transform our original single product into a product platform to support the full range of use cases [32].However, this initiative was much more daunting than we initially thought and took us about three years to complete.Through the process, we realized that tightly coupled modules and functions in our original product architectures had caused a lot of dependencies.Many engineers and product managers had to attend long and frequent status update meetings to make architectural and product decisions, and several teams had to coordinate to modify the same modules.Transitioning to a product platform sets a foundation for loosely coupled engineering and product teams with minimal organizational resistance.During the transition process, we set the platform initiative to be the No. 1 priority for our entire engineering organization.This approach helped engineering teams stay focused on a tightly aligned goal and prevented engineers from confusing motivation.It also gave engineers the autonomy to come up with ways to achieve the goal.Hence, keeping our engineering organization focused on one single goal at a time increased individual potential, engineering organizational potential, and outcome-output efficiency.Also, our codebase was a Java-based monolith, which included a single code repository with one Maven project, one integrated development environment (IDE) setup, a single build artifact, a single large Spring runtime, a single continuous integration (CI) system, a few user interface applications, and a single MySQL database.It took engineers a long time for a full build, a monolith runtime startup, switching or rebasing branch, syncing IDE, and completing CI and tests.The monolith imposed massive infrastructure resistance to engineering teams due to infrastructure friction, and negatively impacted engineering individual potential due to engineer demoralization.We started to separate the monolith into microservices and macroservices, and used new product development opportunities to test out the microservices and macroservices code, build, and release.We saw some early wins, while that the monolith to microservices and macroservices journey will take several years.Refactoring the entire monolith without breaking things is not easy.However, when the journey is accomplished, our engineering team will have lower infrastructure, process, and structure resistance due to loosely coupled architectures, processes, and organizational structures.Also, engineers will improve their skills and motivation since they can learn and utilize a modern technology stack.
We noticed that, broadly speaking, organizational structures and communication paths should be mapped to the purpose of the teams.The purpose of engineering and product teams is to build products that customers love, thus, the teams' organizational design should be aligned with the architectures and codebases of products.The purpose of sales and marketing teams is to serve our customers.Therefore, their organizational design should be aligned with customer personas, verticals, and geographies.Moreover, organizational design mapping is a continuous process, we need to constantly adjust the mapping for optimal results.

A. Fred Brooks's the Mythical Man-Month
In Brooks' work, he made the statement that "adding manpower to a late software project makes it later" based on his IBM software engineering and project management experience.Fred explained that "complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them" [14].The essence of Brooks' argument is that software development is hard to decouple into small pieces and is not completely parallelizable.The augment is consistent with the concept of resistors in series versus in parallel discussed in Section IV.Moreover, our circuit diagram approach provides a visual representation of the software development complexity.

B. Software Complexity At Microsoft
When the Microsoft Word Team tried to leverage Power-Point's enhanced visual support features, the team's estimates on the cost of building the features were many times larger than PowerPoint's estimates.The reason for the growth in estimates was because "Word's feature set interacted in ways that made the specification (and, hence, the implementation) more complex and more costly" [33].Applying Ohm's law, the costly implementation was due to cross-team and cross-feature structure resistance.The cross-team and cross-feature structure resistors were in series with each other, therefore, the more interdependent the features, the larger the structure resistance.If the value of cross-team and cross-feature structure resistors was larger than that of other resistors, engineering velocity or time to complete the task would be roughly proportional to the number of cross-teams and cross-features, which is consistent with what Crowley observed: "Features interact-intentionally-and that makes the cost of implementing the N+1 feature closer to N than 1." Applying a similar argument, organizational Ohm's law can be used to explain other software complexity examples, such as the Microsoft FrontPage editor, Microsoft OneNote, Microsoft's open source practice, and Microsoft Office versus Google Apps [33].

C. Google Software Engineering Best Practices
A large part of Google's success can be attributed to Google's software engineering practices.Google's unique engineering culture, processes, and tools have contributed to the effectiveness of its engineering organization [34].Applying organizational Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Ohm's law, Google's best practices in culture, processes, and tools correspond to the variables of organizational potential, process resistance, and infrastructure resistance, respectively.

VII. HOW TO USE ORGANIZATIONAL OHM'S LAW AND FUTURE WORK
Organizational Ohm's law can be utilized retrospectively and predictively.As a root cause analysis tool, organizational Ohm's law can be used to provide an in-depth understanding of organizational productivity.Companies always try to apply learnings from their experience and industry best practices.However, direct copy and paste rarely works.Practitioners need to understand the drivers behind the best practices and tweak the best practices to fit their situations.The organizational Ohm's law framework illustrated in Section III provides a way to figure out root causes.The best practice mapping shown in Table II serves as a look-up table to stimulate ideas.As a simulation tool, organizational Ohm's law can be used to foresee the impact of action plans on organizational productivity.By applying the organizational Ohm's law formula or drawing equivalent circuits discussed in Section IV to best practices or new observations, practitioners can understand the interdependent nature of their actions, anticipate potential outcomes, refine their plans, and make iterations.The simulation process would encourage rigorous thinking, quick feedback or adjustments, and better outcomes.
Moreover, we believe the implication of organizational Ohm's law is beyond a qualitative framework.The quantitative nature of organizational Ohm's law will be the focus of our future work.With modern engineering management philosophy and the proliferation of enterprise software and survey tools, we can now extract the value of each parameter in organizational Ohm's law.Therefore, organizational Ohm's law could provide both qualitative understanding and quantitative measurement of organizational productivity.

VIII. CONCLUSION
We have proposed organizational Ohm's law inspired by Ohm's law in electrical engineering I outcome = η × V R , where I outcome is outcome current, η is outcome-output efficiency, V is organizational potential, and R is organizational resistance.We claimed that organizational velocity can be described by outcome current.The value of organizational velocity is proportional to outcome-output efficiency and organizational potential, and inversely proportional to organizational resistance.We then applied organizational Ohm's law to understand engineering velocity, exploring factors that contribute to the parameters of organizational Ohm's law, and introducing an equivalent circuit approach to decompose organizational resistance.We attributed organizational resistance with a composition of structure, process, and infrastructure resistance.We analyzed the importance of skills and motivation in a team setting to organizational potential.Our model revealed consistent findings with empirical experimentations and software development best practices.Furthermore, we shared our own stories of transforming into a product platform and migrating from a monolith to microservice and macroservice architectures.We learned that organizational design should be mapped to the purpose of teams, and organizational design mapping is a continuous dynamic process.We also realized that keeping an organization focusing on a single goal at a time escalated outcome-output efficiency and organizational potential.We discussed how to apply organizational Ohm's law in practice using real-life examples from several other companies.Despite the fact we used software engineering velocity as an example to discuss organizational Ohm's law, organizational Ohm's law is a general model and can be utilized for other organizational productivity problems, including but not limited to, operational excellence in sales, finance, and human resource organizations, and productivity in university, healthcare, government, and nonprofit corporations.We hope organizational Ohm's law can help practitioners think more comprehensively to drive organizational productivity advancements.
Fei Liu received the B.S. degree in electronic engineering from Tsinghua University, Beijing, China, in 2002, the Ph.D. degree in electrical engineering from University of California, Los Angeles, Los Angeles, CA, USA, in 2006, and the MBA degree in finance from New York University, New York, NY, USA, in 2011.
She is an emerging technology researcher with Okta, San Francisco, CA, USA.She uses her technical and business skills to help Okta stays apprised of relevant market trends and technological developments.Prior to joining Okta, she held various research and strategy roles at Huawei and IBM.She is the author of more than 40 journal papers and conference presentations, and more than 70 patents.Over the years, her research interests have spanned from semiconductors, to identity and security, to organizational management.
Todd McKinnon received the B.S. degree in management and information systems from Brigham Young University, Provo, UT, USA, in 1993, and the M.S. degree in computer science from California Polytechnic State University, San Luis Obispo, CA, USA, in 1995.
He is the CEO and co-founder of Okta, the leading independent identity provider, which he co-founded in 2009 with Frederic Kerrest.Under his leadership, Okta has transformed the way millions of people access technology and put identity at the forefront of security.His experience as a leader and technology visionary spans more than 25 years, with deep roots in enterprise software and cloud transformation.Prior to Okta, he led engineering at Salesforce.com, where he grew the team from 15 people to more than 250, and the service from two million daily transactions to more than 150 million.He started his career at PeopleSoft, where he held a number of engineering and leadership roles throughout his 8-year tenure.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 2 .
Fig. 2. Equivalent circuit of the organizational resistance of independent engineering team m.

Fig. 3
illustrates hypothetical communication paths for team m.Suppose that team m has five employees and one manager, with total team members of N = 6.There are N * (N − 1)/2 of

Fig. 4 .
Fig. 4. Equivalent circuit of two independent workstream teams, working on two different workstreams.

Fig. 7 .
Fig. 7. Simplified equivalent circuit of two dependent workstream teams, working together on one workstream.

Fig. 8 .
Fig. 8. Equivalent circuits of centralized engineering teams in different states.

Fig. 9 .
Fig. 9. Equivalent circuit of a company with engineering, product, and sales organizations.
Manuscript received 5 July 2022; revised 26 October 2022; accepted 14 December 2022.Date of publication 16 January 2023; date of current version 16 February 2024.Review of this manuscript was arranged by Department Editor E. Kongar.(Corresponding author: Fei Liu.)

TABLE II MAPPING
ENGINEERING VELOCITY BEST PRACTICES FOR THE VARIABLES IN ORGANIZATIONAL OHM'S LAW