Writing for my future self: You are the man now, dog.
A tongue-in-cheek brain dump on companies, processes, leadership and IT operations. Probably this is a fruit of biased learning and bad experiences fading in my memory.
On vendors, architecture and innovation
(The part where I say that system architecture is not planned, it emerges)
Companies have being under pressure as their customers complains about slowness, billing mistakes, bad service and outages straight on social media. Churn goes up, sales goes down. Look for any company profile at Twitter or Facebook and you will see that any glitch cost more than the cost of customer acquisition in the marketing budget would be able to pay.
At these bad times, high management start questioning why things went wrong, the high cost and timespan to implement new features or recover from outages and end up surprised on how architecture got this or that way. You see directors and president standing behind the tech folks figuring out how to bring back services or meetings with conflicting powerpoint slides trying to explain whom should be blamed.
IT executives setup Tiger Teams and War Rooms to work out a solution, after finding out that their vendor's bills about the double of what they paid before for a fix. Meanwhile someone has to manually tend to the system operation.
The many "how did it ended this way" questions indicated that the current architecture either was not planned or drifted from what was thought to be.
I remember when a Brazilian Company moved their ops team working hours up to match television ads, because the site would crash due to the load and they could not risk being out too long while someone was in transit going home. Another huge top 10 retailer company used to brag about IT team size and how they never had an outage that they were responsible for — their service providers took the fall for all of them.
Manual ops work to guarantee SLA never scales, is both a sign of lack of technical north and a reflex of the current culture: throw people (money) at a problem until the noise goes down. Also in certain corporate cultures, CIOs are more concerned with their value face the executive organization (i.e. bonus and succession) which makes technical and engineering work be seem as a commodity. I recall the mantra "Nobody Ever Got Fired For Buying {IBM, Microsoft}".
While finding the true way ™, folks high up, the higher executives , eventually realize that they cannot (or should not) buy their way out of their problems. Buying off the shelf support and solutions, moving people around, throwing everything away and ignoring current customers to grow market share tires the organization and people start moving away, changing jobs.
Taking for instance Cloud Computing there is a lot to say about how many companies bought hardware and installed Openstack/Cloudstack as their "Cloud" and saw it wither away unused while the hardware gets obsolete (and gets converted to be Container Orchestration — to die alone and unused). They figure out that "Amazon build their cloud selling spare capacity" is an investor pitch.
Companies investing on culture change and innovation teams are essentially incorporating new ways to execute proven technology. Innovation departments and teams usually navigate the day convincing other teams about being efficient and to look at their projects as products, not designing a new language or framework. Innovation in this context is to copy what other smarter companies already found, try it, measure success and failure, iterate again.
On processes and their bodycount
(The part where I say that Culture is always there, good or bad)
One of the most common (but necessary) iteration companies take is getting something like SCRUM and interpret roles as positions. People are moved into these new positions with the “manager” title along the way, without teams, budget and commitments towards the main company goal. Make a mental note if people that you didn’t knew the job in the company become “product owners”.
It also happens with ITIL and its “change managers” or “incident managers”. Every time a new process comes in, you gotta have people to take care of it and the process becomes what keep their jobs.
The current fads are "Design Thinking": teams and cross companies meetings to collectively chalk up new ideas in a brainstorm setting and OKR: quarterly or less the company evaluates, and sometimes mistakenly changes, what seems to be promoted backlog items. In both cases the original ideas and success cases probably fired the people that became instructors selling their version of these processes due to lack of execution performance.
It is a necessary learning phase as with any new technology: you gotta get hurt to learn what work and what won't work for you. This is the same to companies that can't afford to move quickly.
Another common strategy is to start product oriented teams hoping for full rewrites or a new cash cow that end up preventing the current team to work in the elephant in the room. Meanwhile customers get lost in the middle of it. Owning up to what is and what should be part of leadership and part of culture. This is akin to the Tiger Teams and War Rooms.
There are places and value to these methodologies but we fail short when adopting them. At the time of their inception they were trying to fix the same issues we discuss all the time and breed from experience. But sold out as an IT product they depend too much on people and culture, not the other way.
On leadership and management
(The part where I say leadership SHOULD emerge. For real.)
At feedback meetings in transition times I often heard the “I want to go for management career because I don’t think I can be as technical as person X” line from people that were struggling long time in the same company and wanted change.
The frustration lies in that one will never get to manage smart people without investing time on improving their own skills. This combination happens but leads to people leaving companies, no quality and low engagement of technical team. Telling people what to do is different from leading. And just as architecture, leadership emerge from the team.
Don’t think that tech folks don’t have a clear view of what is to be a manager and what they expect from their managers. I had my share of feedbacks that were precise to the point of recommending me tools and resources to improve myself as a manager. Coming from the most technical guys ever, not from my bosses. I also saw potential leaders leaving because of culture and lack of space to develop.
Uncompromising leadership
(The part were I say you should think big)
This research at Harvard Business Review explores the mix between energy and uncompromising leaders at CEO level. To all levels, from business needs to personal needs, the commitment and energy have to be full on.
One of the best advices I got from someone I consider a mentor is to think like a CEO, as if whatever I am working on is my company. In any scale, even for the humblest of the jobs. This might get hard, specially when the bullshit is strong, but the focus pays off.
(Books as The Hard Things about Hard Things by Ben Horowitz are great to understand how CEOs went by on what he calls "War times", taking decisions that challenged what they believed and the market. I published a list of books about leadership that you might be interested.)
