On Negative Examples
Finding examples of things you want to mimic is great… but looking for examples of things you’d like to avoid (good and bad) is also important.
To preface this piece - negative examples are about finding attributes, outcomes, etc. that you choose to avoid, not necessarily things that have failed.
Frequently we look around a good example of what we want to do. We find some project, or team, or event that was insanely successful and point at it as a model to follow. This is a great approach since we can learn from that things success, and then build on it. It is, however, also important to find negative examples - things that didn’t go the way you want, or things you don’t want to do - to learn from. These both teach you what can go wrong, but also help provide a better definition to the shape of what you want.
Filling in the edges
Just like how negative space in artwork can define interesting shapes (or even the artwork itself), negative examples at work help us define our outcome. They allow us to look at another project/outcome/team/whatever and make more informed decisions on how we want to operate. As noted above, this doesn’t necessarily mean those projects/outcomes/teams are not effective or working properly… just that you choose a different route. Some examples:
Methodologies - Agile project management makes a lot of sense…. In certain circumstances. Many projects, however, will not benefit to the same degree, and some may even suffer. Watching another project struggle with the wrong methodology can serve as an example for your work, and what to avoid.
Team structure - How teams are setup differs widely, both between and within organizations. Looking at other orgs will help you determine the shape of yours. Maybe the People team has a great structure that’s super successful for them, but for some reason wouldn’t work in Engineering. Noting that difference, and being able to point out why it wouldn’t be good for your team, will help avoid
Documentation - While there are some more standardized ways to document material, at some point it comes down to specifically how a team operates, and choices they make in cataloging information. Understanding why another group’s decisions wouldn’t be the best for your needs will help you better shape what would be best for you.
When finding negative examples it is important to keep any judgement of good/bad or any blame out of your assessment. The intention is to help identify what the best solution for your particular need, not to pass judgement on how someone else operates (which may be best for them).
Trust. But Verify.
Trust what you’re seeing/being told…but always verify it with your own testing.
One of the favorite things I’ve learned working in IT is to “Trust. But Verify”. I find it especially helpful when I answer support tickets as users are frequently either mistaken about what they’re seeing (an ambiguous error message), or unable to provide all the information (e.g. they don’t realize they’re missing permissions). To me it means that I trust that the partner or customer I’m working with is giving me their best possible info, but that I still need to back it up and look into it myself. Pulling up the floorboards this way not only helps me determine the root cause of whatever’s happening, but also helps me learn about systems and processes in new ways.
Generally I don’t say “Trust, but verify” to the folks I’m working with (although I do use it in mentoring/coaching sessions to help folks get in the mindset of validating everything). Instead I have a number of variations I use, things like
“Prove it” - Generally more in teaching situations where someone tells me they have the answer / they’ve done something cool. I use this phrase to challenge the person I’m working with and see if they’ve really done what they think they’ve done. Also something I only really use with folks who know me and won’t be put off by the wording.
“Can you walk me through what’s happening?” - The more user-friendly version of “Prove it”. Everyone in IT know folks tend to report only small portions of what’s going on, this helps uncover the underlying pieces. It also helps my partners learn the process a bit better since they have to go through it a few times so I can understand it better.
In addition to answering support tickets, this phrase is also great when performing any kind of systems analysis. Frequently what I see isn’t what you get (the opposite of WYSIWYG). I’m finding this to be especially true as I navigate new systems (like Workday) that have underlying architecture or concepts I am unfamiliar with. Simply accepting what I see is a wonderful way to setup myself up for failure! In the same way I trust that my partners are telling me the best info they have, I have to trust that my current understanding is the best one I have at the time. I’m finding I cannot stop there though, I have to dig in deeper to verify what I think I see or know. This might take the form of reading up on documentation (everyone’s favorite past time!), or if I’m lucky asking a teammate who knows more than I do for help.
Every so often I give myself a reminder of this and forget to verify…. this usually results in a bit of rework as I have to go back in a fix things, but the silver lining is I both reinforce this lesson and learn the process a bit better. As a result I’ve found I constantly remind myself to not only trust my own work, but followup and verify that it’s the best I can do.