As organisations are finishing the last quarter of 2021 and as we put all our heads together and try to compose the plans, roadmaps and strategies for an upcoming year. We must remind ourselves not just what we want to achieve; but how will we get there. As planning is important and needed, so are discussions around the essentials for growth and continuous delivery of business value.

With that intro, I’ll try to illustrate what I consider to be a few key topics that often get overseen, forgotten or intentionally left out of conversations as it is tough to justify “investment” in those areas as they don’t immediately show up on your fancy ROA/KPI/OKR dashboards. Especially compared to excellent and shiny new features that “customers would really like”.

Complexity

One of the first “pillars” that often start shaking, crumbling and cracking is the “complexity”. It is this tiny side-effect that happens when you engineer for the future that never happened. That little library you added does just one thing, yet it pulls in the universe of other dependencies that do god-knows-what. This combo of 100+ micro-services that you really really needed as you had big FOMO when you’ve read brilliant HackerNews PR. But now you have to deploy them, version them, evolve them, fuse them and retire them (Hello, Systems Development Life Cycle)… Then there is this organisational complexity; as your product, team, and company grow, so does the number of people, number of “papers”, number of stakeholders - tables are bigger and harder it is to move swiftly and nimbly.

Another scary thought that should cross your mind when thinking about complexity should be this. Every day that passes every engineering hour spent, it’s spent on building “something”. Is this “something” the right thing? Is this the right thing for “now”, or is this the right thing 2, 3, 5, 10+ years from now? The longer the answer, the more scared you should be. Fight the complexity with good problem definitions, clear goals and continuing “simplification” across the board.

When talking and reasoning about complexity, arm yourself with “time measurements”; log or count hours wasted on the support of features, count hours lost because X needs to happen or be done before Y can get to “production”. Don’t forget to also account for things like “how long it takes for me to find information about Z”… In general, also make sure that people understand what is needed and why.

Tech-debt

That brings us to the second pillar that will destroy morale, plans, deadlines and, in not-so-few cases, bring down the whole organisation. Every serious project has it, every organisation has. It is this fella that few like to talk about it, or if they talk about it, often gets blamed for a lot of delays and “that’s just freaking impossible!” - excuses.

Sure, you can build another patch. Then another patch. Then a hack on top. Then you can tweak the UI so that the progress bar stays on the screen for just a few seconds longer. You can also extend the timeouts to minutes on your load balancer so that the service can “digest” the payload. You can also wrap the whole service with another service and then treat it like a plague.

All these improper solutions are indeed buying you time, and in many cases, that is an essential commodity, especially young products.

However, make sure that you keep track of all these “hacks”; treat them as “loans” because the time will come when you will have to settle the debt. And if you don’t. It will cripple you and your organisation. Tech debt is a risk, and especially if you are in “managerial” position, you need to keep track of it.

Discuss it. Document it. Explain to other engineers why certain things are done in “shady ways”. Talk to management about it - in terms that will be familiar to them - loss of revenue, downtime, long development cycles, errors, bugs and fire.

Resources

One of those pillars that are kind-a obvious and could also have different names - “assets”, “people”, “infrastructure”, “things needed to build things”… And we often plan or discuss this in terms of the future - we need to hire 50+ more engineers, we need to hire 20+ data-scientist, we need to expand our cloud budget, buy new SaaS service subscriptions etc.

Let’s spend more time thinking about how we will retain existing people, leverage existing services, and utilise our resources in more efficient ways.

From the perspective of risk, it is likely less risky to enrich existing experts who know your domain with additional knowledge than getting new ones - especially in current times. Equality with technology - new technology means you’ll have another “dragon” in your stack that you likely don’t know how to tame.

I suggest spending some serious thinking time on your current resources and elevating their value and performance.

Experimentation

I love this pillar. It has a particular smell, a specific scent some might even say magical appeal. Yet I’ve seen so many examples where organisations forget to do it - or be more explicit; they restrict experimentation and innovation so much that it becomes “business as usual”, some might even say forced. Sure, you’ve been on those “we must invent something” meetings? Right?

I want to encourage you to provide a framework and genuine support for plainly “doing things that have not been done before” and individually guiding people’s goals towards solving the problems that resonate with your organisational vision and challenges.

As an engineer, challenge your management with questions on how the company plans on innovating and competing? As managers think about how much time and resources you can give for such activities, how can those tiny ideas turn into more prominent solutions?

Conclusion

There is more than just four pillars to every organisation, project or product. There are also things such as priorities, budgets, sales and many many more… However, I think that keeping these in good shape will likely help your engineering stay on top…

Tell me, how healthy are your tech pillars? 🏛

This post was originally published as an article on my LinkedIn profile.