One of the questions that we are usually asked first when starting relationships with new partners is how do we work towards aligning ourselves organizationally. It’s obviously a great question. One maxim that I’ve been conditioned to in my years in this industry is that it’s usually not what you know but how you execute it. I can’t recount the number of times that I’ve seen someone with a number of acronyms at the end of their name fail to execute on what, ostensibly, was an easy project or process. While we certainly value technical acumen and all that comes with it, we continually ask ourselves how could have we done that better? One item that we’re continually evaluating and improving is our organization structure.
Let’s start by reviewing the type of structure that organizations are generally rolled into.
1. Administrative Structures
Administrative structures include a specific level of regularization. They are preferably suitable for greater scale or larger multifaceted organizations, most compelling on an extraordinary structure. The stress between non- administrative and administrative structures is resounded difference between gradual and automatic structures.
2. Functional Structure
Functional Structure organizational is a structure which includes undertakings like supervision, direction, management, and allocation of responsibilities. The organizational structure selects how the processes and presentations of the organization can carry. The communication organization structure narrates to how the associate in a company are gathered and to whom can they report. One unoriginal means of establishing individual is done function. Few collective activities in a company contain marketing, HR, manufacture, and bookkeeping. The benefits and importance of functional structure include quick decision making as the members of the group are able to interconnect effortlessly with each other. Also, since the members already own same sets of skill and interests’ individuals in this type of structures can easily learn from each other.
3. Divisional Structure
The divisional structure, which is also called as product structure is an arrangement of a business that breakdowns the organization into separation which is self-concerned with. A division is self-oriented and includes groups of functionalities that execute to make a product. It plans to operate and enter like a distinct revenue or business center.
4. Matrix Structure
The roles and duties incline to be considerably more complex defined in the matrix structure. The matrix structure bonds employees by both function as well as the product. A matrix company over and over again exploits and develops groups of staffs to accomplish the task, so as to take advantage of the power and in order to hide the weaknesses, of reorganized and practical forms.
The Matrix Structure is obviously the best for us. What’s also obvious is that other organizations have done it. What’s disruptive about that? It’s important to look at our industry – this organizational structure is never used, particularity in the technology space. Usually, companies such as our are setup into distinct technology or niche-driven buckets. What this fails to do is acknowledge that what that is really doing is creating Knowledge Islands. Information doesn’t flow from bucket to bucket as easily as we might hope. Our clients are best service by companies which are nimble and where communication ties disciplines together, rather than arbitrary Org Chart-driven buckets. Execution of this strategy is definitely not a hands-off problem, however.
The hierarchical service provider mindset is brought on by very many things, many of them not inherently bad. However, it’s key to note that the biggest reason why this mindset is prevalent in our industry is perceived revenue growth. Our competitors are being bought up by PEs such as Silver Lake whose entire goal is to drive bottom line growth (arguably at the cost of long term growth). A core takeaway is that The Pylon Mindset requires a leap-of-faith that operating away from the Organizational Mindset will result in longer-term growth, stability and customer satisfaction.
Other reasons why the Matrix has failed in the past, within this industry, is that it’s very difficult to pull off given that there are two competing, yet completely correct, mindsets. The first mindset is the customer mindset. It’s proper and expected that everyone march to their needs. Their needs include a simple way to communicate because if there is complexity (inherent with Matrix, as far as the customer is concerned) then this will lead to frustration and miscommunication.
The competing mindset is that of the technical mind. In most successful technical organisations you’ll find groups of techs flocking together. The amount of inter-locking dependencies between any well-functioning group is staggering. Lunch rooms are often occupied for hours after the traditional lunch has been completed due to these separate groups getting together and picking apart large problems, evolving ideas together or just learning from each other. Organized chaos. This type of communication is essential to a well-formed tech team but can be harmful to a well-formed customer-focused team. This is why organizations which are weight-heavy on the sales side will often find great technical team attrition and vice versa. In order for us to be able to deliver the top 1% in each discipline it was not only essential that we learn how to work together, but that we simply acknowledge that the two actually exist in disparate disciplines. Not many have.
This leads us into how we are innovating to make this work.
While it is possible to find the 1%s engineers who can speak to our customers and partners with 1% communication skills, there is a small Venn diagram which represents the two. Doing the math we need to comb through thousands of people through applicants, our respective networks, our trusted industry peers to find there people. It’s just not scalable. It can be expensive in terms of time commitment, professional development and retention.
Communication: Client Operations
We also recognize that if we can’t create a super-army of technicians who can also speak with the eloquence and engagement as seasoned customer-facing. Making the esoteric simple is perhaps a quality that is harder to find than the most rigorous technical certification. If both these traits are rare then why should we challenge ourselves with the insurmountable business challenge of finding technically employees who are both industry leaders in skills/aptitude but communications? It’s a near-impossible Venn diagram to fill. Instead, our delivery teams are given incentives based on 1. client understanding of the issues and 2. ability to communicate technical jargon into business language. And speaking of those languages…
Engineers and Client-facing speak different languages and this need . Customers are often, by necessity, often aligned with timelines or other business actions that our technology actions are only a part of. Techs, on the other hand, don’t by nature think in timelines. They think in critical path. A firewall move is coming up. There are 100 things to do, but a engineer is going to hone in on the parts that define success of their particular piece of the puzzle.
Ever get on a phone call where engineers are discussing a project? You’ll find that more often than not the conversation gravitates towards singular issues rather than the overall project. Engineers have tremendous mind muscle memory. They are literal rather than interpretive. They’ve likely don’t this, or things very similar to it, a thousand times. Most will know right away what parts of the project are likely going to be high risk, time consuming or ill-defined. They think in Critical Path.
Businesses, on the other hand, are often more aligned with the GANTT chart rather than the BPMN chart. While I’ve yet to meet someone who loves talking about GANTT charts, but most admit that they are a necessary component of any large corporate project plan. Time-based decisions are at times the most effciient way of aligning large groups across even larger organization or even groups of disparate organizations.
Our biggest and strongest leaders are put in a position of client advocacy. While it may now sound trite that customer problems are everyone’s priority, let’s face it, supporting existing clients is the single most important thing that any service provider can and should do. Sound simple? Not so much in our experience. Many our our industry competitors are faced with demands for year over year growth that takes precedence over making their own client’s business more successful. It’s our belief that if we invest in our clients that they will in turn invest in us, and that isn’t something that you can necessarily set a quota. This is a critical acknowledgement that we simply couldn’t talk our way out of avoiding the transaction mindset, that our organizationally would need to be structurally aligned to specifically prevent it. This goes from how we create incentives for our business development teams to how we communicate inter-disciplinary to how we
Defining Communication Brokers
We take communication very seriously here. We also appreciate that the skills necessary to communicate outwards oftentimes are not the same ones that are used to communicate inwards. We also are almost universally those who love doing their jobs, so understandably it’s sometimes tough to look up from what we are doing only to learn that the world has changed since we last took a breath and stepped away from our monitoring.
Understanding this, Pylon has employed task-specific individuals who are wholly-responsible
Org Charts can be ineffective
Org charts in tech organizations are inherently broken. The strongest technology departments are those who cross “buckets”. The most successful bucketed IT groups I’ve ever seen are ones who sit at lunch together, go to the bar together and share ideas. “The Brainstorm” No technology is independent. By creating a Technology Roundtable coordinated by a highly-respected member of our team, with a militaristic approach to organization, will allow our techs to exhibit greatest creativity with a safety net of regular check points of all of us to take a breath, report status then get back to creating world-class technology. By offloading immediate/direct response as well as maintaining the ubiquitous task list from our engineers to Communication Brokers, we are simple acknowledging a reality that many organizations simply refuse to amidst – great engineers do their best in unstructured environments that are protected on the outsides by those who have structural core competency.
We do not have an org chart at Pylon. We have a collection of inter-dependent RACI charts where each Service Leader is held wholly-accountable for their Organizational Unit (for those technically-inclined readind this, we organize our structure similar to DNS TLD -> down has been organized, why reinvent the wheel on something that works?)