Click here to read previous retrospective entries.
From Steve Jones (blog | Twitter) in December 2010 comes the question “What issues have you had in interacting with the business to get your job done?”
However a little digging showed that the business didn’t really understand the technology. They were asking for a result, and [the DBA] took them literally in how [they] implemented a process. A classic impedance mismatch.
One of the key skills of a senior technologist — which might come as a surprise to someone just starting out in this industry — is the ability to listen. In my younger days, first as a network technician and later as a network administrator, I would hear a lot of requests from my colleagues that were focused on their particular workstream. In other words — and through no fault of their own — they would only provide the requirements of their particular problem, without contextualizing it as part of the larger organization.
By way of example, this would be a software developer requesting full administrative access to a production environment to do a deployment. Best practice says that’s a terrible idea, but in that particular developer’s mindset everything they’ve tried can only be solved by admin rights, because they are locked out of everything by some arbitrary company policy. An exhausted network administrator passes on the admin password and forgets about it. Word gets out to the other developers; the stumbling blocks preventing them from doing their job means that the admin password is handed around their department, and suddenly a rogue click on a phishing email results in a company-wide malware encryption attack because one developer happened to have system administrator privileges on the same network as the database and accounting systems.
This is just an example, but it speaks to a problem where siloed departments impede the work of others. DevOps is one way to tackle the issues of communication and responsibility between development and operational teams, but what it really comes down to is communication. One team has a problem and they need it solved. They think about it and decide the only way to fix it is administrative access. Instead, by speaking to the folks in operations and explaining what they’re trying to do (and of course a willing ops team prepared to listen and help), they can come up with a compromise where deploying to production is broken up into different stages, where each stage is automated and has a way to roll back (or roll forward) in case of a problem.
Bringing this back on topic, I have had several occasions where management (whether it be my own employer or a consulting customer) might have heard a term in the news and decided that they must implement it immediately, without understanding the ramifications. A junior technologist might say “sure” and do it because they want to keep management happy. I would frame it in a way that tries to understand why. One of the greatest questions in my consulting toolbox is “What problem are you trying to solve?” If a company wants to implement a blockchain because they heard about it on the news, I then ask what their threat model is. What is it they’re trying to secure? What is their current information security solution? Are they employing defence in depth? Will a blockchain (or in more palatable terms, a decentralized append-only cryptographic chain) actually solve something? (Hot take: it does not.)
Then my job as the highly-paid expert in my field, is to guide them into making a decision that is a better fit for their environment. Perhaps they just need a password manager. Perhaps SQL Server is in fact a better fit than Oracle for running their payroll software. Often it might require a proof of concept, and I happen to be good at those. I have saved at least one organization millions of dollars per year in cloud costs, by doing analysis and (usually minor) performance improvements of their implementation.
If your manager asks you to do something that sounds like it might be a thing they heard on the golf course or on Twitter, don’t be shy to ask why. If you need to, you can couch it in terms of security or maintainability. Then, build a proof of concept to see if it works. One of the great things about experimenting is that you can figure out quite quickly if it is the wrong way of performing a task.
It definitely pays to listen, though. By listening and asking questions, you can figure out what the business actually wants — not what it asked for — and, speaking for myself, save them a bunch of money as well.
Photo by Brett Jordan on Unsplash.