CTO vs. CIO: How many tech “corners” do you really need?

Have you ever thought about what “departments” really means? The word “department” starts with another word: “depart”. Stop, think, continue reading.

Technical Chief Officer’s Dilemma: Departments and “Agency”

Are you in a situation where you honestly need people who purposely segregate themselves into groups that start with a departure from each other, rather than a congregation of ideas, people, and purpose?

If you are responsible for a technology “department”, you are responsible for a “failure”. #explain

Consider a geometric line, the most efficient way to connect one point to another. If only people were that easy. Get enough of them together and you start having to group them into manageable departments. IT, Development, Operations, Finance, Sales, Marketing, Management. Business lines to make things easy, right?

Departments are “Depart”-ments

Wrong. Department f*ck screw things up. Drawing lines isn’t a good thing unless if it’s to connect people with each other. They distract people from the simple truth that businesses who succeed are filled with people who instinctually understand that they are all on the same path, together.

Consider a geometric shape, the triangle. A line plus one point, an important point, an entire dimension. What good does it do to add another point beyond that? A square? Another department? Finance? HR? Marketing? Why?

I’m minimizing, I know wonderful, necessary in finance and human resource. Apologies to them, it’s just to make a point.

Only the Right Lines Need to Be Drawn

People who work with very large organizations know this inside out. Enterprises, government agencies, financial institutions. Corporations. The more lines there are, the more overhead and lack of progress there is. Sure, there’s stability, structure, fortitude; but the further we get away from connecting point A to point B in a straight line, the less efficient we are.

Truly effective business starts with figuring out how to define things with the least number of lines. Communication, organization, collaboration all benefit from simplifying how many lines are drawn. #karma

More reading:

DevOps, Burnout, and the Search for the Holy Grail

I’ll be speaking at APIdays Melbourne about the technological equivalent of the holy grail, continuous deployment, and why maybe we should re-think certain dynamics coming from the push to “do DevOps”, which like many good ideas is marred by poor implementations and shotty management.

2/2 Update: Things come up, shit happens, and I am incredibly bummed not to be able to be part of the crew at APIdays Melbourne this time around. However, priorities are priorities, and I’m not going to regret missing the 18 hour flight there and back.

Grateful for the opportunity, hope this doesn’t burn bridges, but sufficed to say I’ll be there in spirit. Thinking of shipping a TelePresence bot and asking @switzerly to set it up for me. 🙂

I’ll still be looking to find a more local forum for this talk, hopefully at APIstrat.

Of course, I’ll be showing how to inject comprehensive testing into a pipeline of API design, build, deployment, and monitoring tools, but I’m a people person more than anything else, so germane to my presentation will be the topic of how “doing DevOps” affects us at a personal level too.

Humans are tool builders, not the other way around.

Why are we talking about DevOps?

I love the ideas coming from that space. Any time people work closer, tighter, better together, I’m down. But revenue doesn’t care about you or me, and the impetus behind most practical implementations of continuous delivery are indeed revenue, over-trumped expectations from the business on IT as their main blocker rather than proper decision making.

Often the result of forcing unprepared teams to “do DevOps”: #burnout

In November at APIstrat Austin I stood up and said that teams are more important to get right than the software they produce, though they’re both very important. People produce software. If the people are buggy (i.e. bad team dynamics), you will see that in their product.

At the company kick-off last week, I sat in the front row as a panel of exec-level customers validated that the immense pressure to release software faster than ever before is real, is connected directly to revenue (loss not just gain), and is incredibly challenging due to people problems more than just technological ones.

Business leaders looking to implement new paradigms on technical teams will also find it surprisingly hard to “do DevOps” if there are cultural or personal issues laying around like land mines. From my last job, I know this first-hand.

I’m a Developer, but My Cape is at the Dry Cleaners

15 years professionally and counting. Right now, I see that code written in an IDE isn’t the only important factor to bringing excellent products to market. Code of conduct in teams, the responsibilities a business has to its employees, and how we treat each other along the way to building world-class software are just as important for a sustainable business model

Sorry startups who “do DevOps” because it’s cool, call me in 6 months if you still exist and want to talk for real. I would *love* that as a podcast interview episode.

For now, like an underwhelming version of Clark Kent, I temporarily hang up my [developer] superhero cape, put on thick-rimmed glasses, and work a job in the big metropolis during the day. I am educating myself and rounding out my ideas on what it really takes to be in cutting edge technology. I surround myself with very driven, passionate, fun, and smart people to get better…at everything I can.

I am expanding my understanding of how to bring about great technology beyond what an IDE can provide me. I work with people, code, and businesses.

More reading: