Overall, I’ve found that I continually push for a lot of things that don’t easily fit nicely into a technical checklist or well-defined process that are easier to articulate. When discussing this with a peer, they made the observation that these were more like long-term visionary points or core values that I care about. I collected these one-off points in an unordered list for about six months before I tried to categorize them for this article. Here is what I believe is needed to have a well-oiled machine.
Everyone should understand how their work adds business value
Starting with company goals and objectives, leaders and managers should go through a cascading goals exercise to tie individual and team goals into the overarching goals. Some teams will be easier than others, and some cascaded goals get fuzzier the further out you try to plan, but that’s okay. The exercise is less about having firm goals for 12 months, and more about teaching your teams to understand the ‘why’ in their day-to-day work. I don’t want order takers anywhere within Technology.
People should be empowered to ask questions up front to know what business value is added by the request / work, and be able to challenge the requirements if they have a better or faster way to achieve the same or more value. This does require engineers and others in technology to truly understand the business itself, which is another benefit. The more shared understanding that exists, the more new ideas or different ways of working will surface, and feedback loops between groups will be reduced.
Not sure if I read this in a book or heard from a colleague, but I like using some variation of this phrase: “If I ask you to do something and you do it, if it turns out to be a bad idea, it’s on you, not me.” Setting this type of culture ensures that people understand what they’re working on and have the right level of ownership of the work and outcomes.
Make everything obvious
Sitting on top of Technology allows me to watch how different teams operate on a broader landscape, both within and outside of Technology itself and I spend a lot of time working to “make things obvious” across the company and within individual teams.
One primary goal is reduce decision atrophy and allow people to focus. For example, one company I worked at had four different ways to request IT support. How are our stakeholders supposed to know which method to use? What types of requests should get reported in one tool vs another? Which support team do they actually need to resolve their issue quickly? This decision friction could mean that they freeze and decide against asking for help at all, or they ignore all of them and just reach out to an individual that helped them previously, which isn’t scalable long-term. To solve for this, we decided to consolidate to a single tool and a single method of asking for support. The tool collects the information we need and automatically routes the ticket to the right support team, giving us one simple way for anyone to reach out about any topic. Spreading the work around like this leads to a second important point.
We should not have a single go-to person for anything. We should proactively work to remove “tribal knowledge” wherever it is. If you feel like you’re the only person that could troubleshoot a particular issue, pair up with a teammate and show them how to do it, or better yet, walk them through how to do it themselves. This knowledge sharing can also be in the form of documentation as well. Write down how a certain process or task occurs and let the next person follow, and more importantly, modify/update your documentation. Rinse and repeat. One nuance with documentation is that we should avoid writing anything that will be out-of-date very quickly. If whatever process or steps evolve quickly, use the documentation to highlight those types of changes and where someone could find the latest process, whether that’s a specific team to reach out to or link to a script that contains the technical steps.
Making things obvious also applies to your internal architecture and applications. The architecture should make it obvious which teams, languages, and tools to use for particular types of work. The teams should have similar sprint rituals and processes to allow cross-functional work to go smoothly. We should have well-known meaningful naming conventions and tagging so it’s clear what each part of our ecosystem does. We should have common logging and observability tools for easier triaging of issues. We should have one way to bring data into our data lake, one way to prepare that data for our warehouse, one way to visualize data, and one way to alert on anomalies. I think you get the picture.
Strive towards long-term sustainability and maintainability
Last, but not least, I’m continually looking for how to make everything we do more sustainable and maintainable for the future. This often manifests itself in standardizing our processes, automating repetitive tasks, and simplifying our technology overall (I’m a member of the Boring Technology Club).
When looking at our processes, I like to let teams evolve on their own and then have a monthly or quarterly checkpoint where managers across teams share any recent changes and how they are going. We then take those ideas back to each team to recalibrate and standardize around the best ideas. I generally like processes to be very lightweight and not get in the way. I’m constantly avoiding implementing new processes that come out of post-mortems or retros. While the suggestions are genuine and will help resolve whatever issue occurred, new processes will add up quickly and become bureaucratic in the long run. In general, we must be able to acknowledge that mistakes happen and do what we can to prevent the same mistakes from reoccurring, but with the awareness that we’re not trying to be perfect and prevent all mistakes.
Seeking out repetitive tasks can sometimes be more difficult than you’d expect. I’ve found that some people don’t consider what they do “repetitive” or don’t do it often enough to feel the need to automate it. While there is a cost of automation to be considered, automating isn’t just to do something faster. It’s to perform the steps in the exact same way each time, reduce manual errors, allows others to execute the automation, and documents the process in code. Automation should be prevalent and part of the culture. People should not fear their work being automated, they should look forward to handling more creative challenges.
Simplifying technology can be more of an art than a science. It’s keeping a close eye on your ecosystem as it grows and making sure each piece fits into the overall puzzle well (and sunsetting orphaned technology along the way). It’s maintaining consistency in our languages, tools, environments, and release processes. It’s making everything as easy and straight-forward as possible. If a release can be a single button to push, automate (and standardize) the pipeline and add a button somewhere for people to press (or build a command to initiate the release via ChatOps). It’s avoiding fancy code that will be harder to understand later. It’s building your infrastructure in a way that you can delete and recreate everything from scratch easily.