Ego driven architecture, confusing needs with solutions
Your executives, especially the new ones, are often full of enthusiasm and ‘thought leadership’. It is always great to have leaders with…
Your executives are often full of enthusiasm and looking to make a difference. It is great to have leaders with vision, especially when the vision ties to interesting opportunities to support an organization or a set of customers. With all of that said, it is important for new executives to find their feet to get a view of the landscape before jumping head first and deciding on solutions that may have worked in a prior organization. Learning what didn’t work before is often just as useful as finding out what has been working to understand where the challenges and constraints exist. Going to the Gemba and talking to people is a wonderful way to find out the stories of success and failure if people feel comfortable, rather than intimidated. Depending on the organizations existing cultural context and emotional scar tissue they may still be recovering from the previous executive.
New executives can inadvertently attract people like moths to a flame, people love to prove their worth, sometimes out of pride but often out of fear and insecurity. A seasoned executive will know these tactics and not and not take things at face value, they will get an understanding of the environment and challenges people face.
The executives are often presented with the best and brightest, as an offering to show just how great the department is. This can be dangerous if the executive doesn’t delve deeper into the organizations capabilities. Especially if they are banking on such skills to take the organization in a direction that relies on modern skills that many people don’t have (take cloud as a common enough example).
Given the focus on engineering culture, a new executive is likely to experience an abundance of both technical and organizational debt to contend. Keeping a broad view initially can help keep perspective.
If executives are presented with the best and the brightest, lookout for the dragon slayers in search of dragons — these are the super stars but may have gotten to that status at the expense of others.
The expert engineers who are so good don’t need to write tests! These essential people are often the bottlenecks of the organization (the Herbie’s from the Goal, the Brent’s from the Phoenix, and Unicorn Projects).
Organizational capability
Architecture patterns and paradigms are important for simplifying and solving problems at scale. If the paradigms are not understood by the average population, and the organization hasn't had time to experiment, learn and work on that technology, the organization is at major risk of setting themselves up for failure.
A common example if the introduction of a functional language like Scala because it is used often in big data systems, where only a small handful of people are willing to learn themselves and the people bought in to be overnight miracle cures don’t know the organization or the culture to which they’ve just landed.
Scala may be a great language, it isn’t popular and certainly not ubiquitous. Getting all your people to learn Scala or hiring a bunch of expensive experts isn’t necessarily going to solve your problems overnight. Unless the organization is investing in building knowledge and capability for the new language, it is going to be a hell getting people productive.
Expensive experts to the rescue
The Scala experts are also likely to be significantly more expensive than the existing staff, this is going to ruffle some feathers and news will get out. This makes learning from these experts challenging in two ways, the existing staff are afraid of them as they see them as a threat and the newly employed experts are brought in for their expertise, now they want to show just how good they really are.
That often means working on a pet project to show how the technology works, but no one else in the organization can keep up. What should have happened, is the pet project should be mentored by the expert to teach and support a bunch of existing people on how they can use the technology.
You risk alienating your ‘average engineer’ with fancy new stuff, that they don’t have time to learn or they aren’t allowed to learn, because they are stuck working on the monolith app they are still trying to decompose and move to the cloud.
Legacy skills don’t solve modern problems
There’s a fine line between a great idea and genuinely identifying common needs across multiple groups of users / stakeholders or even product and engineering groups.
Identifying the ‘problem’ is usually perceived as visionary, especially when the vision allows the executive to position it into a ‘well formed’ solution that solves a widespread problem across the organization.
The latest paradigm to do so is the data mesh (a brilliant concept but still immature in the industry). This isn’t a productized approach and still emerging — it’s very much in the self-assemble stage so only those with the technical skills and curiosity can truly take advantage of it. All the ducks need to be lined up: code, delivery, and operations.
If you are still delivering on a quarterly basis with month long UAT (User Acceptance Testing) / QA testing cycles, you will not be able to take advantage of this.
These patterns expose legacy complexity and amplify a lack of capability. Unless you have your ducks in a row you are going to struggle. This is hard to do and takes years to master.
When you are establishing a new capability or architectural paradigm, half the battle is often getting stakeholder buy in. The other half is, can your people build ‘the thing’. If they can’t, then how, where and who can they learn from?
Unless you are willing to invest in your people, they won’t have time to learn and experiment in a safe to fail way. Give people time to learn and figure out the implications for the organization. Selling vision is one thing, but selling commitment is another thing entirely.
Learning offerings as a band-aid
Fear not dear ‘engineers’, you have a subscription to Coursera, Pluralsight, Public Cloud Certification library, Udemy (etc…). The organization takes learning very seriously, they spend money on such things!
If the organization is sufficiently contemporary, they even have an approach to help gamify people’s learning journeys (the cognitive equivalent to factory farming).
All of this sounds great, how can this not produce a swathe of cloud native engineers that can propel the organization into the 21st century?
Big technology budgets don’t make you a tech organization
The company is now taking engineering seriously — despite having continually resisted being referred to as a technology company — they are a company who does X (insert industry) and uses technology, but not a technology company.
All of this, whilst spending hundreds of millions or more (each year) on technology (often dwarfing many start-ups and medium to large ‘technology companies’ budgets).
Isn’t Uber a transportation company, Amazon a delivery service? I often see many pointless arguments about this topic, the labels don’t matter. What matters is how you embrace and use technology to solve problems and create opportunities in a way that allows for learning and feedback loops.
The issue isn’t the amount of money spent, it’s the what you do with it that matters most! Typically, it’s as a lack of prioritization, alignment between groups and focus. The organization hires more people to do more work, rather than de-prioritizing / de-investing in initiatives that don’t deliver any value.
All of this, because the organization doesn’t understand product management, and the business treats the IT organization as a vendor who does their bidding.
This is the worst kind of command and control, no trust, autonomy, or empowerment. The only thing in abundance is grand expectations and extreme pressure.
The IT department is held hostage (financially speaking), by the business to deliver something that offers little to no value.
Antipattern: The death march comes to mind
Here are the demands, here is the money, why isn’t the IT department delivering? The business doesn’t trust the IT department, that much is clear.
The technology changes (or accumulates), people are spread too far and now capable of even fewer things so start to freak out. People are working on too many ‘strategic’ priorities, proof of concepts to appease egos on things that could be done differently. All to make the executives look good with their vision. The executives take the effort as a win and move onto the next company where the cycle continues.
This is the modern equivalent of leaving a bathroom (restroom) with toilet paper stuck to your shoe and no one telling you it’s there. OK that’s a stretch, but it does leave a trail!