Principles to Shape your Tech

The famous Emerson quote “A foolish consistency is the hobgoblin of little minds” is one that comes to mind all too often when working with established teams. The reframe “That’s how we’ve always done it” or “The standards say how we should do that” seems to hold teams back from questioning their current viewpoints and moving past them. We don’t want to argue that standards are all de-facto bad, but like the old Agile principles, we value Why we do things more than How we do things.

Valuing the Why over the How in our opinion fosters creativity, varying expression and more elegant solutions to problems. For example many many many years ago the fad of N-Tier architectures made its way into company standards, and for a period statements like “Your design must contain Presentation, UI, Business Logic, Data Access and Data Storage layers” were codified . Now when the team whose job it is to create some basic functionality takes weeks and tens of thousands of lines of code, we start to see the problems with defining rigidly How teams do their work.

We want the team to be able to choose how they work, because they have all the context available to them to make choices relevant to what they are creating. To do this though we still need to provide them with some guidance. That guidance can be defined as a set of principles, Each containing a Rationale to elaborate on Why the principles are important, and some implications as examples how that might impact the way you work but are not prescriptive.

For example we have a principle entitled “Automate Everything” which has the rationale…

“Automation will reduce cognitive load for the mundane everyday tasks and allow you to focus on the new and interesting problems. This is closely linked to Facilitate future you.”

Some of the implications of Automation could be…

• Human errors: Manual tasks will inevitably suffer from human errors occasionally.
• Difficulty diagnosing unexpected behaviour: Automated processes offer a higher visibility into what went wrong through logs, monitoring and a myriad of capabilities available to us. That makes time to recover much quicker and the process less stressful.
• "How do we do this again?": Humans are forgetful. When something happens infrequently we are prone to forgetfulness and sometimes that would require us to do our research all over again before any bells start ringing.
• Time waste: Linked to the above, this could lead to a lot of wasted time having to solve the same problem over and over again every few months.
• Knowledge silos: Chances are, you haven't built the entire product yourself which means there are bits of knowledge spread across the team. When things are automated then that knowledge is documented somewhere. Otherwise, it exists solely in someone's head.
• More difficult onboarding: Closely linked to the above. When you have a new member joining, it can be an excruciating process trying to extract all the knowledge from everyone's heads. When Things are automated then it's easier to understand what's going on which helps the new teammate hit the ground running much quicker.

Hopefully you can see this doesn’t stipulate what should be automated (e.g. your build and tests) or how it should be automated (e.g. via GitHub Actions, or Shell Script) but still should drive teams to remove the cognitive and time load on repetitive tasks.

What impact has this had for us…

Culture

When people are focused on delivering an outcome, they can figure out the best way to get there. There’s a deep sense of empowerment, autonomy, pride and ownership in the work that we do. It’s very much shaped by us as a collective instead of prescribed by a few.

Hiring

Being a software engineer requires a great deal of creativity. Dare I say that’s one of the most enjoyable parts of the job. Some organisations see developers as executors of a playbook designed and laid out a few levels removed from the actual team on the ground that deals with the ins and outs of the systems at play and the customers they’re serving. That can be stifling and how the term “code monkeys” probably came into existence. Providing a place to work where we’ve eliminated the extra bureaucracy and put the power back in the hands of the teams themselves has allowed us to attract individuals that are passionate about what they do and those are exactly the people we want to have onboard.

Clients

Being aligned on principles and ethos fosters trust and keeps us nimble. Our clients appreciate the flexibility this approach gives them as they know and trust that we have their best interest at heart. Focusing on outcomes assures them that we will pivot and make the necessary changes to meet their changing needs as the markets fluctuates.

We’ve written quite a few of these principles, which you can find (https://deliberate.uk/handbook) here in our handbook. If this approach interests you we urge you not to take ours wholesale, use them for inspiration. Start to look at why you do things, extract those as principles if they do make sense, question them if they don’t.