Every Constraint is an Opportunity

When looking to transform a traditional organization, one will inevitably find oneself surrounded by countless constraints that have been shaped over time and occasionally even became encoded in legal frameworks such as labor agreements. Although they are bound to be frustrating, with a little creativity constraints can become an unlikely source of opportunity to start changing an organization. Here some examples from my hard-earned experience.

Bimodal Transformation

As I indicated in The Software Architect Elevator, I am not a big fan of the so-called “bimodal IT”, also called two-speed architecture, where some parts of the organization or system landscape move fast while others move slowly. Interestingly, teams actively engaging in a transformation will find themselves in a different type of two-speed reality: they are looking to speed up software delivery, but will depend on existing, slow processes. They won’t be able to first transform every single surrounding activity–it’d be death by a thousand paper cuts.

So, they need to accept that getting things done will take longer and is typically more cumbersome than they would expect. This can be hugely frustrating, but there’s a silver lining: you can make at least some of the limitations work to your advantage.

Intransparency

Most large organizations aren’t know for their transparency. This was one of my biggest surprises when joining from a Silicon Valley company that uses a single source code repository to one that considers information an asset that’s closely guarded to protect one’s own power base instead of sharing it with other teams. “We’re all working for the same company” was a common utterance in those situations, but it did little to change them.

Lack of transparency can be particularly inhibiting during a transformation because it makes determining the current state rather difficult. And after all, any successful transformation needs a valid and relevant starting point to plot a viable strategy. Taken in the right dosage and with good spirits, lack of transparency can also work for your advantage, though.

When building my team of architects, I hired a talented team with a significant amount of hands-on skill. Those skills were instrumental in building the organization’s first viable cloud platform. Not a few people were surprised that a team of architects, who were expected to mainly draw diagrams, implemented—and operated—a production-ready on-premises cloud platform.

Intransparency, used wisely, affords you certain freedoms, for example to choose the folks you are hiring or the things that you work on. Naturally, this should be used in good faith to actually deliver value to the organization in the long run. In my example, having an architecture team with delivery capability turned out to be instrumental to solving one of the organization’s major problems: slow software delivery.

Long Planning Cycles

Intransparency comes in an additional flavor: time-bound intransparency. Most folks looking to transform an organization will be frustrated by long planning and budgeting cycles. I have criticized them for numerous reasons, ranging from sandbagging or pretending predictability to a grotesque lying contest that rewards those who promise the most, knowing well that the inevitable failure to deliver will be ignored 12 months later.

But such long cycles can also work to your advantage. Not that you should engage in any lying contest, but long cycles give you the opportunity to work on things for up to 12 months before you have to explain what you did. If you are building internal platforms or products, as was the case in my team, this can be sufficient time to deliver and even sign up internal customers, converting your risky maneuver into a success story. And it’s hard to argue against success, especially when everyone is stunned how your team could deliver anything in “only” 12 months.

Innovative Innovation Funds

Most organizations want their employees to be innovative–as long as it doesn’t take time from project work. After all, we have those much-advertised innovation programs where everyone submits ideas, out of which only very few get selected to become demo-ware.

Burying a slice of innovation funds inside your large overall budget often works better–the odds of someone finding out are slim, aside from “wow, how were you able to build this?”

Deep Hierarchy

Large, traditional organizations are designed around division of labor and tend to have many organizational levels. Executives’ calendars fill up months in advance and access to them is heavily guarded by many layers of middle management and staffers. If you do get to meet senior execs, it’s often in a steering committee where the executives’ main role is to establish their position by poking holes into any proposals, for added drama perhaps in the presence of your superiors.

This apparent inaccessibility of senior execs can also be a used to motivate architects or provide them with a token of appreciation. On my architecture team, authoring short technical papers was initially a rather unwelcome activity as we set a high bar for communicating complex technical topics to a broad audience without diluting the actual content. However, once those papers got attention from an executive audience, the architects realized that these documents afford them senior leadership exposure that they otherwise might have never achieved–a perfect example of riding the Architect Elevator.

A key motivator behind writing Tech Briefs, short documents that convey an aspect of our technology strategy, was the ability to reach senior executives like CIOs and COOs.

You can’t expect to burst through all those organizational layers without some effort. For example, my organization lacked a defined channel to distribute technical papers to senior executives. So I used my presence at a CIO/COO gathering to carry small booklets with our papers and hand them to any unsuspecting executive. Although this form of architectural canvassing required me to jump over my own shadow, I knew that it worked when someone approached me at the next meeting to tell me that they didn’t receive a booklet.

Connecting through levels can also benefit the folks higher up in the organizational penthouse.

During our architect qualification program, we rewarded architects with a final presentation to the CEO of the IT division, a seasoned executive overseeing several Billion Euros in IT spend. The CEO, finding herself with rare access to a room full of accomplished architects, quickly started to ask them detailed questions. It was a reward also for her.

Senior executives know fair well that much of the information they receive is filtered up through many layers and often tuned to individual preferences. So, direct access to the engine room–in a trusted setting with no intermediate managers–can be a major asset to them also.

Vast Organization

Many large organizations can be cumbersome to operate in. You may find yourself continually trying to boil the ocean or getting the runaround across a myriad of departments and approval instances. But being part of an expansive organization can also provide opportunity. For example, you may find support for your initiatives from unlikely places.

The original funding for our cloud platform initiative was provided by market management. Although marketing might appear far removed from IT and architecture, it has a keen interest in speeding up delivery to support campaigns and new product launches. That’s exactly what we were looking to deliver.

As much as a large organization can be challenging to change, it does allow you to cast a wider net for your initiatives. The business side might be more interested in agility and a faster pace than the IT department, which is often guided by utilization and task efficiency, which are known to drive up wait times (see “Who likes standing in line” in The Software Architect Elevator).

Reliance on External Developers

Occasionally, you can also benefit from organizations constraints by doing the opposite of a poor but established practice. Over-dependence on external staff is a common challenge in large and traditional IT organizations, once again driven by the desire to cut cost while ignoring the cost of delay and the cost of lost agility due to rigid multi-year contracts. Plus, as I have also pointed out before, outsourcing work also means outsourcing learning, which a very poor maneuver in a constantly changing world that requires new skill sets all the time.

Nevertheless, there’s a silver lining on that transformation cloud as well, and in my case it appeared quite unexpectedly. I built my architecture team exclusively with full-time staff, partly based on my conviction that transformation can only come from the inside out and partly due to my Silicon Valley experience that routinely shunned externals (“if they’re good, they should work for us”). We did engage specialist consultants on time-limited contracts, but primarily as teachers and coaches to boost our team members’ skills.

What seemed entirely natural to me was not all that common throughout the broader IT organization: headcount was hard to come by and if you got it, it was tough to attract candidates with the needed skill sets to fill it. So, most departments retained external help from a slew of staff augmentation firms that were more than happy to meet this need.

Building a team exclusively from full-time staff earned us much respect and goodwill from the works council leaders.

The benefit from going this route materialized in an unexpected corner: the works council. Being a part of most large organizations in Europe, and often prescribed by law, works councils are tasked with building a bridge between company leadership and employees. A common stereotype is that works councils are opposed to modernization because historically automation meant replacing manual labor and thus reducing the workforce. That’s why many folks predicted that as a former Silicon Valley engineer, where organized labor is largely unheard of, I would be on a pre-programmed collision course with the European works council.

Much has changed, though, since the introduction of the assembly line, especially in the services sector. The works council understands, perhaps better than anyone else, that acquiring new skills is the key to sustaining a commercial organization and its workforce. Seeing that I was tackling novel tasks exclusively with internal full-time staff earned us much recognition from the works council and led to a very positive working relationship.

Silos and Turf Wars

Intransparency and hierarchy often lead to silos—each organizational unit appears to be working for itself and against everyone else. Some leaders tacitly enjoy this situation because it prevents any one unit from becoming too powerful and “keeps everyone hungry” for attention, budget, and headcount. Such a setup is notoriously difficult for an architecture team that works by influencing across the organization: decisions are often made in private and facts alone are unlikely to sway them.

Rather than battle against a multi-headed hydra of organizational silos, a fellow architect found an ally in operations.

One architect was able to overcome this hurdle by engaging a part of the organization that’s traditionally been shut out from strategic discussions—operations. A transition to the cloud is a good opportunity to highlight changes in the operational model and shift the focus from functional silos to an operations-centric view that will concern all teams.

Volunteering

Organizational constraints can also determine which tasks employees are allowed to do or, more specifically, which tasks the company is allowed to ask them to perform—each employee is welcome to scrub their desks and windows, but most office workers can’t be asked to perform cleaning tasks. Similarly, in many organizations only operations staff were allowed to be scheduled for weekly on-call rotation that deals with production issues after hours. Once our team of architects decided to operate our own in-house platform, this became a challenge as the ops teams weren’t ready yet to take over the operations for the new and evolving platform.

Our labor contracts restricted architects from being assigned to on-call work, but it didn’t restrict them from volunteering for it. So, the whole team volunteered.

We found out, though, that employees can absolutely volunteer for on-call, and they even get paid for it (a good relationship with the works council was instrumental in receiving this tip). So, the value proposition to the team was simple: if your platform runs well, you’ll get free money. Soon, being on call became a rite of passage and a badge of honor for new team members.

Similarly, we couldn’t require participants of our architect training to present to the divisional CEO, the one who enjoyed having access to architects so much. The key motivation behind this restriction is well-intended: such a presentation could also backfire and put a person in a poor light in front of a powerful executive. This organizational lemon turned out to be lemonade for our training, though. Would participants believe in riding the Architect Elevator to the top and volunteer to present to a top executive? They all did.

YMMV

Bending rules is risky business, so be prudent when looking for similar “opportunities” in your workplace. The test I apply is as follows:

• Is the end result a positive outcome for a wide group of people and not just something to show for yourself and your team?
• Are you breaking any unwritten rules? Bending or tweaking official rules is often accepted in rigid organizations, but overstepping unwritten rules will cost you a lot of political capital.
• Make sure you’re dealing with internal rules and not regulatory, compliance, or legal aspects. The CEO resigning due to a scandal you caused isn’t the kind of change of change you were looking to bring.

So, the end doesn’t justify all means, but some creativity might be needed to untie the Gordian knot of organizational constraints. Or, as my friend and fellow architect put it, build a healthy translation layer between “what” the organization expects from your team and “how” you’re implementing it.