Creating an API to a team – a system developer’s take at company communication

Hey Kalle!

Been a while since I posted here (we should really publish the podcast too btw, need to speak to Jeff about that).

As you know, I’m now working for a really big company (about 18000 employees) and as such I’m but a grain of sand on a large beach of company culture.

However, the part of the company I’m working for used to be a smaller company that was bought and incorporated into the bigger company in a single-brand strategy (i.e. the old company’s name is not used any more etc). It is still a fairly self-contained branch with stable customer relations that was established before the merger and has the application management of a product that has been around since the early 90’s.

So our department is both a part of the rest of the organization, as well as our own ship, and this reflects in our methodology. In some parts we are running some SCRUM, we are looking at Kanban for some of our stuff and we also have a lot of waterfall in a lot of parts as well as some ITIL-inspired roles for application management. On top of this, we also have a delivery excellence process that is instituted by the company as a whole. In short, it’s all a bit of a mixed sallad (one that has both tomatoes and tuna as well as steak and kumquats – yummy!) with each bite tasting slightly different (not very agile-sashimi at all).

Here is our dilemma:

We need to work out a way of working that works for our independent unit given our customers, our products and our staff – while at the same time working together with the large organization we are also a part of in a way that they can understand and appreciate.

The good news is that I feel that it would be accepted to run any kind of methodology internally in our branch as long as it meshed well with the rest of the company and it yielded great results (i.e. we were efficient and very profitable), so it is a great situation for improving our process. However, the key here is how to work together with everyone else in the company in a manner that is efficient for them and for us.

So I thought:

Why not approach this as a system developer and picture our part of the company as a module in a large piece of software?

If we could just provide an API to the exterior world (the rest of the company and our customers) with metrics and ways of communication that is useful and efficient for them, we could pretty much run any kind of internal process as long as it was CPU-efficient (i.e. cost-effective).

This is obviously the opposite of transparency, and it would be interesting to hear your thoughts on the subject. Maybe transparency should be a topic for a future podcast, sometimes I feel that people just don’t want to know and too much transparency might just create confusion as to what they are looking at.

I’ll keep you posted on how this develops – I think my next step will be to map our “interface” in a way similar to how I would map the interface of a module and see if that yields any interesting results.

Thanks for reading all of this (I think I just scored 0/3 on my own scale…), let’s talk soon.

Take care,

Mattias

 

Advertisements

2 thoughts on “Creating an API to a team – a system developer’s take at company communication

  1. I disagree, I think this is a very interesting post, so it meets the “good” criteria…

    I think this is a very interesting idea, and I would live to see how it develops.

    One thing I would say, is I think you need to be careful of the maintenance cost of this API… Let me explain…
    Say you decide to run Scrum inside the department. Then the PO role is perfect to function as this API, that’s part of the idea of the role… But, if the PO spends all their time creating complex reports that no one reads, then they won’t have that time to spend with the team… Hence, high maintenance for little benefit… Does tat make sense?

    I have some more ideas, but I am on the tram, so, I will save them for later.

  2. It always makes perfect sense to be vary about the maintenance cost of administration – it’s one of the biggest sources of waste in software development IMHO.

    Part of the idea behind thinking about communication and interaction as an API is that with an API, you usually only need to pass a well defined amount of data to a function and that data is critical for the function to run.

    Hence, waste tends to be very limited in APIs so wouldn’t it be great if the same logic could be applied to communicating with stakeholders for instance (only give what they actually use)?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s