Developing Relationships

When you hold a senior technical position within an organisation, whilst no skill set should trump your technical knowledge of your chosen discipline, it becomes increasingly important that your able to manage relationships with those around you.

The approach to this will vary based on the people in question, whether technical or non-technical or based on the direction of seniority.

Dealing with these issues may not be why you entered your chosen profession, but if you end up in a position where you work in complete isolation it suggests that your work has no consequences and this is also not a desirable situation to be in,

As with many skills these communication skills will be earned by trial and error with bumps along the way but mastery is none the less important.

Taking People With You

There are many aspects of software engineering that align themselves more to art than science, it is also possible for a question to have multiple correct answers.

All of this means when you engage with others in your technical community people may not see things your way immediately.

If the first presentation of your argument doesn't persuade your peers its important to take a step back. Views can often become entrenched if arguments are presented more forcibly. 

Instead it can often be more beneficial to allow others to pursue alternative solutions. This will either lead to your view point being proven correct or a genuinely better idea being demonstrated. The more often this plays out the more likely people will be persuaded to your way of thinking and understand your rationale.

There can be a difficult balancing act in this situation, on occasion when arguments relate to critical issues such as security it may be necessary to be firmer but it should always be preferred to take people with you rather than force them to agree with you.        

Not Everyone Cares About The Tech

You will often be required to engage in technical conversations with non-technical colleagues. Whilst in these situations it should be a goal to educate your colleagues in technical matters, it has to be acknowledged that this has limitations.

Issues around technical debt and architecture will always be problematic for people without a technical outlook, this means no matter how much they may want to, an understanding of the technical merit of addressing these issues may always be slightly out of reach.

Instead an alternative strategy is to focus on the consequences and make the impact of these issues more tangible.

This maybe errors reported by users, performance impacts limiting sales or completed user journeys or an increase in the cost of development of new features.

If you can't make people appreciate an issue on its technical merits present the impacts in terms of things that your colleagues will appreciate. This equates to not trying to make people understand a solution make them appreciate that there is a business related problem that needs solving.

Constantly Pragmatic

If I had to sing the virtues of any non-technical skill that a technical role should require it would be pragmatism.

If you work in a sufficiently large organisation you will interact with many different people across many different subjects. If you resolve to win every argument or discussion this presents your progress in delivering the things you really care about will be severely curtailed.

Identify the discussions that are core to what you are trying to achieve and as a consequence those that are less important and where you can bend a little.

These two lists are likely to vary over time, some discussions will need immediate resolution and some may represent more long time thinking where you have more time to persuade people of the merits of your approach.

You may find that issues that are lower down the priority order for you are higher for others and being prepared to bend with others views may be reciprocated when attention turns to something you feel is key.

This may not always be easy but learn to understand problems that do have multiple workable solutions even if your preference would have been to go in another direction and save you energy and credit for the situations where you feel only one solution is the right solution.

As you interact with others as part of your role it isn't enough to only have technical skills, you also have to have an understanding of human nature and how others will interact with you and with your wider team.

This will be frustrating and possibly time consuming but is an unavoidable consequence of people being people. Remember that others maybe thinking along very similar lines when it comes to their interactions with you, recognise your own biases and tendencies to be illogical.

On nearly every occasion everybody involved in a discussion will be aiming for the same outcome only the means to achieve it is a cause of disagreement, understand that this is often a journey and help people to arrive at the same destination as you even they take a different route.          

Technological Endeavour

Its has long been the case that any serious business enterprise is expected to have a digital presence in the form of websites and apps.

This has lead many different companies to become involved in software development activities but at what point to do you become a technology company.

Is it enough for digital channels to represent your primary connection with your users and customers or does the development of technology need to extend further towards the heart of your company's operation?

Deployment Opportunities

A great deal of insight can be garnered from your attitude to your production environment. While no self respecting company should play fast and loose with production up-time or service levels, technology companies are single minded in their determination to reduce barriers to deployment and pride themselves on the rate at which they can deliver change.

Non-technology companies see deployment to production as something to be feared and controlled.

This fear is generally driven by a lack of faith in their ability to be certain code is ready for production combined with an anxiety about the effectiveness of system monitoring to spot issues before users post-deployment.

True technology companies embrace automation as an answer to these questions and find themselves unable to work within the constraints of human process or manual road blocks.

Few companies can claim to be at the scale of a company like Amazon, but as an example of what can be achieved using this mindset in 2014 Amazon used Apollo, their internal deployment tool, to make a total of 50 million deployments to various development, testing and production environemnts (an average in excess one every second).

The Story of Apollo

Whilst this is an extreme example it demonstrates that is it impossible to achieve large scale technology deployment and still keep humans and human process part of the deployment chain.

Data, Data, Data

Many industries used to have a simple model for making profit, a good or service was offered and if users liked it an opportunity to make money would present itself.

This simple model involves a degree of risk that you may misjudge what users want or not be able to fully realise potential sales or interactions.

Technology companies realise that a digital marketplace offers a unique opportunity to monitor and react to users activity, they realise that this data can reduce risk and uncertainty and allow users likes and dislikes to be predicated and measured.

This combined with the potential to rapidly deploy change into production provides a unique opportunity for test and learn, to be continually taking advantage of marginal gains.

This mindset assumes things could always be better, not necessarily by introducing new features or functionality but by monitoring and improving what is already being made available to users.

Leader Alignment

Technology companies are attempting to leverage engineering skill and expertise to deliver profits and growth, they see this as their number one skillset that shouldn't be degraded by any other concern.

To facilitate this they ensure the leaders and decision makers within the business are aligned to their engineering operation and that they have a technological view point combined with an experience of delivery.

This means that they act as guardians for the integrity of engineering practices within the organisation and maintain standards regardless of the pressures to implement change.

This isn't to say that engineering is conducted for engineerings sake, ultimately the needs of the business still need to be fulfilled,  but once a commitments is made to construct something then the quality of the engineering employed is not a variable in the process.

Non-technology companies view the engineering function with their business as purely a production line of change that can be scaled and and manipulated easily to deliver any functionality in any time scale.

Engineering quality takes a back seat to the need to deliver and quality is a lever to be adjusted rather than an absolute.

Whether or not you are a technology company or a non-technology company as presented here is not a matter of being right or wrong. Its possible for a company to offer a digital marketplace whilst still only considering it one avenue to attract users but not the only one.

Its possible to develop software but not to feel the need to become a technology company, but if you decide to embark on attaining that label ensure that the mindsets and attitudes within your organisation understand what it takes to achieve.

Certain practices need to be let go and others need to be embraced, trust needs to be placed in engineers as well as an appreciation for what they offer your business.

Nobody should be expecting to mature into the next Amazon or Google but this is simply a degree of scale the practices and principles are universal. 

Micro-World

Modern development philosophies represent a campaign to divide our code bases into ever decreasingly sized chunks. Referring to micro-apps, micro-services even nano-services has now become common place when describing a target architecture.

So why do we think less is more? Is this simply a practice of trying to devise ways to have smaller and smaller blocks of distinct functionality or are the benefits of this way of thinking only realised with slightly more subtle thinking.

As with most schools of thought employed within software engineering there are shades of grey, while micro-services and micro-apps aren't a silver bullet they do represent an approach that can have a positive impact on your code.

Solidly Decoupled

Regardless of whether or not you are following a micro approach presiding over a loosely coupled code base is a desirable situation to be in.

The ability and likelihood of code conforming to SOLID principles will be inversely proportional to its size, that isn't to say that its impossible to have a large well structured class but it is certainly harder to achieve.

Source code isn't an asset where its value increases with its volume, the more code you write the more technical debt you are probably incurring so anything that results in dealing with smaller areas of code at any one time is likely to be a driver for improvement.

Adopting a micro approach will naturally encourage you to think in this decoupled way. Thinking about how to make a piece of functionality self contained and independent will promote an adoption of single responsibility, open-close and interface segregation while dependency inversion will likely be a tool to help you achieve the necessary decoupling.

Drivers For Change

A major reason for employing a micro philosophy is to take a more agile approach to implementing change. Whilst this may seem an obvious advantage its effectiveness is reliant on understanding the drivers for change within your business.

The nature of some changes to a system maybe purely technical but the majority will be as a result of a required change in functionality needed by the business.

This requires a balancing act between drawing up dividing lines based solely on technical concerns, to create the smallest most self-contained micro apps or services, and having an architecture that mirrors the business your software operates within.

The nirvana that is the goal of this approach is for these views to converge causing the most efficient configuration of your software to happily match the requirements of the most frequently altered areas of your system.

This will likely lead to different levels of granularity based on whether the concern of the code you are looking at is purely technical, for example a cross-cutting concern such as logging, or more business related, for example order fulfilment.

Again, regardless of whether or not you chose to adopt a micro architecture understanding the business your software serves is no bad thing.

Micro Deployability

When you first embark on dividing your code into micro-apps or micro-services then the initial natural view point is on the code itself.

However at least equally important, and potentially more important, is the ability of these new micro elements to be deployed independently.

Whilst it is possible to realise many of the benefits described here while still deploying your software as a monolith, the agility of your team to affect effective change for both your users and your business will be severely curtailed if your micro-apps or micro-services cannot be deployed in isolation.

Achieving this acknowledges that different areas of your code base exhibit differing speeds of change, it also acknowledges that certain areas have a criticality to your business that means you must have the ability to fix them the instant they are being less than effective.

Implied in both the above points is that your system must also be sufficiently composed as to allow the performance of different areas to be monitored independently.

A micro way of thinking should influence every area of your development from the code itself, to its deployment to the monitoring and management of the functionality it implements.

Architectural buzz words or new paradigms may come and go but well organised code exhibiting SOLID principles will always be in fashion. In this respect micro-apps and micro-services are not a fad, they are a natural extension to these time honoured approaches to software development.

It can be more subtle then simply trying to compose your system of an ever increasing number of distinct elements but a goal of decomposition and de-coupling will not steer you far wrong.