Managing Priorities — The “Now” Struggle.
The “Now” in a organisation is always a struggle. It is a complex system with conflicting priorities, rigid organisational structures, frequent directional changes and implicit goals. It can be fun in great organisations or a dread in mediocre ones. In such a system, very often then not work is mostly driven by immediate managers needs or the loudest voices or incidents severely impacting the business. This becomes the norm and the important aspects of building the right capabilities which help organisations navigate these complexities never get prioritised.
Any organisations goal is ultimately to run the business well, grow and keep customers happy while doing so. These outward looking goals tend to be the most important in many organisations.
Can an organisation, a complex and chaotic system deliver on these goals without the capabilities to navigate such complexity & chaos ? In many organisations running the business means getting things done fast no matter how and so fundamental aspects of their own well-being gets little or no importance. Inward looking goals like culture, people and their growth & technology capabilities become implicit goals due to lack of organisational focus and impetus.
Ideally, running the business well means the ability to make meaningful impact on both outward and inward looking goals. Better outcomes on inward looking goals result in happier, commited and better performing teams. These capabilities help achieve the outward looking goals. Sometimes though, even with balanced intentions and focus on outward and inward looking goals, the decisions made along that journey leads many into unexpected destinations and when it does the inward capabilities that an organisation has built helps course correct faster.
This struggle is true for both startups and medium-big-enterprises. Startups tend to underestimate infra-ops and treat Operations engineers as support engineers for developers while enterprises struggle with alignment and collaboration with too much centralisation of functions, rigid structures etc.
How can we build these capabilities in an organisation then ? In my experience, you cannot fix any one problem in a silo. For instance, if infra-ops teams are a bottleneck and ill-prepared to build and manage infrastructures for todays complex IT environments, you then need to review all interactions of this organisational unit with the environment including Management, Dev, Product, Sales & Support etc as the problems are usually systemic in nature. The lack of alignment is because of the incapability to create a system where work happens colloboratively and constructively between the various engineering groups.
James Clear, in his book Atomic habits says that goals define a target but a system of small improvements helps us get there. This system of small improvements are habits that teams inculcate and follow everyday. Here are some examples between good and bad habits in a organisation with software delivery & reliability issues.
- (bad) PMs write business cases, Devs code for 2+ weeks and few days before the launch infra-ops teams are involved and require new rabbitmq clusters giving no time for ops to code the infrastructure and results in very transactional work for ops teams with no meaning vs (good) PMs write business cases and gets Dev & Ops involved , everyone understand the outcomes, ask questions , activities are planned, changes incoprorated into the plan, Devs code & write test cases, Ops write code & tests to provision infra, monitor , collect metrics etc and ensure best practices are implemented and on launch day everyone is ready.
- (bad) Changes are pushed to production services continuously with a automated pipeline with inefficient or without any CI, change management and peer review practices and without any notifications to stakeholders and so any production degrade is a surprise vs (good) Investing time in CI & quality tests, Involving ops and following simple change management practices such as publishing changelogs with impact, change & rollback steps, peer review, deploy, watch the health of the service and colloborate as necessary.
I can go on with many such scenarious and they all boil down to poor engineering culture within the organisation.
So, where do we start to fix this ? Any process of improvement begins with realisation and acceptance. In infra-ops terms, they are
- Operations Engineering is equal to Software engineering in all aspects. It is not a support role for Developers.
- Workflows are mostly waterfall , Planning & prioritisation practices currently employed is dysfunctional and is causing surprises to teams involved in the delivery chain.
- Isolating software developers from infra-ops is an anti-pattern. Just how Operations engineers have learned to code its time for Developers to at the least understand infrastructre stack. See Charity Majors tweet storm and grasp why.
Solution to these problems is usually a cultural change. As a start, we need to change how the teams deliver outcomes, build self sufficient teams w.r.t skills, give them a high degree of autonomy and provide direction & visibility into business goals, help them craft SLOs and let the teams balance priorities between features and capabilities such as tooling, reliability, resilience etc.
Cultural change is hard , it’s a struggle but not impossible. As leaders, we need to encourage & enable the teams to become slightly better every day. To quote James Clear,
“The 1 Percent Rule states that over time the majority of the rewards in a given field will accumulate to the people, teams, and organizations that maintain a 1 percent advantage over the alternatives. You don’t need to be twice as good to get twice the results. You just need to be slightly better.”
This is how many ops teams operate, constantly conflicted, stressed and never finding time for the activities that make them or the services they manage better.
Building capabilities or being slightly better cannot be an implicit goal. Leaders need to be explicit and help the teams balance the priorities.
An ideal way for teams to prioritise is to balance between various work activities that enable them to consistently improve the quality of services they build and manage.
This is a very simplistic representation of a prioritising system that helps improve capabilities of both people (1:1s , Hiring , Retention) and Technology (Repeatable & Operable). The general idea is to invest time to be slightly better than wherever you are now.
Practical examples would be to allocate few days more to automate a manual process instead of trying to meet a deadline by cutting corners or address alert-fatigue by removing noise instead of ignoring them.
Commit to a process that helps balance the available time between various activities, make everything you dislike slightly better, keep at it everyday, its a struggle but well worth it in the long run.
To conclude, a 1% improvement everyday results in 37% improvement over a year while the inverse or inertia makes you worser.
1.0³⁶⁵ = 37.8
0.9³⁶⁵ = 0.03
