What is my Normal Role/Job?

 

What I normally do for a living is glue things together for corporations; we can split that up into historical and what I do currently.

Currently, I glue or fix anything that is not working well together so that you can deliver on promises to the business.

This is normally given a title of: “Integration Architect”, “Integration Project Manager”, or the generic role of “Technical Project Manager”

As Integration Architect, that is, quite frankly, more often than not people. Computers nowadays glue themselves together rather easily, there is nice concrete standards, huge amounts of built in systems and vendors that handle all of the complexities and oddities that used to take so much time in the past. Most of my main job now is trying to get the human components of a corporation to mesh well but seen from a technical point of view.

Everybody has very strong opinions about whose integration should come first, who standards should be adhered to, Why we should do it one way rather than another. I help companies resolve these issues, sometimes it is just sitting down with technical standards and helping to judge which works best. Sometimes it is using decade’s worth of experience to give examples of what is the best way to integrate various things together. Sometimes it is just getting two sets of humans to talk better together because not all problems are technical, stuff like budgets, politics and personal pride can all ruin what would seem like a simple technical integration.

And that breadth is the key to the role, Managers often think only in terms of delivery and budgets, PM’s / scrum masters only in terms of dates and sprints, Tech’s only in terms of functionality and the support and security teams only in terms of SLA’s and standards, this is because that is what they are judged on. My role is to think of all of them at once, see each persons point of view so you can break down the blocks and get a delivery sorted they can all feel proud of.

A varied career history has given me the skills to do that, originally I was a purely technical person. I started in Help Desk, then desktop support, then server support. and finally speciality support 1. At that level, a lot of the tasks I did revolved around trying to get very different systems to work together and this was back in the day where there wasn’t anything like the normal standards we see now, every company was trying to force their own standards on the rest of the world in order to make a lot of money.

Solving such issues sooner or later always seemed to involve writing some code. I ended up writing more and more integrations code and sooner than I realised I was a full time coder. I then worked my way up through normal programmer to specialist programmer, to integration architect.

With this expanded view point it became obvious that most of the problems people were having were at a managerial or people level because most managers didn’t appreciate the technical problems involved in integration, while most coders don’t appreciate the pressure that managers are under to provide simple visibility to the business, and neither side is good at explaining this conflict. At this point I as an individual got very very lucky, I bumped into people who were experts in both communication and seeing things from the other side of the fence, as such I ended up presenting at conferences as well as learning a huge extra skill set in empathy which has made an unbelievable difference in how I see problems and their solutions.

And that’s where I currently reside, I try and make integrations work, regardless of their solutions. It might be pure code, 2 or It might be just getting two argumentative individuals in a room. The core of it is I take ownership, I take responsibility, and I take the blame when needed, but without the desire to build an empire.

 

  1. Email and workflow was my thing[]
  2. something I still have a lifetime love in writing,[]