Making sense of the socio-technical mashup that is called the IT-world
In an attempt to make sense of this world in general, and the IT-world in particular, we all use shortcuts and stereotypes.
When joining a software consultancy company, I quickly learned that there is ‘business’ and ‘IT’, which are two very different things and shall not be intertwined. The ‘business’ is full of ‘non-technical’ people that have no clue about actual software development and need everything to be done yesterday, whereas ‘IT’ is full of ‘technical’ people who cannot resolve issues in a timely manner, talk a whole different language and is way too expensive as a department.
Pretty inconvenient, as technology is the enabler of significant business change and the relationship between the business and IT is critical to the success of the organization.
Technical versus non-technical — Is it really that black and white? ¯\_(ツ)_/¯
I’ve met and worked with brilliant ‘technical’ AND ‘non-technical’ individuals that have both excellent technical skills (and coding skills,obviously) and have amazing social skills (plus — absolutely hilarious). Being either ‘technical’ or ‘non-technical’ is not really an option anymore, I think.
Sure, technical skills are crucial, but how you think is inseparable from those skills.
Asking the right questions, connecting with end users and figuring out what they want, knowing which problem you are actually solving and not losing sight of that fundamental part. This will help you put your excellent skills to good use and staying on track to reach the defined outcome.
While working with brilliant colleagues, I am learning a lot by listening. And asking questions. I’m pretty sure my ‘non-technical questions’ surprised a few of them. I remember one of my colleagues saying, after discussing a project they did for a large bank, “Actually, yes, their technical issues might be a consequence of their organizational issues.”
And then it hit me. It’s not about being technical or non-technical. You have to speak both languages.
So, where does that leave me? I’ve always considered myself a ‘non-technical’ person, so this ‘new’ information made me rethink that. That’s what happens when you move away from those comforting stereotypes: you start asking questions.
What does ‘technical’ actual mean to me? What skills or tasks do I consider ‘technical’? Am I doing these kinds of tasks? When would I call myself ‘technical’ — would I ever?
You see — I’m heading towards an existential crisis here.
I also got convinced that ‘communication’ is not that different from coding. As Andrea Goulet puts it brilliantly: “Communication — the artifacts of your ideas”. And that is pretty similar to coding. Both are skills, and both can be learned, improved and mastered.
<Confession> It scared the hell out of me when I realized I probably had to put that into practice and thus start learning more about API’s, bugs, open source, security by design, ISO/IEC 25010 standards and so much more. And — oh boy — work on my actual coding skills. Ok, my coding skills are pretty basic compared to those of my radiant colleagues, but I am convinced it’s a skill that is not that different from any other skill. It just takes dedication, asking for help, perseverance and handling frustration gracefully (working on that…).
My conclusion: this ‘IT-world’ is a perfect socio-technical mashup that forces you to get out of your comfort zone if you want to make sense of it. And that is pretty exciting.
Building Maintainable Software Architecture
Luckily, I have some brilliant colleagues who get this, and understand this interplay between technical and social. And so, it came to pass Pepijn van de Kamp and I will give a talk at the O’Reilly Software Architecture Conference about how to how to keep your systems maintainable, while leveraging both technical and social factors.
We believe that the culmination and success of technical choices is strongly determined by their social context. In this talk, we will discuss the following:
- How to address the major communication challenges around combining effective measurement and software architecture into a cohesive working system.
- How to make architectural decisions within a team-based environment.
- How to measure, interpret, and act on the actual characteristics of the implemented architecture.
- How to balance technical and social skills to design and implement the best software architecture for your organization.
We discussed a ton of projects and yes, we’ve heard and seen it all. From “I’m the architect, I’m not responsible for the actual implementation” to “We’ll deal with security later”. All this experience and research resulted in a couple of best practices that will help building maintainable software architecture, while leveraging both technical and social success factors.
Obviously, we cannot reveal everything yet — we do want all of you to come hear our talk in October of course. However, being the passionate, caring nerds that we are (pardon me for using stereotypes here), we do want to share some insights that can get you going even before October.
Evolve — Don’t dogmatically hold on to choices that are not working out the way you planned. Dare to be agile and reflect on your choices, and adjust requirements in order to prevent your systems from becoming too complex. Test-driven architecture is key here.
Measure — Make your results and outcomes measurable. Objective data can increase value congruence within and outside the team, and strengthen persuasiveness when adjustments are needed.
Educate — Empower your team; invest in skills and talent. There’s a reason CIO’s say that bridging the skill gap is still one of their top priorities. Happy employees are more productive — and that is not just about training them. Feeling part of something bigger, being involved and on the same page drives this too.
So much to talk about, so much to discuss.
And we’re just getting started.
Evelyn van Kelle 