Go Challenge it!

Why are you here? What is your purpose and what do you want to achieve? If you’ve now started contemplating the meaning of life and your relative insignificance in the universe, that’s a topic for a different day. What I want to discuss is why you’re here and the value that you bring during the working day? If you continue reading perhaps you may find some enlightenment…

A good friend of mine recently introduced me to a visualisation of the alignment and autonomy chart. I know what you’re thinking How did I manage to oversee this part from Spotify’s engineering culture video. If you weren’t thinking that, it’s ok because this never happened then.

Alighment vs Autonomy

Now the question is where do you fit in this chart? In your current position, how do you correlate with the chart above?

Within any large company you will find many people have different ideas about how they should be working and where they fit in on this chart.

This often has little to do with the company you work for, and more to do with what you, the individual have experienced throughout your career, or in some cases, what you haven’t.

Agile has adopted itself into a wonderful process for companies to adapt and follow with pride and passion. Although the pure concept behind Agile is providing contextual consistency across your company, you could argue that this also extends to future companies you’ll be employed at. Now, before you start filling my inbox with emails about Agile and its importance — I am a big fan of Agile and always have been — I just want to make sure you’re not ‘doing’ Agile but being it.

Now jumping back into this ‘build a bridge’ concept shown on the picture above. What if I told you that this Bridge needed to be the very best that no one ever was. Yes my geekiness totally slipped out on that last sentence, in case you were wondering. If not, well then… moving on…

Let’s imagine this bridge is an existing piece of software,software that has been built by individual teams, focused on solving their particular task that fits their domain knowledge. The figure below will act as a representation of each component of the ‘bridge’.

Each component needs to broadcast data to every other component and make sure that all the transferred information is accurate, otherwise the bridge collapses. Well let’s just hope this bridge wasn’t a Production ‘bridge’ but a safe CIT environment.

Now how do you manage the interactions between events and components? Well, from a quick logical perspective you will notify all the other components of changes. But wait! All the other components are looked at by teams. Ahh ok, well let’s just notify the team/s, that consume the data from our component, that things have changed.

Sweet! So now I have notified the team/s that I am making a change. However, that’s not how it really works. Many times these communications are back and forth. Ok lets try this again.

So now it is Team A that is making a change and have notified Team B. Consequently, Team B have asked Team C to update their code. Furthermore, Team D needs to make changes because the changes Team A wants in Team B will also impact them and they need to transfer the correct data over to Team C.

I am getting confused in just writing this down. The bottom line is, instead of just going “Hey I need this done. Team XYZ can you do it?” The real question is — What is the impact of the entire system?

To make circumstances even harder, how do you perform these things to a 10+ year old legacy system that was designed to just go “Hey Team B can you do..? Yeah that’s easy because I only need to worry about you Team A”.

We need to build awareness into how our software systems interact with one another. Figuring out the pressure points not just from one specific domain but all of them. After all, our domain isn’t just our area, but the overall software and product that we deliver to the end consumer.

In the end you are contributing to the health of a system, delivering value at a higher scale. We want your mind, your input, your feedback, and all together, your aid in the solution to building that bridge. This is what a company should want from you. Now, is this fantasy thinking? Yes. Not to say there are companies out there that do this. So the question is what is your company like? What is your software like?

So, Go Challenge It! Ask all the questions, go experiment and if you fail, learn fast from these failures and embrace them. Ultimately seek purpose in what you do. Because, even if your feeling that you’re just banging away at the keys writing ‘x = calculated_value’, it should be delivering some value. As a Product Owner, focus on the bigger picture, not just from your area but of the company you’re in. Align your goals with that vision and if you don’t agree, Go Challenge It!