Talking bluntly doesn’t make you an asshole
In-fact, chances are, whoever you’re blunt to will appreciate it more.
Whether you are talking to clients, stakeholders, your boss, or a colleague. At some point you will be asked a question that directly relates to work that you have been doing, and the answer to that question will be one that you think shines a bad light on you.
If you can’t give an honest answer to that question, you will end up making the situation worse 100 percent of the time.
One of the biggest reasons that companies turn to DevOps are they they do not feel that their expectations are managed properly by their IT teams. Whether that relates to volume of work, length of the work itself, or just poor communication in general. The fact that businesses are outlining these as company wide problems is huge. And understanding what businesses want out of you within this new culture is a great way to make your stamp on a company and leave a lasting impression.
The best thing (in my mind) that has come out of the culture switching that is being seen over last few years is that it’s okay to be an asshole.
That doesn’t mean that you can turn up to work, and actually be an asshole to the people you work with. But rather that you’re okay to be brutally honest about your body of work. If you’re feeling down about a current piece of work, let someone know, don’t do the ‘the end is in sight, so I can put up with it’ facade. Being unhappy with your work tends to mean that the quality of your work drops, and that ends up being a slippery slope when it’s the quality of the work itself that is making you unhappy. When the project inevitably overruns, you’ll be too far into the rabbit hole to turn back.
Companies are starting to truly value time spent on non-deliverable pieces of work. Refactoring code ends up saving time (and money) in the long run when the next piece of work on that product comes around and people can actually follow the code inside it. If you don’t like how something is coded or how it looks then the best time to ask for a refactor is during the messy work itself; While the coding standard and the business rules are fresh in everyone’s head. If you can demonstrate the actual value in refactoring and cleaning up work product then the refactor work will (hopefully be approved). It isn’t going against your colleagues to try and increase standards and they won’t look at you in a lesser light for it either.
These talks (while all doom and gloom sounding) are all vital to getting the best workplace possible for you. Making your opinions known is crucial into helping your company develop their new culture, even if your opinions are voiced via little mentions inside meetings, stand ups and retrospectives. Its the idea of getting them into an open forum that will help drive the company and your career forward.
Your bosses aren’t wanting a political answer any more. They don’t want to hear how well your terrible project is going while you work overtime every day to make up for your lies. They want the truth. And in the end, everyone will be better off for it.
