Teams and Operations

First things first. I want to apologise once again for the prolonged break. I appreciate everyone that subscribes to this newsletter and value the time you spend reading and responding to each release.

Preamble

As a Solution Architect (SA), you hardly ever get to do any lifting or shifting by yourself. Rather, you inform, persuade and inspire various stakeholders. A compromise here, an extension there, a stretch target here, a pattern or a standard somewhere else. Your dependencies are a complex web that spreads out across the enterprise. But among all these folks that you rely on in a software focussed organisation, one group stands out; the development teams/squads/units or whatever they are referred to in your organisation. They are the boots on the ground, the equivalent of foot soldiers in an army. They take, hold and secure positions, and without them, architecture and business have little impact. I should also add DevOps, or DevSecOps as they are sometimes called. - the term keeps changing ??. While it is not often that you get to pick teams as an SA, if you do, or have influence in that scope, here are some things to bear in mind.

Size

There would not be a team without personnel, right. But what is a good size? An ideal number is between 4 and 7, much more and you get too much chatter, and misalignment with Agile. It is common for each team to require competencies in frontend, backend and testing, at least. One could add a BA, Scrum Master and DevSecOps, although these typically serve multiple teams concurrently. This gives a minimum of 3 unique roles, but adjusting for relative load, there will be differential allocation; more of some roles and less of others. A signal downside of having too many members in the team is that the technical lead becomes overloaded with non-delivery commitments. Communicating, supporting and coordinating team members turns them into an admin, not a techie. As SA, do bear in mind that the team should be sufficient for delivering an "atomic" feature within a Sprint. That means, there should be no passengers, all hands are on oars.

Blend

Think of how football teams are constituted and learn a lesson. You need a variety of skills, yes, but you also need a variety of personalities. A team of superstars is not always as productive as a mixed bunch of above-average performers. Indeed, you should avoid creating or depending on superstars. Over dependence on one or a few persons can put them under undue strain, while at the same time fostering disillusionment and detachment in the overlooked team members. Don't shy away from the loud and opinionated, the "anti-social" introvert, the cynic, or the fantasist; they all bring something to the table, where properly managed. The only type to avoid is the conceited, even if they are very talented. The damage they do is far greater, and lasts longer, than the value they bring.

Location

Co-location is great, if/when you have that option, i.e. all the team in one office and on the same floor. Every displacement counts, even being in separate rooms or on different floors! If there is a door (virtual or physical) between team members, the dynamics change. I intend to write more on this topic in one of the last releases, to wit, "Lessons from the coalface". When teams are dispersed, over time, silos and cohorts can start to emerge. This can lead to a "we and them" mentality, where the separated groups lose sight of the project or enterprise, and instead, rally round each other. If co-location is not possible, you will need to work extra hard on communication. First, to keep everyone informed of what each location is doing, i.e. we need each other to get things done. Second, to highlight the great people and things in each location, i.e. the best of us and the best of what we do is everywhere/dispersed. You will also need more formalism in process and communication. Statuses should be updated frequently and distributed widely, to simulate a global village.

Culture

Homogeneity has its advantages, but it is not perfection. Heterogeneity has its disadvantages, but it has its benefits. Of the two, the latter is preferable. The greater the diversity of perspectives, the more likely that synergy will produce great/new things. Each culture perceives reality slightly differently than others. As an SA, you need to see the value that each perspective brings, and leverage them to help synthesise the best solutions. Language can be a barrier, but each language brings a different cultural outlook, and in tough times these perspectives can be the balancing forces that stop the house from caving in. I will not go into stereotypes here, but, over time, I have observed strengths that are prevalent in certain cultures. It is important to identify and leverage those beneficial values and the outlook that each person brings. This multiplicity of perspectives can be especially useful when dealing with edge-case problems that do not have clear-cut solutions.

Technical Leadership

Leadership at this level has got to be exemplary, i.e. of persons capable of teaching/helping others, and demonstrating values that advance the team. One mistake some organisations make is to appoint team leads based on how long they have been in the organisation. This does not work in the development team. The lead must be someone that others can look up to, technically speaking. It helps that they are also inspirational and not cynical, but the former could be socialised from the company/corporate culture. What I mean here is that the team lead should themselves be helped to expect great things from their colleagues. When there is support to the lead, and they pass the same on to team members, and we get to see some impressive output and amazing achievements by teams. An arrow with two or more heads is at best a toy or work of art, not a tool or a weapon. The same is true of development teams, it is vital to have clear leadership that goes in front and cuts a path for the rest to follow.

Governance (EA, Business, Regulatory) and Security

Let’s flip the ancient and antiquated view of governance on its head, because that carry-over continues to do damage in enterprises where it has not been expunged. We all collaborate to further the interests of our organisation/enterprise. I see governance as more about who is responsible (what & when), than who is in charge/control. When you cannot commit to Git because you haven't got a valid JIRA ticket, that is governance. But Git is not in charge, it does not control or direct you, all it does is to ensure that certain quality gates are respected. Of course, you could have done the right thing in the first place, and the intervention would not have occurred. Advance this to the human-to-human context, and the equivalent would be the "Accountable" in the RACI matrix. When your code is peer-reviewed against your agreed Definition-of-Done (DoD), that is governance, but your peer is not in charge/control; they are responsible. If everyone sees governance in this light, it will not involve rank-pulling, neither will it become adversarial. The SA is positioned at the crossroads of the enterprise, you should take the lead in changing attitudes and mindsets in all teams you interact with, even if they were not chosen by you. Governance is a necessity that ensures we are on target, lead to evolve a culture where self-governance predominates. What you do, day by day, can help to nurture such a culture.

Day to Day

Having done all to choose or evolve the optimal team, there are some things that help things to tick along nicely in day-to-day operations. In a previous release, I mentioned the Six Sigma SIPOC tool. It is very useful for analysing relationship between teams in a value chain. Bear that in mind. Your team is part of a production system. The whole system must create valuable output consistently. In order to survive and thrive, the organisation/enterprise is only as strong as the weakest link. SIPOC helps to understand that you will need input from others in the system. You will add value to those inputs by your internal processes, and then generate higher quality outputs for some others to consume/use. To do this consistently and to a high quality, there are some tools and techniques that you will find useful, especially as an SA. If they are in place, hone them, if they are missing, introduce them.

• Principles: sounds philosophical but is very useful; essentially what are your ideals
• Standards: rules and directives already settled for the industry, organisation, or role
• Best Practices: things that have been learned and known to work best in your context
• Tools: technologies that improve productivity, efficiency, accuracy, etc. especially AI
• Patterns: reusable logic that addresses a recurring need/problem
• Templates: similar to patterns but created physically as a document or artefact
• Libraries: more developed than the template, this is a working solution written by an authority
• Frameworks: a composite of the last three, this is a more encompassing solution

The idea is to identify your "north star" and to continually evolve towards it as efficiently as possible, avoiding a reinvention of the wheel, and making tomorrow easier & better than today.

Security

Having done everything else, stay safe!

Online rogue actors are the greatest threats organisations face today, because almost everything is digitalised and Cloud based. Intelligent criminals do not always break down the door, sometimes, they simply piggyback on unsuspecting members of the household (social engineering). Champion a mindset that is security conscious. Communicate and implement security policies and practises in the way laptops are used, emails and documents are sent/shared, software is written, how meeting attendees are determined, access is granted to buildings and equipment, etc. The value of your corporation/company is linked with the security of its intellectual property and those USPs that differentiate you from the rabble. If your organisation/enterprise is involved with creating digital assets (information, artefacts, designs, software, etc), it is important that you build a fort (virtual) around them, and ensure that the troops are well-trained and alert. Both are important. No point building a castle and leaving the crown jewels in open view. You get the gist. To that end, a culture evolved is better than governance enforced.

That is all for now; see you all at the next release, and once again, apologies for the hiatus.

Adios; hasta luego!

????????

Intro | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Conclusion

#enterprise #ops #team #efficiency #effectiveness #ai #business #operations #architecutre #solution